RFC Errata
Found 10 records.
Status: Verified (1)
RFC 4302, "IP Authentication Header", December 2005
Source of RFC: ipsec (sec)
Errata ID: 134
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Vishwas Manral
Date Reported: 2006-01-12
Section 3.3.4 says:
NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire implementations, it will be necessary to examine all the extension headers to determine if there is a fragmentation header and hence that the packet needs reassembling prior to IPsec processing.
It should say:
NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire implementations, it will be necessary to examine all the extension headers to determine if there is a fragmentation header, and either the More flag or the Fragment Offset is non-zero. If so that packet needs reassembling prior to IPsec processing.
Status: Held for Document Update (4)
RFC 4302, "IP Authentication Header", December 2005
Source of RFC: ipsec (sec)
Errata ID: 744
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-01
Held for Document Update by: Pasi Eronen
(1)
RFC 4301, in section 13, "Differences from RFC 2401", in the
second bulleted item (near the top of page 73) states:
o There is no longer a requirement to support nested SAs or "SA
bundles". [...]
And later on, on page 74:
o Support for AH in both IPv4 and IPv6 is no longer required.
Therefore, the paragraph on page 10 of RFC 4302,
ESP and AH headers can be combined in a variety of modes. The IPsec
Architecture document describes the combinations of security
associations that must be supported.
^^^^^^^^^^^^^^^^^
entails more or less a "NOPE". If something like the second
sentence is still desired, it might better say, e.g.,
ESP and AH headers can be combined in a variety of modes. The IPsec
Architecture document briefly describes the methods to configure
such combinations of security associations.
(2)
On page 25, Appendix A1 presents a table classifying the IPv4 options.
Within that table, the second column is partially misaligned.
(3)
On page 26, the table within Appendix A2 classifying the IPv6
extension headers,
Option/Extension Name Reference
----------------------------------- ---------
MUTABLE BUT PREDICTABLE -- included in ICV calculation
Routing (Type 0) [DH98]
BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING
TRANSIT)
Hop-by-Hop options [DH98]
Destination options [DH98]
NOT APPLICABLE
Fragmentation [DH98]
perhaps would have better been formatted like:
Option/Extension Name Reference
----------------------------------- ---------
MUTABLE BUT PREDICTABLE
-- included in ICV calculation
Routing (Type 0) [DH98]
BIT INDICATES IF OPTION IS MUTABLE
(CHANGES UNPREDICTABLY DURING TRANSIT)
Hop-by-Hop options [DH98]
Destination options [DH98]
NOT APPLICABLE
Fragmentation [DH98]
to avoid the overlap of the columns.
(4)
In Appendix B2.1, at one place on page 30, the variable
"seqh" is mis-spelled as "seqH" (this is in the 6th-to-last
line of Appendix B2.1).
(5)
Appendix B, as a whole, is a [near] duplicate of Appendix A of
RFC 4303; the latter does not contain the typo from item (4)
above, and it contains extended and improved explanations in
the third subsection -- corresponding to page 32 of RFC 4302.
Readers and potential implementors need to read both Appendices
just to detect that they are in fact essentially the same spec.
IMHO, it would have been better to avoid this re-specification,
and instead have pointers to the (better, and mandatory!) ESP
Appendix placed into the AH RFC.
Having a single specification always avoids disagreement or
inconsistency, and it facilitates the maintenance of the spec.
(6)
Finally:
I would have appreciated the introduction of an explicit version
numbering for AH, e.g. rename:
AH as per RFC 1826 to AHv1,
AH as per RFC 2402 to AHv2 or AHv2.0, and
AH as per RFC 4302 to AHv3 or AHv2.1
(or similar).
This would make it easier to specify / identify versions and/or
version specific behaviour in implementations, without having
to refer to the RFC numbers explicitely. (Similar numbering has
proven very useful with protocols like BGP, SNMP, IMAP, POP, etc.)
It should say:
[see above]
Notes:
from pending
Errata ID: 1644
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2008-12-25
Held for Document Update by: Pasi Eronen
Section B2 says:
Appendix B2 says:
+ Case A: Tl >= (W - 1). In this case, the window is within one
sequence number subspace. (See Figure 1)
+ Case B: Tl < (W - 1). In this case, the window spans two
sequence number subspaces. (See Figure 2)
In the figures below, the bottom line ("----") shows two consecutive
sequence number subspaces, with zeros indicating the beginning of
each subspace. The two shorter lines above it show the higher-order
bits that apply. The "====" represents the window. The "****"
represents future sequence numbers, i.e., those beyond the current
highest sequence number authenticated (ThTl).
Th+1 *********
Th =======*****
--0--------+-----+-----0--------+-----------0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 1 -- Case A
Th ====**************
Th-1 ===
--0-----------------+--0--+--------------+--0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 2 -- Case B
It should say:
Must say:
+ Case A: Tl >= (W - 1). In this case, the window is within one
sequence number subspace. (See Figure 2)
+ Case B: Tl < (W - 1). In this case, the window spans two
sequence number subspaces. (See Figure 3)
In the figures below, the bottom line ("----") shows two consecutive
sequence number subspaces, with zeros indicating the beginning of
each subspace. The two shorter lines above it show the higher-order
bits that apply. The "====" represents the window. The "****"
represents future sequence numbers, i.e., those beyond the current
highest sequence number authenticated (ThTl).
Th+1 *********
Th =======*****
--0--------+-----+-----0--------+-----------0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 2 -- Case A
Th ====**************
Th-1 ===
--0-----------------+--0--+--------------+--0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 3 -- Case B
Notes:
Wrong numbers for figures in Section B2.
Errata ID: 1645
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2008-12-26
Held for Document Update by: Pasi Eronen
Section B2.2 says:
+ Under Case A (Figure 1):
If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th
If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th + 1
+ Under Case B (Figure 2):
If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th - 1
If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th
It should say:
+ Under Case A (Figure 2):
If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th
If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th + 1
+ Under Case B (Figure 3):
If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th - 1
If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th
Notes:
Wrong numbering for figures
Errata ID: 2157
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Carsten Bormann
Date Reported: 2010-04-10
Held for Document Update by: Sean Turner
Section 2.5 says:
anti-reply
It should say:
anti-replay
Notes:
(End of first para.)
Obvious, but maybe confusing to learners.
Status: Rejected (5)
RFC 4302, "IP Authentication Header", December 2005
Source of RFC: ipsec (sec)
Errata ID: 2188
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-30
Section 3.3.3.2.2. says:
If padding bytes are needed but the algorithm does not specify the padding contents, then the padding octets MUST have a value of zero.
It should say:
The padding bytes MUST be zero. The algorithm MUST NOT specify anything else.
Notes:
This is forced two times in this RFC4302, namely before in this
section 3.3.3.2.2 and in 3.4.4 .
--VERIFIER NOTES--
Section 3.4.4 deals with verification of the ICV, whereas section 3.3.3 deal with generation of an ICV. Thus discussion of padding is needed in both contexts and is not redundant. The text should remain as it is.
Errata ID: 2189
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20
Section 3.4.3. says:
received Sequence Number against the receive window. In constructing the full sequence number, if the low-order 32 bits carried in the packet are lower in value than the low-order 32 bits of the receiver's sequence number counter, the receiver assumes that the high-order 32 bits have been incremented, moving to a new sequence number subspace. (This algorithm accommodates gaps in reception for
It should say:
received Sequence Number against the receive window. In constructing the full sequence number, if the low-order 32 bits carried in the packet are lower in value than the low-order 32 bits of the receiver's left edge's sequence number counter, the receiver assumes that the high-order 32 bits have been incremented, moving to a new sequence number subspace. (This algorithm accommodates gaps in reception for
Notes:
--VERIFIER NOTES--
There is no mention of a "left edge sequence number counter" in 4302.
Errata ID: 2185
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2010-07-20
Section 2.4. says:
datagrams to SAs. Implementations that support only unicast traffic need not implement this de-multiplexing algorithm.
It should say:
datagrams to SAs. Implementations that support only unicast traffic need not to implement this de-multiplexing algorithm.
Notes:
grammar
--VERIFIER NOTES--
The original text is grammatically correct.
Errata ID: 2186
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Tim Polk
Date Rejected: 2010-07-20
Section 2.5. says:
Verification". Thus, the sender MUST always transmit this field, but the receiver need not act upon it.
It should say:
Verification". Thus, the sender MUST always transmit this field, but the receiver needs not to act upon it.
Notes:
grammar
--VERIFIER NOTES--
The original text is grammatically correct.
Errata ID: 2187
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Tim Polk
Date Rejected: 2010-07-20
Section 3.3.3.2.1. says:
(The padding is arbitrary, but need not be random to achieve security.) These padding bytes are included in the ICV calculation,
It should say:
(The padding is arbitrary, but needs not to be random to achieve security.) These padding bytes are included in the ICV calculation,
Notes:
grammar
--VERIFIER NOTES--
The original text is grammatically correct.