Workshop on HIP and Related Architectures

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. Sessions • Applying and deploying an ID/locator split • changing and managing applications and hosts • dealing with legacy infrastructure and middleboxes • introducing new infrastructure • Overlays, rendezvous, middleboxes, and delegation • advanced middleboxes and firewalls • advanced resolution and indirection • General architectural directions • late binding • encouragement of middleboxes in architecture • approaches (FARA, HIP, i3, NIMROD, multi6, etc.)

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

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 • Host: Implementing and managing an ID/locator split • host and application concerns • Network: Making it work in today’s networks • firewalls • middleboxes (existing NATs) • (resolution) infrastructure • 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 • 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 • What names are in use within applications and APIs, and how to secure the various bindings? • 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 • 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”? • 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? • Should work on Teredo/STUNT/NUTSS-like middleboxes (relays) to traverse transparent NATs be considered a priority?

20. Discussion (cont.) • Will flat (DHT) resolution mechanisms for new identifiers work on an Internet scale? • Should DNS be taken advantage of, or sidestepped? • 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) DHCP- Discover DHCP- Request *(Heikkinen, Tschofenig, and Gelbord white paper)

26. Discussion • What are the possible killer apps for id/locator split in general, and HIP in particular? • enhancing existing apps • new applications • Or is HIP primarily a security (DoS and MITM prevention) enhancement? • Or is HIP a solution in search of a problem?

27. HIP and Related Architectures Session II: Infrastructure, or Overlays, Rendezvous, Delegation, and Middleboxes (Pekka Nikander)

28. Presentation outline • About this session • Related position papers • A framework for the discussion • Combinatiorial complexity • Where is the state? • Strapping the boots • Open questions

29. 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...)

30. 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

31. 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, …

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

33. 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?

34. 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?

35. 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?

36. 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?

37. Extra slides

38. i3

39. i3

40. Plain HIP without DHT

41. Plain HIP without DHT

42. Plain HIP with NAT

43. Plain HIP with NAT

44. FA instead of NAT and RVS

45. HIP Workshop@IETF 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...