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

Reply via email to