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

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

On 15 Oct 2013, at 20:05, Praveen Sathyanarayan <[e-mail]>
 wrote:
>> 
>> Are there any other detail that are not part of this draft, that is
>> required for interoperating with existing DMVPN solution?
> 
> I think the draft is exhaustive.
> 
> [PRAVEEN] Thanks. Good to know. I can think of, handling of NAT in DMVPN
> (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
> 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.

> 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.


>> And, is there
>> any other feature that DMVPN supports today (and not required for
>> interoperability) that is not part of this draft?
> 
> yes. Not sure how much more you want to know...
> 
> [PRAVEEN] Yes means there are features that are related to DMVPN, that are
> 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

> Thanks,
> Praveen
> 
> 
>> Thanks,
>> Praveen
>> 
>> 
>> On 10/9/13 8:23 AM, "Frederic Detienne (fdetienn)" <[e-mail]>
>> wrote:
>> 
>> Hi Yoav,
>> 
>> Thanks indeed for your comments! Please find additional [Fred] comments
>> inline.
>> 
>> On 07 Oct 2013, at 19:47, Manish Kumar (manishkr) <[e-mail]>
>> wrote:
>> 
>>> 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" <[e-mail]> 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.
>> 
>> [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.
>> 
>> 
>>>> - 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.
>> 
>> 
>> [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
>> 
>>>> - 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.
>>> 
>>>> 
>>>> 
>>>> Yoav
>>>> 
>>>> _______________________________________________
>>>> IPsec mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>> 
>>> _______________________________________________
>>> IPsec mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ipsec
>> 
>> _______________________________________________
>> IPsec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ipsec
>> 
>> 
>> 
>> 
> 
> 
> 
> 
>