Search RFCs

RFC Editor

Found 8 records.

Status:Verified (5)

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

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.

Status:Held for Document Update (3)

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

Errata ID:3876
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Yaron Sheffer
Date Reported: 2014-01-31
Held for Document Update by: Stephen Farrell
Date Held: 2014-05-08

Section Introduction says:

Using encryption-only for confidentiality is allowed by ESP. However, itshould be noted that in general, this will provide defense only againstpassive attackers.  Using encryption without a strong integritymechanism on top of it (either in ESP or separately via AH) may renderthe confidentiality service insecure against some forms of activeattacks [Bel96, Kra01].  Moreover, an underlying integrity service, suchas AH, applied before encryption does not necessarily protect theencryption-only confidentiality against active attackers [Kra01]. ESPallows encryption-only SAs because this may offer considerably betterperformance and still provide adequate security, e.g., when higher-layerauthentication/integrity protection is offered independently. However,this standard does not require ESP implementations to offer anencryption-only service.

It should say:

Using encryption-only for confidentiality is allowed by ESP.However, it should be noted that in general, this will provide defenseonly against passive attackers.  Using encryption without a strongintegrity mechanism on top of it (either in ESP or separately via AH)may render the confidentiality service insecure against some forms ofactive attacks [Bel96, Kra01, DP07].  Moreover, applying AHbefore encryption does not protect the encryption-onlyconfidentiality against active attackers [DP10]. ESPallows encryption-only SAs primarily for compatibility with olderimplementations, and because this may offer better performance.It is noted (and has been demonstrated, e.g. in [DP07]) thatESP in this mode does not provide adequate security even whenhigher-layer authentication/integrity protection is offeredindependently. This standard does not require ESP implementations tooffer an encryption-only service.[DP07] Jean Paul Degabriele and Kenneth G. Paterson, Attacking theIPsec Standards in Encryption-only Configurations, IACR 2007/125.[DP10] Jean Paul Degabriele and Kenneth G. Paterson: On the(in)security of IPsec in MAC-then-encrypt configurations.ACM Conference on Computer and Communications Security 2010:493-504.

Notes:

The existing text asserts that ESP in encryption-only mode can in some cases provide "adequate security", even though the sense of the paragraph is in general against it. A series of papers published subsequently to the RFC demonstrate that this assertion is incorrect: active attackers can defeat the confidentiality guarantees, and such attacks are practical.

Errata ID:721
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)Section 2.1 of RFC 4303 re-states a lot of material from theIPsec Architecture document, RFC 4301, without being able topresent all the details.  SPI selection has become a quitecomplicated procedure with subtle details, which all can befound in RFC 4301.IMHO, it would have been very much preferrable to replace mostof the text in section 2.1 by a short referral to RFC 4301.Any replication of specification entails the danger ofinconsistencies and raises the question of "truth weight"for the concurring specifications; it is better to avoidsuch "races" from the beginning.This same issue applies to section 2.4 of RFC 2402. (By accident,I have forgotten to mention it in my comments on that document.)More concretely, I would have preferred the replacement of thesecond up to the second-to-last paragraph of section 2.1 of RFC 4303,on pages 10/11,  For a unicast SA, the SPI can be used by itself to specify an SA, or  it may be used in conjunction with the IPsec protocol type (in this  ...  ...  ...  ...  ...  multicast address, and source address.  An Any-Source Multicast group  SA requires only an SPI and a destination multicast address as an  identifier.by a short note, e.g.  All implementations of ESP MUST support the Security Association  Database (SAD) as specified in the IPsec Archtecture document  [Ken-Arch] and the SA lookup procedures for unicast traffic  specified therein.  ESP implementations SHOULD support extensions  to the SAD and the SA lookup procedures specified in documents  amending [Ken-Arch], e.g. for multicast traffic or mobility support,  if they intend to provide ESP support for such scenarios.A similar change would be applicable to RFC 4302, section 2.4,pages 6/7.(2)In section 3.4.3, on the lower half of page 29, RFC 4303 says:                                                    [...].  In either   case, if the integrity check fails, the receiver MUST discard the   received IP datagram as invalid; this is an auditable event.  The   audit log entry for this event SHOULD include the SPI value,   [...]Because the audit log details are in a separate sentence, the logicalhierarchy implied by using one semicolon and one full stop is brocken.It would have been better to say:                                                    [...].  In either   case, if the integrity check fails, the receiver MUST discard the|  received IP datagram as invalid.  This is an auditable event.  The   audit log entry for this event SHOULD include the SPI value,   [...]Similar punctuation already is used in many places of the RFC.(3)As mentioned in section 7, section 3.4 has been reorganized fromRFC 2406.During that process, the perhaps most important part of ESP inboundpacket processing has disappeared from the section headlines:decryption !To cover what's inside, and to make that locatable in the ToC,perhaps the section headline, 3.4.4.  Integrity Check Value Verificationon page 30, and in the ToC, should be modified to read: 3.4.4.  Integrity Check Value Verification and Payload DecryptionI would like to recommend that you submit an RFC Errata Note tocatch this issue.(4)In section 3.4.4.2, the same issue as (2) above also applies tothe item numbered "2." on page 32.(5)  ReferencesRFC 4306 repeatedly refers to its predecessor, RFC 2406, but it omitsgiving a formal (Informative) Reference to that document in Section10.2 on page 37.Perhaps it would also have been worth noting that a *full* versionof the research paper [Kra01] can be found on IACR ePrint, document2001/040.(6)  Appendix AAs mentioned in my comments on RFC 4302, this appendix is the morecomplete and hence preferrable text compared to App. B of RFC 4302.There is one exception:The formatting of tha last part of A2.1 ia less pleasant.To enhance readability, it is always preferrable not to breaksimple expressions apart by line breaks, whenever possible.  Inthis case, simple relational expressions are broken into 2 lines.RFC 4303, on page 40, says:   In checking for replayed packets,      + Under Case A: If Seql >= Bl (where Bl = Tl - W + 1) AND Seql <=        Tl, then check the corresponding bit in the window to see if        this Seql has already been seen.  If yes, reject the packet.  If        no, perform integrity check (see Appendix A2.2. below for        determination of Seqh).      + Under Case B: If Seql >= Bl (where Bl = Tl - W + 1) OR Seql <=        Tl, then check the corresponding bit in the window to see if        this Seql has already been seen.  If yes, reject the packet.  If        no, perform integrity check (see Appendix A2.2. below for        determination of Seqh).The formatting in RFC 4302 of the same text (with the alreadymentioned typo there corrected, and the Appendix name adapted),is better:   In checking for replayed packets,      + Under Case A: If Seql >= Bl (where Bl = Tl - W + 1) AND        Seql <= Tl, then check the corresponding bit in the window to        see if this Seql has already been seen.  If yes, reject the        packet.  If no, perform integrity check (see Appendix A2.2        below for determination of Seqh).      + Under Case B: If Seql >= Bl (where Bl = Tl - W + 1) OR        Seql <= Tl, then check the corresponding bit in the window to        see if this Seql has already been seen.  If yes, reject the        packet.  If no, perform integrity check (see Appendix A2.2        below for determination of Seqh).But I would even have preferred this formatting:   In checking for replayed packets,      + Under Case A:        If Seql >= Bl (where Bl = Tl - W + 1) AND Seql <= Tl,        then check the corresponding bit in the window to see if this        Seql has already been seen.  If yes, reject the packet.        If no, perform integrity check (see Appendix A2.2 below for        determination of Seqh).      + Under Case B:        If Seql >= Bl (where Bl = Tl - W + 1) OR Seql <= Tl,        then check the corresponding bit in the window to see if this        Seql has already been seen.  If yes, reject the packet.        If no, perform integrity check (see Appendix A2.2 below for        determination of Seqh).

It should say:

[see above]

Notes:

from pending

Errata ID:859
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

The 'version numbering' issue (as reported as item (6) for RFC 4302)I would have appreciated the introduction of an explicit versionnumbering for ESP, e.g. rename:      ESP as per RFC 1827  to  ESPv1,      ESP as per RFC 2406  to  ESPv2  or  ESPv2.0,   and      ESP as per RFC 4303  to  ESPv3  or  ESPv2.1(or similar).This would make it easier to specify / identify versions and/orversion specific behaviour in implementations, without havingto refer to the RFC numbers explicitely. (Similar numbering hasproven very useful with protocols like BGP, SNMP, IMAP, POP, etc.)

Notes:

from pending

Report New Errata