1

Workshop on HIP and Related Architectures

Workshop Overview

November 6, 2004

Tom Henderson, Pekka Nikander, and Scott Shenker

2

Goals

• Interaction and exchange of ideas– New name space(s) for the Internet– Consequences of separating ID/locator– HIP experimentation and deployment

• Outcomes– new perspectives for participants– identify research/experimental directions– identify areas of consensus or disagreement

3

HIP vs. other approaches

• Although HIP is a current focus of IETF/IRTF, workshop can consider other identifiers, e.g.– multi6 (SIM, NOID, CB64, WIMP, LIN6, multi6dt)– i3 triggers– non-global identifiers (FARA)– identifiers for web services– SIP URIs / IMS– Identity-based cryptography (DoCoMo paper)

4

1. Applying and deploying an ID/locator split– changing and managing applications and hosts– dealing with legacy infrastructure and middleboxes– introducing new infrastructure

2. Overlays, rendezvous, middleboxes, and delegation– advanced middleboxes and firewalls– advanced resolution and indirection

3. General architectural directions– late binding– encouragement of middleboxes in architecture– approaches (FARA, HIP, i3, NIMROD, multi6, etc.)

Sessions

5

Logistics

• $30 fee to cover catering (cash or check)– Payable to whom?

• Hotel wireless service only?• Availability of white papers on public site?• Working lunch (buffet sandwiches/salad)• Room vacated at 4:30• Discussions can continue at bar/dinner BOFs

tonight and through IETF– IRTF HIP-RG meeting Friday Nov. 12

6

Session 1:Applying and deploying an

identifier/locator split

Tom Henderson

7

Session discussion theme

• Assume that users and networks want to deploy ID/locator separation

• How to “cross the chasm” between architecture and reality (Early Adopters)?

Architecturesand specs

Deployed systemsand workableinfrastructure

8

Relevant white papers

• “HIP, a Marketing Analysis” by Tim Shepard• “HIPpy Road Warriors Jumping Hoods over

Road Blocks” by Pekka Nikander• “Network Attachment and Address

Configuration using HIP” by Seppo Heikkinenet al.

• “Middlebox Traversal of HIP Communication”by Martin Stiemerling et al.

• “Can SIP use HIP?” by Tom Henderson

9

Discussion organization

1. Host: Implementing and managing an ID/locator split– host and application concerns

2. Network: Making it work in today’s networks– firewalls– middleboxes (existing NATs)– (resolution) infrastructure

3. Incentives: Application/user incentives for deployment– what are the killer apps?

10

1. Some host/application concerns

• Managing another set of identifiers– DNS FQDN and IP can be complicated enough– securing new identifiers (e.g. against phishing)

• APIs and application IDs– the referral problem

• Support within network stack– changes to IPsec (BEET mode)– locator selection for multihoming– transport responses to mobility and multihoming– safekeeping of cryptographic material within

systems (trusted computing)

11

Experience with HIP implementations

HIP has been shown to work, but...• Software not completely ready for prime time• Not trivial to install

– modified kernel or tap packets to user-space

• HITs/HIs are cumbersome to deal with– stored in insecure places– how to manage multiple identities?

• Transport layer issues unsolved• API issues and locator spoofing have been hard

problems• HIP conflicts with host firewall policies (sometimes

outside of control of user)

12

Managing identifiers

• How are average users going to manage a new name space?– existing network/DNS configuration can be

confusing even today – privacy concerns– non-repudiation/revocation concerns

• Many stack identifiers (e.g. HITs) are not human readable– how to securely bind user-friendly names like URIs

to stack names?

13

API issues

What is the identifier used by transport and applications?

Alternatives:– Require apps to use to a new resolver library and

become HIP-awareLegacy apps?

– Spoof a “local scope identifier” as an IP address in the name resolution• Problems with referrals and delegation• What if no DNS query?

– Use IP addresses and do a “host NAT” in the stack• May cause ambiguity in mobility scenarios

14

In the network stack

• IPsec modifications for BEET mode• locator selection and management policies

(which to use when?)– relevant work: MAST, CELP

• locators change and transport protocols– Congestion control, MTU– what to do when no locators are active?

• where to store keys?– should be in hardware somewhere– how to make this less cumbersome?

15

Discussion

1. What can be done to make management of new name space(s) easier for users?• Privacy and security concerns• Standard ways of including identity in applications• New vs. legacy applications

2. What names are in use within applications and APIs, and how to secure the various bindings?

3. How to handle multiple identities and multiple locators within a stack• securing the identifiers (e.g., key escrow)• policy issues for transport connection triggers,

locator selection, etc.

16

2. Making it work in real networks

• Middlebox traversal– firewall restrictions– traversing legacy NATs– how??

• Deploying basic infrastructure– Resolution service (names to locators)– Dynamic Association Module (NIMROD) – keeping

resolution up-to-date across locator changes

• How much will it cost to support/administer?

17

Legacy middlebox traversal*• HIP base exchange

– would be a problem for IPv6 NATs– suggested IPv4 UDP HIP format is problematic for

NATs that use source port for demultiplexingconcurrent streams

– well-known problem of no inbound traffic– no means to indicate sender’s (public) IP address

• Firewalls have similar (policy) concerns• IPsec traversal of NATs• Application-level gateway traversal (e.g. HTTP

proxy)* Stiemerling, Quittek, and Eggert white paper

18

Infrastructure issues• Can DNS RRs suffice for name resolution?• What about deploying (flat) EID to locator

resolution?– e.g. Wide-scale DHT deployment

• How to optimize resolution services both for fast lookup and fast update?– or should update and lookup be handled separately?

• How much will this all cost to deploy and administer?

* Stiemerling, Quittek, and Eggert white paper

19

Discussion

1. Should we consider IPv4 a “lost cause”because of NATs/firewalls?– but can we expect to have pure HIP-aware IPv6

middleboxes?– or.... is IPv6 deployment a “lost cause”?

2. How much to “defile” the architecture to get it to work in current or anticipated networks?– Is transport port # now a fundamental piece of IP

header and should be treated as such?

3. Should work on Teredo/STUNT/NUTSS-like middleboxes (relays) to traverse transparent NATs be considered a priority?

20

Discussion (cont.)

4. Will flat (DHT) resolution mechanisms for new identifiers work on an Internet scale?

5. Should DNS be taken advantage of, or sidestepped?

6. How to get providers to support resolution infrastructure, and punch firewall holes?• how much can we expect it to cost and still get

deployed?

21

3. Deployment incentives

• Can HIP (or other ID/loc split) have an SSH-like success story?

• What applications need this now?– or are present workarounds “good enough”

• What new applications might be enabled by ID/locator split?

• How expensive will the deployment be?

22

Some possible applications

• HIPpy road warriors• HIP + SIP

– use SIP control plane to exchange host identities– use HIP to secure data plane and provide mobility

• Network configuration• ??

– multi6 (site multihoming for IPv6)– trusted computing– peer to peer– anti-spam

23

Road warrior case study (Nikander)

Requirements:• fully secured• no user actions and taking no time• mirrored synchronizing file systemsChallenges:• NAT and legacy firewalls• legacy servers• authentication through “captive” web pagesSolutions:• Upgrade NATs and firewalls• Possibly combining HIP and CGA in network access• HIP over UDP and related bridging/proxying

24

SIP+HIP case study*

• SIP can be used to disseminate Host Identities– negates somewhat the need for HIP resolvers

• HIP provides man-in-the-middle security in the data plane

• HIP mobility similar to MIPv6 with RO• Other HIP benefits similar to purpose-built-keys

or traditional IPsec?

(i.e., is HIP’s utility to SIP only incremental, as presently defined?)

*(Henderson white paper, and draft-tschofenig-hiprg-host-identities-00)

25

Network configuration*

• Additional techniques (SAML, SPKI) to authenticate ephemeral IDs• Related solutions?:

– Cisco Network Admission Control (NAC) and Microsoft Network Access Protection (NAP)

– Transactions for Accessing Public Infrastructure-- TAPI (Nikander et al)

*(Heikkinen, Tschofenig, and Gelbord white paper)

DHCP-Discover

DHCP-Request

26

Discussion

1. What are the possible killer apps for id/locator split in general, and HIP in particular?• enhancing existing apps• new applications

2. Or is HIP primarily a security (DoS and MITM prevention) enhancement?

3. Or is HIP a solution in search of a problem?

HIP and Related ArchitecturesSession II: Infrastructure, or Overlays, Rendezvous, Delegation, and Middleboxes

(Pekka Nikander)

Presentation outline•About this session–Related position papers

•A framework for the discussion–Combinatiorial complexity

•Where is the state?•Strapping the boots•Open questions

About this session•Compared to Session I:–More open ended–Less structured

•Just a few slides, and then let it go•(Backup slides just for the case...)

Related position papers

•Arkko et al: Hi3

•Gurtov & Joseph: Friends or Rivals: HIP and i3

•Eggert et al: HIP Resolution and Rendezvous•Walfish & Balakrishnan: ID/Loc Split is Useful for Middleboxes, too•Tschofenig et al: HIP Middlebox Traversal•Tschofenig et al: Advanced HIP-based Firewall Traversal

A framework for thought

•Maybe just one protocol (like in i3)•Maybe separated protocols (like HIP and ESP)•Maybe additional protocols–Registration, middle box internal, …

Combinatorial complexity•Combination of different types of middle boxes?–Existing NATs and firewalls–DHT nodes–Architected HIP-based and firewall–Application level intermediaries

Where is the state?

•How is the state created in the network?–Snooping?–Protocol?

•How much “state” is there in the packet?•Soft state, but softer or harder?

Packet Middle box

EID EID → Locator

EID EID → EID’ @ Locator

EID* EID → Locator

Locator*, EID nothing

<EID@Locator>* nothing [checks EID]

Bootstraps•How to arrange initial rendezvous?–Identity based overlay routing?–Look up locator(s) from the infrastructure?

•How to find the infrastructure?–Manual configuration is a bad answer!–!Anycast? Router advertisement?–Middle boxes that announce themselves on first communication?

Open questions (1)•Rendezvous: overlay routing or name resolution?•Bootstrap: how to find an infrastructure node?•Layer 3.5 routing:–How much state in packet vs middle boxes?–How is the middle box state managed?–Effects of asymmetric routing?

•What are the limiting and decisive factors?

Open Questions (2)•Address hiding and DDoS protection•Combination of different types of middle boxes?•Operations and management issues?–Debugging the system

•Dangers of having any centralization–Aim for decentralised infrastructure?•How to manage free riding?

Extra slides

i3

i3

Plain HIP without DHT

Plain HIP without DHT

Plain HIP with NAT

Plain HIP with NAT

FA instead of NAT and RVS

45

HIP Workshop@IETF 61

Architecture SessionJames Kempf

DoCoMo Labs USA

46

Papers for this session• “The FARA Architectural Model”, NewArch

– I’ll include the NewArch final report in the discussion, because it touches on many of the same issues but discusses them more broadly

• “The Benefits of Late Binding for HIP-like Mechanisms”, Lakshminarayanan and Stoica, UCB

• “Exploring Deeper Issues of Separating Identity and Location for Mobile Hosts” Kempf, Fu, Wood, and Kawahara, DoCoMo

47

Identity in HIP• Right now in HIP:

– identity management == key management

• Key management is an unsolved problem in the Internet currently

• Bottom line: Identifier is a computational object with undefined relationship to offline considerations

48

Identity

49

Tying HIP identifiers to the non-cyberworld?

• What it is:– Pushing identity down into the stack

• Why it might be a good idea:– Early mitigation of phishing and other security attacks based on

spoofed identity– Good for naïve users

• Why it might be a bad idea:– Compromises privacy and anonymity

• Are these the same? – Bad for sophisticated users

50

DoCoMo Id Crypto• Use identity-based cryptography to tie non-cyber identity to

security• Use identity as public key, generate private key from that

– Requires identity-based crypto key generator– Like Kerberos

• Identity could be DNS name, NAI or any other string– In principle, authenticatable at I3 or HI3 rendezvous – Looks like a good idea but...

51

0

50

100

150

200

250

300

Encryption Decryption Signature Verify

RSABF

Performance of Boneh/Franklin v.s. RSA

RSA:1024 bit modulusBF: 512 bit P

52

Stack Architecture

53

Stack Architecture• HIP works somewhat like a session layer but it’s not

at the OSI model session layer– Discussion this morning on SIP and HIP– HIT is session identifier across locator changes

• Is the OSI model out of date?• Does the stack architecture need some modification?

54

Problem with Layers*• Pressure for new layer violations due to cross layer

optimization • Functional dependency causes feature interactions

with loss of extensibility• Reluctance to change existing implementation leads

to introduction of inter-layer shims• Out-of-band signaling for middle boxes

*from NewArch final report

55

NewArch Roles?• Functional units of communication are roles

– Building blocks out of which a communication is built

• Remodularization of large IP protocols– Congestion control– Forward Packet– ...

• Organize data and metadata in packet is different• But what about backward compatibility?

56

Compiler Model?• Front end - Role modules activated by events

– Arrival of a packet– Some application level user action– ECN

• Back end - Events trigger compilation into standard stack layers

• Limited, won’t handle complex cases

57

Routing

58

HIP and IP Routing• HIP uses underlying IP routing

– Locators are IP addresses– Src/dest IP address pair

• NATs/Firewalls and other middleboxes are reality• Conventional wisdom is that they will disappear with IPv6

– Well, NATs at least...– But is will that really be so?

59

Late Binding• FARA and UCB• Include identifier in packet• Source route to network entity that can resolve the

identifier to actual locator• Removes need for DNS lookup• Semantics become “send packet to high level id”

rather than “send to address”

60

Discussion• What are the possible killer apps for id/locator split in

general and HIP in particular?– Enhancing existing apps– New apps

• Is HIP primarily a security (DoS and MITM prevention) enhancement?

• Is HIP a solution in search of a problem?

61

Summary of workshop

Pekka Nikander

Important•Lowest layer of location independence–Goals of HIP: Narrow or wider focus?

•Tradeoffs in identifier semantics–Security vs. convenience

•How to coherently incorporate middle boxes–Enumeration of what are the options–Discussion on legacy middle boxes and NATs

•Killer apps: NAT, FW, IPv4/v6 crossing layer•Configuration and management is a hard problem

Round table summary

•What was important to you in today’s discussions?•What are you planning to work on (based on this)?

Scott & Ion•What HIP is?–A: Map public keys to identifiers–B: Map identifiers to locators

Paul•Reachability is the important problem•Confirmation that HIP is not needed•No killer app needed

Meta-Important•How IETF deals with architectural questions•How one evolves into a new architecture•What are the building blocks for successful apps•Increased understanding of HIP and connections to other stuff•Understanding that there is this confusion of what HIP really is–Lack of short term motivation

•SIP may be more important

Misc points•Late binding•Location vs. security aspects•What should there be or not be•What degree of crypto is needed?–In Internet, private networks, etc.

•Peer-to-peer as a potential killer app