Hi Stephen, please find some answers inline.
On 04 Nov 2013, at 22:57, Stephen Kent <[email protected]> wrote: > Mike, > > A couple of your comments caught my attention, as an author of 4301, 02, and > 03. I admit to not having read the DMVPN proposal, so my comments are based > only on your message, which argues why DMVPN is the preferred solution. >> IPsec encryption layer. In this layer ISAKMP/IKEv2/IPsec is the correct >> standard protocol to use. This is what IPsec does really well, encrypt >> traffic. The layers above greatly simplifies IPsec's job by presenting to it >> the tunnel to encrypt instead of all of the individual >> protocols/subnets/flows that are within the tunnel. The IPsec selectors are >> now for the tunnel, which makes path redundancy and load-balancing doable. >> IPsec doesn't deal well with the same set of selectors to encrypt traffic to >> more than one peer. With DMVPN this is handled at the routing/forwarding >> and GRE tunnel layers. > IPsec is not just about encryption, although the DMVPN proposal may relegate > it to that. IPsec provides access control, and, typically, > authentication. Does DMVPN preserve the access control features of IPsec, or > are users now relying on a hub to do this, or what? The proposal relies on everything IKE and IPsec do today. All the cryptography and authentication/authorization mechanisms remain between hub&spokes as well as between spokes. All the access control features of IPsec and IKE remain untouched. NHRP only facilitates the network and peer discovery. >> ... With 10s of thousands of nodes and perhaps 100s of thousands of >> network/subnets reachable via the VPN the number of IPsec selectors across >> the VPN would get completely out of hand, especially if each different pair >> of subnets (selector) requires a separate encryption, between the same two >> nodes. > More properly, a separate SA, and only if the folks who manage policies at > each end of the SA decide to provide fine-grained access control for the > traffic flows. It was not clear to me that the problem statement for this > work envisioned VPNs of the scale you mention. Also, the comments above are a > bit confusing. Both end points and security gateways are "nodes" wrt IPsec, > in the general sense. I can create a selector that secures traffic from my > node (and point of subnet) to all hosts on a subnet, irrespective of how many > are present there. >> This doesn’t even count the fact that in order to run IPv4 and IPv6 between >> the same two nodes you have to use at least double the number of selectors. > At least? Under what circumstances would the number grow by more than a > factor of two? I am not sure I understand your comment. Here is what we are trying to say: Assuming two nodes A and B hosting subnets A1, A2 and B1, B2 respectively (A* and B* not summarizable), the selectors between A and B have a form A1-B1 A1-B2 A2-B1 A2-B2 yielding up to A# x B# selectors. There can be thousands of A* and B*. Can you elaborate please ? >> Routing protocols are already designed to scale to 100s of thousands and >> even millions of routes. So with DMVPN the forwarding and GRE tunneling of >> both IPv4 and IPv6 is handled within a single GRE tunnel and IPsec selector. > So, the proposal simplifies use of IPsec by limiting the granularity at which > SAs may be created? Does it also cause each SA to terminate at a hub, so that > the security services are no longer e-t-e? In the context of the perpass > discussions, this seems like a questionable design decision. Each SA is established between the spokes and the entire IKE/IPsec negotiation takes place between the spokes. The hub does not act as a broker. thanks, fred > > Steve _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
