That seems like a good starting point.
Mike
----- Original Message -----
From: Nico Williams
To: Michael Ko
Cc: Paul Hoffman ; IPsecme WG
Sent: Tuesday, November 29, 2011 2:17 PM
Subject: Re: [IPsec] Discovery (Was: Preparing a charter change for P2P VPN)
On Tue, Nov 29, 2011 at 3:36 PM, Michael Ko <mich...@huaweisymantec.com>
wrote:
> 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.
For credentials it's easier to think in terms of administrative
domains, and the mapping operation is admin_domain->cert_store. (I
say certificate store because the node may have multiple certificates
for different users' traffic, though this is not really common at all,
and will almost never happen on a mobile node, which is what needs
discovery.)
For target IP addresses... mapping addresses to administrative domains
will be the challenging task, particularly when private-use addressing
is involved (for example, one can't use the public DNS/DNSSEC for
discovery in that case). For private-use addresses my instinct says
that each administrative domain should operate a lookup service and
that the node should have a domain precedence list, asking each domain
in turn until one claims the target address or all fail to claim it
(the lookups can be parallelized though). For public-use addresses
the DNS (using DNSSEC) should be able to provide the answer.
As for nearest SG for a given administrative domain, well, I'm
thinking of anycasting and multicasting, as well as SRV RRs.
That's several operations then:
- anycast/multicast to find topologically close SGs
- DNS (SRV RR lookups) to find a domain's SGs
- a protocol by which to ask a domain which SGs to use for
specific addresses (probably as an IKEv2 extension as the
SGs will know best)
(this can double as the protocol for private-use address to
admin. domain mapping)
(this protocol should probably export IGP route metrics, with
the SG having access to the IGP routing table, obviously)
- DNS (w/ DNSSEC) to map public-use addresses to admin.
domains
- a local admin. domain -> cert [store] lookup operation
Or have I misunderstood the problem space?
Nico
--
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
