Hi, Tiru,
Based on your replies, I am now fine for no actions on the comments 1 and 2.
Also thanks for adding the helpful leading paragraph in Section 3 of version
05,
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-reliable-transport/.
So comment 4 was also addressed.
However, it seems that part of comment 3 is not addressed yet. After reading
the text in Section 3.1 again, I still think that the diagram (copied below) is
for hybrid KE, rather than for a pure PQ KE.
Initiator (UDP) Responder (UDP:4500)
-------------------------------------------------------------------
IKE_SA_INIT request:
HDR , SAi1, KEi1, Ni,
[N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),]
N(SEPARATE_TRANSPORTS) --->
IKE_SA_INIT response:
HDR, SAr1, KEr1, Nr,
[N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),]
<--- N(SEPARATE_TRANSPORTS)
=> Initiator switches to TCP:4500 for IKE_INTERMEDIATE /
IKE_AUTH / subsequent IKEv2 exchanges (with IKETCP prefix)
=> ESP directly over IP or ESP with UDP encapsulation - depending on the
presence of NATs
The reason is, as mentioned in previous message, the payloads of KEi1 and KEr1
are all about traditional KE transported over UDP here. And the PQ KE payloads
will be transferred later via TCP, specified the above as “Initiator switches
to TCP:4500 for IKE_INTERMEDIATE / IKE_AUTH / subsequent IKEv2 exchanges
(with IKETCP prefix)”.
So, even the target of the document is for pure PQ KE via TCP transport, but
this mode will be unavoidably run in hybrid. Hope I did not misunderstand the
technical description here.
If this is the case, I would like to further suggest give some text explaining
how to derive the keys, as here at least two rounds of key derivation will be
involved. Also, here not just the initiator, but also the responder needs to
switch TCP: 4500 for completing IKE_INTERMEDIATE/ IKE_AUTH etc. Also, the
description for the above diagram may need to update correspondingly.
Alternatively, if the draft is deemed to include pure PQ KE only, this mode may
have to be removed, while keeping mode 2 specified in Section 3.2 (it works for
pure PQ KE well). Then, we may consider to work on another draft for supporting
hybrid KE with Separate Transports for IKE and ESP, if this is a good
motivation.
Cheers,
Guilin
From: tirumal reddy <[email protected]>
Sent: Tuesday, 26 May 2026 2:16 pm
To: Wang Guilin <[email protected]>
Cc: Tero Kivinen <[email protected]>;
[email protected]; [email protected];
[email protected]
Subject: Re: [IPsec] WG Last Call:
draft-ietf-ipsecme-ikev2-reliable-transport-02 (Ends 2026-05-11)
Please see inline
On Mon, 25 May 2026 at 18:38, Wang Guilin
<[email protected]<mailto:[email protected]>> wrote:
Sorry for my late review. I support publication as well!
Attached below is my review report, on the updated 4 version,
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-reliable-transport/04/.
Guilin
=====================
This specification allows to decouple IKE and IPsec transports, making it
possible to use a reliable transport (TCP)for IKEv2 while continuing to use an
unreliable transport (UDP) for IPsec (say ESP). Technically, it is a further
extension of RFC 9329.
The specification has been organized and written clearly, though a few
improvements could be possible, as suggested below.
1. Verb tenses. For me, it seems better if the verb tense in the first two
paragraphs in Section 1 could be updated a little bit.
For example, the first paragraph in Section 1 reads:
“The Internet Key Exchange protocol version 2 (IKEv2) [RFC7296] originally used
unreliable transport (UDP) for its messages. Later it was extended to use TCP
[RFC9329] where UDP is blocked. UDP remains the preferred transport for IKEv2,
and TCP is only used if UDP datagrams cannot get through. ”
This sounds a little like [RFC7296] is obsoleted. However, this RFC is still
the current valid version of IKEv2, it seems for me the following tenses of
verbs better:
"... [RFC7296] uses unreliable transport (UDP) for its messages. Later it has
been extended to use TCP [RFC9329] where UDP is blocked. ..."
The verb tense for the first paragraph in Section 1 is similar.
"Originally used" and "was extended" are standard IETF style for describing
protocol history, there's nothing wrong with them.
2. Before the diagram 2 given in Section 3.2, the following description is
given if the responder does not return the SEPARATE_TRANSPORTS notification.
"If the responder does not return the SEPARATE_TRANSPORTS notification in the
IKE_SA_INIT response, the initiator MUST treat this as an indication that the
responder does not support separate transports. In this case, both IKEv2
messages and ESP packets MUST be sent over TCP as specified in [RFC9329]."
My question is: If is the above "MUST" definitely necessary?
Namely, in this case it seems also natural to the initiator to ignore or
terminate this IKE_SA_INIT over TCP and then restarts a normal new IKE_SA_INIT
(over UPD) with the responder, due to either without receiving the response
from the responder or receiving the response but this response not including
the SEPARATE_TRANSPORTS notification.
In Section 3.2, the initiator starts over TCP from the beginning, so falling
back to UDP is not a viable option. If the responder does not return
SEPARATE_TRANSPORTS, both IKEv2 and ESP continue over TCP as per RFC 9329, this
is the natural consequence of the connection already being over TCP, not a
fallback mechanism.
3. This specification supports two modes to negotiate TCP transport for IKEv2
(i.e., Sections 3.1. and 3.2). However, Section 1 seemingly only mentions the
pure PQ mode (which responds to Section 3.2?).
However, for my understanding, this specification does support PQ/T hybrid key
exchange well. As the diagram in Section 3.1 shown, KEi1 and KEr1 are for
traditional KE, while PQ KE via ADDKE is switched for transmission over TCP.
Also, it seems also ok to run PQ/T hybrid KE via the diagram in Section 3.2 too.
So, I would suggestion mention the support of PQ/T hybrid KE clearly in the
specification and explains how they are supported in both modes. Now, neither
"hybrid" nor "PQ/T" is mentioned in the specification. In fact, the mainstream
for IKEv2 key exchange is hydbrid.
PQ/T Hybrid KE is already handled by RFC 9370 and works with this draft without
needing special mention.
4. Editorial Suggestion. It may be helpful to give a short leading paragraph to
explain the content of Section 3, in particular about the two modes of
negotiating TCP transport for IKEv2.
Sure, we will update the draft.
Cheers,
-Tiru
================
-----Original Message-----
From: Tero Kivinen via Datatracker <[email protected]<mailto:[email protected]>>
Sent: Monday, 27 April 2026 8:58 pm
To:
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-reliable-transport-02
(Ends 2026-05-11)
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]<mailto:[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]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
