Search RFCs

RFC Editor

Found 10 records.

Status:Verified (1)

RFC 4302, "IP Authentication Header", December 2005

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

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 thesecond 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 secondsentence 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 IPv6extension 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-lastline of Appendix B2.1).(5)Appendix B, as a whole, is a [near] duplicate of Appendix A ofRFC 4303; the latter does not contain the typo from item (4)above, and it contains extended and improved explanations inthe third subsection -- corresponding to page 32 of RFC 4302.Readers and potential implementors need to read both Appendicesjust 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!) ESPAppendix placed into the AH RFC.Having a single specification always avoids disagreement orinconsistency, and it facilitates the maintenance of the spec.(6)Finally:I would have appreciated the introduction of an explicit versionnumbering 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/orversion specific behaviour in implementations, without havingto refer to the RFC numbers explicitely. (Similar numbering hasproven 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

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 neededbut the algorithm does not specify the padding contents, then thepadding octets MUST have a value of zero.

It should say:

The padding bytes MUST be zero. The algorithm MUST NOT specifyanything 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 constructingthe full sequence number, if the low-order 32 bits carried in thepacket are lower in value than the low-order 32 bits of thereceiver's sequence number counter, the receiver assumes that thehigh-order 32 bits have been incremented, moving to a new sequencenumber subspace.  (This algorithm accommodates gaps in reception for

It should say:

received Sequence Number against the receive window.  In constructingthe full sequence number, if the low-order 32 bits carried in thepacket are lower in value than the low-order 32 bits of thereceiver's left edge's sequence number counter, the receiver assumesthat thehigh-order 32 bits have been incremented, moving to a new sequencenumber 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 trafficneed not implement this de-multiplexing algorithm.

It should say:

datagrams to SAs.  Implementations that support only unicast trafficneed 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, butthe receiver need not act upon it.

It should say:

Verification".  Thus, the sender MUST always transmit this field, butthe 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 achievesecurity.)  These padding bytes are included in the ICV calculation,

It should say:

(The padding is arbitrary, but needs not to be random to achievesecurity.)  These padding bytes are included in the ICV calculation,

Notes:

grammar
--VERIFIER NOTES--
The original text is grammatically correct.

Report New Errata