Hi Yoav, Valery,

Valery is right that the IKE_SESSION_RESUME exchange does not have a protected payload.

But his new text is incorrect, since the (session resumption) ticket is sent in IKE_SESSION_RESUME and not in the immediately following IKE_AUTH (he might have got it mixed with the ticket sent when *requesting* a ticket). So I guess we should just replace "within the protected payload of the IKE_SESSION_RESUME exchange" by "within the IKE_SESSION_RESUME exchange".

According to http://en.wikipedia.org/wiki/Christmas#Listing, it's still more than a week until the Eastern Churches' Christmas. So Merry Christmas to some of us, and a Happy New Year to all.

Thanks,
        Yaron


On 12/26/2012 10:42 AM, Yoav Nir wrote:
Hi

I agree with point #2. I'll leave it to some of the session resumption experts 
to comment on point #1.

It's a little late for "Merry Christmas", so just happy new year.

Yoav

-----Original Message-----
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of 
Valery Smyslov
Sent: Wednesday, December 26, 2012 8:11 AM
To: ipsec@ietf.org
Subject: [IPsec] Error in RFC6290

Hi,

RFC6290 (Quick Crash Detection) contains an error. In Section 4.3 it states:

    For session resumption, as specified in [RFC5723], the situation is
    similar.  The responder, which is necessarily the peer that has
    crashed, SHOULD send a new ticket within the protected payload of the
    IKE_SESSION_RESUME exchange.  If the Initiator is also a token maker,
    it needs to send a QCD_TOKEN in a separate INFORMATIONAL exchange.

But IKE_SESSION_RESUME exchange, as specified in RFC5723, doesn't contain any 
protected payload - it is completely in clear and must be followed by IKE_AUTH 
exchange. I suspect this error came from early versions of IKE SA Resumption 
protocol that, as far as I remember, did contain protected payload. But 
currently this para should look like:

    For session resumption, as specified in [RFC5723], the situation is
    similar.  The responder, which is necessarily the peer that has
    crashed, SHOULD send a new ticket in IKE_AUTH exchange
    that immediately followed IKE_SESSION_RESUME exchange.
    If the Initiator is also a token maker, it needs to send a QCD_TOKEN in
    the same IKE_AUTH exchange.



And one more consideration. In Section 4.1 RFC6290 states:

    o  Protocol ID (1 octet) MUST be 1, as this message is related to an
       IKE SA.

    o  SPI Size (1 octet) MUST be zero, in conformance with Section 3.10
       of [RFC5996].

I think here we have contradiction with RFC5996 (despite clamed conformance 
with it). In abovementioned Section 3.10 it is written:

    o  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.  If the SPI
       field is empty, this field MUST be sent as zero and MUST be
       ignored on receipt.

Let me emphasize that RFC5996 clearly requires that If the SPI field is empty, 
Protocol ID field MUST be sent as zero and MUST be ignored on receipt, but 
RFC6290 while requiring SPI field to be empty, requres Protocol ID field to be 
non-zero. Actually, I see no value in this requirement, as Protocol ID MUST be 
ignored on receipt anyway (if SPI field is empty), so it just complicates 
protocol and makes it cumbersome.

Merry Christmas,
Valery Smyslov.

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Email secured by Check Point
_______________________________________________
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