On Tue, 30 Jan 2024, Lorenzo Colitti wrote:
Not necessarily. A VPN client might know for sure that the server it wants to talk to supports ESP ping. Before the IKE handshake, it could send the ping, and if no response came back, it simply wouldn't bother with negotiating ESP or IPv6 at all and just go back to IPv4.
That would be a poor implementation. A man-in-the-middle could quickly reply with an ICMP message before the ESP ping reply would come back. It would be a handy way to disable IKEv2/IPsec entirely. The IKEv2 part should be much easier to get updated compared to the kernel support part. I would think it not very common to have kernel support without IKE support. So making it part of IKE makes sense to me. Also, if UDP (4)500 is blocked, getting the ESP reply back does not help you either. I thought the use case was more for you got an IKEv2 connection but want to confirm see if packet flow is working at all. Which an IKEv2 liveness does not tell you. Then there is IKE on UDP (4)500, ESP, ESPinUDP and ESPinTCP to consider. The RFC already says that even without negotiation, any IKEv2 peer may decide to switch from ESP to ESPinUDP or ESPinTCP and back. And Linux does not support any of this switching. Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
