Subject: [IPsec] IPsec RFC Errata

From: Tero Kivinen <[email-masked]>
Date: Thu, 24 Mar 2022 15:04:32 +0200

I went through all reported errata, and here is my take on them.

It seems that if we mark errata as "verified" then it will get inline
fixes for the rfc by the rfc-editor, but if we mark it as hold for
document update we do not... I think most of those could also be hold
for document update, but if we get the inline fixes by marking them as
just "verified" then even better...

Actually some of those held for document update errata could also be
useful to be inlined... Especially for documents which are not yet
obsoleted ( RFC2104, RFC4301, RFC4302, and RFC4303).

Actually there should be new state which is "Was Held for Document
Update, Document was already updated, and errata was incorporated"...

--

https://www.rfc-editor.org/errata/eid6388

This simple typo in RFC2408 (ISAKMP), should be verified.

Status: Verified

--

https://www.rfc-editor.org/errata/eid4936

This is incorrect errata to the RFC3947 (IKEv1 NAT-T negotiation). It
asks to change where initiator MUST send NAT-OA payloads if it
proposes any UDP-Encapsulation mode, compared to the proposing
EDP-Encapsulated-Transport mode. The original text is correct, we only
need to send NAT-OA payloads if UDP-Encapsulated-Transport mode is
proposed, it is not required if only UDP-Encapsulated-Tunnel mode is
proposed.

So this errata should be rejected.

Status: Rejected

--
https://www.rfc-editor.org/errata/eid4937

Simple typo fix in RFC3947 (IKEv1 NAT-T negotiation) changing "source
IP and port address" to "source IP and port number". So verified.

Status: Verified

--

https://www.rfc-editor.org/errata/eid4709

By checking the ASN1 code in the RFC4301 (IPsec architecture) it seems
to already have the changes that are listed in the errata. The ASN.1
mostly matches the one in the corrected text except RFC4301 still uses

           parameters  ANY -- DEFINED BY algorithm} -- defined outside
                                    -- of this document for AES modes.

not the one in the corrected text which has version:

           parameters  ANY } -- defined outside

                                    -- of this document for AES modes.

I think the one in the RFC4301 is correct, so I think this errata
should be rejected.

Status: Rejected.

--

https://www.rfc-editor.org/errata/eid6559

This is updating the figure in RFC4303 (ESP) and I think the errata
should be set to verified, as I think we should use "updated IP hdr"
instead of "orig IP header", as we do in fact modify the protocol,
total length and checksum fields.

In the document update we most likely want to add text explaining
which fields are updated like 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 we are still using ESP, we might want to make a RFC4303bis at some
point and this change should be made then. Perhaps we should think
about moving it from proposed standard to internet standard at one
point. 

Status: Verified

--

https://www.rfc-editor.org/errata/eid4798

Fixing wrong reference in the RFC4303 (ESP) from 2.4 to 2.7 when
talking about the transport flow confidentiality.

Status: Verified

--

https://www.rfc-editor.org/errata/eid4799

Fixing wrong reference in the RFC4303 (ESP) from 2.4 to 2.7 when
talking about the transport flow confidentiality.

Status: Verified

-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 24 Mar 2022 14:42:28 +0100

> obsoleted ( RFC2104, RFC4301, RFC4302, and RFC4303).

I think that having stuff inlined is always good.

I read your list, and I agree with them all.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-