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 protected]> wrote: Hi Yoav, Thanks indeed for your comments! Please find additional [Fred] comments inline. On 07 Oct 2013, at 19:47, Manish Kumar (manishkr) <[email protected]> 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" <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
