RFC Errata
RFC 4301, "Security Architecture for the Internet Protocol", December 2005
Note: This RFC has been updated by RFC 6040, RFC 7619
Source of RFC: ipsec (sec)
Errata ID: 717
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-01
Held for Document Update by: Pasi Eronen
Date Held: 2010-03-11
(1) [typo] In section 4.1, on page 14, RFC 4301 says: DISCUSSION: Although the DSCP [NiBlBaBL98, Gro02] and Explicit Congestion Notification (ECN) [RaFlBl01] fields are not "selectors", as that term in used in this architecture, the sender will need a mechanism to direct packets with a given (set of) DSCP values to the appropriate SA. This mechanism might be termed a "classifier". It should say ( s/in used/is used/ ) : DISCUSSION: Although the DSCP [NiBlBaBL98, Gro02] and Explicit Congestion Notification (ECN) [RaFlBl01] fields are not "selectors", | as that term is used in this architecture, the sender will need a mechanism to direct packets with a given (set of) DSCP values to the appropriate SA. This mechanism might be termed a "classifier". (2) [textual improvement] In section 4.4.3.2, the last lines on page 45 say: [...]. An entry used with certificate-based authentication MAY include additional data to facilitate certificate revocation status, e.g., a list of << page break >> appropriate OCSP responders or CRL repositories, [...] This seems to make not much sense. It should perhaps say: [...]. An entry used with certificate-based authentication MAY include additional data to facilitate certificate revocation status determination, e.g., a list of appropriate OCSP responders or CRL repositories, [...] (3) [typo] The second paragraph of section 4.4.3.3, on page 46, says: If the entry indicates that the IKE ID is to be used, then the PAD entry ID field defines the authorized set of IDs. If the entry indicates that child SAs traffic selectors are to be used, then an additional data element is required, in the form of IPv4 and/or IPv6 address ranges. [...] It should say ( s/SAa/SA/ ) : If the entry indicates that the IKE ID is to be used, then the PAD entry ID field defines the authorized set of IDs. If the entry | indicates that child SA traffic selectors are to be used, then an additional data element is required, in the form of IPv4 and/or IPv6 address ranges. [...] (4) [textual consistency] Below the table on page 59, section 5.1.2.2 says: Notes: (1) - (6) See Section 5.1.2.1. It should say: Notes: | (1) - (3), (5), (6) See Section 5.1.2.1. (5) [typo] The second paragraph of App. D.2, on page 89, says: [...]. (If we choose to allow carriage of fragments on transport mode SAs for IPv6, the problems arises in that context as well.) ^ ^^ There obviously is a singular/plural mismatch. The text should say: [...]. (If we choose to allow carriage of fragments on transport mode SAs for IPv6, the | problem arises in that context as well.) (6) Insufficient IPcomp integration At the end of section 3.1, on page 10, RFC 4301 says: IPsec optionally supports negotiation of IP compression [SMPT01], motivated in part by the observation that when encryption is employed within IPsec, it prevents effective compression by lower protocol layers. It has also been observed that payload compression can help counter TPA. Thus, there are at least two reasons for a tight integration of IPComp with IPsec. But I could not find any 'hook' in RFC 4301 (and in RFC 4302 / 4303 as well) for the concrete support of IPComp in ESP / AH IPsec SAs. IKEv2 (RFC 4306) roughly allows negotiation of IPComp, but how shall that be triggered and work, in an interoperable way, if there are no architectural provisions for the support of IPComp designed in into the IPsec databases (SPD, SAD) as described in RFC 4301 ???? (7) Insufficient integration with QoS (DS) The steps taken for the integration with Differentiated Services are half-hearted. The processing rules specified for the DSCP field in the IP header[s] remain incomplete as long as there is no specified interoperable way to use DSCP as an selector as well. IMHO, the discussion on page 14 of RFC 4301 is misleading because DS classification and treatment needs to be done independent from IPsec treatment. In many scenarios, e.g. on 'hosts' or 'QoS gateways' that must perform fine-grained traffic classification, DS treatment must be performed strictly before IPsec treatment in the outbound case (and after IPsec in the inbound case), to make ULP fields accessible to the DS classifiers. IPsec should then be capable of guaranteeing the same security treatment of all packets of certain traffic class to a given destination. I still have problems to imagine how DS integration could be achieved with the processing model of section 5.1 of RFC 4301. At the end of section 3.1, on page 10, RFC 4301 says: (8) Inconsistent DS Field handling specified in Section 5.1.2.x The IPv6 related table in section 5.1.2.2 contains the line, DS Field copied from inner hdr (5) no change (9) and the subsequent Notes give a lengthy explanation under (9). Contrary to that, the corresponding table line for IPv4, in section 5.1.2.1 on page 57, is *not* linked to such a note. I cannot see any reason precluding the application of the arguments given in Note (9) of section 5.1.2.2 to the IPv4 case as well. Have I missed any significant point there? (9) SA negotiation -- capability mismatch with IKEv2 See section 4.4.1.2, second paragraph.
It should say:
[see above]
Notes:
from pending