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]
