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)? Architectures and specs Deployed systems and workable infrastructure

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 Heikkinen et 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-aware Legacy 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 demultiplexing concurrent 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 systems Challenges: NAT and legacy firewalls legacy servers authentication through “captive” web pages Solutions: 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 Architectures Session 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: Hi 3 Gurtov & Joseph: Friends or Rivals: HIP and i 3 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 i 3 ) 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? PacketMiddle box EIDEID → Locator EIDEID → Locator EID*EID → Locator Locator*, EIDnothing *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

i3i3

i3i3

Plain HIP without DHT

Plain HIP with NAT

FA instead of NAT and RVS

45 HIP 61 Architecture Session James 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 Performance of Boneh/Franklin v.s. RSA RSA:1024 bit modulus BF: 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