RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Verified (2)

RFC 6290, "A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE)", June 2011

Source of RFC: ipsecme (sec)

Errata ID: 3448
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Valery Smyslov
Date Reported: 2013-01-09
Verifier Name: Sean Turner
Date Verified: 2013-03-16

Section 4.3 says:

   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.

It should say:

   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 QCD_TOKEN in the IKE_AUTH exchange
   that immediately followes the 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.

Notes:

Original text mixes up terms "ticket" (as Session Resumption ticket from RFC5723) and "token" (as QCD token from this RFC). As QCD token must never be sent in an unprotected message (see section 9.2 from this RFC) it cannot be sent in the IKE_SESSION_RESUME exchange because this exchange is done in clear. So, QCD token must be sent in the IKE_AUTH exchange that immediately followes the IKE_SESSION_RESUME exchange. In this case there is no need for the separate INFORMATIONAL exchange the Initiator's QCD token (if any) to be sent in, because it could be sent in the same IKE_AUTH exchange.

Errata ID: 3449
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Valery Smyslov
Date Reported: 2013-01-09
Verifier Name: Sean Turner
Date Verified: 2013-03-16

Section 4.1 says:

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

It should say:

   o  Protocol ID (1 octet) MUST be 0.

Notes:

RFC5996 (IKEv2) in section 3.10 while describing Protocol ID field in Notify Payload specifies that "If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt". As this RFC requires SPI field to be empty (later in section 4.1), Protocol ID should be zero to be consistent with RFC5996.

Report New Errata



Advanced Search