Michael, I would say that DMVPN is much more than a "brilliant hack". Of the three proposals it is the only one that uses layering to create a real VPN with emphasis on network. The other two proposals are just adding some dynamic functionality onto a collection of tunnels, but don't actually form that collection into a network. If we look at the layers (which are based on standard protocols) from top-down we see: * Routing/forwarding layer over the VPN. This uses standard routing protocols (EIGRP, OSPF, BGP, RIP) to advertise and propagate throughout the VPN the networks (subnets,...) that are available through the VPN. If a new IP based routing protocol comes along no changes would be needed in the other layers to support it. Also if more forwarding granularity is needed there are standard mechanism to do policy based forwarding, including SDN (or SDN like features). These could be implemented without changes to the other layers. * GRE tunneling layer. This provides standards based multi-protocol tunneling. GRE can tunnel both IPv4, IPv6 and non-IP protocols over the same IPv4 or ipv6 infrastructure transport layer. IPsec doesn't know nor need to know anything about the passenger protocols and therefore doesn't need to change. Also in the future if a better standard tunneling protocol comes along, the GRE layer could be replaced with this new layer with minimal changes to the adjacent layers. * NHRP mapping layer. In any dynamic network there needs to be the equivalent of ARP (like on an Ethernet). When you are talking about a collection of tunnels this ARP like protocol must be a bit more complex. NHRP was specifically designed for "tunnel NBMA networks" (ATM, Frame Relay) and the VPN networks that we are talking about building here are the exact same thing. So it is best to go with a standard protocol that was specifically designed for this layer of the network. * IPsec encryption layer. In this layer ISAKMP/IKEv2/IPsec is the correct standard protocol to use. This is what IPsec does really well, encrypt traffic. The layers above greatly simplifies IPsec's job by presenting to it the tunnel to encrypt instead of all of the individual protocols/subnets/flows that are within the tunnel. The IPsec selectors are now for the tunnel, which makes path redundancy and load-balancing doable. IPsec doesn't deal well with the same set of selectors to encrypt traffic to more than one peer. With DMVPN this is handled at the routing/forwarding and GRE tunnel layers.
The other proposals will have to reinvent one or more of these layers, which will end up being less efficient. There are also specific issues with IPsec, in particular, IPsec having to deal directly with the data plane flows. With 10s of thousands of nodes and perhaps 100s of thousands of network/subnets reachable via the VPN the number of IPsec selectors across the VPN would get completely out of hand, especially if each different pair of subnets (selector) requires a separate encryption, between the same two nodes. This doesn't even count the fact that in order to run IPv4 and IPv6 between the same two nodes you have to use at least double the number of selectors. Routing protocols are already designed to scale to 100s of thousands and even millions of routes. So with DMVPN the forwarding and GRE tunneling of both IPv4 and IPv6 is handled within a single GRE tunnel and IPsec selector. NHRP for spoke-hub tunnels doesn't have to do anything more, routing takes care of this. NHRP for shortcut tunnels will have to pass and store (in the routing table) the individual subnets that are to be reachable through the shortcut tunnel, but this is much more lightweight then IPsec doing the same thing, which it would have to do with the other proposals. Also, as mentioned above, IPsec is particular bad at supporting redundancy and load balancing of the same data subnets via different paths, without having to create an IPsec SA per data flow. Note, with DMVPN at the routing/forwarding level you can use various static and dynamic features that "split-tunnel" traffic even down to the specific application or flow. All without having to deal with possibly thousands of negotiated IPsec 5-tuples. By dynamic a mean that application traffic flows can be measured over one path and flow by flow can be redirected over another path. Since this is done at the routing/forwarding layer these are exactly the same mechanisms that are already in use over LAN and physical WAN networks. My point here is that, why reinvent the same mechanism in IPsec when you don't have to and are likely not going to be able to do as good a job as a mechanism that was designed just for that specific purpose. As far as implementation is concerned, there are now at least 3 main vendors other than Cisco that claim they have support for DMVPN, and I pretty much believe their claim is likely to be true. Once DMVPN is a standard then any differences will be quickly worked out. As for hosts they can join the network in one of three ways. * As a non-encrypting node behind a gateway node that supports DMVPN. * As a pure IPsec node connecting into a gateway or hub node and thus gaining access to the DMVPN, but not able to support direct shortcut tunnels. * As a full node, in which case the node would have to support a routing protocol (possibly optional), GRE tunneling, NHRP mapping and IPsec. Of this list the only new thing is NHRP mapping functionality. There will of course need to be some additions to the code for the layers to work cleanly with each other. Many host stacks already have a level of support for the other three layers (routing, GRE, IPsec). As for the draft-mao-ipsecme proposal, I think the ADS is the wrong way to go. The ADS is going to be a single point congestion and failure in the VPN. Even if you have multiple ADSs in the network they will have to all keep their databases in sync, which adds more problems when trying to scale these networks to 10s of thousands of nodes and larger. Mike. Mike Sullenberger, DSE [email protected]<mailto:[email protected]> .:|:.:|:. Customer Advocacy CISCO > -----Original Message----- > From: [email protected]<mailto:[email protected]> > [mailto:[email protected]] On Behalf > Of Michael Richardson > Sent: Saturday, November 02, 2013 12:18 PM > To: IPsecme WG > Subject: Re: [IPsec] AD VPN: discussion kick off > > > {Sorry about that, the email configuration my tablet had a \n in a header > that did not belong} > > I have read all three proposals, although I missed the Q&A in Berlin. > I am looking forward to further Q&A in Berlin. > > When I read the NBMA protocol (DMVPN, I think) version what I saw was a > very brilliant hack that managed to take two code bases (IPsec and ATM) > that were likely already present in that vendor's firmware and connect > them. Likely, it took only a few weeks of brilliant hacking, and it was ready > for customer use. > > I find that this solution for anyone else involves the most amount of new > code, and I think it will the most difficult to support on various mobile and > laptop platforms as it requires new encapsulation modes. > > draft-mao-ipsecme is architecturally the closest to me, and I like the ADS > idea: it seems that it be implemented without any new kernel code, and I > think that if we are trying to get remote warrior and branch office RTP > traffic to take a more direct route, then eliminating the need for a more > network plumbing, and just doing things in IKE is the right answer. (%) > > I don't like having a new protocol: I want it in IKE. While it can and should > run inside the tunnel, I don't see why adding a new port to my IKE daemon > makes my life easier. > > I *do* like the way that DMVPN uses probe packets to discover the end > points of the shorter routes, and I would look forward to including that > mechanism somehow. I don't know how to do that without hacks to the > data plane, which I'd like to avoid. I can imagine some ways to do this with > a > traceroute process, but it seems kludgy and brittle. (really, that's still > dataplane, but it's using an existing mechanism) > > I don't like that DMVPN does not let http traffic continue to travel via HQ's > virus/trojan/netnanny while RTP takes the shortcut. > > > (%)- the plumbing might need a way to sample 5-tuple flows to see if there > is traffic that should be shortcut. However, various schemes to put more > specific SPD entries in that cause key requests might accomplish this > without new kernel code. > > -- > Michael Richardson > -on the road- > > -- > Michael Richardson <[email protected]<mailto:[email protected]>>, > Sandelman Software Works >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
