1

November 2006 in Dagstuhl, Germany

Jari.Arkko@ericsson.com

Marcelo@it.uc3m.es

2

Identity - Locator Merge

November 2006 in Dagstuhl, Germany

Jari.Arkko@ericsson.com

Marcelo@it.uc3m.es

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