On Mon, 18 May 2020, Linda Dunbar wrote:
We are experiencing the problems described in RFC 7018 (Auto-Discovery VPN Problem Statement and Requirements), i.e. the problem of enabling a large number of peers (primarily Gateway) to communicate directly using IPsec to protect the traffic between them.
unfortunately, standarization failed because vendors wanted their own solution standarized, and the WG didn't want multiple standards, so it decided to do none. For libreswan, we do "Opportunistic IPsec", which is basically "just try host-to-host IPsec, fail to either clear or block depending on policy". We also have a "you can do auth-null for passive attack protection" in one or both directions" and a migration path from there to fully authenticated IPsec. Authentication based on a shared CA or DNSSEC. These are packet trigger based solutions. It works well for most meshes, and requires no proprietary or new standards. The only two non-standard parts are that when using certificates, we allow requiring an addictional call to match the IKE ID with certificate SAN in the DNS (to prevent a compromised node from pretending to be another node in the mesh) and we have one non-standarized payload to signify we can do auth-null as well as authenticated IPsec, which we hopefully can retire once this document gets adopted / implemented: https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-auth-announce/
Is there any drafts describing the solutions to the problems identified by RFC7018?
There might be the old drafts of the autovpn candidates, but as that is all incompatible and/or proprietary, and mostly from before my time, I have not looked at those solutions much. One issue I have with Cisco solutions, is that they now prefer to wrap everything in GRE, which isn't the best from a security point of view. NHRP (using opennhrp) seems somewhat popular too? Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
