Hi Valery I believe that you are correct. The text in section 2.25 clearly says that the SPI field is populated, while section 3.10 says that this field is populated only for INVALID_SELECTORS and REKEY_SA.
Section 3.10 was carried over from RFC 4306, while section 2.25 is new to 5996. The error is in section 3.10. Please file an errata on the RFC Errata page. http://www.rfc-editor.org/errata.php Thanks Yoav On Nov 25, 2011, at 9:34 AM, Valery Smyslov wrote: > Hi, > > I found some contradicting text in RFC5996. > > Section 3.10 describes Protocol ID field in Notify Payload and > includes the following text: > > Protocol ID (1 octet) - If this notification concerns an existing > SA whose SPI is given in the SPI field, this field indicates the > type of that SA. For notifications concerning Child SAs, this > field MUST contain either (2) to indicate AH or (3) to indicate > ESP. Of the notifications defined in this document, the SPI is > included only with INVALID_SELECTORS and REKEY_SA. > > On the other hand, section 2.25 describes using CHILD_SA_NOT_FOUND > notification and includes the following text: > > A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives > a request to rekey a Child SA that does not exist. The SA that the > initiator attempted to rekey is indicated by the SPI field in the > Notify payload, which is copied from the SPI field in the REKEY_SA > notification. > > From my reading, these two pieces of text are contradicting. > The first paragraph forbids putting SPI in SPI field of Notify > Payload for all notifications other than INVALID_SELECTORS and REKEY_SA, > while the second requires to do it for CHILD_SA_NOT_FOUND. > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
