In addition to what Praveen said, I'd like to point out that draft-sathyanarayan defines a two-tier network. On the top tier are security gateways that are (presumably) always-on and know the union protected domain of the VPN. The second tier are devices that do not know the entire protected domain. The group of first-tier nodes is not necessarily identical to the group "hubs", but that is typical. Also typical is for that group to be relatively small - 2-30 gateways in a network that contains 10s of thousands of nodes.
Second tier devices are typically remote access clients, home routers or small office routers. Their initial configuration is simple - one peer, and credentials for connecting to that peer. First tier devices should know at all times what the union protected domain is. It's possible that they won't know which peer gateways protects a particular address, but they have to know the difference between "send through the VPN" and "send through the unprotected Internet". The PROTECTED_DOMAIN attribute described in section 3.9 is always sent from a first-tier gateway to a second tier node, and includes the union protected domain, unless policy requires something different: for example, remote access clients are often required to send all their traffic (even google searches) through a center gateway. The PROTECTED_DOMAIN is a bootstrap mechanism for 2nd tier nodes. It is *not* part of the normal continuous operation of the network, although 2nd tier nodes may use it periodically. The Shortcut exchange, described in most of section 3 is the one used among all the nodes in the AD-VPN to tell each other where a particular part of the union protected domain is protected. That *is* part of the normal operation of the protocol. When adding or deleting a spoke with a protected domain, two steps are required: 1. Configure the new spoke with the identity, address, and credentials for a hub gateway 2. Configure the hub gateway with the identity, credentials and protected domain of the new spoke. You cannot omit step #2 in any solution unless you forego authentication. Accepting a protected domain from an unauthenticated node, whether the protected domain is sent in a CFG payload, an HTTP resource, or a routing protocol message is a security vulnerability. Accepting any valid certificate without pre-configuring the expected content (for example, "Subject must contain 'CN=Tokyo Office' and Issuer must be xxxx") is no authentication at all. The missing piece here is the propagation of the union protected domain information among all the 1st tier nodes. This is fairly simple in a single enterprise network where such nodes are managed centrally. I can also see how in more heterogenous environments routing protocols could be used. Or the WG can develop some new mechanism (although I don't think that's a good idea). I think this is more useful than requiring 2nd tier [1] devices to participate in routing protocols. Yoav [1] I've often heard people use mobile phones as the ultimate example of low-end, but looking at the specs of small-office gateways, many of them are lower-spec than the average phone - under 1GB of memory, around 1GB of flash space, CPUs that are leftovers from last year's mobile phones. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
