1 November 2006 in Dagstuhl, Germany

2 Identity - Locator Merge November 2006 in Dagstuhl, Germany

3 Goals of the Talk Generate some controversy Suggest that the benefits of identity- locator split are far from clear Explore a design alternative that focuses on repairing the original IP model and minimal change

4 Erosion of Identity in Addresses Addresses are both identifiers and locators. But the identity part no longer works well: No secure way to verify owner Dynamics of address assignment and node mobility make it hard to use them for identification The use of non-unique address spaces Lost in various translations

5 Identity-Locator Split Architecture A commonly suggested response to these issues involves the separation of the roles Locators are only used for routing Upper layer protocols bound to identities Cryptographic identifiers allow movement between locators, multi-homing, etc.

6 But There’s a Downside! Making applications aware of identities requires a major rewrite Identity-unaware applications will be unable to handle referrals This in turn forces us to create reverse lookup services that have either significant infrastructure costs or create administrative bottlenecks Enough bang for the buck?

7 Reality Check for the Goals (1) Solving the right problem is crucial So what is the problem? What already works?

8 Reality Check for the Goals (2) End-to-end security –High-value traffic is already secure, often application specific –(There may be value in opportunistic security) Mobility and multihoming –On longer time scales, applications, DNS etc work well –L2 handles tiny time scale; medium scale session survivability remains Multiple name spaces –But we seem to be able to do this already Routing scalability –It’s a problem. But will id/locator split help?

9 Our Suggestion 1. Repair our ability to use addresses as identifiers 2. Make the IP layer robust and secure enough to perform internetworking -- but not more Constraints: Get a 99% solution -- build for the common case NO additional configuration over basic IP Incrementally deployable Do NOT make the registry owner filthy rich

10 The Ingredients of A Solution The basic approach is to communicate using secure IPv6 addresses, employing an overlay where no native IPv6 is available –Cryptographic addresses –Overlays –IPv6 Provide reachability and secure binding for: –Mobility –Local operations, such as ND, DHCP, RVS allocation, or IPv6 transition

11 Cryptographically Generated Addresses Employ generalized CGAs: address1 = prefix | h(PK1 | PK2 … | prefix |...) Binds an IPv6 address to public keys and other data Private key can be used to sign statements from the “owner” Statement can indicate node’s other addresses (including IPv4 and MAC)

12 How Does it Work? (1) Mobility, multi-homing, ND: we have already done this earlier –See Shim6, CGA-based mobile IPv6 proposals With the session bound to overlay address, we can handle IPv4 as well –“I moved to ” Even bindings to NAT port can be handled –“I moved to :56”

13 How Does it Work? (2) DHCP, RVS or home agent allocation, tunneled IPv6 connectivity: These are similar –No pre-configuration or AAA –Modeled after local DHCP servers or anycast- reachable IPv6 tunnel servers –You do not get a permanent resource Always the same generic approach: –Agreement of a server to delegate one of its addresses for a host (address PK delegates to the host PK) –Ability of the host to prove its ownership –Optional server forwarding capability

14 Observations (1) What did NOT change: No new identity space -- no IANA, RIRs, DHTs Referrals work just like today TCP works just like today No forklift upgrade to routers ISP does not have to deploy IPv6 Backwards compatible with existing hosts

15 Observations (2) What DID change: Restores the ability of the IP address to function as an identifier Secures all address operations on hosts Sessions survive across mobility events DHCP server-like forwarding agents Challenges: Host that want the benefits need to be modified