RFC Errata
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.