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