Hi I think one of the most striking things is how similar all three mechanisms are.
They all begin with a node doing what the DMVPN guys call a "hairpin" - it decrypts packets from one peer, then re-encrypts them and sends them to another peer. In all three proposals, the node doing the hairpin notices this inefficiency, and informs one or both of the peers. In all three proposals, the peers learn of each other, and open a direct tunnel. The semantics are practically identical, so the difference is only in the mechanism. In our proposal (draft-sathyanarayan), it is the hairpin node that does the introduction, which takes place at the same time as the notification. In draft-mao there is an omniscient server known as ADS that the peers ask for tunnel information In DMVPN the peer runs a discovery process using NHRP over a GRE tunnel. Our proposal in an IKE extension draft-mao defines a new UDP-based protocol DMVPN (draft-detienne) uses NHRP over a GRE tunnel As a document, I think ours has the advantage of being more complete. Both DMVPN and the other ADVPN gloss over authentication, identities and authorization. Mike pretty much said it in the conf call: any gateway that has a valid certificate will connect, and will be trusted. There might be some routing protocol security, but that is outside scope, and anything based on RPKI is unlikely in corporate networks. Those are, however, gaps that can be filled. Whichever proposal gets chosen is only a starting point, and the WG can decide to tightly profile the authentication and authorization in any proposal, as well as augment any of the protocols with identities and credentials. Our advantages are: - fewer packets, because notification, introduction and credential provisioning are all done in one round-trip. - Less complexity, as it's all in an IKE extension (compared with the new protocol of ADVPN2 and the whole GRE+NHRP+routing protocol implementation of DMVPN) - Works with IPsec tunnels (no need for an extra GRE tunnel) - Requires no new components which can be points of failure (like an ADS) - Scalability. Consider 10,000 remote access clients - Mike said you could do that with GRE. The fact is that Cisco's clients use IPsec tunnels or L2TP, neither requires a virtual interface on the gateway. Running GRE and routing protocols to the clients is not done, and probably for a good reason. I've also been told that having a large number of neighbors is a problem for routing protocols (although I'm no expert on those) - ADS is an obvious potential bottleneck. Loss of state there can be devastating - how would it recover the data? OTOH we have the ability to keep servers running without losing state. It costs money, but servers can work reliably and scalably. Just look at the Facebook web servers :-) Our disadvantages: - Shortcuts work a single hop at a time. If the path through the VPN is longer, we may set up some useless SAs. - Not tested in the field Yoav _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
