1 / 15

November 2006 in Dagstuhl, Germany Jari.Arkko@ericsson Marcelo@it.uc3m.es

November 2006 in Dagstuhl, Germany Jari.Arkko@ericsson.com Marcelo@it.uc3m.es. November 2006 in Dagstuhl, Germany Jari.Arkko@ericsson.com Marcelo@it.uc3m.es. Identity - Locator Merge. Goals of the Talk. Generate some controversy

nathaniel-gates
Download Presentation

November 2006 in Dagstuhl, Germany Jari.Arkko@ericsson Marcelo@it.uc3m.es

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. November 2006 in Dagstuhl, Germany • Jari.Arkko@ericsson.com • Marcelo@it.uc3m.es

  2. November 2006 in Dagstuhl, Germany Jari.Arkko@ericsson.com Marcelo@it.uc3m.es Identity - Locator Merge

  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 1.2.3.4” • Even bindings to NAT port can be handled • “I moved to 1.2.3.4: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

More Related