1 November 2006 in Dagstuhl, Germany [email protected] [email protected].
15
-
Upload
augustus-dickerson -
Category
Documents
-
view
212 -
download
0
Transcript of 1 November 2006 in Dagstuhl, Germany [email protected] [email protected].
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
