Please see inline On Mon, 25 May 2026 at 18:38, Wang Guilin <[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]> > Sent: Monday, 27 April 2026 8:58 pm > To: [email protected]; [email protected]; > [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] 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]
