Search RFCs
The Series
For Authors
Sponsor
RFC Errata
Found 14 records.
Status:Verified (2)
RFC 4301, "Security Architecture for the Internet Protocol", December 2005
Note: This RFC has been updated byRFC 6040, RFC 7619
Source of RFC: ipsec (sec)Errata ID:2180
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Verifier Name: Sean Turner
Date Verified: 2010-07-20
Section 4.4.2.2. says:
OPAQUE**** 0 prot. "P" OPAQUE
It should say:
OPAQUE**** 0 prot. "P" discard packet
Notes:
Opaque means protocol must not be available. Therefore this packet does not match and must be discarded.
The same four times more.
Errata ID:2184
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Verifier Name: Sean Turner
Date Verified: 2010-07-20
Section D2 says:
We could define ANY as the complement of OPAQUE,i.e., it would match all values but only for accessible port fields.
It should say:
We could define ANY as the complement of OPAQUE,i.e., it would match all values but only for accessible port fields.But we did not. ANY encompasses OPAQUE.
Notes:
misleading
Status:Held for Document Update (7)
RFC 4301, "Security Architecture for the Internet Protocol", December 2005
Note: This RFC has been updated byRFC 6040, RFC 7619
Source of RFC: ipsec (sec)Errata ID:135
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: 2008-12-04
Appendix A2 says:
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]
It should say:
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]
Notes:
Perhaps it should be formatted as shown above to avoid the overlap of the columns.
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 integrationAt 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 counterTPA. Thus, there are at least two reasons for a tight integrationof IPComp with IPsec.But I could not find any 'hook' in RFC 4301 (and in RFC 4302 / 4303as well) for the concrete support of IPComp in ESP / AH IPsec SAs.IKEv2 (RFC 4306) roughly allows negotiation of IPComp, but how shallthat be triggered and work, in an interoperable way, if there are noarchitectural provisions for the support of IPComp designed in intothe IPsec databases (SPD, SAD) as described in RFC 4301 ????(7) Insufficient integration with QoS (DS)The steps taken for the integration with Differentiated Servicesare half-hearted. The processing rules specified for the DSCPfield in the IP header[s] remain incomplete as long as there isno specified interoperable way to use DSCP as an selector as well.IMHO, the discussion on page 14 of RFC 4301 is misleading becauseDS classification and treatment needs to be done independent fromIPsec treatment.In many scenarios, e.g. on 'hosts' or 'QoS gateways' that mustperform fine-grained traffic classification, DS treatment mustbe performed strictly before IPsec treatment in the outboundcase (and after IPsec in the inbound case), to make ULP fieldsaccessible to the DS classifiers.IPsec should then be capable of guaranteeing the same securitytreatment of all packets of certain traffic class to a givendestination.I still have problems to imagine how DS integration could beachieved 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.xThe 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 section5.1.2.1 on page 57, is *not* linked to such a note.I cannot see any reason precluding the application of the argumentsgiven 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 IKEv2See section 4.4.1.2, second paragraph.
It should say:
[see above]
Notes:
from pending
Errata ID:1684
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2009-02-17
Held for Document Update by: Pasi Eronen
Section 4.5.3. says:
Consider a situation in which a remote host (SH1) is using the Internet to gain access to a server or other machine (H2) and there is a security gateway (SG2), e.g., a firewall, through which H1's traffic must pass.
It should say:
Consider a situation in which a remote host (SH1) is using the Internet to gain access to a server or other machine (H2) and there is a security gateway (SG2), e.g., a firewall, through which SH1's traffic must pass.
Errata ID:1713
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2009-03-12
Held for Document Update by: Pasi Eronen
Section 12 says:
The IANA has assigned the value (3) for the asn1-modules registry and has assigned the object identifier 1.3.6.1.5.8.3.1 for the SPD module. See Appendix C, "ASN.1 for an SPD Entry".
It should say:
The IANA has assigned the value (3) for the asn1-modules registry and has assigned the object identifier 1.3.6.1.5.5.8.3.1 for the SPD module. See Appendix C, "ASN.1 for an SPD Entry".
Notes:
See http://www.iana.org/assignments/smi-numbers
Errata ID:2179
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Sean Turner
Section 4.4.2.2 says:
list of prot's
It should say:
list of prots
Notes:
This is not genitive. It's plural.
Errata ID:2181
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Tim Polk
Section 4.4.3.1. says:
The Key ID field is defined as an OCTET string in IKE. For this nametype, only exact-match syntax MUST be supported (since there is noexplicit structure for this ID type). Additional matching functionsMAY be supported for this ID type.
It should say:
The Key ID field is defined as an OCTET string in IKE. For this nametype, exact-match syntax MUST be supported (since there is noexplicit structure for this ID type). Additional matching functionsMAY be supported for this ID type.
Notes:
'only A must be supported' is ambigous.
Does it mean 'A must be supportet and anything else must not be supportet', or does it mean 'A must be supportet and anything else may be supportet'. The next sentence clearifies that it is the second interpretation.
Errata ID:2182
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Held for Document Update by: Tim Polk
Section 4.4.3.2 says:
This document requires support for two required authentication datatypes:
It should say:
This document requires support for two authentication datatypes:
Notes:
pleonasm
Status:Rejected (5)
RFC 4301, "Security Architecture for the Internet Protocol", December 2005
Note: This RFC has been updated byRFC 6040, RFC 7619
Source of RFC: ipsec (sec)Errata ID:2178
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 4.1.1. says:
SPD-S, SPD-I, SPD-OPages 20,21
It should say:
Needs to be formulated differently.
Notes:
This text needs information which comes later in RFC4301. There must be an explanation of decorrelation (hint on Appendix B).
The part of outbound traffic is confusing. If you have no SPD-S entries, you can handle it the same way as explained for inbound traffic.
--VERIFIER NOTES--
There is no section 4.1.1.
Errata ID:6635
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Isaac Lewis
Date Reported: 2021-07-09
Rejected by: Benjamin Kaduk
Date Rejected: 2021-07-21
Section 3.2 says:
Note that ESP can be used to provide only integrity, withoutconfidentiality, making it comparable to AH in most contexts.
It should say:
Note that ESP can be used to provide both integrity andconfidentiality.
Notes:
The original sentence contradicts the following one in the same section:
o The Encapsulating Security Payload (ESP) protocol [Ken05a] offers
the same set of services, and also offers confidentiality.
--VERIFIER NOTES--
The original text is conveying the intended sentiment, namely that: despite primarily being a mechanism to provide both confidentiality and integrity protection, ESP can also be configured in a mode that only provides integrity protection and not confidentiality protection. Such a mode is essentially directly analogous to what AH provides, and thus this statement supports the downgrading of AH support to only a MAY-level requirement.
Errata ID:2183
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 5.1. says:
There is no requirement that an implementation buffer the packet if there is a cache miss.
It should say:
There is no requirement that an implementation buffers the packet ifthere is a cache miss.
Notes:
typo
--VERIFIER NOTES--
original text was grammatically correct.
Errata ID:2661
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bob Briscoe
Date Reported: 2010-12-04
Rejected by: Sean Turner
Date Rejected: 2011-03-10
Section header block says:
Obsoletes: 2401
It should say:
Obsoletes: 2401Updates: 3168
Notes:
RFC 4301 updates RFC 3168 but does not indicate this in its header block.
Specifically, RFC 4301 updates the processing of the ECN field for IPsec tunnel mode that was specified in RFC 3168.
--VERIFIER NOTES--
This action was taken already. The RFC index is already updated and so is the datatracker.
Errata ID:4709
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Phillip H. Griffin
Date Reported: 2016-06-14
Date Rejected: 2023-08-02
Section Appendix C says:
In the ASN.1 module for this RFC, the following errors prevented syntax checking and compilation for programming language code generation:1. Changed "DEFINITIONS IMPLICIT TAGS = BEGIN" to "DEFINITIONS IMPLICIT TAGS ::= BEGIN"2. Changed "SPD = SEQUENCE OF SPDEntry" to "SPD ::= SEQUENCE OF SPDEntry"3. Changed "parameters ANY -- DEFINED BY algorithm } -- defined outside" to "parameters ANY } -- defined outside"4. Changed "SPDEntry = CHOICE" to "SPDEntry := CHOICE"5. Changed "IPsecEntry = SEQUENCE" to "IPsecEntry ::= SEQUENCE"6. Changed "BypassOrDiscardEntry = SEQUENCE" to "BypassOrDiscardEntry ::= SEQUENCE"7. Changed "InOutBound = CHOICE" to "InOutBound ::= CHOICE"8. Changed "iso(1) org (3) dod (6)" to "iso(1) identified-organization (3) dod (6)"A correct ASN.1 module follows in the "Corrected Text" field.
It should say:
SPDModule { iso(1) identified-organization (3) dod (6) internet (1) security (5) mechanisms (5) ipsec (8) asn1-modules (3) spd-module (1) } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS RDNSequence FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) };-- An SPD is a list of policies in decreasing order of preferenceSPD ::= SEQUENCE OF SPDEntrySPDEntry ::= CHOICE { iPsecEntry IPsecEntry, -- PROTECT traffic bypassOrDiscard [0] BypassOrDiscardEntry } -- DISCARDBYPASS IPsecEntry ::= SEQUENCE { -- Each entry consists of name NameSets OPTIONAL, pFPs PacketFlags, -- Populate from packet flags -- Applies to ALL of the corresponding -- traffic selectors in the SelectorLists condition SelectorLists, -- Policy condition processing Processing -- Policy action}BypassOrDiscardEntry ::= SEQUENCE { bypass BOOLEAN, -- TRUE BYPASS, FALSE DISCARD condition InOutBound }InOutBound ::= CHOICE { outbound [0] SelectorLists, inbound [1] SelectorLists, bothways [2] BothWays } BothWays ::= SEQUENCE { inbound SelectorLists, outbound SelectorLists } NameSets ::= SEQUENCE { passed SET OF Names-R, -- Matched to IKE ID by -- responder local SET OF Names-I } -- Used internally by IKE -- initiator Names-R ::= CHOICE { -- IKEv2 IDs dName RDNSequence, -- ID_DER_ASN1_DN fqdn FQDN, -- ID_FQDN rfc822 [0] RFC822Name, -- ID_RFC822_ADDR keyID OCTET STRING } -- KEY_ID Names-I ::= OCTET STRING -- Used internally by IKE -- initiator FQDN ::= IA5String RFC822Name ::= IA5String PacketFlags ::= BIT STRING { -- if set, take selector value from packet -- establishing SA -- else use value in SPD entry localAddr (0), remoteAddr (1), protocol (2), localPort (3), remotePort (4) } SelectorLists ::= SET OF SelectorList SelectorList ::= SEQUENCE { localAddr AddrList, remoteAddr AddrList, protocol ProtocolChoice } Processing ::= SEQUENCE { extSeqNum BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate & audit fragCheck BOOLEAN, -- TRUE stateful fragment checking, -- FALSE no stateful fragment checking lifetime SALifetime, spi ManualSPI, algorithms ProcessingAlgs, tunnel TunnelOptions OPTIONAL } -- if absent, use -- transport mode SALifetime ::= SEQUENCE { seconds [0] INTEGER OPTIONAL, bytes [1] INTEGER OPTIONAL } ManualSPI ::= SEQUENCE { spi INTEGER, keys KeyIDs } KeyIDs ::= SEQUENCE OF OCTET STRING ProcessingAlgs ::= CHOICE { ah [0] IntegrityAlgs, -- AH esp [1] ESPAlgs} -- ESP ESPAlgs ::= CHOICE { integrity [0] IntegrityAlgs, -- integrity only confidentiality [1] ConfidentialityAlgs, -- confidentiality -- only both [2] IntegrityConfidentialityAlgs, combined [3] CombinedModeAlgs } IntegrityConfidentialityAlgs ::= SEQUENCE { integrity IntegrityAlgs, confidentiality ConfidentialityAlgs } -- Integrity Algorithms, ordered by decreasing preference IntegrityAlgs ::= SEQUENCE OF IntegrityAlg -- Confidentiality Algorithms, ordered by decreasing preference ConfidentialityAlgs ::= SEQUENCE OF ConfidentialityAlg -- Integrity Algorithms IntegrityAlg ::= SEQUENCE { algorithm IntegrityAlgType, parameters ANY -- DEFINED BY algorithm -- OPTIONAL } IntegrityAlgType ::= INTEGER { none (0), auth-HMAC-MD5-96 (1), auth-HMAC-SHA1-96 (2), auth-DES-MAC (3), auth-KPDK-MD5 (4), auth-AES-XCBC-96 (5) -- tbd (6..65535) } -- Confidentiality Algorithms ConfidentialityAlg ::= SEQUENCE { algorithm ConfidentialityAlgType, parameters ANY -- DEFINED BY algorithm -- OPTIONAL } ConfidentialityAlgType ::= INTEGER { encr-DES-IV64 (1), encr-DES (2), encr-3DES (3), encr-RC5 (4), encr-IDEA (5), encr-CAST (6), encr-BLOWFISH (7), encr-3IDEA (8), encr-DES-IV32 (9), encr-RC4 (10), encr-NULL (11), encr-AES-CBC (12), encr-AES-CTR (13) -- tbd (14..65535) } CombinedModeAlgs ::= SEQUENCE OF CombinedModeAlg CombinedModeAlg ::= SEQUENCE { algorithm CombinedModeType, parameters ANY } -- defined outside -- of this document for AES modes. CombinedModeType ::= INTEGER { comb-AES-CCM (1), comb-AES-GCM (2) -- tbd (3..65535) } TunnelOptions ::= SEQUENCE { dscp DSCP, ecn BOOLEAN, -- TRUE Copy CE to inner header df DF, addresses TunnelAddresses } TunnelAddresses ::= CHOICE { ipv4 IPv4Pair, ipv6 [0] IPv6Pair } IPv4Pair ::= SEQUENCE { local OCTET STRING (SIZE(4)), remote OCTET STRING (SIZE(4)) } IPv6Pair ::= SEQUENCE { local OCTET STRING (SIZE(16)), remote OCTET STRING (SIZE(16)) } DSCP ::= SEQUENCE { copy BOOLEAN, -- TRUE copy from inner header -- FALSE do not copy mapping OCTET STRING OPTIONAL} -- points to table -- if no copy DF ::= INTEGER { clear (0), set (1), copy (2) } ProtocolChoice::= CHOICE { anyProt AnyProtocol, -- for ANY protocol noNext [0] NoNextLayerProtocol, -- has no next layer -- items oneNext [1] OneNextLayerProtocol, -- has one next layer -- item twoNext [2] TwoNextLayerProtocol, -- has two next layer -- items fragment FragmentNoNext } -- has no next layer -- info AnyProtocol ::= SEQUENCE { id INTEGER (0), -- ANY protocol nextLayer AnyNextLayers } AnyNextLayers ::= SEQUENCE { -- with either first AnyNextLayer, -- ANY next layer selector second AnyNextLayer } -- ANY next layer selector NoNextLayerProtocol ::= INTEGER (2..254) FragmentNoNext ::= INTEGER (44) -- Fragment identifier OneNextLayerProtocol ::= SEQUENCE { id INTEGER (1..254), -- ICMP, MH, ICMPv6 nextLayer NextLayerChoice } -- ICMP Type*256+Code -- MH Type*256 TwoNextLayerProtocol ::= SEQUENCE { id INTEGER (2..254), -- Protocol local NextLayerChoice, -- Local and remote NextLayerChoice } -- Remote ports NextLayerChoice ::= CHOICE { any AnyNextLayer, opaque [0] OpaqueNextLayer, range [1] NextLayerRange } -- Representation of ANY in next layer field AnyNextLayer ::= SEQUENCE { start INTEGER (0), end INTEGER (65535) } -- Representation of OPAQUE in next layer field. -- Matches IKE convention OpaqueNextLayer ::= SEQUENCE { start INTEGER (65535), end INTEGER (0) }-- Range for a next layer fieldNextLayerRange ::= SEQUENCE { start INTEGER (0..65535), end INTEGER (0..65535) }-- List of IP addressesAddrList ::= SEQUENCE { v4List IPv4List OPTIONAL, v6List [0] IPv6List OPTIONAL}-- IPv4 address representationsIPv4List ::= SEQUENCE OF IPv4RangeIPv4Range ::= SEQUENCE { -- close, but not quite right ... ipv4Start OCTET STRING (SIZE (4)), ipv4End OCTET STRING (SIZE (4)) }-- IPv6 address representationsIPv6List ::= SEQUENCE OF IPv6RangeIPv6Range ::= SEQUENCE { -- close, but not quite right ... ipv6Start OCTET STRING (SIZE (16)), ipv6End OCTET STRING (SIZE (16)) }ENDNotes:
Note that I included an ASN.1 module stub to resolve an imported value in the module.
PKIX1Explicit88 {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18)
}
DEFINITIONS EXPLICIT TAGS ::= BEGIN
RDNSequence ::= SEQUENCE {}
END -- PKIX1Explicit88 --
--VERIFIER NOTES--
This is for RFC4301 and tries to fix the ASN.1 in Appendix C.
The proposed changes uses lines which are not part of the
RFC4301, i.e., the "=" -> "::=" that are listed as needed to
be done, are already "::=" in the RFC4301.
The only other proposed changes are to remove
"-- DEFINED BY algorithm" from one location, but it
leaves it in in few other places. It also proposes to change
iso(1) org (3) dod (6)" to "iso(1) identified-organization (3)
dod (6) which might be correct, but is not needed.