Thanks Hannes for the detailed review. I raised a PR https://github.com/smyslov/ikev2-reliable-transport/pull/8 to address the comments; please have a look.
-Tiru On Tue, 28 Apr 2026 at 22:48, Hannes Tschofenig <[email protected]> wrote: > Thanks for the work, Tiru & Valery. > > > I have a few minor comments: > > 1. I believe you should put the Updates "RFC 9329" statement into the > boilerplate. RFC 9329 defines TCP transport for IKEv2 messages and you > are extending the functionality with this draft. Particularly the text > in Section 4.1 appears to make such a statement in the frontpage of the > document necessary. > > 2. In Section 3.7 you write: > > " > If no ESP > Echo Reply is received after exhausting the retransmissions described > below, the peers MUST switch ESP to TCP as specified in [RFC9329]. > " > > I am uncertain what text you are referring to regarding "described below". > > How about: > > " > If the initiator performs ESP reachability verification and receives no > ESP Echo Reply after its configured retry procedure, it MUST switch ESP > to TCP as specified in [RFC9329]. > " > > FWIW there is a dangling character at the end of this sentence: > > " > * If a NAT was detected, the initiator MUST send the ESP Echo > Request using UDP encapsulation on port 4500 [RFC3948].I > " > > 3. In Section 3.1, the initiator starts IKE_SA_INIT over UDP/4500, gets > the SEPARATE_TRANSPORTS notification back, and then MUST switch > subsequent IKE exchanges to TCP/4500. That proves UDP/4500 works, but > not that TCP/4500 works across the path. > > What happens when TCP/4500 is blocked? > > 4. Encrypted ESP Echo Protocol > > Your draft uses ESP Echo Request as the specified verification mechanism > in Section 3.7. To me it looks like I-D.ietf-ipsecme-encrypted-esp-ping > is a normative reference. > > 5. Editorial issues > > Section 4.2: s/quicly/quickly > Section 4.2: s/re-establish IKE SA/re-establish an IKE SA > Section 4.2: s/Since network condition may change/Since network > conditions may change > “then, unless configured…” → remove “then” > Section 4.2: > > FROM > " > Since no large public keys are > transferred in the IKE_SESSION_RESUME exchange, then, unless > configured to use TCP only, the initiator, when resuming, MUST start > using UDP with destination port 4500, as discussed in Section 3.1. > " > TO: > > " > Since no large public keys are > transferred in the IKE_SESSION_RESUME exchange, unless > configured to use TCP only, the initiator, when resuming, MUST start > using UDP with destination port 4500, as discussed in Section 3.1. > " > > This sentence sounds very complex to me. How about this version: > > " > When resuming an IKE session, the initiator MUST start with UDP to > destination port 4500, unless it is configured to use only TCP. This is > because the IKE_SESSION_RESUME exchange does not transfer large public > keys. > " > > Did I understood the intention of the sentence correctly? > > > Section 1: > > FROM > > " > Most of post-quantum > algorithms require IKE peers to exchange much more data, than > classical algorithms, up to tens (or even hundreds) Kbytes. > " > > TO: > > " > Most post-quantum > algorithms require IKE peers to exchange much more data, than > classical algorithms, up to tens (or even hundreds) Kbytes. > " > > Section 1: > > FROM: > > " > A few > proposals exist that allow to overcome the 64 Kbytes limitation on > the size of an IKE payload ([I-D.nir-ipsecme-big-payload], > [I-D.smyslov-ipsecme-ikev2-extended-pld], > [I-D.tjhai-ikev2-beyond-64k-limit]). > " > > TO: > > > " > A few > proposals exist that allow overcoming the 64 Kbytes limitation on > the size of an IKE payload ([I-D.nir-ipsecme-big-payload], > [I-D.smyslov-ipsecme-ikev2-extended-pld], > [I-D.tjhai-ikev2-beyond-64k-limit]). > " > > Section 1: > > FROM: > > " > In this case larger amount of > data need to be sent in the IKE_SA_INIT exchange, that makes using > UDP problematic. > " > > TO: > > " > In this case larger amount of > data needs to be sent in the IKE_SA_INIT exchange, that makes using > UDP problematic. > " > > Section 1: > > FROM > > " > However, the current use of TCP for IKE and ESP > [RFC9329] implies that ESP SAs are also encapsulated in TCP, which > has negative impact on IPsec performance (see Section 9 of TCP > encapsulation of IKE and ESP packets [RFC9329]). > " > > TO: > > " > However, the current use of TCP for IKE and ESP > [RFC9329] implies that ESP SAs are also encapsulated in TCP, which > has a negative impact on IPsec performance (see Section 9 of TCP > encapsulation of IKE and ESP packets [RFC9329]). > " > > Section 1: > > FROM: > > " > This specification allows to decouple IKE and IPsec transports, > making it possible to use a reliable transport for IKEv2 while > continuing to use an unreliable transport for IPsec. > " > > TO: > > " > This specification allows IKE and IPsec transports to be decoupled, > making it possible to use a reliable transport for IKEv2 while > continuing to use an unreliable transport for IPsec. > " > > Section 3.1 and Section 3.2: > > To me the following wording is a bit better: > > s/ESP over UDP or IP depending on the presence of NATs/ESP directly over > IP or ESP with UDP encapsulation - depending on the presence of NATs > > > Section 3.2: > > FROM: > " > In this case, both IKEv2 and ESP MUST use TCP transport for all > subsequent exchanges, as per TCP encapsulation of IKE and ESP packets > [RFC9329]. > " > > TO: > > " > In this case, both IKEv2 messages and ESP packets MUST be sent over > TCP as specified in [RFC9329]. > > " > > Ciao > Hannes > > Am 27.04.2026 um 14:57 schrieb Tero Kivinen via Datatracker: > > This message starts a WG Last Call for: > > draft-ietf-ipsecme-ikev2-reliable-transport-02 > > > > This Working Group Last Call ends on 2026-05-11 > > > > Abstract: > > The Internet Key Exchange protocol version 2 (IKEv2) can operate > > either over unreliable (UDP) transport or over reliable (TCP) > > transport. If TCP is used, then IPsec tunnels created by IKEv2 also > > use TCP. This document specifies how to decouple IKEv2 and IPsec > > transports so that IKEv2 can operate over TCP, while IPsec tunnels > > use unreliable transport. This feature allows IKEv2 to effectively > > exchange large blobs of data (e.g., when post-quantum algorithms are > > employed) while avoiding performance problems that arise when IPsec > > uses TCP. > > > > File can be retrieved from: > > > > Please review and indicate your support or objection to proceed with the > > publication of this document by replying to this email keeping > [email protected] > > in copy. Objections should be explained and suggestions to resolve them > are > > highly appreciated. > > > > Authors, and WG participants in general, are reminded of the Intellectual > > Property Rights (IPR) disclosure obligations described in BCP 79 [1]. > > Appropriate IPR disclosures required for full conformance with the > provisions > > of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. > > Sanctions available for application to violators of IETF IPR Policy can > be > > found at [3]. > > > > Thank you. > > > > [1] https://datatracker.ietf.org/doc/bcp78/ > > [2] https://datatracker.ietf.org/doc/bcp79/ > > [3] https://datatracker.ietf.org/doc/rfc6701/ > > > > The IETF datatracker status page for this Internet-Draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-reliable-transport/ > > > > There is also an HTMLized version available at: > > > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-reliable-transport-02 > > > > A diff from the previous version is available at: > > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-ikev2-reliable-transport-02 > > > > _______________________________________________ > > IPsec mailing list -- [email protected] > > To unsubscribe send an email to [email protected] >
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
