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
