Hi Tiru, Thanks for the quick update. I took a look at PR #11, and the added operational/security-considerations text looks aligned with the point I was trying to raise.
The follow-up NAT-T clarification that Valery mentioned also seems worth handling separately, since it affects the assumptions behind UDP-encapsulated ESP reachability. Best, Songbo Bu On Mon, 25 May 2026 19:19:50 +0530, tirumal reddy [email protected] wrote: Thanks for the review, raised PR https://github.com/smyslov/ikev2-reliable-transport/pull/11 to address it. -Tiru On Thu, 21 May 2026 at 02:47, Blue Dog [email protected] wrote: Hello, I reviewed draft-ietf-ipsecme-ikev2-reliable-transport-04 with a focus on deployment behavior when IKEv2 uses a reliable transport for large exchanges while ESP remains on UDP or direct IP transport where possible. I think the mechanism is useful, especially for post-quantum migration, where large key exchange payloads can make unreliable IKE transport operationally fragile. I have one suggested clarification for the operational and security considerations around ESP reachability verification and fallback behavior. Section 3.7 requires the initiator to verify ESP reachability when IKEv2 starts over TCP and to delete and re-establish the IKE SA without proposing separate transport if ESP reachability cannot be confirmed. That behavior is clear, but the security and operational framing could be made more explicit: - Active path interference with ESP reachability can bias the endpoint toward re-establishment behavior or fallback to carrying ESP over TCP. This appears to be primarily an availability and performance concern, rather than a confidentiality downgrade, assuming IKEv2 authentication and Child SA establishment remain intact. - Implementations should provide policy control over whether fallback is acceptable in a given deployment. For some deployments, “fail closed” may be preferable to automatic fallback if separate ESP transport is required by local policy. - Repeated ESP reachability failures after successful IKE negotiation should be visible to operators, for example through rate-limited logs or counters. Otherwise, the failure mode may be difficult to diagnose and may be misinterpreted as a generic tunnel-establishment problem. - Operators should not infer the ESP transport policy solely from the IKE transport. If IKE over TCP is enabled to accommodate large post-quantum exchanges, the resulting ESP transport behavior should remain explicit in configuration and documentation. Possible text: Failure to confirm ESP reachability when IKEv2 is carried over TCP can be caused by benign path filtering or by active interference with the ESP path. Such interference does not by itself weaken IKEv2 authentication or the negotiated Child SA cryptographic protection, but it can affect availability and can cause implementations to re-establish the IKE SA using the fallback behavior described above. Implementations SHOULD make this condition visible to operators, and deployments SHOULD define whether fallback to ESP over TCP is acceptable or whether the SA establishment should fail according to local policy. This would help operators distinguish cryptographic downgrade concerns from availability/performance fallback behavior, while preserving the protocol behavior already described in the draft. Best regards, Songbo Bu 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]
