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 _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
