On Tue, Nov 29, 2011 at 3:36 PM, Michael Ko <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/ipsec
