November 2006 in Dagstuhl, Germany Jari.Arkko@ericsson [email protected]
-
Upload
nathaniel-gates -
Category
Documents
-
view
23 -
download
0
description
Transcript of November 2006 in Dagstuhl, Germany Jari.Arkko@ericsson [email protected]
![Page 3: November 2006 in Dagstuhl, Germany Jari.Arkko@ericsson Marcelo@it.uc3m.es](https://reader036.fdocuments.in/reader036/viewer/2022083004/56813500550346895d9c4c67/html5/thumbnails/3.jpg)
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
![Page 4: November 2006 in Dagstuhl, Germany Jari.Arkko@ericsson Marcelo@it.uc3m.es](https://reader036.fdocuments.in/reader036/viewer/2022083004/56813500550346895d9c4c67/html5/thumbnails/4.jpg)
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
![Page 5: November 2006 in Dagstuhl, Germany Jari.Arkko@ericsson Marcelo@it.uc3m.es](https://reader036.fdocuments.in/reader036/viewer/2022083004/56813500550346895d9c4c67/html5/thumbnails/5.jpg)
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.
![Page 6: November 2006 in Dagstuhl, Germany Jari.Arkko@ericsson Marcelo@it.uc3m.es](https://reader036.fdocuments.in/reader036/viewer/2022083004/56813500550346895d9c4c67/html5/thumbnails/6.jpg)
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?
![Page 7: November 2006 in Dagstuhl, Germany Jari.Arkko@ericsson Marcelo@it.uc3m.es](https://reader036.fdocuments.in/reader036/viewer/2022083004/56813500550346895d9c4c67/html5/thumbnails/7.jpg)
7
Reality Check for the Goals (1)
• Solving the right problem is crucial
• So what is the problem?
• What already works?
![Page 8: November 2006 in Dagstuhl, Germany Jari.Arkko@ericsson Marcelo@it.uc3m.es](https://reader036.fdocuments.in/reader036/viewer/2022083004/56813500550346895d9c4c67/html5/thumbnails/8.jpg)
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?
![Page 9: November 2006 in Dagstuhl, Germany Jari.Arkko@ericsson Marcelo@it.uc3m.es](https://reader036.fdocuments.in/reader036/viewer/2022083004/56813500550346895d9c4c67/html5/thumbnails/9.jpg)
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
![Page 10: November 2006 in Dagstuhl, Germany Jari.Arkko@ericsson Marcelo@it.uc3m.es](https://reader036.fdocuments.in/reader036/viewer/2022083004/56813500550346895d9c4c67/html5/thumbnails/10.jpg)
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
![Page 11: November 2006 in Dagstuhl, Germany Jari.Arkko@ericsson Marcelo@it.uc3m.es](https://reader036.fdocuments.in/reader036/viewer/2022083004/56813500550346895d9c4c67/html5/thumbnails/11.jpg)
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)
![Page 12: November 2006 in Dagstuhl, Germany Jari.Arkko@ericsson Marcelo@it.uc3m.es](https://reader036.fdocuments.in/reader036/viewer/2022083004/56813500550346895d9c4c67/html5/thumbnails/12.jpg)
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”
![Page 13: November 2006 in Dagstuhl, Germany Jari.Arkko@ericsson Marcelo@it.uc3m.es](https://reader036.fdocuments.in/reader036/viewer/2022083004/56813500550346895d9c4c67/html5/thumbnails/13.jpg)
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
![Page 14: November 2006 in Dagstuhl, Germany Jari.Arkko@ericsson Marcelo@it.uc3m.es](https://reader036.fdocuments.in/reader036/viewer/2022083004/56813500550346895d9c4c67/html5/thumbnails/14.jpg)
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
![Page 15: November 2006 in Dagstuhl, Germany Jari.Arkko@ericsson Marcelo@it.uc3m.es](https://reader036.fdocuments.in/reader036/viewer/2022083004/56813500550346895d9c4c67/html5/thumbnails/15.jpg)
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