Subject: Re: [IPsec] AD VPN: discussion kick off

From: "Mike Sullenberger (mls)" <[email-masked]>
Date: Mon, 4 Nov 2013 15:26:02 +0000

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-masked]<mailto:[email-masked]>            .:|:.:|:.
Customer Advocacy          CISCO

> -----Original Message-----
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] 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-masked]<mailto:[email-masked]>>, Sandelman Software Works
>

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Mon, 4 Nov 2013 19:43:31 +0000

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)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 4, 2013 at 8:26 AM
To: Michael Richardson <[email-masked]<mailto:[email-masked]>>
Cc: "Stephen Lynn (stlynn)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Mark Comeadow (mcomeado)" <[email-masked]<mailto:[email-masked]>>, "Mike Sullenberger (mls)" <[email-masked]<mailto:[email-masked]>>, "Michael Guilford (mguilfor)" <[email-masked]<mailto:[email-masked]>>, IPsecme WG <[email-masked]<mailto:[email-masked]>>
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.

Mike.

Mike Sullenberger, DSE

---

From: Stephen Kent <[email-masked]>
Date: Mon, 04 Nov 2013 16:57:18 -0500

Mike,

A couple of your comments caught my attention, as an author of 4301, 02, 
and 03. I admit to not having read the DMVPN proposal, so my comments 
are based only on your message, which argues why DMVPN is the preferred 
solution.
> 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.
IPsec is not just about encryption, although the DMVPN proposal may 
relegate it to that. IPsec provides access control, and, typically, 
authentication. Does DMVPN preserve the access control features of 
IPsec, or are users now relying on a hub to do this, or what?
> ... 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.
More properly, a separate SA, and only if the folks who manage policies 
at each end of the SA decide to provide fine-grained access control for 
the traffic flows. It was not clear to me that the problem statement for 
this work envisioned VPNs of the scale you mention. Also, the comments 
above are a bit confusing. Both end points and security gateways are 
"nodes" wrt IPsec, in the general sense. I can create a selector that 
secures traffic from my node (and point of subnet) to all hosts on a 
subnet, irrespective of how many are present there.
> 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.
At least? Under what circumstances would the number grow by more than a 
factor of two?
> 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.
So, the proposal simplifies use of IPsec by limiting the granularity at 
which SAs may be created? Does it also cause each SA to terminate at a 
hub, so that the security services are no longer e-t-e? In the context 
of the perpass discussions, this seems like a questionable design decision.
Steve

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Tue, 5 Nov 2013 19:41:45 +0000

Hi Stephen,

please find some answers inline.

On 04 Nov 2013, at 22:57, Stephen Kent <[email-masked]> wrote:

> Mike,
> 
> A couple of your comments caught my attention, as an author of 4301, 02, and 03. I admit to not having read the DMVPN proposal, so my comments are based only on your message, which argues why DMVPN is the preferred solution.
>> 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.
> IPsec is not just about encryption, although the DMVPN proposal may relegate it to       that. IPsec provides access control, and, typically, authentication.  Does DMVPN preserve the access control features of IPsec, or are users now relying on a hub to do this, or what?

The proposal relies on everything IKE and IPsec do today. All the cryptography and authentication/authorization mechanisms remain between hub&spokes as well as between spokes.

All the access control features of IPsec and IKE remain untouched.

NHRP only facilitates the network and peer discovery.

>>  ...  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. 
> More properly, a separate SA, and only if the folks who manage policies at each end of the SA decide to provide fine-grained access control for the traffic flows. It was not clear to me that the problem statement for this work envisioned VPNs of the scale you mention. Also, the comments above are a bit confusing. Both end points and security gateways are "nodes" wrt IPsec, in the general sense. I can create a selector that secures traffic from my node (and point of subnet) to all hosts on a subnet, irrespective of how many are present there.  
>> 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.
> At least? Under what circumstances would the number grow by more than a factor of two?

I am not sure I understand your comment. Here is what we are trying to say: Assuming two nodes A and B hosting subnets A1, A2 and B1, B2 respectively (A* and B* not summarizable), the selectors between A and B have a form

A1-B1
A1-B2
A2-B1
A2-B2

yielding up to A# x B# selectors. There can be thousands of A* and B*.

Can you elaborate please ?

>> 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.
> So, the proposal simplifies use of IPsec by limiting the granularity at which SAs may be created? Does it also cause each SA to terminate at a hub, so that the security services are no longer e-t-e?  In the context of the perpass discussions, this seems like a questionable design decision.

Each SA is established between the spokes and the entire IKE/IPsec negotiation takes place between the spokes. The hub does not act as a broker.

thanks,

	fred

---

From: "Mike Sullenberger (mls)" <[email-masked]>
Date: Tue, 5 Nov 2013 19:55:00 +0000

Steve,

Sorry, I wasn't clear on our use of IPsec. We definitely use both the authentication and encryption capabilities of IPsec. We do the following when bringing up a new tunnel.
1.      Trigger ISAKMP/IKEv2/IPsec with an SPD of (LocalPeer IP, RemotePeer IP, GRE).
2.      ISAKMP/IKEv2 authenticates the peers, creates the IKE SAs and the IPsec/Child encryption SAs.
3.      IPsec signals it has authenticated and encryption is ready, the GRE tunnel is activated.
4.      NHRP registration (for spoke-hub) or resolution reply (for final phase of spoke-spoke) are sent over the tunnel.
5.      Routing is brought up over the spoke-hub tunnels.
Also to be clear there are NO packets, control or data plan, that are transferred between the peers outside of the GRE/IPsec encrypted tunnel, except for ISAKMP/IKEv2.  On a router/FW in the middle it would only "see" UDP 500/4500 and ESP (IP 50) packets. Note, you can also use AH, but we generally recommend not to use AH and AH breaks NAT support.

As for scaling, we already have DMVPN networks of 10000+ nodes and looking at building networks of 40000+ nodes.
In many cases customers have multiple subnets behind each node, therefore with just IPsec I would need to have multiple SAs/encryption between the same two nodes, even if you are only doing subnet to subnet SPDs.  Take the case of two nodes that each have 4 subnets. I could need as many as 16 SAs to cover all cases.  Or even a simpler case between a host (1 local address) and a node at a data center (say 20 subnets), I would need up to 20 SAs to cover this.  In many of our networks we are asked to support at least 5 (sometimes 10) subnets per spoke location.

As far as IPv4 and IPv6 support, you are correct it would only double the number of SAs needed, assuming that there are the same number of subnets for IPv4 and IPv6.  From what I have seen IPv6 tends to increase the number of subnets.

For end-to-end encryption, take the case where a spoke node is a host.  Then initially the spoke/host will connect to one or more hubs (we recommend at least 2 for redundancy).  Communication between two such connected hosts would be through the hub and would be two hops (Host1 encrypt-decrypt Hub encrypt-decrypt Host2). Once the shortcut tunnel is setup then communication would be direct between the hosts (Host1 encrypt-decrypt Host2).

Thanks,

Mike.

[X]
Mike Sullenberger, DSE
[email-masked]            .:|:.:|:.
Customer Advocacy          CISCO

From: Stephen Kent [mailto:[email-masked]]
Sent: Monday, November 04, 2013 1:57 PM
To: Mike Sullenberger (mls); Michael Richardson
Cc: Stephen Lynn (stlynn); [email-masked]; Mark Comeadow (mcomeado); Michael Guilford (mguilfor); IPsecme WG
Subject: Re: [IPsec] AD VPN: discussion kick off

Mike,

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.
At least? Under what circumstances would the number grow by more than a factor of two?

Steve

---

From: "Manish Kumar (manishkr)" <[email-masked]>
Date: Tue, 5 Nov 2013 20:49:39 +0000

Hi Stephen,

Thanks for your inputs  vis-a-vis  4301/2/3. I concur that IPSec is not just about encryption but don't quite buy into what somebody spelled out during the meeting as 'IPSec is an access control mechanism that also provides other security services'; IMO, strict access control is more a firewall functionality. RFC 4301 spells out the access control rationale as
"IPsec includes a specification for minimal firewall functionality, since that is an essential aspect of access control at the IP layer… The IPsec firewall function makes use of the cryptographically-enforced authentication and integrity provided for all IPsec traffic to offer better access control than could be obtained through use of a firewall (one not privy to IPsec internal parameters) plus separate cryptographic protection."

I know that we might have ruffled a few feathers wrt making the SPD relatively trivial but let's get down to some details as far as the comparison goes. The first ADVPN proposal does talk about the shortcut suggester possibly including traffic selectors in the shortcut exchange. While this seems to give the notion of the ability to provide SA granularity, the source of such information is a third party (even though both peers have an active connection with this third party) and doesn't quite stand up to the very reason of including access control in IPSec (The IPsec firewall function makes use of the cryptographically-enforced authentication and integrity provided for all IPsec traffic to offer better access control than could be obtained through use of a firewall (one not privy to IPsec internal parameters) plus separate cryptographic protection.) - this is a case of the information not even privy to the same device, leave alone the same layer in the same device.

Let's say, the shortcut suggester passes on an information in the shortcut exchange to the two peers about the selectors (X->Y) to be used for the shortcut while selectors (X'->Y') be still allowed through the spoke-hub-spoke path. It's entirely upto the peers (shortcut partners) to choose what to do with that; well, the draft prescribes that the shortcut partners should use this but when we are talking about multi-vendor, multiple administrative domains, how do we trust that the shortcut partners do that. We must realise that the role of the suggester/hub is more advisory in nature; it can only advise not enforce. The problem is a system wide design problem not one to be sorted out just between two nodes (and IKE is intrinsically designed to operate in a peer-to-peer model), so e.g. even if policies prescribe (as obtained from the shortcut exchange) that a certain traffic be routed via the hub, once the two peers(shortcut partners) have all the authentication information for each other, they might give a damn and say we don't care, lets bypass the policy and use the shortcut for everything leaving the hub in dark. Unlike a traditional IPSec case, where each peer could enforce specific access control policies (e.g. if the peer you negotiated an SA with sends a traffic using an SA which was not supposed to be used for that traffic, you could simply drop it post decryption), the hub can't enforce such policies – it can dictate what doesn't pass through it but not what MUST pass through it, which is what the common requirement is.

What all this effectively means is if really need to enforce access-control policies, it has to be agreed between the spokes/shortcut partners, not prescribed by the hub. IPSec typically deals with a case where the SPD is in place apriori based on which SAs are negotiated but here we end up with a case where the SPDs need to be negotiated and agreed upon as well !!! In that sense, I would say DMVPN still provides better access control – it already determines what portion of the network should use the shortcut depends on the address/subnet sent in NHRP resolution reply. This is used to install shortcut routes and/or policy based routes and the same can be used to also install an ACL if we suspect the peer to play foul. It's another matter that this is not as part of IPSec access control directly. This is on top of the route/forwarding policy based tunnel selection.

- Manish

From: Stephen Kent <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 5 November 2013 3:27 AM
To: Mike Sullenberger <[email-masked]<mailto:[email-masked]>>, Michael Richardson <[email-masked]<mailto:[email-masked]>>
Cc: "Stephen Lynn (stlynn)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Mark Comeadow <[email-masked]<mailto:[email-masked]>>, "Michael Guilford (mguilfor)" <[email-masked]<mailto:[email-masked]>>, IPsecme WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [IPsec] AD VPN: discussion kick off
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: Frederic Detienne <[email-masked]<mailto:[email-masked]>>, Manish Kumar <[email-masked]<mailto:[email-masked]>>, Mike Sullenberger <[email-masked]<mailto:[email-masked]>>
Resent-Date: Tuesday, 5 November 2013 3:27 AM

Mike,

A couple of your comments caught my attention, as an author of 4301, 02, and 03. I admit to not having read the DMVPN proposal, so my comments are based only on your message, which argues why DMVPN is the preferred solution.
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.
IPsec is not just about encryption, although the DMVPN proposal may relegate it tothat. IPsec provides access control, and, typically, authentication.  Does DMVPN preserve the access control features of IPsec, or are users now relying on a hub to do this, or what?
 ...  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.
More properly, a separate SA, and only if the folks who manage policies at each end of the SA decide to provide fine-grained access control for the traffic flows. It was not clear to me that the problem statement for this work envisioned VPNs of the scale you mention. Also, the comments above are a bit confusing. Both end points and security gateways are "nodes" wrt IPsec, in the general sense. I can create a selector that secures traffic from my node (and point of subnet) to all hosts on a subnet, irrespective of how many are present there.
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.
At least? Under what circumstances would the number grow by more than a factor of two?
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.
So, the proposal simplifies use of IPsec by limiting the granularity at which SAs may be created?Does it also cause each SA to terminate at a hub, so that the security services are no longer e-t-e?  In the context of the perpass discussions, this seems like a questionable design decision.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 05 Nov 2013 17:21:51 -0500

Mike,

Thanks for the responses to my comments, including ones from yesterday's 
meeting.
> Steve,
> Sorry, I wasn't clear on our use of IPsec. We definitely use both the 
> authentication and encryption capabilities of IPsec. We do the 
> following when bringing up a new tunnel.
>
>  4. NHRP registration (for spoke-hub) or resolution reply (for final
>     phase of spoke-spoke) are sent over the tunnel.
If a shortcut between two spokes is available, as advised by a hub, that 
requires an SDP entry. Did that entry preexist in the spoke, or was it 
provisioned by a hub in some fashion? If it existed in the spoke, 
initially, "normal" IPsec operation would cause traffic to that spoke to 
trigger formation of an SA to that destination. Can you clarify?
> As for scaling, we already have DMVPN networks of 10000+ nodes and 
> looking at building networks of 40000+ nodes.
> In many cases customers have multiple subnets behind each node, 
> therefore with just IPsec I would need to have multiple SAs/encryption 
> between the same two nodes, even if you are only doing subnet to 
> subnet SPDs.  Take the case of two nodes that each have 4 subnets. I 
> could need as many as 16 SAs to cover all cases.  Or even a simpler 
> case between a host (1 local address) and a node at a data center (say 
> 20 subnets), I would need up to 20 SAs to cover this.  In many of our 
> networks we are asked to support at least 5 (sometimes 10) subnets per 
> spoke location.
That's a helpful clarification. It does not appear to be the sort of 
environment that initially seemed to be the focus of this work, e.g., 
road warriors calling home or home/satellite offices for a moderate size 
enterprise.
> As far as IPv4 and IPv6 support, you are correct it would only double 
> the number of SAs needed, assuming that there are the same number of 
> subnets for IPv4 and IPv6.  From what I have seen IPv6 tends to 
> increase the number of subnets.
I'm glad we're on the same page here.
> For end-to-end encryption, take the case where a spoke node is a 
> host.  Then initially the spoke/host will connect to one or more hubs 
> (we recommend at least 2 for redundancy). Communication between two 
> such connected hosts would be through the hub and would be two hops 
> (Host1 encrypt-decrypt Hub encrypt-decrypt Host2). Once the shortcut 
> tunnel is setup then communication would be direct between the hosts 
> (Host1 encrypt-decrypt Host2).
see my question re the shortcut SPD entries.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 05 Nov 2013 17:22:54 -0500

Manish,
> Hi Stephen,
>
> Thanks for your inputs  vis-a-vis  4301/2/3. I concur that IPSec is 
> not just about encryption but don't quite buy into what somebody 
> spelled out during the meeting as 'IPSec is an access control 
> mechanism that also provides other security services'; IMO, strict 
> access control is more a firewall functionality. RFC 4301 spells out 
> the access control rationale as
> "IPsec includes a specification for minimal firewall functionality, 
> since that is an essential aspect of access control at the IP layer... 
> The IPsec firewall function makes use of the 
> cryptographically-enforced authentication and integrity provided for 
> all IPsec traffic to offer better access control than could be 
> obtained through use of a firewall (one not privy to IPsec internal 
> parameters) plus separate cryptographic protection."

You cited one of several sentences that mention access control in 4301, 
in Section 2.1.  Other quotes, very close to the one you chose, make a 
stronger case for access control as an important element of IPsec:

    The set of

security services offered includes access control, connectionless

integrity, data origin authentication, detection and rejection of

replays (a form of partial sequence integrity), confidentiality (via

encryption), and limited traffic flow confidentiality.

and

    The IPsec firewall function makes use of the

cryptographically-enforced authentication and integrity provided for

all IPsec traffic to offer better access control than could be

obtained through use of a firewall (one not privy to IPsec internal

parameters) plus separate cryptographic protection.

This second quote notes that a separate firewall, operating at the 
Internet layer, is
NOT as secure as the one integrated into IPsec.

> I know that we might have ruffled a few feathers wrt making the SPD 
> relatively trivial but let's get down to some details as far as the 
> comparison goes. The first ADVPN proposal does talk about the shortcut 
> suggester possibly including traffic selectors in the shortcut 
> exchange. While this seems to give the notion of the ability to 
> provide SA granularity, the source of such information is a third 
> party (even though both peers have an active connection with this 
> third party) and doesn't quite stand up to the very reason of 
> including access control in IPSec (The IPsec firewall function makes 
> use of the cryptographically-enforced authentication and integrity 
> provided for all IPsec traffic to offer better access control than 
> could be obtained through use of a firewall (one not privy to IPsec 
> internal parameters) plus separate cryptographic protection.) - this 
> is a case of the information not even privy to the same device, leave 
> alone the same layer in the same device.
OK, this paragraph shows that you do understand the importance of the 
internal firewall in an IPsec implementation. I'm not asserting that 
ADVPN is better or worse in this regard. I just happened to be alerted 
to the issue by the DMVPN message from Mike. I'm equally disappointed 
with any proposal that essentially eliminates the access control feature 
;-) .

Steve

---

From: "Manish Kumar (manishkr)" <[email-masked]>
Date: Tue, 5 Nov 2013 23:44:39 +0000

Steve,

To answer your question, the SPD entries are not already there, they are created as the result of a message exchange between the two spokes; it's the spokes that choose the policy, not the hub. If the SPDs were already there, every IPSec node in the network would need to know about all the networks in the overall topology apriori – to solve this is one of the main drivers of the whole exercise. This becomes even more complex if the hosts (not necessarily an IPSec node) acquire address dynamically and/or are mobile.

Thanks,
Manish

From: Stephen Kent <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 6 November 2013 3:51 AM
To: Mike Sullenberger <[email-masked]<mailto:[email-masked]>>, ipsec <[email-masked]<mailto:[email-masked]>>
Subject: Re: [IPsec] AD VPN: discussion kick off

Mike,

Thanks for the responses to my comments, including ones from yesterday's meeting.
Steve,

Sorry, I wasn’t clear on our use of IPsec. We definitely use both the authentication and encryption capabilities of IPsec. We do the following when bringing up a new tunnel.

If a shortcut between two spokes is available, as advised by a hub, that requires an SDP entry. Did that entry preexist in the spoke, or was it provisioned by a hub in some fashion? If it existed in the spoke, initially, "normal" IPsec operation would cause traffic to that spoke to trigger formation of an SA to that destination. Can you clarify?
 As for scaling, we already have DMVPN networks of 10000+ nodes and looking at building networks of 40000+ nodes.
In many cases customers have multiple subnets behind each node, therefore with just IPsec I would need to have multiple SAs/encryption between the same two nodes, even if you are only doing subnet to subnet SPDs.  Take the case of two nodes that each have 4 subnets. I could need as many as 16 SAs to cover all cases.  Or even a simpler case between a host (1 local address) and a node at a data center (say 20 subnets), I would need up to 20 SAs to cover this.  In many of our networks we are asked to support at least 5 (sometimes 10) subnets per spoke location.
That's a helpful clarification. It does not appear to be the sort of environment that initially seemed to be the focus of this work, e.g., road warriors calling home or home/satellite offices for a moderate size enterprise.
 As far as IPv4 and IPv6 support, you are correct it would only double the number of SAs needed, assuming that there are the same number of subnets for IPv4 and IPv6.  From what I have seen IPv6 tends to increase the number of subnets.
I'm glad we're on the same page here.
 For end-to-end encryption, take the case where a spoke node is a host.  Then initially the spoke/host will connect to one or more hubs (we recommend at least 2 for redundancy).  Communication between two such connected hosts would be through the hub and would be two hops (Host1 encrypt-decrypt Hub encrypt-decrypt Host2). Once the shortcut tunnel is setup then communication would be direct between the hosts (Host1 encrypt-decrypt Host2).
see my question re the shortcut SPD entries.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 05 Nov 2013 22:34:28 -0500

Manish,
> Steve,
>
> To answer your question, the SPD entries are not already there, they 
> are created as the result of a message exchange between the two 
> spokes; it's the spokes that choose the policy, not the hub. If the 
> SPDs were already there, every IPSec node in the network would need to 
> know about all the networks in the overall topology apriori -- to 
> solve this is one of the main drivers of the whole exercise. This 
> becomes even more complex if the hosts (not necessarily an IPSec node) 
> acquire address dynamically and/or are mobile.
So the spokes, while connected through the hub, exchange messages to 
cause SPD entries to be created. What protocol is used to do this?

Steve

p.s. please use the correct (vs.the Cisco-preferred?) spelling, i.e., 
IPsec, vs. IPSec.

---

From: "Manish Kumar (manishkr)" <[email-masked]>
Date: Wed, 6 Nov 2013 15:53:12 +0000

Steve,

NHRP is used to resolve the remote peer which serves/owns the address we're interested in. The information in this resolution culminates in the creation of SPD.

Manish

From: Stephen Kent <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 6 November 2013 9:04 AM
To: Manish Kumar <[email-masked]<mailto:[email-masked]>>, Mike Sullenberger <[email-masked]<mailto:[email-masked]>>, ipsec <[email-masked]<mailto:[email-masked]>>
Subject: Re: [IPsec] AD VPN: discussion kick off

Manish,
Steve,

To answer your question, the SPD entries are not already there, they are created as the result of a message exchange between the two spokes; it's the spokes that choose the policy, not the hub. If the SPDs were already there, every IPSec node in the network would need to know about all the networks in the overall topology apriori – to solve this is one of the main drivers of the whole exercise. This becomes even more complex if the hosts (not necessarily an IPSec node) acquire address dynamically and/or are mobile.
So the spokes, while connected through the hub, exchange messages to cause SPD entries to be created. What protocol is used to do this?

Steve

p.s. please use the correct (vs.the Cisco-preferred?) spelling, i.e., IPsec, vs. IPSec.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 06 Nov 2013 11:09:44 -0500

Manish,
> Steve,
>
> NHRP is used to resolve the remote peer which serves/owns the address 
> we're interested in. The information in this resolution culminates in 
> the creation of SPD.
So the NHRP interaction creates a new SPD entry as a side effect? This 
entry is
more specific re selector values (for IP addresses), and that causes 
traffic to trigger
an IKE SA for the shortcut route, and then child SAs are created, right?

I presume this is new functionality for NHRP (given te age of that RFC), 
and is viewed as
an external management interface to IPsec, for SDP maintenance. Is it 
safe to assume that
the SPD  selectors are the same for every NHRP-triggered SA pair? Since 
(I believe) that NHRP
doesn't care about higher layer protocols, and since the SA is transport 
mode and
encapsulating GRE, that means that no transport protocol/port access 
controls are imposed on
the SA, right?

Is there a corresponding management mechanism, tied to NHRP, to cause 
these SAs to
terminate, or do you rely on the SA lifetime values to time out these 
shortcut SAs?
How are these values managed?

Steve

---

From: Yoav Nir <[email-masked]>
Date: Wed, 6 Nov 2013 18:01:08 +0000

On Nov 6, 2013, at 7:53 AM, Manish Kumar (manishkr) <[email-masked]<mailto:[email-masked]>> wrote:

Steve,

Manish

Hi, Manish

Wouldn't it be more correct to say that the side effect of NHRP resolution creates a PAD entry for the discovered node, and an SPD entry for GRE traffic to that newly discovered node?

Yoav

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Nov 2013 13:10:17 -0500

Manish Kumar (manishkr) <[email-masked]> wrote:
    > we're 
    > interested in. The information in this resolution culminates in the
    > creation of 
    > SPD.

I think your description is not quite precise enough for SK; so I want to
restate this for the list, even though we discussed this at the meeting.

The result of the NHRP (which runs inside the GRE/IPsec tunnels) creates a
new GRE/IPsec SPD to connect the spokes that have the remote peers.

The SPD that gets created does not mention the remote peers, that part is
done in the routing algorithm. 

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 Nov 2013 04:30:58 +0200

Mike Sullenberger (mls) writes:
> looking at building networks of 40000+ nodes. In many cases
> customers have multiple subnets behind each node, therefore with
> just IPsec I would need to have multiple SAs/encryption between the
> same two nodes, even if you are only doing subnet to subnet SPDs.

Why do you need multiple SAs even if there is multiple subnets? IKEv2
allows you to create Child SAs covering multiple subnets in both ends,
so you should be able to use just one Child SA as long as the number
of subnets is less than few hundred... There is limit of 255 traffic
selector per Child SA, but I would except that implementations might
not support that high number, but tens of selectors should be ok. 

> Take the case of two nodes that each have 4 subnets. I could need as
> many as 16 SAs to cover all cases. Or even a simpler case between a
> host (1 local address) and a node at a data center (say 20 subnets),
> I would need up to 20 SAs to cover this. In many of our networks we
> are asked to support at least 5 (sometimes 10) subnets per spoke
> location.

All of those would require one Child SA in IKEv2. If talking about
obsolete protocols from the historic times, then you might have needed
multiple SAs....

> As far as IPv4 and IPv6 support, you are correct it would only double the
> number of SAs needed, assuming that there are the same number of subnets for
> IPv4 and IPv6.  From what I have seen IPv6 tends to increase the number of
> subnets.

IPv4 and IPv6 traffic most likely do need separate SAs, as some
implementations do things that way, i.e. if you offer both IPv4 and
IPv6 addresses in the proposal the other end will narrow it down to
include only IPv4 or IPv6 addresses (or it can accept the SA if it
understand internally that even if there is both IPv4 and IPv6 address
in traffic selector list, that does not mean you can have packets
where source address is IPv4 and destination IPv6 :-)
-- 
[email-masked]

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Fri, 8 Nov 2013 09:43:54 +0000

Hi Tero,

yes you are right about the Child SA and definition. I think what Mike had in mind is that in some platform architectures the selectors have to be expanded in TSi x TSr entries which is not very friendly.

When we developed the protocol with IKEv1, multiple SA's simply were a no-no.

When we evaluated IKEv2, the 255 limit was anyway still a problem and we kept tunneling method unchanged. The 255 limit is definitely too short for practical designs.

Thanks!

	fred

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Fri, 8 Nov 2013 13:01:12 +0000

On 06 Nov 2013, at 17:09, Stephen Kent <[email-masked]> wrote:

> So the NHRP interaction creates a new SPD entry as a side effect? This entry is
> more specific re selector values (for IP addresses), and that causes traffic to trigger

NHRP create a new SPD entry that protects GRE between two spokes. It also creates a new GRE tunnel (or a new tunnel endpoint) to that same spoke.

NHRP finally creates a prefix in the routing table or a policy that forces the traffic into that new tunnel.

> I presume this is new functionality for NHRP (given te age of that RFC), and is viewed as 
> an external management interface to IPsec, for SDP maintenance. Is it safe to assume that 
> the SPD  selectors are the same for every NHRP-triggered SA pair? Since (I believe) that NHRP 
> doesn't care about higher layer protocols, and since the SA is transport mode and 
> encapsulating GRE, that means that no transport protocol/port access controls are imposed on 
> the SA, right?

The selectors are GRE-hostA-hostB and are traffic agnostic.

NHRP installs policies that decide the traffic needs to be forwarded (and given to a particular SA).

I.e. instead of having IPsec determine the peer after matching specific selectors, the peer is first selected based on a policy (routing table, policy route…) and the traffic is then protect with the generic GRE traffic selector leading to host-B.

NHRP alone only cares about network prefixes and not traffic types. When we reach to use cases, we tend to revert to policy routing that would provide the granularity you are talking about.

> Is there a corresponding management mechanism, tied to NHRP, to cause these SAs to
> terminate, or do you rely on the SA lifetime values to time out these shortcut SAs?

Both IPsec and NHRP have hold timers. We refresh the entries if they have been used before expiration.

The IPsec/IKE SA's can be torn down for the same reasons a classical IKE/IPsec session can be torn down (eg. peer certificate expiry, explicit administrative control, receiving of a delete-notify, liveness checks …)

It is sufficient for one of the entries (NHRP or SA) to disappear to take down the other entries. E.g. if the IPsec SA is deleted, the corresponding tunnel or tunnel endpoint is torn down, the NHRP entries are deleted and the forwarding policies are removed.

regards,

	fred

> Steve
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Fri, 8 Nov 2013 13:02:14 +0000

On 06 Nov 2013, at 19:01, Yoav Nir <[email-masked]> wrote:

> 
> On Nov 6, 2013, at 7:53 AM, Manish Kumar (manishkr) <[email-masked]> wrote:
> 
>> Steve,
>> 

that is one of seeing it. I think it is correct. It depends on the point of view but from an IPsec point of view, this is the net effect.

	fred

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Fri, 8 Nov 2013 13:05:27 +0000

> done in the routing algorithm. 

this is another way of doing it.

Technically, we create a full fledged SA (protecting GRE hostA hostB) but the selection of the remote host is done before the SPD lookup. We first determine the host (forwarding algorithm) and then we pass the packet to the SA for that specific host.

I think Yoav's view of calling is a PAD more accurately describes our implementation but we do not mandate an implementation.

thx,

	fred

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Fri, 8 Nov 2013 13:05:57 +0000

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 <[email-masked]> wrote:

> 	• 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.
> 
> From: "Mike Sullenberger (mls)" <[email-masked]>
> To: Michael Richardson <[email-masked]>
> Cc: "Stephen Lynn (stlynn)" <[email-masked]>, "[email-masked]" <[email-masked]>, "Mark Comeadow (mcomeado)" <[email-masked]>, "Mike Sullenberger (mls)" <[email-masked]>, "Michael Guilford (mguilfor)" <[email-masked]>, IPsecme WG <[email-masked]>
> 	• 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.
>  
> 	• 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).
>  
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Michael Richardson

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Fri, 8 Nov 2013 13:09:51 +0000

Hi Stephen,

> That's a helpful clarification. It does not appear to be the sort of environment that initially seemed to be the focus of this work, e.g., road warriors calling home or home/satellite offices for a…

In fact, there are multiple environments in play. From simple networks to complex network. The DMVPN proposal addresses both.

regards,

	fred

---

From: Stephen Kent <[email-masked]>
Date: Fri, 08 Nov 2013 12:56:03 -0500

Fred,

Thanks for the detailed answers to all of my questions.

I look forward to seeing the description of how DMVPN relates to the
processing model defined in RFC 4301 (Figures 1, 2, and 3).

Steve