No, in my understanding, we should not send SPI value in Notify payload telling CHILD_SA_NOT_FOUND. As the SPI sent by the initiator of rekey has sent wrong SPI, which the responder doesn't have. Thus, first paragraph states correctly.
Thanks, Prashant -----Original Message----- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Valery Smyslov Sent: Friday, November 25, 2011 1:05 PM To: ipsec@ietf.org Subject: [IPsec] Contradiction in RFC5996 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. Do I misunderstand something? Regards, Valery Smyslov. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec