1

Who Are You?
Identity and Location in IP
Geoff Huston
Chief Scientist
APNIC

Addresses and the IP Architecture
Architecturally, IP Addresses are:
 Drawn from a Stable Global space Intended to be used in a unique context

Within the IP architecture addresses are:
 Endpoint identifiers
 Routing objects
 Key value for Forwarding Lookup

11

IP Addresses are:A means of uniquely identifying a device interface
that is attached to a network
 Endpoint identifier

A means of identifying where a device is locatedwithin a network
 Location identifier

A lookup key into a forwarding table to make local
switching decisions
 Forwarding identifierThis deliberate overload of sematic intent has
been a basic property of the IP architecture
2

Challenges to the IP Address Model
Roaming endpoints - Nomadism
Mobile endpoints – Home and Away
Mobile Networks
Session hijacking and disruption
Multi-homed endpoints and “session” resiliency
Scoped address realms
NATs and ALGs
VOIP
Peer-to-Peer applications
Routing Complexity and Scaling
Middleware, DNS and Renumbering3

1Wouldn’t it be good if…..
Your identity was stable - irrespective of your location
You could maintain sessions while being mobile
You could maintain sessions across changes in local
connectivity
That locator use was dynamic while identity was long-term
stableAnyone could reach you anytime, anywhere
You could reach anyone, anytime, anywhere

4

Wouldn’t it be good if…
IPv6 offered solutions in this space that allowed
endpoint identity to be distinguished fromlocation and forwarding functions“Second-Comer” Syndrome:
This perspective can be phrased as: Unless IPv6 directly tackles some of the fundamental issues
that have caused IPv4 to enter into highly complex solution spaces that stress various aspects ofthe deployed environment than I’m afraid that we’ve achieved very little in terms of actual progress
in IPv6. Reproducing IPv4 with larger locator identifiers is not a major step forward – its just a small
step sideways!

“We’ve Been Here Before” Warning:
Of course this burdens the IPv6 effort in attempting to find solutions to quite complex networking
issues that have proved, over many years of collective effort, to be intractable in IPv4. If theproblem was hard in an IPv4 context it does not get any easier in IPv6! That should not stop further
exploration of the space, but it should add a touch of caution to evaluation of solutions in this space.

5

1

What do we want from “Identity”?
Varying degrees of: Uniqueness Persistence Structure Clear Scope of Applicability
 Validity and Authenticity
 Clear line of derivation authority

 Identity is not a unilateral assertion – it is better

viewed as a recognition of derived uniqueness within
a commonly understood context
6So far we have:
Mobile IPv4 Mobile Ipv6
 AD Hoc Networking
 NEMO
 HIP
 SCTP SHIM6
 Teredo Dynamic DNS NAPTR and SNAPTR DNS RRs
7

1Choices, Choices, Choices
Its possible to inject an identity object at almost any level ofthe protocol stack model
Application Identities shared across transport sessions
Transport Identities to allow agility of stack location
 Host identities to allow agility of location of all hosted sessions
In this context an “identity” is a token to allow multiple
locators to be recognised as belonging to a single
communication state at both (or multiple) ends of thecommunication

8Choices, Choices, Choices
Identity at the Application levelUse a stable name space that is mapped to a locator (using the DNS)

Allow indirection and referral via DNS NAPTR records

DNS incremental updates
Generic identity ornamented with service-specific mappingsENUM

Use application agents to provide stable rendezvous points

Issues:For example: sip:gih@sip.apnic.net

Can the DNS support dynamic interaction at a suitable scale and speed?
Are a family of diverse application-specific identities desireable (crossapplication referral and hand-over) Can we stop application designers from creating NAT-agile locatorindependent application-specific solutions that rely on an application-specificidentity space?


9

1

Choices, Choices, Choices
Identity at the Transport LevelCan we provide a mechanism to allow identity / locator
independence at the session level?
An application opens a session with a generated session identity
token
 The identity token is dynamically associated with locator pairs
 Changes in locators do not change the session tokenApplication of the layering approachAllow applications to assume a framework of identity association
Perform identity / locator association at a lower level of the protocolstack Use opportunistic identity values that have a limited context and roleof supporting session integrity
 Support legacy applications by providing a consistent API

10Choices, Choices, Choices
Identity at the IP level
Can we provide an identity / locator association that is sharedacross multiple sessions?
 Reduce the overhead of identity locator mappings to allow all
sessions to a common endpoint to share a mapping state Want to provide a more comprehensive support of identity tosupport both session-oriented transport protocols and(potentially) datagram transactions
 Reduce the complexity of applications and transport sessions
and place the per-endpoint mapping state in the IP level

11

1Identity Issues
How could an identity mapping function?

ULP
Transport

Connect to server.apnic.net
Connect to id:3789323094

ULP
Transport

Identity

id:3789323094 Ù 2001:360::1

Identity

IP

Packet to 2001:360::1

IP

12Identity Issues
How could an identity mapping function?

ULP
Transport

Connect to server.apnic.net
Connect to id:3789323094

ULP
Transport

Identity

id:3789323094 Ù 2001:ffff::1

Identity

IPPacket to 2001:ffff::1

IP

Change of locator

13

1

Identity Implementations“Conventional”
 Add a wrapper around the upper levelprotocol data unit and communicate with thepeer element using this “in band” space
IP Header

ULP

Identity Field

Transport

Transport Header

Identity

PayloadIP

14

Identity Implementations“Out of Band”
 Use distinct protocol to allow the protocols

element to exchange information with its peer
ULP

ULP
Transport
IdentityIP

Transport Protocol
Identity Peering Protocol

Transport
Identity
IP

15

1

Identity Implementations
Application Identity: Above the Session
ULP

ULP
Identity

Transport
Transport
Transport

Identity Peering Protocol

Identity

Transport Protocol
Transport Protocol
Transport Protocol

Transport
Transport
Transport
IPIP

16

Identity Implementations“Referential”
 Use a reference to a third party point as ameans of peering (e.g. DNS Identifier)
ULP

ULP
Transport

Identity

Identity
IP

Transport

Transport Protocol

DNSIP

17

1

Identity Implementations
Self-Referential
 Use an opportunistic identity as anequivalence token for a collection of locators
ULP

ULP

Transport

Transport Session

Transport

Identity Token Exchange

Identity

Identity
IPIP

Locator Pair A
Locator Pair B
Locator Pair C18

Identity Types
Use identity tokens lifted from a protocol’s “address space”


DNS, Appns, Transport manipulate a “distinguished address”
IP functions on “locators”
Stack Protocol element performs mapping

FQDN as the identity tokenIs this creating a circular dependency?
Does this impose unreasonable demands on the properties ofthe DNS?

Structured token
What would be the unique attribute of a new token space thatdistinguishes it from the above?

Unstructured tokenAllows for self-allocation of identity tokens that may notglobally assuredly unique (opportunistic tokens)
How to map from identity tokens to locators using a lookup
service? Or how to avoid undertaking such a mapping function19

1Some Identity Suggestions
 IPv4 Address Centrally Assigned IPv6 Unique Local

Addresses
 A crypto hash of your public key
 A crypto hash of a set of locator values
 The IPv6 address used to initiate thecommunication IPv6 Address DNS names
 URIs Telephone numbers
20

Identity Issues


Identity / Locator Binding domainScope of identity role






Session or host?
Dynamic or static?
Configured or negotiated?
Locator independent identity
Equivalence binding for multiple locators

Locator Selection
Application visibility of identity capability
Scoped identities
Identity Referrals and hand-overs
Third party locator rewriting
Security of the binding
Context of use determining semantic interpretation

211Upper Level Issues of Identity Realms
The significant effort and cost of supporting a new global
unique token distribution system as an endpoint identity
system

The side-effects of reusing some other existing token set as
an identity set

Uniqueness is not cheap!

Recycling is dangerous!

The issue of support of dynamic identity to locator binding

Speed vs accuracy

The protocol overhead of identity handshake for datagramtransactions
 The security issues in maintaining integrity of identity
22IPv6 and Identity
Is the 64bit Interface Identifier a rich location for carryingopportunistic identity?
Can the Flow-Id field be exploited?
Are header extensions and options useful?
Is packet inflation necessary?
Is IPv6 the only protocol for consideration of IP levelidentity approaches?
Is there any leverage for transport session approaches?
 Can such approaches be IP version agnostic?
23

1

百花齊放，百家爭鳴*

Our current direction appears to be developing
solutions in all of these spaces simultaneously: Multi-Party Applications
 Application Agents
 Rendezvous protocols
 DNS Incremental Updates and DNSSEC DNS Indirection and Referral SCTP, HIP at the transport-layer
 Shim6 Mobile IPv6
 Mobile IPv4
 And probably many more!

* Let a hundred flowers bloom: let a hundred schools of thought contend
24
Mao Zedong, 1956

一花独放， 一家主鳴* Should there be just one SINGLE identity model?
 Can we coerce all the requirements of identification

into a single identity realm?
 Or are the various desireable properties of identity somutually contradictory that there is no single solution?
 Many of the approaches we’ve see assume a single
identity mapping function that wants to ignore anyside effects from any other simultaneous identity
scheme in operation
 One the other hand, retrofitting any form of identity
function into today’s IP architecture is bad enough interms of legacy requirements without having to factor
in other identity functions as well!
* Let one flower bloom: let one school of thought prevail

25

1Where Now?
We appear to have a lot more to learn here
 Its more than scaling routing or avoiding

renumbering or multihoming
 Its more than IPv4 and IPv6
 If we want a more agile and flexible model ofpacket networking to support diverse
communications environments and services
then we need to understand how split apartthe semantics of who wants to talk from themechanics of how they may talk26

Thank You

27