I can live with the term "map-making" in referring to the functions provided
by the centralized repository ("introducer") that I discussed in my earlier
e-mail. Note that there is quite a bit of overlap between "map-making" and
"discovery". In both cases, a node wants to find out "What ID and
credential (certificate or PSK) will the peer show" and "What ID and
credential should I show". For "discovery", there is also the need to find
out "What other addresses does this gateway protect" (presumably all
addresses protected by the gateway) whereas for "map-making", a node only
wants to find out which nodes it is authorized to access. Also for
"discovery", a node already knows that it "has a packet bound for host
194.29.35.43" before it contacts "the universe", whereas for "map-making", a
node does not necessarily know the IP address of the peer it wants to reach
when it contacts the central repository.
Mike
----- Original Message -----
From: Paul Hoffman
To: IPsecme WG
Sent: Tuesday, November 29, 2011 7:55 AM
Subject: Re: [IPsec] Discovery (Was: Preparing a charter change for P2P VPN)
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
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
