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 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

Report New Errata