Steve, To answer your question, the SPD entries are not already there, they are created as the result of a message exchange between the two spokes; it's the spokes that choose the policy, not the hub. If the SPDs were already there, every IPSec node in the network would need to know about all the networks in the overall topology apriori – to solve this is one of the main drivers of the whole exercise. This becomes even more complex if the hosts (not necessarily an IPSec node) acquire address dynamically and/or are mobile.
Thanks, Manish From: Stephen Kent <[email protected]<mailto:[email protected]>> Date: Wednesday, 6 November 2013 3:51 AM To: Mike Sullenberger <[email protected]<mailto:[email protected]>>, ipsec <[email protected]<mailto:[email protected]>> Subject: Re: [IPsec] AD VPN: discussion kick off Mike, Thanks for the responses to my comments, including ones from yesterday's meeting. Steve, Sorry, I wasn’t clear on our use of IPsec. We definitely use both the authentication and encryption capabilities of IPsec. We do the following when bringing up a new tunnel. 1. Trigger ISAKMP/IKEv2/IPsec with an SPD of (LocalPeer IP, RemotePeer IP, GRE). 2. ISAKMP/IKEv2 authenticates the peers, creates the IKE SAs and the IPsec/Child encryption SAs. 3. IPsec signals it has authenticated and encryption is ready, the GRE tunnel is activated. 4. NHRP registration (for spoke-hub) or resolution reply (for final phase of spoke-spoke) are sent over the tunnel. 5. Routing is brought up over the spoke-hub tunnels. If a shortcut between two spokes is available, as advised by a hub, that requires an SDP entry. Did that entry preexist in the spoke, or was it provisioned by a hub in some fashion? If it existed in the spoke, initially, "normal" IPsec operation would cause traffic to that spoke to trigger formation of an SA to that destination. Can you clarify? As for scaling, we already have DMVPN networks of 10000+ nodes and looking at building networks of 40000+ nodes. In many cases customers have multiple subnets behind each node, therefore with just IPsec I would need to have multiple SAs/encryption between the same two nodes, even if you are only doing subnet to subnet SPDs. Take the case of two nodes that each have 4 subnets. I could need as many as 16 SAs to cover all cases. Or even a simpler case between a host (1 local address) and a node at a data center (say 20 subnets), I would need up to 20 SAs to cover this. In many of our networks we are asked to support at least 5 (sometimes 10) subnets per spoke location. That's a helpful clarification. It does not appear to be the sort of environment that initially seemed to be the focus of this work, e.g., road warriors calling home or home/satellite offices for a moderate size enterprise. As far as IPv4 and IPv6 support, you are correct it would only double the number of SAs needed, assuming that there are the same number of subnets for IPv4 and IPv6. From what I have seen IPv6 tends to increase the number of subnets. I'm glad we're on the same page here. For end-to-end encryption, take the case where a spoke node is a host. Then initially the spoke/host will connect to one or more hubs (we recommend at least 2 for redundancy). Communication between two such connected hosts would be through the hub and would be two hops (Host1 encrypt-decrypt Hub encrypt-decrypt Host2). Once the shortcut tunnel is setup then communication would be direct between the hosts (Host1 encrypt-decrypt Host2). see my question re the shortcut SPD entries. Steve
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
