On Wed, Feb 28, 2024 at 7:12 AM Michael Richardson <[email protected]> wrote: > In github issue: > https://github.com/furry13/ipsecme-esp-ping/pull/6 > > I said: > >I am not in favour of any link to IKE. > > I don't think it's useful to signal in IKE that the host/gateway supports > SPI=7. > I believe in many debug situations, the person doing the diagnostics won't > have a credential that they can use in IKE, and the person that has that > credential (it could be a physical token) won't know how to do the debugging. > > Consider a scenario where some branch office regularly has an external > auditor physically present. Said auditor expects to operate their Remote > Access VPN from their laptop, for which they got permission some years before. > Central IT turns on IPv6, and everything is great, but they didn't think to > enable ESP (because NAT44 rules, right?). Assume auditor's VPN hub supports > IPv6.
[skip] In your scenario announcing ESP Ping capability in IKE is useless but harmless. You seem to assume that ESP ping is only used by humans troubleshooting the network, but think about other case: a device (a phone, for example) is going to establish an IPSec session to a VPN server or, even better, a voice gateway (as WiFi Calling requires IPSec). Currently, if IKE succeeds but ESP fails, it's very hard for the device to detect the issue. If the peer supports ESP ping and announces it in IKE, the device can use ESP ping to find out that..ooops, the corporate WiFi the device is connected to is having issues with end2end ESP connectivity, and switch back to the mobile network, instead of blackholing the data packets. So I do not see any harm in advertising it in IKE but I do see some benefits - but I clearly might be missing smth here. -- Cheers, Jen Linkova _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
