RFC Errata
RFC 4303, "IP Encapsulating Security Payload (ESP)", December 2005
Source of RFC: ipsec (sec)
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 the IPsec Architecture document, RFC 4301, without being able to present all the details. SPI selection has become a quite complicated procedure with subtle details, which all can be found in RFC 4301. IMHO, it would have been very much preferrable to replace most of the text in section 2.1 by a short referral to RFC 4301. Any replication of specification entails the danger of inconsistencies and raises the question of "truth weight" for the concurring specifications; it is better to avoid such "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 the second 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 logical hierarchy 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 from RFC 2406. During that process, the perhaps most important part of ESP inbound packet 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 Verification on page 30, and in the ToC, should be modified to read: 3.4.4. Integrity Check Value Verification and Payload Decryption I would like to recommend that you submit an RFC Errata Note to catch this issue. (4) In section 3.4.4.2, the same issue as (2) above also applies to the item numbered "2." on page 32. (5) References RFC 4306 repeatedly refers to its predecessor, RFC 2406, but it omits giving a formal (Informative) Reference to that document in Section 10.2 on page 37. Perhaps it would also have been worth noting that a *full* version of the research paper [Kra01] can be found on IACR ePrint, document 2001/040. (6) Appendix A As mentioned in my comments on RFC 4302, this appendix is the more complete 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 break simple expressions apart by line breaks, whenever possible. In this 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 already mentioned 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