RFC Errata
Found 5 records.
Status: Verified (5)
RFC 4303, "IP Encapsulating Security Payload (ESP)", December 2005
Source of RFC: ipsec (sec)
Errata ID: 133
Status: Verified
Type: Technical
Publication Format(s) : TEXT
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.
Errata ID: 1654
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2009-01-16
Verifier Name: Pasi Eronen
Date Verified: 2009-06-18
Section 3.4.4.1 says:
Implementation Note:
Implementations can use any set of steps that results in the
same result as the following set of steps. Begin by
removing and saving the ICV field. Next check the overall
length of the ESP packet minus the ICV field. If implicit
padding is required, based on the block size of the
integrity algorithm, append zero-filled bytes to the end of
the ESP packet directly after the Next Header field, or
after the high-order 32 bits of the sequence number if ESN
is selected. Perform the ICV computation and compare the
result with the saved value, using the comparison rules
defined by the algorithm specification.
It should say:
Implementation Note:
Implementations can use any set of steps that results in the
same result as the following set of steps. Begin by
removing and saving the ICV field. Next check the overall
length of the ESP packet minus the ICV field. If implicit
padding is required, based on the block size of the
integrity algorithm, append padding bytes (according integrity
algorithm specification, see Section 3.3.2.1) to the end of
the ESP packet directly after the Next Header field, or
after the high-order 32 bits of the sequence number if ESN
is selected. Perform the ICV computation and compare the
result with the saved value, using the comparison rules
defined by the algorithm specification.
Notes:
(confirmed by Stephen Kent)
Errata ID: 6559
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Yaakov Stein
Date Reported: 2021-04-25
Verifier Name: Paul Wouters
Date Verified: 2022-04-10
Section 3.1.1 says:
AFTER APPLYING ESP
-------------------------------------------------
IPv4 |orig IP hdr | ESP | | | ESP | ESP|
|(any options)| Hdr | TCP | Data | Trailer | ICV|
-------------------------------------------------
It should say:
AFTER APPLYING ESP
----------------------------------------------------
IPv4 |updated IP hdr | ESP | | | ESP | ESP|
|(any options) | Hdr | TCP | Data | Trailer | ICV|
----------------------------------------------------
Notes:
"orig" implies that the IP header is left as-is, while in fact the "protocol" field and the "total length" and the checksum must be updated. There IS appropriate text explaining this in RFC 3948 "The Total Length, Protocol, and Header Checksum (for IPv4) fields in the IP header are edited to match the resulting IP packet." but this text is missing here.
We have encountered an implementation that does not update the "total length" and the implementer claims that this is mandated by RFC 4303.
Paul / Tero:
This is updating the figure in RFC4303 (ESP) and should use "updated IP hdr" instead of "orig IP header", as the specification does in fact modify the protocol, total length and checksum fields.
In any potential future document update, text should be added that explains which fields are updated similar to what is done in the RFC3948:
The Total Length, Protocol, and Header Checksum (for IPv4) fields
in the IP header are edited to match the resulting IP packet.
As ESP is still used the IPsecME WG might want to make a RFC4303bis at some point and this fix should then be included. Perhaps the WG should think about moving it from proposed standard to internet standard at one point.
Errata ID: 4798
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Antonios Atlasis
Date Reported: 2016-09-09
Verifier Name: Paul Wouters
Date Verified: 2022-04-10
Section 2 says:
* If tunnel mode is being used, then the IPsec implementation
can add Traffic Flow Confidentiality (TFC) padding (see
Section 2.4) after the Payload Data and before the Padding
(0-255 bytes) field.
It should say:
* If tunnel mode is being used, then the IPsec implementation
can add Traffic Flow Confidentiality (TFC) padding (see
Section 2.7) after the Payload Data and before the Padding
(0-255 bytes) field.
Notes:
Section 2.4 refers to padding for Encryption. It is section 2.7 which refers to Traffic Flow Confidentiality (TFC) Padding
Errata ID: 4799
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Antonios Atlasis
Date Reported: 2016-09-09
Verifier Name: Paul Wouters
Date Verified: 2022-04-11
Section 2.6 says:
To facilitate the rapid generation and discarding of the padding traffic in support of traffic flow confidentiality (see Section 2.4), the protocol value 59 (which means "no next header") MUST be used to designate a "dummy" packet.
It should say:
To facilitate the rapid generation and discarding of the padding traffic in support of traffic flow confidentiality (see Section 2.7), the protocol value 59 (which means "no next header") MUST be used to designate a "dummy" packet.
Notes:
Section 2.4 refers to padding for Encryption. It is section 2.7 which refers to Traffic Flow Confidentiality (TFC) Padding.