RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (2)

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)

Status: Reported (3)

RFC 4303, "IP Encapsulating Security Payload (ESP)", December 2005

Source of RFC: ipsec (sec)

Errata ID: 6559
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Yaakov Stein
Date Reported: 2021-04-25

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.

Errata ID: 4798
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Antonios Atlasis
Date Reported: 2016-09-09

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: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Antonios Atlasis
Date Reported: 2016-09-09

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.

Report New Errata