RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 10 records.

Status: Verified (1)

RFC 4306, "Internet Key Exchange (IKEv2) Protocol", December 2005

Note: This RFC has been obsoleted by RFC 5996

Note: This RFC has been updated by RFC 5282

Source of RFC: ipsec (sec)

Errata ID: 2279
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Sergiu Todirascu
Date Reported: 2010-05-19
Verifier Name: Sean Turner
Date Verified: 2010-07-21

Section 3.3.2 says:

          Name                     Number                 Defined In
          NONE                       0
          AUTH_HMAC_MD5_96           1                     (RFC2403)
          AUTH_HMAC_SHA1_96          2                     (RFC2404)
          AUTH_DES_MAC               3
          AUTH_KPDK_MD5              4                     (RFC1826)
          AUTH_AES_XCBC_96           5                     (RFC3566)

It should say:

          Name                     Number                 Defined In
          NONE                       0
          AUTH_HMAC_MD5_96           1                     (RFC2403)
          AUTH_HMAC_SHA1_96          2                     (RFC2404)
          AUTH_DES_MAC               3
          AUTH_KPDK_MD5              4                     (RFC1828)
          AUTH_AES_XCBC_96           5                     (RFC3566)

Notes:

The RFC for AUTH_KPDK_MD5 should be 1828, not 1826 which is the first version of AH.

Status: Held for Document Update (8)

RFC 4306, "Internet Key Exchange (IKEv2) Protocol", December 2005

Note: This RFC has been obsoleted by RFC 5996

Note: This RFC has been updated by RFC 5282

Source of RFC: ipsec (sec)

Errata ID: 2190
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner

Section 2.5. says:

Similarly, payload types that are not defined are reserved for future
use; implementations of version 2.0 MUST skip over those payloads and
ignore their contents.

It should say:

Similarly, payload types that are not defined are reserved for future
use.

Notes:

The behaviour of an implementation of version 2.0 depends on the critical flag. See next paragraph.

Errata ID: 2191
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner

Section 3.2. says:

whose type code appears in the first octet.  The reasoning behind
not setting the critical bit for payloads defined in this document
is that all implementations MUST understand all payload types
defined in this document and therefore must ignore the Critical
bit's value.  Skipped payloads are expected to have valid Next

It should say:

?

Notes:

Difficult to understand. More explanation needed:
An implementation of IKE which is older than 2.0 does not know about the
critical bit and will skip an unknown payload. This behaviour fits to
cleared critical bit.

Errata ID: 2192
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner

Section 3.3. says:

If there are multiple transforms with the same Transform Type, the
proposal is an OR of those transforms.  If there are multiple
Transforms with different Transform Types, the proposal is an AND of
the different groups.  For example, to propose ESP with (3DES or

It should say:

If there are multiple transforms with the same Transform Type, those
transforms constitute a group out of which exactly one transform is
to be chosen. If there are multiple of those groups, the proposal is
an AND of the choices out of the different groups.  For example, to
propose ESP with (3DES or

Notes:

Logically unclear. OR means AND/OR. But here you talk about XOR.
Furthermore has AND precedence before OR.

Errata ID: 2194
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner

Section 3.12. says:

identify the implementation as an aid in debugging.  A Vendor ID
payload MUST NOT change the interpretation of any information defined
in this specification (i.e., the critical bit MUST be set to 0).

It should say:

- delete it -

Notes:

According to 3.2 the critical bit has to be clear.
And the rest is trivial: To be compliant you have to comply.

Errata ID: 2195
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner

Section 3.15. says:

Some attributes MAY be multi-valued, in which case multiple attribute
values of the same type are sent and/or returned.  Generally, all
values of an attribute are returned when the attribute is requested.

It should say:

Some attributes MAY be multi-valued, in which case multiple
Configuration Attribute structures of the same type are sent and/or
returned.  Generally, all values of an attribute are returned when
the attribute is requested.

Notes:

The text may suggest that there may be multiple values in one
Configuration Attribute structure.

Errata ID: 1671
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Nikolai Malykh
Date Reported: 2009-01-28
Held for Document Update by: Pasi Eronen

Section 3.1 says:

       --  V(ersion) (bit 4 of Flags) - This bit indicates that
           the transmitter is capable of speaking a higher major
           version number of the protocol than the one indicated
           in the major version number field.  Implementations of
           IKEv2 must clear this bit when sending and MUST ignore
           it in incoming messages.

It should say:

       --  V(ersion) (bit 4 of Flags) - This bit indicates that
           the transmitter is capable of speaking a higher major
           version number of the protocol than the one indicated
           in the major version number field.  Implementations of
           IKEv2 MUST clear this bit when sending and MUST ignore
           it in incoming messages.

Errata ID: 1672
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Nikolai Malykh
Date Reported: 2009-01-29
Held for Document Update by: Pasi Eronen

Section 3.3.2 says:

      o  0 (last) or 3 (more) (1 octet) - Specifies whether this is the
         last Transform Substructure in the Proposal.  This syntax is
         inherited from ISAKMP, but is unnecessary because the last
         Proposal could be identified from the length of the SA.

It should say:

      o  0 (last) or 3 (more) (1 octet) - Specifies whether this is the
         last Transform Substructure in the Proposal.  This syntax is
         inherited from ISAKMP, but is unnecessary because the last
         Transform could be identified from the length of the Proposal.

Errata ID: 2196
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner

Section 3.15. says:

For some attributes (in this version of the specification only
internal addresses), multiple requests indicates a request that
multiple values be assigned.  For these attributes, the number of

It should say:

For some attributes (in this version of the specification only
internal addresses), multiple requests indicate a request that
multiple values be assigned.  For these attributes, the number of

Notes:

typo

Status: Rejected (1)

RFC 4306, "Internet Key Exchange (IKEv2) Protocol", December 2005

Note: This RFC has been obsoleted by RFC 5996

Note: This RFC has been updated by RFC 5282

Source of RFC: ipsec (sec)

Errata ID: 2193
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-05-07

Section 3.3.5. says:

         Attribute Type                 Value        Attribute Format
      --------------------------------------------------------------
      RESERVED                           0-13 Key Length (in bits)
      14                 TV RESERVED                           15-17
      RESERVED TO IANA                   18-16383 PRIVATE USE
      16384-32767

   Values 0-13 and 15-17 were used in a similar context in IKEv1 and
   should not be assigned except to matching values.  Values 18-16383
   are reserved to IANA.  Values 16384-32767 are for private use among
   mutually consenting parties.

   - Key Length

      When using an Encryption Algorithm that has a variable-length key,
      this attribute specifies the key length in bits (MUST use network
      byte order).  This attribute MUST NOT be used when the specified
      Encryption Algorithm uses a fixed-length key.

It should say:

?

Notes:

I do not understand anything.
Therefore I cannot offer a better formulation.
--VERIFIER NOTES--
No alternative text was proposed. Note that I did forward this to the authors of draft-ietf-ipsecme-ikev2bis.

Report New Errata



Advanced Search