Workshop on HIP and Related Architectures Workshop Overview November 6, 2004 Tom Henderson, Pekka Nikander, and Scott Shenker

Transcription

1 Workshop on HIP and Related Architectures Workshop Overview November 6, 2004 Tom Henderson, Pekka Nikander, and Scott Shenker 1

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 2

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) 3

4 Sessions 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.) 4

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 5

6 Session 1: Applying and deploying an identifier/locator split Tom Henderson 6

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 7

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 8

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? 9

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) 10

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) 11

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? 12

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 13

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? 14

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

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? 16

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 17

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 18

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? 19

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? 20

21 3. Deployment incentives Can HIP (or other ID/loc split) have an SSHlike 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? 21

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 22

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 23

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) 24

25 Network configuration* DHCP- Discover DHCP- Request 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) 25

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? 26

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

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

29 Compared to Session I: More open ended Less structured About this session Just a few slides, and then let it go (Backup slides just for the case...)

30 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

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

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? Packet EID EID EID* Locator*, EID Middle box EID Locator EID Locator EID Locator nothing nothing [checks EID]

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 61 Architecture Session James Kempf DoCoMo Labs USA 45

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 46

47 Right now in HIP: Identity 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 47

48 Identity 48

49 Tying HIP identifiers to the noncyberworld? 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 49

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

51 Performance of Boneh/Franklin v.s. RSA RSA BF Encryption Decryption Signature Verify RSA:1024 bit modulus BF: 512 bit P 51

52 Stack Architecture 52

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? 53

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 54

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? 55

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 56

57 Routing 57

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? 58

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 59

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? 60

61 Summary of workshop Pekka Nikander 61

62 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

63 Round table summary What was important to you in today s discussions? What are you planning to work on (based on this)?

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

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

66 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

67 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