On Tue, Jul 25, 2023 at 07:06:47PM -0700, Lorenzo Colitti wrote: > Dear ipsec WG, > > When working on a VPN implementation we found that it's very difficult to > rely on IPv6 ESP packets because many networks drop them, so even if IKE > negotiation succeeds, the data plane might be broken. Worse, this can > happen on migrate, blackholing an existing session until the problem is > detected and fixed with another migration. > > In many cases, I think a simple "pre-flight check" to see if ESP is > supported on a given network path could solve this problem. So after a few > conversations with folks here I put together this draft. It provides the > equivalent of an ESP ping packet. Comments and feedback appreciated.
Thanks Lorenzo for this ID. I believe this is a great idea. Perhaps we could consider allowing a non-zero ESP payload size? This would facilitate correlating responses upon arrival at the sender. Then I would add an ESP message, format similar to ICMP message. For instance, incorporating an identifier, like ICMP ping has, would enable initiating multiple ESP pings from the same client and receiving corresponding responses without mixing them up. We could utilize common denominator payloads resembling ICMP and ICMPv6 ECHO and ECHO responses, as defined in rfc4443#section-4.1 and rfc792. And may be add a couple ESP specific values, especially for encrypted message use case proposed bellow. Additionally, it would be advantageous to support ESP Ping using encrypted ESP messages too. This would be especially useful to send ESP pings from an IPsec gateway that may or may not have an IP address from the tunnel range negotiated by it. The encrypted ESP Ping would allow us to verify if the full path is functional. I've encountered several cases where IKE gets established, but ESP is filtered. In such situations, beside the pre-flight check having encrypted ESP ping functionality would be invaluable. However, for encrypted messages, we may need specify additional payloads, such as SPI and ESP sequence number, for both sending and receiving. > https://datatracker.ietf.org/doc/draft-colitti-ipsecme-esp-ping/ -antony _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
