Hi Hannes, thank you for this review. A few comments below.
> 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. While I can see your reasoning, I think that it is not needed. In the IPSECME WG the current practice is: if the feature defined in the draft is negotiable, then no marking for "update" is needed, since it does not break old implementations. Otherwise "update" is needed. Since the use of separate transports is negotiated, this draft is not an update of RFC 9329. That said, I agree with you that wording in Section 4.1 is unfortunate and should be changed. How about: s/This specification updates that requirement: when separate transports.../However, when separate transports... > 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]. > " Fine with me, thank you. > 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? I think that the initiator will time out and fail to create the SA. It can re-start from scratch without proposing separate transports (provided this option is not critical for the initiator). > 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. Using Encrypted ESP Ping is optional (as "SHOULD"), so I think that we can leave this reference informational. Peers may have other means to determine whether traffic goes through (like the presence of incoming traffic). > 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” Thanks! > 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? Yes. But to be pedantic, it does not transfer any public keys, neither small nor large :-) At least explicitly, since it transfers session ticket, which content is opaque... O don't know whether this matters... And thank you for the rest of editorial suggestions! Regards, Valery. > 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]
