Re: [IPsec] AD VPN: discussion kick off

["Frederic Detienne (fdetienn)" <[e-mail]>]

Hi Praveen,

I think the discussion has been somewhat use case centric.

Like I said, we can take policy information from any source. The routing protocol captures a mindshare in some deployments but it is not the only one.

In our last iteration (product called FlexVPN but compliant with the draft we issued), we also support a prefix exchange mechanism over IKEv2 using config exchange (INTERNAL_IP4_ADDRESS/MASK and INTERNAL_IP6_ADDRESS/MASK). This turns out to be extremely friendly on the software client (Remote Access scenario) as well as for branch deployments having less requirements on dynamic routing.

We did not feel it necessary to document this since our proposal supports IKEv2 entirely as we repeatedly said. I guess we could...

The network discovery system based on a different protocol allows decoupling from IKE which also means it can be ported to SSL for instance.

This means the DMVPN proposal is suitable for both "small branches" (few prefixes or even PC client) and extremely large and complex networks alike.

regards,

	fred

On 04 Nov 2013, at 20:43, Praveen Sathyanarayan <[e-mail]> wrote:

> Hi Mike,
> 
> I am not sure when you refer to other proposal, you meant ours as well :-). Appreciate your review and feedback. 
> 
> You mentioned 4 points that DMVPN is capable of doing that other proposal falls short. I can speak for our proposal 
> 	• Routing protocol: Our proposal does not prevent running routing protocol either. You can definitely configuring any of the route protocol that supports NBMA or P2MP network (example OSPF, RIP, BGP etc). You need to setup right policies, which will allow routing protocol to exchange routing updates and forward the traffic efficiently. Along with Routing protocol support, it can be deployed without Routing protocol.  As an example, this removes requirement of implementing routing protocol on a mobile device, just for establishing a shortcut tunnel with other mobile device.
> 	• GRE tunneling: In our experience, IPsec tunneling does good job as tunneling protocol. IPsec provides all required structures and protocol extensions to support it. And as far as non-IP based traffic, our proposal does not prevent using GRE over IPSec. So if someone wants to use GRE to encap non-IP packet, they should be able to achieve.
> 	• NHRP Layer: NHRP is a nice protocol but that is defined ATM/FR network in mind. FYI,  Juniper did deploy this protocol to solve Spoke to Spoke shortcut tunnel with our AutoConnect VPN feature. But our experience is, this is nice protocol, but not designed with security in mind. It is a protocol that is not sufficient for IPsec.  This does not provide good authentication mechanism nor authorization mechanism. You can change NHRP protocol to support these Security specific feature, that exactly we did with AutoConnect VPN. At Juniper, before we came up with our proposal, we took a step back, and used our experience with AutoConnect VPN, asked our self, can we solve NHRP requirement with IKE. We found out that IKE has everything that was required to solve and NHRP was just hack to use.  
> 	• IPsec layer: As mentioned by you, IPSec does pretty good job of encryption. To add to that, it also does pretty good job of doing tunneling as well.
> 
> I feel, DMVPN is designed and organized in IOS/Security Gateway architecture in mind. Based on the requirements in RFC 7018 and for modern IPsec architecture requirements (Security Gateway, Mobile devices etc), I feel there is a requirement for new protocol, which can be solved without any complexity that DVMPN or ADS requires.
> 
> Thanks,
> Praveen
> 
> From: "Mike Sullenberger (mls)" <[e-mail]>
> Date: Monday, November 4, 2013 at 8:26 AM
> To: Michael Richardson <[e-mail]>
> Cc: "Stephen Lynn (stlynn)" <[e-mail]>, "[e-mail]" <[e-mail]>, "Mark Comeadow (mcomeado)" <[e-mail]>, "Mike Sullenberger (mls)" <[e-mail]>, "Michael Guilford (mguilfor)" <[e-mail]>, IPsecme WG <[e-mail]>
> Subject: Re: [IPsec] AD VPN: discussion kick off
> 
> 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
> [e-mail]            .:|:.:|:.
> Customer Advocacy          CISCO
>  
>  
>  
>  
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] 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 <[e-mail]>, Sandelman Software Works
> >
>  
>