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. Auditor+Auditor's local host: "Hello, IT. The VPN that has works for *Auditor* since 2007 has suddendly stopped working. It was approved in ticket #87245 back in the day." IT: "Uh. When did it stop? When we enabled IPv6. Oh." ESP Ping means that the IT can effectively send ESP packets from some host *they* control at the branch office, aiming at the Auditor's VPN end-point. They don't even need ESP Responses to work, but it's sure nice if they do. Further, ESP Ping could be used in a *traceroute* like way using TTLs to determine how far the ESP Ping packet gets. traceroute --protocol=51 probably gets one 2/3 of the way there, but maybe not all the way. In the process, they discover some IPv6 firewall which thinks only TCP and UDP exist, and it gets fixed. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
