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

Reply via email to