Subject: [IPsec] NUDGE: Reviewing the AD VPN drafts

From: Paul Hoffman <[email-masked]>
Date: Wed, 2 Oct 2013 09:14:29 -0700

Greetings again.

As we announced, we will be having a virtual interim meeting next Wednesday, October 9. The agenda is:

- Detailed presentations of two AD VPN drafts: draft-detienne-dmvpn-00 and draft-mao-ipsecme-ad-vpn-protocol-02. [This is the main focus of the meeting.]
- A short discussion of draft-ietf-ipsecme-esp-ah-reqts-01.

To ensure an effective discussion, we request WG members to have a quick review of the two AD VPN drafts. We suggest that you don't review any of them in detail, instead just consider whether the proposed approach seems to be technically sound and in line with the AD VPN requirements. Please send a short email to the list regarding one of the drafts (or, preferably one email about each) by Wednesday of this week, so we can start a discussion on the mailing list that will help the discussion at the virtual interim meeting.

Thanks,
  Paul and Yaron

---

From: Yoav Nir <[email-masked]>
Date: Wed, 2 Oct 2013 18:44:23 +0000

Hi

I have read the DM-VPN draft. I would not call my reading a review, as it was quite superficial, but here's some thoughts:

- I have to admit that I'm still having trouble wrapping my head around some of the concepts. I understand domain-based and route-pased VPNs, as well as IPsec and GRE tunnels. But I haven't thought of all the VPN endpoints as actually being on the same network. In fact I always thought of VPN as an abstract concept or as a bunch of tunnels, not as a real network. Having said that, I'm still trying to get used to the idea of NHRP being used for discovery (and to the idea of NHRP itself). To my mind a VPN is not an NBMA, but that does not mean an NBMA cannot serve as a good model for a VPN.

- I like how the process described in section 4.3 to 4.6 quickly converges. If host a behind gateway A sends packets to host e behind gateway E, and the packets travel though the tunnels AB, BC, CD, and DE, then the discovery process might go through several hops, but the next tunnel to be set up is AE. There is no case of setting up AC or AD.

- Reading section 4.8, I see that within a single DM-VPN, there is a natural progression from hub&spoke to mesh. There doesn't seem to be a place for policy on whether a shortcut should or should not be established. The resolution request is forwarded until the egress node. So if, for example, you have two government agencies, each with its own set of gateways, and two gateways (one belonging to each agency) have a tunnel between them, there are two possible configurations: a single DM-VPN, in which case they become a mesh, or two DM-VPNs, so that the interdomain tunnel endpoints are egress nodes on their respective DM-VPNs. Is there a way to implement a policy so that some shortcuts are created between those other gateways?

- Section 4.10 seems to be missing something. Suppose gateway A is forwarding traffic to gateway B, and receives an Indirection notification. So A sends a Resolution request. After a while, it receives a Resolution reply with TunS2 and PubS2 addresses. So now A should open a tunnel with TunS2 (right? I'm not clear about the fields). So section 4.10 says that authentication between these two nodes will be done using certificates. Considering that A has only just heard of TunS2's existence, what fields are there going to be in the certificate that will let A know that this is indeed TunS2? While a single domain might have some convention for this, AD-VPN is supposed to be good for multiple administrative domains, so there should be some rule about this.

- The same section hints at using certificate fields for filtering. This sounds weird. Suppose two gateways learn of each other through the resolution process. Now they try to connect, only to find out that the certificate fields do not allow them to connect. So we've gone through an entire IKE handshake just to discover that policy prohibits forming this tunnel? And because caches expire, the gateways will try again and again to form this tunnel, all the time failing on authorization. 

Yoav

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Oct 2013 09:57:10 -0400

I've also read both documents.

Yoav Nir <[email-masked]> wrote:
    > itself). To my mind a VPN is not an NBMA, but that does not mean an
    > NBMA cannot serve as a good model for a VPN.

I agree.  I like the idea of thinking of it as an NBMA, but not the idea of
using the layer-2 protocol *directly*.  It is clearly a quick (but
Brilliant!) hack inside IOS to reuse some layer-2 ATM code over a WAN.

I also do not like the lack of policy control that GRE/IPsec implies,
specifically it directly leads to LPM only routing, and your comment:

    > natural progression from hub&spoke to mesh. There doesn't seem to be a
    > place for policy on whether a shortcut should or should not be
    > established.

This is really a direct result.
It's not clear to me what prevents parts of the mesh from impersonating other
parts,  etc.

======

I also read: draft-mao-ipsecme-ad-vpn-protocol and while conceptually I found
it okay, I think that the protocol should be inside IKE.

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

---

From: Yoav Nir <[email-masked]>
Date: Thu, 3 Oct 2013 21:21:16 +0000

> it okay, I think that the protocol should be inside IKE.

Funny, I came to the opposite conclusion. I think it's too much like IKE.

But actually, this should be split in two. 

ADC to ADC communications, like the REDIRECT and SESSION could easily run over an Informational exchange in IKE. 

But the ADC to ADS communications are, to quote section 1.1, "a client and server protocol". And there is no reason to assume that the ADS can even do IKE - it's a controller. So I think those parts of the protocol could be done in a web service.

But, why am I designing someone else's proposal?

---

From: Yoav Nir <[email-masked]>
Date: Thu, 3 Oct 2013 21:46:28 +0000

Hi

There is something that I think is missing from all three proposals, and that is the handling of duplicate protected networks. As long as we live in a predominantly IPv4 world, we have a lot of NATs and a lot of RFC 1918 addresses.

So unprotected traffic from such networks gets NATted by the perimeter gateway (or a dedicated device between the gateway and the Internet). For protected traffic, there qre two options:

1. Translate the traffic before sending it through the tunnel, or
2. Send packets from non-routable addresses through the tunnel

Option #1 has a weird side effect. If the translated address is a routable address of the gateway, the peer gateway cannot forward it to the Internet without translating it again: the return packets would go directly to the original gateway, creating some asymmetric routing.

So let's assume option #2, the other tunnel endpoint will NAT the traffic behind itself if it forwards the traffic to the Internet. If it forwards the traffic through another tunnel, it has the same choices as the first gateway. But if it forwards the traffic to its own protected domain, it has two options
1. Forward them as is. That requires that there be no duplicates, and that routing will be set up so that return packets go to this gateway., or
2. NAT the packets behind itself.

There are more subtleties to this, but it's a complexity that network people deal with all the time. The NATs are configured where appropriate, and collisions are avoided through a combination of NATs and a manual partitioning of the RFC 1918 space.

All this goes out the window the moment you try to connect with other administrative domains or worse - merge some administrative domains. And a dynamic setup of tunnels runs a high risk of having the same network on both sides of the tunnel. 

Consider the trivial example. Host a, behind gateway A, sends traffic to host c behind gateway C, but the traffic goes through gateway B, which is the hub gateway. c is a server, so it has port forwarding on gateway C, and C belongs to another organization. A is the gateway of a branch office. Every branch office has a different 192.168.x.0/24 subnet, so within the administrative domain, all hosts have unique IPs. 

So A sends the ac packet unmodified. B is an egress gateway, so it NATs all such addresses behind itself. That's OK because a is a client.

Now, regardless of which solution we choose, it is decided that A should send traffic directly to C, skipping B. But that means that A should now NAT the packets, because C does not wish to receive non-routable IP addresses from a partner. It has its own 192.168.x.x addresses within its network.  But here's a problem. Regardless of whether A does or does not NAT when sending traffic to C, connections are going to be severed. Why? Because the source IP address of the traffic coming from 'a' changes. Before 'c' got the traffic from B's public address. But now it's coming either from 'a''s non-routable address, or from A's public address. Either way, TCP connections get severed.

I don't think this issue is addressed in any of the current drafts.

Yoav

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Oct 2013 19:30:54 -0400

Yoav Nir <[email-masked]> wrote:
    >> I also read: draft-mao-ipsecme-ad-vpn-protocol and while conceptually
    >> I found it okay, I think that the protocol should be inside IKE.

    > ADC to ADC communications, like the REDIRECT and SESSION could easily
    > run over an Informational exchange in IKE.

I agree.

    > But the ADC to ADS communications are, to quote section 1.1, "a client
    > and server protocol". And there is no reason to assume that the ADS can
    > even do IKE - it's a controller. So I think those parts of the protocol
    > could be done in a web service.

I think that the right model to think about here is EAP, IKE, Radius.

I think that the much of the ADC<->ADS protocol is EAP-like in nature.
I think that it should be carried in IKE, much like EAP is, to a hub.
The Hubs (which are small in number, and are well managed) would speak carry
ADVPN in PROTOCOL X, to the ADS.

Protocol X may well be TCP over IPsec, or just TCP, or maybe it's RESTful HTTP(s).

I don't think it matters a hoot if the ADS can do IPsec. It's IKE.
IKE is a UDP based protocol, and if you remove the IPsec requirement, it's
just another deamon.

It is the *HUB* and the *SPOKES* where I think one wants to remove as many
moving parts as possible, and in particular, remove any additional
firewall/policy complexity.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Oct 2013 19:46:12 -0400

Yoav Nir <[email-masked]> wrote:

    > There is something that I think is missing from all three proposals,
    > and that is the handling of duplicate protected networks. As long as we
    > live in a predominantly IPv4 world, we have a lot of NATs and a lot of
    > RFC 1918 addresses.

That's one of the reasons I think that it should run inside IKE, so that we
don't have issues of how the spokes talk to the "ADS"...

    > All this goes out the window the moment you try to connect with other
    > administrative domains or worse - merge some administrative
    > domains. And a dynamic setup of tunnels runs a high risk of having the
    > same network on both sides of the tunnel.

I think that connecting multiple adminstrative domains together just won't
work.  You have to go through a HUB machine that does the appropriate
(double?) NAT.   Further, you simply have no way to know, when the client
says he wants to talk to 192.168.1.1, which machine they mean.

So:
  1) protocol must support IPv6.
  2) protocol SHOULD support doing lookups using IPv4-mapped IPv6 addresses
     I'm thinking about some variations of RFC 6333
     Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion
     being used, but I have to think about it more.

     Consider further how a Teredo-type IPv6 address can incorporate
     an IPv4 + port number, and if one then does *ADVPN* for that
     address...

  3) It's less of a big deal to connect the two adminstrative domains
     given ADVPN:  one can have as many NAT44 machines as one needs to
     get the job done, and they can be distributed into as many data
     centres as one likes, because the ADVPN protocol would just
     direct the spokes in a consistent and load balanced way.

  4) IPv6 traffic goes direct, or goes through a NAT'ess ADVPN router.

One still has the problem that two end systems have difficulty addressing
each other, but potentially the address each gets NAT'ed to that leads to
the other system could concievably be managed by the same ADVPN multi-realm
hub.

    > Now, regardless of which solution we choose, it is decided that A
    > should send traffic directly to C, skipping B. But that means that A
    > should now NAT the packets, because C does not wish to receive
    > non-routable IP addresses from a partner. It has its own 192.168.x.x
    > addresses within its network.  But here's a problem. Regardless of
    > whether A does or does not NAT when sending traffic to C, connections
    > are going to be severed. Why? Because the source IP address of the
    > traffic coming from 'a' changes. Before 'c' got the traffic from B's
    > public address. But now it's coming either from 'a''s non-routable
    > address, or from A's public address. Either way, TCP connections get
    > severed.

What you say is true.
But, if the goal is to shortcut things like media traffic,  then it might
be okay.  The media setup protocol may be able to deal with the changes to the
addresses/port numbers.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Mike Sullenberger (mls)" <[email-masked]>
Date: Sun, 6 Oct 2013 19:45:14 +0000

Hi Yoav,

I thought I would answer your questions about DMVPN.   I also think that there are a couple places where we need to clarify some concepts in the draft.

More inline.

Thanks,

Mike.

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Yoav Nir
> Sent: Wednesday, October 02, 2013 11:44 AM
> To: Paul Hoffman
> Cc: [email-masked] WG
> Subject: Re: [IPsec] NUDGE: Reviewing the AD VPN drafts
> 
> Hi
> 
> I have read the DM-VPN draft. I would not call my reading a review, as it was
> quite superficial, but here's some thoughts:
> 
> - I have to admit that I'm still having trouble wrapping my head around some
> of the concepts. I understand domain-based and route-based VPNs, as well
> as IPsec and GRE tunnels. But I haven't thought of all the VPN endpoints as
> actually being on the same network. In fact I always thought of VPN as an
> abstract concept or as a bunch of tunnels, not as a real network. Having said
> that, I'm still trying to get used to the idea of NHRP being used for discovery
> (and to the idea of NHRP itself). To my mind a VPN is not an NBMA, but that
> does not mean an NBMA cannot serve as a good model for a VPN.

It is true that we normally have a single tunnel subnet (IP addresses on the tunnel interfaces), but it isn't a requirement, we can support using tunnels with different subnets in the same DMVPN. Though often within a single domain/area having the tunnels in the same subnet works well for grouping those nodes.  Spokes in region A connect to Region A Hub and Spokes in region B connect to region B Hub.  Region A and B hubs connect to central hub. This could be divided into three tunnel subnets (Region A, B and Central).  We still support dynamic spoke-spoke tunnels between any pair of nodes (spoke in A - spoke in A, spoke in A - spoke in B, Spoke in A or B - Central Hub, Region A Hub - Region B Hub, spoke in A - Region B Hub, spoke in B Region A Hub).

The use of GRE with NHRP was our way of using layering to solve issues.  By separating the tunneling function from the encryption function we solve a number of issues.
1. Encryption only has to deal with encrypting the GRE/IP tunnel packet so there is at most one set of encryption selectors between encryption peers needed, no matter how many host data flows or subnets are using the tunnel.
2. We naturally handle two VPN gateways supporting the same hosts/subnets. The remote peer can use regular routing/forwarding to forward traffic over the two tunnels to one or both (load-balancing) to the VPN gateways.
3. It is easy to add other passenger protocols, because we only need to add them to GRE (Protocol Type field in header) and to NHRP (is designed to handle multiple passenger protocol types). For example: this made it easy to add IPv6 passenger support.

> - I like how the process described in section 4.3 to 4.6 quickly converges. If
> host a behind gateway A sends packets to host e behind gateway E, and the
> packets travel though the tunnels AB, BC, CD, and DE, then the discovery
> process might go through several hops, but the next tunnel to be set up is
> AE. There is no case of setting up AC or AD.

We worked fairly diligently to make it so we only build the end-to-end tunnel (ingress-egress) tunnel.

> - Reading section 4.8, I see that within a single DM-VPN, there is a natural
> progression from hub&spoke to mesh. There doesn't seem to be a place for
> policy on whether a shortcut should or should not be established. The
> resolution request is forwarded until the egress node. So if, for example,
> you have two government agencies, each with its own set of gateways, and
> two gateways (one belonging to each agency) have a tunnel between them,
> there are two possible configurations: a single DM-VPN, in which case they
> become a mesh, or two DM-VPNs, so that the inter-domain tunnel endpoints
> are egress nodes on their respective DM-VPNs. Is there a way to implement
> a policy so that some shortcuts are created between those other gateways?

Yes you can.  This would be controlled on the gateways.  They could be configured to send or not to send indirection messages depending on destination subnet or routing to the destination subnet. That would suppress indirection messages when you don't want a spoke-spoke tunnel at all.  Otherwise an indirection message would be sent, which would generate a resolution request. The resolution request goes through the same path as the data packets that triggered the indirection.  At this point the gateways on either side of the inter-government tunnel have the choice of answering the resolution request themselves (shortcut the end-end tunnel) or forwarding the resolution request (allow the end-end tunnel).  Note, the endpoint devices will not know the difference. I think that this is not very clear in the draft, and we will have to expand the explanation.

> - Section 4.10 seems to be missing something. Suppose gateway A is
> forwarding traffic to gateway B, and receives an Indirection notification. So
> A sends a Resolution request. After a while, it receives a Resolution reply
> with TunS2 and PubS2 addresses. So now A should open a tunnel with TunS2
> (right? I'm not clear about the fields).

Two things can happen, when B receives the resolution request from A, within the request is the TunS1 and PubS1 addresses.
1. B now has sufficient information to initiate the tunnel (PubS2 - PubS1) back to A.  Assuming B authenticates with A and they have common crypto parameters, then B will send the resolution reply through this new tunnel.  When A receives the resolution reply it will check to initiate a tunnel back to B (PubS1-  PubS2) only to find on already exists and it only needs to change the packet forwarding to send data packets over the new tunnel.
2. B sends the resolution reply back to A via the gateway/hub path.  A receives the resolution reply and it now has sufficient information to initiate the tunnel (PubS1 - PubS2) to B. Once the tunnel is setup the A can change the packet forwarding to send data packets over the new tunnel.

Note, this describes the interaction for data traffic going from A to B. It is assumed that there will also be corresponding data traffic going from B to A.  The same above actions take place relative to this "return" traffic.  But, since the tunnels use PubS1 and PubS2 as the endpoints we only get one tunnel/encryption between these two endpoints which is used for the by directional traffic within two data subnets.  Note, if there is only one-way data traffic (say A  to B) everything still works, it is just that B will never send a resolution request nor receive a resolution reply and not modify its routing/forwarding for corresponding packets going B to A. The A to B traffic will flow over the tunnel.

> So section 4.10 says that
> authentication between these two nodes will be done using certificates.
> Considering that A has only just heard of TunS2's existence, what fields are
> there going to be in the certificate that will let A know that this is indeed
> TunS2? While a single domain might have some convention for this, AD-VPN
> is supposed to be good for multiple administrative domains, so there
> should be some rule about this.

The assumption has been that the certificates have a common node in the certificate chain or the nodes have multiple certificate chains installed so that they can authenticate each other.  I agree that this may not cover all inter-domain scenarios.  You could add the capability in the Gateway nodes (those that have the inter-domain interconnect tunnel) for them to attach any needed certificate information to the resolution request and replies.  This would mean that for these types of connections you would use option 2 in the above forwarding of request and replies. 
 
> - The same section hints at using certificate fields for filtering. This sounds
> weird. Suppose two gateways learn of each other through the resolution
> process. Now they try to connect, only to find out that the certificate fields
> do not allow them to connect. So we've gone through an entire IKE
> handshake just to discover that policy prohibits forming this tunnel? And
> because caches expire, the gateways will try again and again to form this
> tunnel, all the time failing on authorization.

I covered this above.  If the policy is such that if two nodes should not build a direct tunnel then they or their gateways should be configured to block sending indirection messages, block sending resolution requests, block sending resolution replies (optional to send NACK resolution reply).  Also indirection messages must be rate-limited so if the above condition is transitory, we don't trigger the end nodes "too often" to attempt to set up the direct tunnel.

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

---

From: "Manish Kumar (manishkr)" <[email-masked]>
Date: Mon, 7 Oct 2013 17:47:20 +0000

Hi Yoav,

Thanks for your comments. I would try adding clarity to some of these
inline [Manish] to supplement what Mike said.

Manish

On 03/10/13 12:14 AM, "Yoav Nir" <[email-masked]> wrote:

>Hi
>
>I have read the DM-VPN draft. I would not call my reading a review, as it
>was quite superficial, but here's some thoughts:
>
>- I have to admit that I'm still having trouble wrapping my head around
>some of the concepts. I understand domain-based and route-pased VPNs, as
>well as IPsec and GRE tunnels. But I haven't thought of all the VPN
>endpoints as actually being on the same network. In fact I always thought
>of VPN as an abstract concept or as a bunch of tunnels, not as a real
>network. Having said that, I'm still trying to get used to the idea of
>NHRP being used for discovery (and to the idea of NHRP itself). To my
>mind a VPN is not an NBMA, but that does not mean an NBMA cannot serve as
>a good model for a VPN.

[Manish]: What the applications running over the VPN see a VPN as (NBMA or
otherwise), depends a lot on the services provided on the VPN and the
draft doesn't preclude any possibilities that way.
RFC 4301 already prescribes the arms and ammunitions needed to protect IP
packets (when used in connection with GRE can be used to protect IP
multicast as well as non-IP packets) over untrusted networks. Also, as
appropriately noted in the requirements document, 4301 is silent on the
way the IPSec databases are populated. So the problem is essentially of
discovery and resolution. The discovery can be left to the routing
protocol but the resolution would still be needed unless IGPs are
multi-protocol, which they typically aren't. Even if they were, this would
need a next-hop preservation which won't scale. So, essentially DMVPN
picks up an appropriate address resolution protocol in NHRP which is
enhanced to support both discovery and resolution. This is combined with
GRE to make sure IP multicast and non-IP packets can be seamlessly(without
changing any other layer/protocol) carried across the same tunnel and also
to simplify the SPDs.

>
>- I like how the process described in section 4.3 to 4.6 quickly
>converges. If host a behind gateway A sends packets to host e behind
>gateway E, and the packets travel though the tunnels AB, BC, CD, and DE,
>then the discovery process might go through several hops, but the next
>tunnel to be set up is AE. There is no case of setting up AC or AD.
>
>- Reading section 4.8, I see that within a single DM-VPN, there is a
>established. The resolution request is forwarded until the egress node.
>So if, for example, you have two government agencies, each with its own
>set of gateways, and two gateways (one belonging to each agency) have a
>tunnel between them, there are two possible configurations: a single
>DM-VPN, in which case they become a mesh, or two DM-VPNs, so that the
>interdomain tunnel endpoints are egress nodes on their respective
>DM-VPNs. Is there a way to implement a policy so that some shortcuts are
>created between those other gateways?
>
>forwarding traffic to gateway B, and receives an Indirection
>notification. So A sends a Resolution request. After a while, it receives
>a Resolution reply with TunS2 and PubS2 addresses. So now A should open a
>tunnel with TunS2 (right? I'm not clear about the fields). So section
>4.10 says that authentication between these two nodes will be done using
>certificates. Considering that A has only just heard of TunS2's
>existence, what fields are there going to be in the certificate that will
>let A know that this is indeed TunS2? While a single domain might have
>some convention for this, AD-VPN is supposed to be good for multiple
>administrative domains, so there should be some rule about this.
>
>- The same section hints at using certificate fields for filtering. This
>sounds weird. Suppose two gateways learn of each other through the
>resolution process. Now they try to connect, only to find out that the
>certificate fields do not allow them to connect. So we've gone through an
>entire IKE handshake just to discover that policy prohibits forming this
>tunnel? And because caches expire, the gateways will try again and again
>to form this tunnel, all the time failing on authorization.

[Manish]: Iff routing and NHRP policies(in general, all upper layer
policies) allow the shortcut, IKE proceeds till Auth the first time and
fails; this can be conveyed back to the upper layer (NHRP) with an
appropriate error code, which sends a NACK resolution reply. The NACK
serves to stop further resolutions either permanently or for an interval
either configured or communicated by the peer.

---

From: Toby Mao <[email-masked]>
Date: Tue, 8 Oct 2013 23:44:07 +0800

> ADC to ADC communications, like the REDIRECT and SESSION could easily run over an Informational exchange in IKE.

[Toby]: Yes, it may be, but I think the ADVPN protocol should be a
seperate and complete protocol, thus it is better not to extend IKE
protocol, it can be protected by IKE/IPsec protocol.

> But, why am I designing someone else's proposal?

[Toby]: For ADVPN solution, the main goal of ADVPN protocol is to
discover IPsec peer neighbor on demand and establish a shortcut
tunnel. To find the shortcut path efficiently, It maintains the
private network information and private/public address. It is
different with IKE protocol, so it can be a totally new protocol.

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Wed, 9 Oct 2013 15:23:08 +0000

Hi Yoav,

Thanks indeed for your comments! Please find additional [Fred] comments inline.

> changing any other layer/protocol) carried across the same tunnel and also

[Fred] I would add that any forwarding database is good as long as it meets the security requirements of the administrator. Routing tables are used for the description but policy routing can be used too… VRF's or routing context are frequently used in practice as well. There are not "pure" routing tables anymore.

When it comes to L2 forwarding, the SPD today does not even fit anymore and a total revamp would be necessary.

By decoupling the output tunnel selection (or next-hop selection)  from the IPsec policy, we can take advantage of various forwarding policy engines.

>> administrative domains, so there should be some rule about this.

[Fred]  We link the tunnel to an IKE profile. This IKE profile turns contains the identity, identity filter, certificate and certificate filter to send to and to accept from the remote peer. So we can create IKE profiles for each DMVPN and send or accept specific certs. Typically, O or OU fields are used.

regards,

	fred

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Tue, 15 Oct 2013 16:06:03 +0000

Are there any other detail that are not part of this draft, that is
required for interoperating with existing DMVPN solution? And, is there
any other feature that DMVPN supports today (and not required for
interoperability) that is not part of this draft?

Thanks,
Praveen

On 10/9/13 8:23 AM, "Frederic Detienne (fdetienn)" <[email-masked]>
wrote:

Hi Yoav,

Thanks indeed for your comments! Please find additional [Fred] comments
inline.

> changing any other layer/protocol) carried across the same tunnel and

[Fred] I would add that any forwarding database is good as long as it
meets the security requirements of the administrator. Routing tables are
used for the description but policy routing can be used tooŠ VRF's or
routing context are frequently used in practice as well. There are not
"pure" routing tables anymore.

When it comes to L2 forwarding, the SPD today does not even fit anymore
and a total revamp would be necessary.

By decoupling the output tunnel selection (or next-hop selection)  from
the IPsec policy, we can take advantage of various forwarding policy
engines.

>> administrative domains, so there should be some rule about this.

[Fred]  We link the tunnel to an IKE profile. This IKE profile turns
contains the identity, identity filter, certificate and certificate filter
to send to and to accept from the remote peer. So we can create IKE
profiles for each DMVPN and send or accept specific certs. Typically, O or
OU fields are used.

regards,

	fred

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Tue, 15 Oct 2013 16:56:58 +0000

On 15 Oct 2013, at 18:06, Praveen Sathyanarayan <[email-masked]> wrote:

> required for interoperating with existing DMVPN solution?

I think the draft is exhaustive.

> And, is there

yes. Not sure how much more you want to know...

regards,

	fred

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Tue, 15 Oct 2013 18:05:39 +0000

[PRAVEEN] Thanks. Good to know. I can think of, handling of NAT in DMVPN
(looks like there is some special mechanism). And are there anything
specific changes to routing protocols to support on NBMA network?
Description on policy based routing requirement for policing traffic.

[PRAVEEN] Yes means there are features that are related to DMVPN, that are
not described in the current draft?

Thanks,
Praveen

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Wed, 16 Oct 2013 17:00:47 +0000

On 15 Oct 2013, at 20:05, Praveen Sathyanarayan <[email-masked]>
 wrote:
> (looks like there is some special mechanism).

The DMVPN product features a NAT mechanism necessary for plain GRE (no IPsec) in order to figure the public outside address.

Since we are talking about IKE/IPsec only here, that information can be drawn from IKE itself.

>  And are there anything

No change is required to the routing protocols. By treating the connections as tunnels and tunnel interfaces or tunnel endpoints, routing protocols run natively over these.

It really only depends on the modularity of the routing protocol implementation.

> Description on policy based routing requirement for policing traffic.

There is no specific requirement for policy based routing.

To be absolutely precise, as described in the draft, we inject NHRP entries in the routing table by pointing to a next-hop or an output interface. I suppose you could call that policy routing somehow or you could call NHRP a routing protocol... but  all you need is in the document.

We manipulate the routing table using all possible sources (NHRP, Routing protocols, IKE,…) but our draft does not strictly command how packets are forwarded inside a gateway.

> not described in the current draft?

yes too but this is a different question. You asked me a precise, closed question and I answered with a precise "yes".

Let me rewrite the answers to both questions in a low context form:

A1) There is no other feature that DMVPN/FlexVPN (product names) supports today (and not required for interoperability) that is not part of the draft. 

A2) There are other features related to DMVPN/FlexVPN (product names) that are not in the draft (but they are not required for interoperability).

thanks,

	fred

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Thu, 17 Oct 2013 00:22:49 +0000

Thanks Fred for clarifications.

-- Praveen

On 10/16/13 10:00 AM, "Frederic Detienne (fdetienn)" <[email-masked]>
wrote:

> (looks like there is some special mechanism).

The DMVPN product features a NAT mechanism necessary for plain GRE (no
IPsec) in order to figure the public outside address.

Since we are talking about IKE/IPsec only here, that information can be
drawn from IKE itself.

> specific changes to routing protocols to support on NBMA network?

No change is required to the routing protocols. By treating the
connections as tunnels and tunnel interfaces or tunnel endpoints, routing
protocols run natively over these.

It really only depends on the modularity of the routing protocol
implementation.

To be absolutely precise, as described in the draft, we inject NHRP
entries in the routing table by pointing to a next-hop or an output
interface. I suppose you could call that policy routing somehow or you
could call NHRP a routing protocol... but  all you need is in the document.

We manipulate the routing table using all possible sources (NHRP, Routing
protocols, IKE,...) but our draft does not strictly command how packets are
forwarded inside a gateway.

> not described in the current draft?

yes too but this is a different question. You asked me a precise, closed
question and I answered with a precise "yes".

A1) There is no other feature that DMVPN/FlexVPN (product names) supports
today (and not required for interoperability) that is not part of the
draft. 

A2) There are other features related to DMVPN/FlexVPN (product names) that
are not in the draft (but they are not required for interoperability).

thanks,

	fred

>>>> a Resolution reply with TunS2 and PubS2 addresses. So now A should
>>>>open
>>>> a