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. 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. 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. 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. ================ -----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]
