Host Identity Protocol

1
Host Identity Protocol

• Pekka Nikander
• Ericsson Research Nomadiclab and
• Helsinki Institute for Information Technology
• http//www.hip4inter.net

2
Presentation outline

• Introduction What and why?
• Background
• HIP in a Nutshell
• Mobility and multi-homing (multi-addressing)
• HIP infrastructure Hi3
• Current status
• Summary

3
What is HIP?

• HIP Host Identity Protocol
• A proposal to separate identifier from locator at
  the network layer of the TCP/IP stack
• A new name space of public keys
• A protocol for discovering and authenticating
  bindings between public keys and IP addresses
• Secured using signatures and keyed hashes (hash
  in combination with a secret key)

4
Motivation

• Not to standardise a solution to a problem
• No explicit problem statement
• Exploring the consequences of the id / loc split
• Try it out in real life, in the live Internet
• A different look at many problems
• Mobility, multi-homing, end-to-end security,
  signalling, control/data plane separation,
  rendezvous, NAT traversal, firewall security, ...

5
Presentation outline

• Introduction What and why?
• Background
• HIP in a Nutshell
• Mobility and multi-homing (multi-addressing)
• HIP infrastructure Hi3
• Current status
• Summary

6
Background

• A brief history of HIP
• Architectural background
• Related IETF Working Groups

7
A Brief History of HIP

• 1999 idea discussed briefly at the IETF
• 2001 two BoFs, no WG created at that time
• 02-03 development at the corridors
• 2004 WG and RG created
• Now base protocol more or less ready
• Four interoperating implementations
• More work needed on mobility, multi-homing,NAT
  traversal, infrastructure, and other issues

8
Architectural background

• IP addresses serve the dual role of being
• End-point Identifiers
• Names of network interfaces on hosts
• Locators
• Names of naming topological locations
• This duality makes many things hard

9
New requirements to Internet Addressing

• Mobile hosts
• Need to change IP address dynamically
• Multi-interface hosts
• Have multiple independent addresses
• Mobile, multi-interface hosts most challenging
• Multiple, dynamically changing addresses
• More complex environment
• e.g. local-only connectivity

10
Related IETF WGs and RGs
Better-Than-Nothing Security, IKE requires
authentication (shared secret, certificate,
Kerberos), Unauthenticated IKE, Bare RSA keys,
self-signed certificates, late binding
IPv6 Signaling and Handoff Optimization
Site multihoming for IPv6 minimize adverse effects
IKEv2 mobility and multi-homing support.
Multiple/changing prefixes in SA.
Site multihoming by IPv6 Intermediation, new shim
layer, based on Multi6
Multi-homing
Namespace research group (IRTF), need other
namespace than IP? API implications.
shim6
mobike
hip
btns
11
Presentation outline

• Introduction What and why?
• Background
• HIP in a Nutshell
• Mobility and multi-homing (multi-addressing)
• HIP infrastructure Hi3
• Current status
• Summary

12
HIP in a Nutshell

• Architectural change to TCP/IP structure
• Integrates security, mobility, and multi-homing
• Opportunistic host-to-host IPsec ESP
• End-host mobility, across IPv4 and IPv6
• End-host multi-address multi-homing, IPv4/v6
• IPv4 / v6 interoperability for apps
• A new layer between IP and transport
• Introduces cryptographic Host Identifiers

13
The Idea

• A new Name Space of Host Identifiers (HI)
• Public crypto keys!
• Presented as 128-bit long hash values, Host ID
  Tags (HIT)
• Sockets bound to HIs, not to IP addresses
• HIs translated to IP addresses in the kernel

Process
Host ID
IP addr
lt , portgt
Transport
IP address
IP layer
Link layer
14
An analogy What if people were hosts
Current IP
HIP
15
More detailed layering
Transport Layer
End-to-end, HITs
IP layer
IPsec
HIP
Fragmentation
Forwarding
Hop-by-hop, IP addresses
Link Layer
16
Protocol overview
Responder
Initiator
17
Base exchange
Select precomputed R1. Prevent DoS. Minimal state
kept at responder! Does not protect from replay
attacks.
Based on SIGMA family of key exchange protocols
standard authenticated Diffie-Hellman key
exchange for session key generation
Initiator
Responder
solve puzzle
verify, authenticate, replay protection
draft-ietf-hip-base-02.txt, draft-jokela-hip-esp-0
0.txt
18
Other core components

• Per-packet identity context
• Indirectly, through SPI if ESP is used
• Directly, e.g., through an explicit shim header
• A mechanism for resolving identities to addresses
• DNS-based, if FQDNs used by applications
• Or distributed hash tables (DHTs) based

19
How applications work today(when IPsec ESP is
used)
DNS server
Server app
Client app
IKE
IKE
socket API
socket API
IPsec SAD
IPsec SPD
IPsec SPD
IPsec SAD
20
One way to implement HIP
DNS server
Server app
Client app
socket API
socket API
IPsec SPD
IPsec SPD
21
Using HIP with ESP
DNS server
Server app
Client app
socket API
socket API
IPsec SPD
IPsec SPD
22
Many faces

• More established views
• A different IKE for simplified end-to-end ESP
• Super Mobile IP with v4/v6 interoperability and
  dynamic home agents
• A host multi-homing solution
• Newer views
• New waist of IP stack universal connectivity
• Secure carrier for signalling protocols

23
HIP as the new waist of TCP/IP
v4 app
v6 app
v4 app
v6 app
TCPv6
TCPv6
IPv4
IPv6
IPv4
IPv6
Link layer
Link layer
24
HIP for universal connectivity

• Goal
• Lowest layer providing location-independent
  identifiers and end-to-end connectivity
• Work in progress
• Support for traversing legacy NATs
• Firewall registration and authentication
• Architected middleboxes or layer 3.5 routing
• Identity-based connectivity with DHTs

25
Signalling carrier

• Originally HIP supported only ESP-based user data
  transport (previous slides)
• ESP is now being split from the base protocol
• Base protocol is becoming a secure carrier for
  any kinds of signalling
• Support for separate signalling and data paths
• Implicitly present in the original design
• Now being made more explicit

26
Faces summary Motivating architectural factors

• A reachability solution across NATs
• New waist for the protocol stack
• Built-in security
• Implicit channel bindings
• connect(HIT) provides a secured connection to the
  identified host
• Puzzle-based DoS protection
• Integrated mobility and end-host multi-homing

27
Presentation outline

• Introduction What and why?
• Background
• HIP in a Nutshell
• Mobility and multi-homing (multi-addressing)
• HIP infrastructure Hi3
• Current status
• Summary

28
Introduction to IP based mobility and multi-homing

• Mobility implemented at lP layer
• IP addresses are assigned according to topology
• Allows for routing prefix aggregation
• Mobile hosts change their topological location
• Multi-homed hosts present at many locations
• In an IP based mm solution
• Transport apps do not see address changes or
  multiple addresses

29
Rendezvous

• Initial rendezvous
• How to find a moving end-point?
• Can be based on directories
• Requires fast directory updates
• Bad match for DNS
• Tackling double-jump
• What if both hosts move at same time?
• Requires rendezvous point

30
Mobile IP

• Home Agent (HA)
• Serves a Home Address
• Initial reachability
• Triangular routing
• Route optimization
• Tunnels to bypass HA
• HA as rendezvous point

HA
MN
CN
31
Multi-addressing dimensions
Multi- homing
end-host multihoming
SoHo site multihoming
enterprise multihoming
moving, multi-homed networks
ad hoc networks
end-host mobility
Moving networks (NEMO)
Mobility
One host
Single subnet
Parts of topology
All hosts
32
HIP Mobility Multi-homing

• Mobility and multi-homing become duals of each
  other
• Mobile host has many addresses over time
• Multi-homed host has many addresses at the same
  time
• Leads to a Virtual Interface Model
• A host may have real and virtual interfaces
• Merges the Home Agent

33
Mobility protocol
Corresponding
Mobile
ESP from MN to CN
34
Presentation outline

• Introduction What and why?
• Background
• HIP in a Nutshell
• Mobility and multi-homing (multi-addressing)
• HIP infrastructure Hi3
• Current status
• Summary

35
Key distribution for HIP

• Depends on application
• For multi-addressing, self-generated keys
• Usually keys in the DNS
• Can use PKI if needed
• Opportunistic mode supported
• SSH-like leap-of-faith
• Accept a new key if it matches a fingerprint

DNS query A, AAAA, KEY
DNS reply A, AAAA, KEY
36
Basic HIP rendezvous
Rendezvous registration
I1
R1
R2
I2
37
HIP registration protocol
Server informs client about registrar capability
(BE)
Client
Server
Client requests registration
I1
R1 REG_INFO
Also update messages (protected) Cancel with zero
timeout
Authz. Based on local policies
I2 REG_REQUEST
R2 REG_RESPONSE
38
The infrastructure question

• HIs originally planned to be stored in the DNS
• Retrieved simultaneously with IP addresses
• Does not work if you have only a HIT
• Question How to get data based on HIT only?
• HITs look like 128-bit random numbers
• Possible answer DHT based overlay like i3

39
Distributed Hash Tables

• Distributed directory for flat data
• Several different ways to implement
• Each server maintains a partial map
• Overlay addresses to direct to the right server
• Resilience through parallel, unrelated mappings
• Used to create overlay networks

40
i3 rendezvous abstraction

• Trigger inserted by receiver(s)
• Packets addressed to identifiers
• i3 routes packet to the receiver(s)

41
Hi3 combining HIP and i3

• Developed at Ericsson Research IP Networks
• Uses i3 overlay for HIP control packets
• Provides rendezvous for HIP
• Data packets use plain old IP
• Cryptographically protected with ESP
• Only soft or optional state in the network

42
Hi3 and DHT-based rendezvous
i3 overlay based control plane
IP-based user plane
43
Control/data separation
i3 overlay based rendezvous infra
44
Hi3 overlay and IPsec connectivity

• i3 overlay for signalling (control plane)
• Routes only HIP control packets
• e2e ESP for data traffic (user plane)
• Firewalls/middle boxes opened dynamically
• Only end-to-end signalling (HIP)
• Middle boxes snoop e2e messages
• Lots of details to be filled in

45
An Internet control plane?

• HIP separates control and data traffic
• Hi3 routes control traffic through overlay
• Control and data packets take potentially very
  different paths
• Allows telecom-like control
• but does not require it

46
Benefits for everyone

• Operators
• Control, security, resilience, revenue
• Enterprises
• Security, resilience, mobility
• Individual users
• Security, mobility, ease of use

47
Benefits to operators

• More controlled network
• Data requires HIP handshake first
• Protection against DoS and DDoS
• Resilience
• Integrated multi-homing
• No single points of failure

48
Benefits to enterprises

• More secure firewalls
• Integrated mobility and multi-access
• Across IPv4 and IPv6
• No single points of failure

49
Benefits to users

• DoS and DDoS protection
• Supports home servers (NAT traversal)
• Configuration free baseline security(ssh-like
  leap-of-faith encryption

50
Presentation outline

• Introduction What and why?
• Background
• HIP in a Nutshell
• Mobility and multi-homing (multi-addressing)
• HIP infrastructure Hi3
• Current status
• Summary

51
Current status

• WG and RG formed at the IETF / IRTF
• First meetings in Seoul, March 2004
• Four known interoperating implementations
• A number of internet drafts
• Base specifications start to be mature
• About a dozen papers published or submitted

52
Implementation status

• Four interoperating implementations
• Ericsson Research Nomadiclab, FreeBSD
• Helsinki Institute for Information Tech., Linux
• Boeing Phantom Works, Linux and Windows
• Sun Labs Grenoble, Solaris
• Other implementations
• Indranet (obsolete), DoCoMo US Labs, rumours
  about other

53
Evolution of drafts Early era
54
Evolution of drafts Restart
55
Evolution of drafts Currently
Architecture
Base exchange
Mobility multi-homing
DNS
Rendezvous
Registration
11
56
Guesstimate schedule
Draft Curr. vers. at IESG
ietf-hip-arch -02 now
ietf-hip-base -02 fall 2005?
ietf-hip-esp -00 fall 2005?
ietf-hip-registration -00 fall 2005?
ietf-hip-dns -01 fall 2005?
ietf-hip-rvs -01 early 2006?
ietf-hip-mm -01 early 2006?
57
Presentation outline

• Introduction What and why?
• Background
• HIP in a Nutshell
• Mobility and multi-homing (multi-addressing)
• HIP infrastructure Hi3
• Current status
• Summary

58
Summary

• New cryptographic name space
• IP hosts identified with public keys
• Integrates security, mobility, multi-homing
• Evolving into a more generic signalling carrier
• Four interoperating implementations (total 7?)
• Base specifications start to be mature
• http//www.hip4inter.net
• http//www.tml.hut.fi/pnr/publications/

59
Backup / other slides
60
Virtual interface model
61
Presentation outline

• HIP in a nutshell
• A potential HIP roadmap
• Current activities
• NAT traversal or layer 3.5 connectivity
• Upper layer identifiers
• Hi3 and other DHT-based rendezvous
• Separating control and data traffic
• Concluding remarks

62
NAT traversal

• Legacy NAT traversal
• Apply ideas from STUN/ICE/STUNT... to HIP
• UDP tunneling
• Short term solution with a clear exit strategy
• SPI-NAT or architected NAT
• Make NAT aware of HIP messages
• Allow servers to register at the NAT
• Learn mappings for HITs and ESP SPIs

63
Upper layer identifiers

• Backward compatible APIs
• Current APIs form a major legacy asset
• HIP allows almost all applications to continue
  unmodified (no recompilation required)
• Q Use HITs / IP addrs / both as the ULID?
• New APIs
• Host vs. Session vs. Service identifiers?
• Using delegation?

64
Hi3 and DHT-based rendezvous
i3 overlay based rendezvous infra
65
Separating control and data

• Originally HIP was tightly bound to ESP, using
  ESP as the data encapsulation protocol
• ESP split from the base specification
• Allow other encapsulations in the future
• Maybe even plain TCP / UDP w/ null encaps
• Fast / slow path separation at middle boxes
• Optionally different locators for control / data

66
Presentation outline

• HIP in a nutshell
• A potential HIP roadmap
• Initial exploration
• Early infrastructure
• Enhanced Infrastructure
• Early markets HIP as a vertical solution
• Current activities
• Concluding remarks

67
Initial exploration

• Pair-wise host-to-host deployment
• e.g. my laptop and my personal server
• HITs typically stored in /etc/hosts
• 192.0.2.1 myserver
• 43bc45214933956c3445956ded233420 myserver
• Initial public test servers in the Internet
• hipserver.hiit.fi

68
Initial exploration
Client side NAT
myserver
mylaptop
69
Initial exploration Requirements

• Host
• Install HIP on the host operating system
• Linux HIPL or Boeing HIP
• BSD HIP4BSD (FreeBSD MacOS X soon)
• Windows Boeing HIP (cygwin based)
• Configure HITs in /etc/hosts
• Configure applications to refer to HITs
• Network none

70
Initial exploration Benefits

• End-to-end security between client and server
• Trust based on static configuration
• Client mobility and multi-homing
• Even across IPv4 / IPv6 boundaries
• IPv4 / IPv6 API-level interoperability
• Protection against CPU / memory DoS attacks
• Soon Client-side NAT traversal
• For plain clientserver TCP / UDP protocols

71
Initial exploration Challenges

• Per-host management of a new name space
• Policy configuration
• Semantics for unsuccessful handshakes
• Management of keys and address bindings
• Privacy management
• Address resolution from HIT to IP address without
  any infrastructure
• Must be explicitly configured

72
Early infrastructure

• Pair-wise deployment between early adopters
• e.g. my laptop and your experimental server
• Store HITs in the DNS as AAAA RRs
• Look like non-routable IPv6 addresses
• Returned as the last entry in an RR set
• Experimental rendezvous (Hi3) at PlanetLab
• Infrastructure for passing HIP packets

73
Early infrastructure
Rendezvous
Server side NAT
Client side NAT
yourserver
mylaptop
Helper box?
74
Early infrastructure Requirements

• Host
• No new significant requirements
• Maybe an update of the HIP software
• Infrastructure on the network
• Store HITs to DNS as AAAA records
• Install experimental rendezvous servers
• Routers and NATs
• no changes

75
Early infrastructure (Additional) benefits

• Opportunistic security between participants
• Perhaps build trust with DNSSEC
• Simultaneous mobility i.e., mobile servers
• Increases the cost of some flooding DoS attacks
• Potential attacker needs to solve the HIP puzzle
  before getting the real IP address
• NAT traversal for both client and server
• Unlikely to work for symmetric NATs

76
Enhanced infrastructure

• Internet-wide experimental deployment
• Stable rendezvous service
• Store HITs in the DNS using new RRs
• Benefits as before but larger audience
• Results to be reported in HIP RG experiment
  report
• Input to the IETF community

77
Markets take overHIP on selected vertical
markets

• Potential markets
• Multi-homed road warriors
• Operations and management
• Military or dual-use systems
• High-availability systems
• Mobile public networks
• e.g., municipal 802.11 networks

78
Issues for the afternoon

• Mobile networks
• Handling legacy IPv4 applications
• Upper layer identifiers
• Users, Services, sessions

79
Upper Layer IDsPreliminary thoughts
80
Outline

• Multiple HITs per a host
• Delegation
• Virtual host migration
• From virtual hosts to services
• Question of session identifiers

81
Multiple HITs per a host
Physical host HITPH
Virtual host HITVH1
Virtual host HITVH2
82
Delegation
Physical host HITPH

• Example Delegate the right to update locators
  from HITVH1 to HITPH
• General Delegate right X from HIT1 to HIT2

Virtual host HITVH1
Virtual host HITVH2
83
Virtual host migration
Physical host HITPH1
Physical host HITPH2
Virtual host HITVH
Virtual host HITVH
Virtual host HITVH
Delegate all rights from HITVH to HITVH
84
From virtual hosts to services
Service HITS
Physical host HITPH
Virtual host HITVH1
Virtual host HITVH2
Service Instance HITSI2
Service Instance HITSI1
Delegate all rights from HITS to HITSI1
85
Question on session identifiers

• We can now identify
• Real and virtual hosts
• Services and users
• What about sessions
• Should they have separate names
• If so, what kind of names?
• Consider dynamic multi-party applications such as
  a voice conference etc.