Hi, I think that’s fine. You are correct. I re-read the section.
Regards, Prashant -----Original Message----- From: Prashant Batra (prbatra) Sent: Friday, November 25, 2011 6:09 PM To: 'Valery Smyslov'; ipsec@ietf.org Subject: RE: [IPsec] Contradiction in RFC5996 Still I think not correct, What it tells is that, the initiator of the rekey is trying to rekey the child_sa indicated by SPI value in REKEY_SA notify payload. Not that, the sender of CHILD_SA_NOT_FOUND should copy the SPI sent in REKEY_SA to the spi in CHILD_SA_NOT_FOUND notify payload. Regards, Prashant -----Original Message----- From: Valery Smyslov [mailto:sva...@gmail.com] Sent: Friday, November 25, 2011 6:42 PM To: Prashant Batra (prbatra); ipsec@ietf.org Subject: Re: [IPsec] Contradiction in RFC5996 The question is: what should SPI field of a CHILD_SA_NOT_FOUND notification contain. From my reading of 2.25 sender of this notification should take SPI from the SPI field of received REKEY_SA notification and put it to the SPI field of CHILD_SA_NOT_FOUND: 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. Is it correct? Regards, Valery Smyslov. ----- Original Message ----- From: "Prashant Batra (prbatra)" <prba...@cisco.com> To: "Valery Smyslov" <sva...@gmail.com>; <ipsec@ietf.org> Sent: 25 ноября 2011 г. 13:52 Subject: RE: [IPsec] Contradiction in RFC5996 > Section 2.25 states- > A peer that receives a CHILD_SA_NOT_FOUND notification > SHOULD silently delete the Child SA (if it still exists) and send a > request to create a new Child SA from scratch (if the Child SA does > not yet exist). > > So it should delete that CHILD_SA by himself. > Regards, > Prashant > > -----Original Message----- > From: Valery Smyslov [mailto:sva...@gmail.com] > Sent: Friday, November 25, 2011 5:13 PM > To: Prashant Batra (prbatra); ipsec@ietf.org > Subject: Re: [IPsec] Contradiction in RFC5996 > > Yes, paragraph 3.10 gives a generic rule, that SPI field > in Notify Payload must refer to existing SA. And > CHILD_SA_NOT_FOUND indicates that SA doesn't > exist, so we seem to be not allowed to use it. > But, on the other hand, receiver of this notification > does have that SA (otherwise he/she wouldn't previously send > notification REKEY_SA), so the rule isn't violated. > At least, it could be interpreted not to be violated... > > But anyway, contradiction must be removed - either by addition > CHILD_SA_NOT_FOUND to the list of notifications > using SPI field (preferred way, IMHO, because it doesn't > break any running code) or by rewriting text about > CHILD_SA_NOT_FOUND notification directing to put SPI > somewhere else apart from SPI field (probably to notification data). > > Regards, > Valery Smyslov. > > > ----- Original Message ----- > From: "Prashant Batra (prbatra)" <prba...@cisco.com> > To: "Valery Smyslov" <sva...@gmail.com>; <ipsec@ietf.org> > Sent: 25 ноября 2011 г. 11:49 > Subject: RE: [IPsec] Contradiction in RFC5996 > > > 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