On 15 Oct 2013, at 18:06, Praveen Sathyanarayan <pravee...@juniper.net> 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.
> 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...
regards,
fred
> Thanks,
> Praveen
>
>
> On 10/9/13 8:23 AM, "Frederic Detienne (fdetienn)" <fdeti...@cisco.com>
> wrote:
>
> Hi Yoav,
>
> Thanks indeed for your comments! Please find additional [Fred] comments
> inline.
>
> On 07 Oct 2013, at 19:47, Manish Kumar (manishkr) <manis...@cisco.com>
> 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" <y...@checkpoint.com> 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
>>> IPsec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
>
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
