On Nov 28, 2011, at 5:31 PM, Michael Ko wrote: > To establish a secure connection between two authorized network nodes, some > of the critical management tasks that are required include the following: > > 1. Discover if the network nodes that a user is authorized to access are > currently online and active. (One can always resort to timeouts to determine > if the peer is online or not, but being able to ascertain the status of the > peer quickly would be nice.) > > 2. Discover the functional attributes associated with these authorized > network nodes. > > 3. Discover the location of the authorized network nodes. (E.g., current IP > address) > > 4. Determine if accessing the network node requires going through a relay > (e.g., TURN). Discover the location of the relay if it is needed. > > 5. Determine the parameters needed to establish a secure connection between > the two network nodes. > > 6. Discover, via inquiry or advertisement, other authorized network nodes as > they become active and available. > If we use the hub as the entity to provide this "discovery" function, then the statement "hubs can receive information from the spokes about what addresses the spoke gateways protect" comes closest to meeting the requirment, although the information to be "discovered" include the above list and goes beyond just addresses.
On Nov 29, 2011, at 12:23 AM, Yoav Nir wrote: > I would define discovery something like this: > > Node A (either a client or a gateway) has a packet bound for host > 194.29.35.43. It asks "the universe" how to encrypt traffic to that host: > - What is the address of the gateway protecting 194.29.35.43 (could be the > host itself, or could be none) > - What ID and credential (certificate or PSK) will the peer show > - What ID and credential should I show > - What other addresses does this gateway protect > > In this discovery process, "the universe" could be a pre-configured hub > (pretty much what the Cisco and Juniper solutions do), a special-use server > (as in the architecture in Michael's presentation) or maybe the DNS. But all > this data needs to be returned. So, there are two divergent views of what "discovery" is. Some people are saying it is discovery by the centralized points (introducers) of the addresses protected by remote gateways and the policies needed to reach them; some people are saying it is discovery by the remote gateways of the addresses protected by other gateways and the policies needed to reach them. These are quite different. Our task would be simpler if we only used the second definition (Yoav's) for "discovery". I propose that we call how introducers discover which addresses gateways protect "map-making" (even though it also involves collecting additional information such as policies). I further propose that there is a requirement for gateways to be able to send introducers map-making information for themselves, but the process by which an introducer uses that information (such as when two gateways claim the same protected addresses) is out of scope. --Paul Hoffman _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
