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]
