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