Hi Stephen, Thanks for your inputs vis-a-vis 4301/2/3. I concur that IPSec is not just about encryption but don't quite buy into what somebody spelled out during the meeting as 'IPSec is an access control mechanism that also provides other security services'; IMO, strict access control is more a firewall functionality. RFC 4301 spells out the access control rationale as "IPsec includes a specification for minimal firewall functionality, since that is an essential aspect of access control at the IP layer… The IPsec firewall function makes use of the cryptographically-enforced authentication and integrity provided for all IPsec traffic to offer better access control than could be obtained through use of a firewall (one not privy to IPsec internal parameters) plus separate cryptographic protection."
I know that we might have ruffled a few feathers wrt making the SPD relatively trivial but let's get down to some details as far as the comparison goes. The first ADVPN proposal does talk about the shortcut suggester possibly including traffic selectors in the shortcut exchange. While this seems to give the notion of the ability to provide SA granularity, the source of such information is a third party (even though both peers have an active connection with this third party) and doesn't quite stand up to the very reason of including access control in IPSec (The IPsec firewall function makes use of the cryptographically-enforced authentication and integrity provided for all IPsec traffic to offer better access control than could be obtained through use of a firewall (one not privy to IPsec internal parameters) plus separate cryptographic protection.) - this is a case of the information not even privy to the same device, leave alone the same layer in the same device. Let's say, the shortcut suggester passes on an information in the shortcut exchange to the two peers about the selectors (X->Y) to be used for the shortcut while selectors (X'->Y') be still allowed through the spoke-hub-spoke path. It's entirely upto the peers (shortcut partners) to choose what to do with that; well, the draft prescribes that the shortcut partners should use this but when we are talking about multi-vendor, multiple administrative domains, how do we trust that the shortcut partners do that. We must realise that the role of the suggester/hub is more advisory in nature; it can only advise not enforce. The problem is a system wide design problem not one to be sorted out just between two nodes (and IKE is intrinsically designed to operate in a peer-to-peer model), so e.g. even if policies prescribe (as obtained from the shortcut exchange) that a certain traffic be routed via the hub, once the two peers(shortcut partners) have all the authentication information for each other, they might give a damn and say we don't care, lets bypass the policy and use the shortcut for everything leaving the hub in dark. Unlike a traditional IPSec case, where each peer could enforce specific access control policies (e.g. if the peer you negotiated an SA with sends a traffic using an SA which was not supposed to be used for that traffic, you could simply drop it post decryption), the hub can't enforce such policies – it can dictate what doesn't pass through it but not what MUST pass through it, which is what the common requirement is. What all this effectively means is if really need to enforce access-control policies, it has to be agreed between the spokes/shortcut partners, not prescribed by the hub. IPSec typically deals with a case where the SPD is in place apriori based on which SAs are negotiated but here we end up with a case where the SPDs need to be negotiated and agreed upon as well !!! In that sense, I would say DMVPN still provides better access control – it already determines what portion of the network should use the shortcut depends on the address/subnet sent in NHRP resolution reply. This is used to install shortcut routes and/or policy based routes and the same can be used to also install an ACL if we suspect the peer to play foul. It's another matter that this is not as part of IPSec access control directly. This is on top of the route/forwarding policy based tunnel selection. - Manish From: Stephen Kent <[email protected]<mailto:[email protected]>> Date: Tuesday, 5 November 2013 3:27 AM To: Mike Sullenberger <[email protected]<mailto:[email protected]>>, Michael Richardson <[email protected]<mailto:[email protected]>> Cc: "Stephen Lynn (stlynn)" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Mark Comeadow <[email protected]<mailto:[email protected]>>, "Michael Guilford (mguilfor)" <[email protected]<mailto:[email protected]>>, IPsecme WG <[email protected]<mailto:[email protected]>> Subject: Re: [IPsec] AD VPN: discussion kick off Resent-From: <[email protected]<mailto:[email protected]>> Resent-To: Frederic Detienne <[email protected]<mailto:[email protected]>>, Manish Kumar <[email protected]<mailto:[email protected]>>, Mike Sullenberger <[email protected]<mailto:[email protected]>> Resent-Date: Tuesday, 5 November 2013 3:27 AM 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 tothat. 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
