errata logo graphic

Found 10 records.

Status: Verified (1)

RFC4302, "IP Authentication Header", December 2005

Source of RFC: ipsec (sec)

Errata ID: 134

Status: Verified
Type: Technical

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)

RFC4302, "IP Authentication Header", December 2005

Source of RFC: ipsec (sec)

Errata ID: 744

Status: Held for Document Update
Type: Technical

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

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

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

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)

RFC4302, "IP Authentication Header", December 2005

Source of RFC: ipsec (sec)

Errata ID: 2188

Status: Rejected
Type: Technical

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

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

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

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

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.


Report New Errata