Workshop on HIP and Related Architectures November 6, 2004 Meeting notes assembled by Tom Henderson, from notes of Tom Henderson, Carsten Bormann, and Joerg Ott Note: Please see 14 related position papers and powerpoint slides Attendees: ---------- Mike Walfish Hannes Tschofenig Pasi Eronen Jari Arkko Kevin Fall Ion Stoica Scott Shenker John Wroclawski Carsten Bormann Tim Shepard Andrei Gurtov Lars Eggert Martin Stiemerling Paul Francis Julien Laganier James Kempf Tom Henderson Pekka Nikander Joerg Ott Noel Chiappa Avri Doria Overview --------- The workshop was organized around three discussion sessions: 1. Applying and deploying an ID/locator split 2. Overlays, rendezvous, middleboxes, and delegation 3. General architectural directions ** Note: See slides for introductory material-- these notes ** only record selected comments during the discussion period 1. Comments from first session (discussion led by Tom Henderson): ------------------------------------------------------------------ Tom: This session's theme: crossing the chasm between specs and deployed system/workable infrastructure and hosts Kevin Is this workshop just focused on the Internet or other spaces? Tom: Other spaces are in scope. Paul: This seems to be about long-term IDs. Identifiers used to be kind of ephemeral... (Consensus that we need to think both about short-and long-term identifiers) James: Is there a difference between ID management and key management? Tom: These are particular implementation issues. John: Most of this should be transparent; privacy (anonymous surfing) may be a nice hook.. Noel: longer lived IDs bring privacy problems. Pekka: They may seem like small architectural problems, but cause major work to get right. Scott: Current architecture does things implicitly w.r.t ID/locator split-- now we talk about doing explicitly Ion: Identifier management is a hard problem. One of the main problems is you don't want to have to expose function to users, so you have to choose default behavior (policy) about things that used to be implicit-- how to make right choices? Ion: Network shortcuts in i3 improves routing performance but exposes location-- a tradeoff. Lars: Do we see HIP as something that should make the Internet user interface easier? Ion: This kind of architecture gives you lots of flexibility, but somewhere you have to manage it. Tim: If you are in technology phase, before you get the early majority, you have to make it work for the innovators. They are hungry for a problem to be solved, so they are willing to deal with all these knobs; may be able to postpone an easy UI for later. Noel: OK, but are there any deep architectural issues here that would make building an easy UI hard? James Kempf: Key issue-- HIP users must see and derive benefit for this to get adopted. Pekka: To get more users, we need better UIs. Tim: Sell this to the innovators-- they will like lots of knobs. James: But even innovators need to be able to sell it internally. Noel: It is hard to quantify life cycle cost savings over the entire life of the architecture-- hard to wrap your brain around this. John: But the end-users are not the marketing target now, anyway. Ion: What are the HIP requirements? Who said you had to do anonymity? Tom: Has been complaint of HIP in the past, but was a conscious decision not to get too bogged down in requirements at first-- "build it and they will come" mentality. John: How to sell the power of a general architecture? Life cycle benefits are hard to quantify. A lot of these benefits are for the future. Requirements don't capture the future, unless you are really smart. Noel: Instead of requirements, we need to find some apps that people really love Kevin: Is it that all legacy apps must work on top of HIP? DNS? James: So maybe we need another name resolution? Pasi: If the benefit is in the future, selling this will be hard. Ion: But we do solve problems of the current Internet Paul: Legacy applications sort it out today (lack of permanence of the network layer) in ad hoc ways; e.g. IM just reconnects to server Pekka: we are trying to engineer HIP for the future; fewer hacks, but maybe we need to mess up the architecture slightly to engineer for the present. Noel: The right way to do that is to have shim layers on the bottom and the top of the right architecture. Don't get yourself into a position where you have to change the infrastructure. James: Yes, think of how the Internet started-- an overlay on telco networks. HIP might need to start as an overlay on the Internet. John: Big win of HIP is that it can be deployed between consenting apps (shim layers, corral all of the bad stuff into corners) Scott: if you require to change the infrastructure, that is a non-starter, vs. setting up a new name resolution service on PlanetLab (easy) James: We have been doing DHT stuff instead of DNS; how to deal with reverse HIT translation (discussion of API issues, resolvers, FTP referrals) Kevin: Is getting this legacy stuff working something we want to spend time on? Tom: One application we are concerned about is how HIP could enhance an application that doesn't use DNS at all-- just hard coded IP addresses. John: There are lots of tactical applications like that. Scott: So just change the way it is configured-- that should be easy. Tom: One problem is that it is hard to identify the application at the resolver level to return a non-IP-address name (distinguishing between HIP and non-HIP applicaitons). Tim: So do a LOAD_LIBRARY_PATH hack... Tom: What if application can't be recompiled or relinked? We are being forced down a path of instantiating a resolution infrastructure. Tim: Many of the peer to peer tools don't make use of DNS Noel: Killer app-- make it hard for the RIAA to track down file sharing-- I am only half joking. John: On using HIP, there are two pieces: i) making sure that the other guy is the one you wanted to talk to, and ii) getting there in the first place. For bootstrapping, could be done with a different mechanism. Kevin: Some of these are layering issues. Ion: You may not need to support all existing apps. (legacy middlebox traversal discussion) Current workarounds to NATs-- if you are forced by firewalls, (UDP) open TCP instead. Discussion on getting HIP base exchange through NATs, and various hacks like IP over HTTP, and the work on middlebox traversal like STUN. Paul: Discussion on NATs is ironic-- the point with HIP is that it does not care about locators-- so HIP should solve NAT. Tom: There has been some push to avoid HIP-over-transport Pekka: Doing that too early would have been a mistake-- we would have screwed the architecture. We can do additional layers for NAT now. Noel: Remember TCP over NCP... the ugliness is hidden from the user. Martin: HIP base exchange needs clear IP. Pekka: We could make it run over TCP and UDP Pasi: L3.5 should be a spanning layer that hides this.. isn't this incompatible with legacy apps? Noel: So have two shim layers Lars: Why not use IPv6 NAT traversal? Jari: I don't like the IPv6 NAT traversal very much. (break) (discussion about apps and killer apps, including possibly SIP) Noel: SIP using HIP and HIP using SIP-- two issues Scott: and redesign of SIP assuming there is HIP Kevin: If the benefit is primarily security-based, does SIP answer 95% of the problem? Tom: Yes, at application level. Pekka: Operators want control over the network; they see SIP and IMS as a way to do this. John: HIP mobility and multihoming-- should be separate from core HIP. Why is HIP overloaded with all of this functionality? John: Part of insights from tussle is that you need to find natural boundaries for things and put them on one side of the boundary, or else it will get torn by the tussle. Don't push a lot of policy mechanisms to HIP. James: SIP mixes session identifier up with setting up media-- these two should be separated. Hannes: what about replacing IP addresses in SIP with HIP? If I have HIP, what happens with SIP? Paul: My research is on NAT traversal and p2p; I'm focusing on SIP because i) taking off ii) has network connectivity negotiation (STUN/ICE) iii) has a lot of network layer choices (TCP or SCTP) SIP is going to be at core of p2p, and p2p community is picking this up because of STUN and ICE. John: STUN/TURN hmm; if you view SIP as the universal negotiator, HIP then is the thing that executes it after that. I'm concerned that a lot of policy is stuffed into HIP (both complexity and duplication of SIP). Could pull mechanism out of SIP into HIP, and policy out of HIP into SIP. (discussion on network configuration, SAML/SPKI to authenticate ephemeral IDs, IEEE 802.1x) Hannes: we are looking at ways to authenticate the visited network in our Ambient Networks project. Security for DHCP... Jari: Mobility is interesting not only at IP layer-- what do the devices do when they need to move? also lower layer, network attachment phase. Pekka: Like NATs, are "capturing web pages" (for user billing in public wireless networks) a burnt-in piece of architecture now? James: Maybe not-- might evolve into something built on SOAP-- also, many devices (VOIP) don't have web interface. What are other possible global IDs? - phone numbers (Tim S.: How do I get one?) - Microsoft GUIDs (a random number) - IEEE numbers - Mike Walfish: Look at Bryan Ford's UIP paper - Skype Pekka: My personal summary of this session: - make it work with NATs and don't care about the ugliness - make it attractive to geeks Noel: Have a viable deployment strategy (technical and adoption) Lars: and for me, what could we do with these new IDs? 2. Comments from second session (discussion led by Pekka Nikander) ------------------------------------------------------------------ Session theme is overlays, rendezvous, delegation, and middleboxes Notes from Pekka's session: Key questions: i) Layer 3.5 routing: where is the state (packets vs. middleboxes) ii) how do we do bootstrapping? iii) Rendezvous: overlay routing vs. looking up locators? Noel: Problems with source routing: - efficiency - how to create the source route (and this one is typically harder) James: may foster competition between ISPs... Ion: tradeoff between setting up middleboxes vs. source-routing Kevin: Networks that are not connected all the time, with EIDs, indirection is expensive if disconnected. On the other hand, sending data into well-connected area-- indirection is easy. Pekka: May be related to proactive vs reactive routing protocol in ad hoc networks. Considerable design space. Ion: Are peer-to-peer rendezvous mechanisms sufficient? (discussion on send packet to identifier? Where to do resolution and when?) Noel: Where do you draw the boundary in your diagram-- this forms an interface. Draw to the left (client) as much as possible. Pekka: We need to worry about the boundary (interface) on the server side as well. are identifiers ephemeral or permanent? should be no constraint on identifier semantics. are these user visible names or transport-level entity names? Noel: Is this architecture useful for server pools? That is a hard problem to understand. John W and Scott S: see if you can define a common core. is core of HIP too overloaded right now? Lars: Still need DNS even with RVS Supporting legacy servers -- stuffing the IP address of the RVS instead of the one making the update... Pekka: not a detail Tim: If the user types a DNS name, fine. What about apps that don't use DNS? Pekka: Could configure RVS Pekka: Different use cases... -- what do you have -- what are your security expectations -- what is your mobility pattern... at least 15 or 20 of these cases Paul: RVS in the middle of the data path? Pekka: If the NAT supports IPsec traversal, RVS does not need to be in the data path (Discussion about not using ESP if we need to use UDP anyway) Pekka: political problem -- some object to using "ESP" name in HIP (forwarding agent instead of NAT and RVS) Julien: Forwarding agent requires upgrading NAT? So do 6to4 instead Pekka: Network behind FA could be non-IP network Tim: RA is a router Pekka: Well, but they don't use a routing protocol, they need registration instead Tim: does this work if nested? Pekka: some ugliness Noel: If you have cycles you need routing Pekka: now imagining DHT. Nested FA that belong to the same DHT structure; nodes just need to register to one of the FAs identity-based routing -> across addressing realms Let's not block our way forward (to something like this) Pekka: identity-based routing down the stack In some parts of the network you can get rid of the IP... Tim: could it scale? Hannes: Is this something like MPLS? A signaling protocol that creates paths and then a different data protocol Noel: Dave Clark invented the term "49 layer problem" (when every layer tries to solve the problems of every other layer) fractal interface problem Mike: If all packets go through the infrastructure, you only need the primitive "send packet to some identifier" Noel: "route to an ID" does not scale Scott: You will not get universal agreement (on this side of the) room Noel: flat name space? Kevin: You didn't say shortest path routing; if you are willing to give this up to some extent, you can do this (2004 theoretical result) Pekka: HIP WG is standardizing DNS/RVS now. What happens if we replace RVS with i3? What happens if we merge RVS and NAT? What happens if both? Ion: identifier space, IP addresses, ... Noel: can we get to a space where we can upgrade the thing in the middle? Pekka: for legacy, we need to support DNS (name -> host identifier) Ion: In theory, you can do everything without invoking DNS name, just work at the ID level Kevin: region name == gateway to the namespace Noel: 1) how to get started, 2) how to transfer data John: "for legacy, use DNS" is misleading Kevin: cruft Noel: important cruft Lars: 1) DNS 2) HITs alone, reverse lookup (IP address or HIT to DNS name) 3) ...location privacy... mobility and multihoming and do you get benefits if talking to non-HIP hosts Pekka: stabilize 1) left side interface 2) right side interface John: independent of whether using HIP Ion: enough questions ...how to prioritize... Pekka: my priorities: -- combinations of different types of middle boxes -- DDoS protection; address hiding maybe HITs are ephemeral, and you have mapping on top of HIT (why change key) John: the tradeoffs between static and dynamic are well-understood CS issues Pekka: ephemeral -> cost -- generating -- propagating For DDoS protection, it gets very interesting to have ephemeral IP addresses Operations and management issues -- how to debug when addresses change all the time Dangers of centralization -- aim for decentralized -- how to manage free riding? Ion: Management is higher layers... e.g., do you allow identifiers to change during one connection Ion: In original HIP, identifier is host -- might as well be session, service, ... There should be one layer in which you impose very little constraints Might have different layers of identifiers Scott: define a core that does not preclude these things... John: HIP did start with a particular limited scope; new namespace for knowing that I'm talking to *you* without having location information ...I sense mission creep here... If the problem does not relate to this, go solve it somewhere else John: Marketing issue; hard to sell a car based on the quality of the drive shaft (and you sell these to the car manufacturers) Scott: If this car does not take us to Jupiter, I'm OK Noel: new name space -- people will figure out completely new ways to use it Pekka: Scott, JTW said: "core HIP" == "I know who you are" Ion: could be person, computer, ... Noel: DNS names name nodes in the DNS tree. HIP names name HIPpy things Pekka: So NATs are in the middle of the problem, as with NATs, you don't know who you are talking to John: HIP names are not user visible -- forces to misuse them are much less... John: Hiding by changing your name -- interesting... (transport layer connection surviving HIP name change?) Noel: for large distributed systems -- reallocate functionality -- endpoint concept may not be as useful here... John: TCP mobility argument replayed Scott: Why are we here? Usage of names in TCP... That's how TCP is interpreting these names... John: type of use creates specific constraints (e.g. visible to end users) more generality -> more constraints 3. Comments from third session (discussion led by James Kempf) ---------------------------------------------------------------- Discussion on Identity-Based crypto and various complaints (performance, parameters) associated with it. HIP as a session identifier. The architectural viewpoints of late binding/decoupling. FARA -- NewArch Right now in HIP: Identity Management = Key Management (which is an unsolved problem in the Internet) How to tie HIP identifiers to non-cyber world? go down the stack mitigate security attacks based on spoofed identity -> good for naive users compromise privacy and anonymity -> bad for spohisticated users DoCoMo Id Crypto: generate private key from public key (= identity) requires something like Kerberos Boneh/Franklin (best one so far) is much worse than RSA BF takes 250-300 ms at 1.5 GHz (vs. very small latency for RSA) Hannes: with Boneh/Franklin, at first you hear that you have an identity and can convert it into a public key -- in reality, you need paramaters as well. if you store the parameters in DNS, you can cache Tim: So you have to trust someone with your private key James: There are ways around that, key splitting and things, but you do need a security association to get Tim: So you could just do symmetric crypto and use Kerberos Kevin: what about disconnected operation? James: Send message to someone while offline... Hannes: generate public key independently... Hmm. Pasi: this is related to "what are the names identifying" e.g., tying it to a person... no longer endpoints JTW: try to separate: - is there a relationship between a session-based ID and "James Kempf" - are they implemented the same Original HIP was "host identifier" Some technical things become simple, some become out of scope If you expand you are "sucking the swamp" at an astounding rate (discussion on stack architecture) HIP works somewhat like a session layer Problem with layers (see newarch) -- pressure for new layer violations due to cross-layer optimization ... -- out-of-band signaling for middleboxes NewArch Roles? remodularize large IP protocols organization of data and metadata is different (backwards compatibility?) Compiler Model? Front end -- role modules activated by events back end -- events trigger compilation into standard stack layers John: The world isn't just e2e any more, different operations occur at different places depending on the circumstances, so this fits the discussion here pretty well Noel: Simple e2e model works for one host to one host; that's what OSI model was designed model; OSI model does not handle e.g. replicated service (discussion on routing) HIP uses underlying IP routing -- locators are IP addresses NATs/FWs and other middleboxes are reality Late binding: Include ID in packet Source route through the network to an entity that can resolve the ID to an actual locator (good for middleboxes) Removes need for DNS lookup Kevin: Is the scope of endpoints transient things like transport connections, or is it something app-related Tom: Are you suggesting the HIP concept still useful, but at a misplaced layer? Ion: Is this the right layer for identity enforcement? (return to discussion of what is a HIP name) Tom: HIP to me has been about two things: i) the lowest layer of naming in the stack without location semantics, and ii) the self-certifying property of the name due to being a public key Ion: Why does it have to be public key? What if you have other means of securing it? Tom: IMO, that would not violate the architectural benefits of HIP, but haven't seen a better proposal on how to secure it. John: In FARA, we tried to balance the cost of assurance vs. the benefit of securing who you are talking to. Ion: Why do I have to bind my identifier with semantics-- why can't I make it optional depending on level of trust I want to enforce? Tom: For security reasons-- even in i3, you have to add some security semantics to avoid trigger hijacking (secure i3). Ion: Yes but that is not the same as HIP. Pekka and James: If you do not secure the bindings, and you have mobility, you can actually inflict damage on third parties via flooding. If you take away mobility, maybe this risk goes away? Scott (and others): Do you want one way (HIP way) of binding lowest location independent name to locators, or many? Pekka: Does it make sense to decouple network from transport given that congestion control implemented in transport? Scott: Think of using HIP (public key name) to name even other things in the stack like data for instance. Maybe "host" in HIP is a misnomer that blocks thinking about it in other contexts. 4. Summary of workshop ----------------------- Pekka asked each participant to answer the following two questions: - What was important to you about the workshop? - What do you plan to do next? Mike Walfish Important: Appreciating the menu of possible middlebox traversals. Next: ID/locator split-- applying it to higher layers in the stack. Hannes Tschofenig Important: Position papers and time to have discussions. Next: Middlebox and firewall traversal-- hash-based HIP really interesting and implications to middleboxes Pasi Eronen Important: The goals discussion. Benefits of solving problems higher in the stack. Pros and cons of naming transport or something else. Next: Pros/cons of layer 3.5 solution or somewhere else. Jari Arkko Important: Legacy middleboxes/NATs, killer apps discussion. Next: NAT/middlebox problem, use of HIP in network access layer. Kevin Fall Important: How does IETF deal with architecture? Security issues of HIP. Lowest layer of location independence. Late binding. Touching upon the aspect of non-IP communications. SIP vs. HIP and Paul's comment that SIP will conquer all. Unmanaged Internet Protocol. Next: DTN is a client for whatever is stuffed in as an identifier, so eager to see what that evolves to become. Also interested in seeing how the globally unique identifier debate wrings itself out. Ion Stoica Important: Nice to see an entire session on configuration/management-- these are hard problems. SIP is more important than I thought. What are degrees of semantics associated with identifiers? Next: Look at tradeoff between convenience and security of identifiers. Applications-- no killer app has emerged, but in the end, need this. Noel Chiappa Important: Expanded ways of looking at HIP. Next: Interested in the 20-30 year out network design-- what is available path to get there? Scott Shenker Important: Decomposition of HIP into two pieces: A) public keys bound to identifiers, and B) identifiers bound to locators. Next: Can we, by using minimal extensions to infrastructure, get an incredibly simple clean core architecture and let proxies clean up the mess? John Wroclawski Important: Surprised at the sense of confusion about the role of HIP and what HIP should be. Disappointed in the weakness of the case for HIP-- lack of short term motivations, and presence of many alternatives to solve same problems. A negative result, but a result nonetheless. Next: NewArch will be continued but as part of an industrial consortium-- attention shifting to application architectures. Want to take today's results to that group. Carsten Bormann Important: Interested in what problems have been solved/ what woud be implications of solving these with HIP. Next: Very interested in header compression; SRTP for VoIP. Joerg Ott Important: Architecture discussion and disagreement/confusion over what HIP is. Surprised at the HIP and NAT traversal details. Need to look closer at ICE and SIP. Tim Shepard Important: Excited-- still a lot of opportunity for the next big thing. Something more useful than the Internet may be invented someday. Next: Look more at SIP and DHT. Andrei Gurtov Important: How things are done in i3 vs HIP. Next: Continued work on Hi3 and more performance tests. Avri Doria Interesting: How one evolves the network substructure. What does it really mean to be a HIT? Are we relocating the overloading in the architecture to another place? What degree of crypto is needed? Took the RIAA joke seriously-- is the need for anonymity a driving application or usage profile? Next: Consider where HIP fits into evolving network. Lars Eggert Important: Meta-level comments-- Time to talk unhurriedly was important, and also having a small group. Next: Rendezvous draft-- want feedback. Ambient Networks project-- naming and addressing HIP like (layered naming architecture). Namespace to name users. HIP enabled research project similar to PlanetLab. Martin Stiemerling Important: Middleboxes important. Discussion about whether the "host" in HIP is correct or the wrong thing to name. Next: Middlebox problems. Paul Francis: Important: Workshop convinced me that the main problems in the IP layer are not identification but reachability (NATs) while allowing firewalls to still do their job. HIP doesn't play an important role, and there is no killer app. Next: SIP might be a deployable solution. Looking at DDoS architectures and NAT traversal. Julien Laganier: Important: Discussion on what we should be naming. Do you really need strong cryptographic identities? ID routing vs. lookup architectures. Next: Rendezvous and resolution integration. James Kempf Important: Narrowing of definition of identity. How important is reverse HIT translation? Next: Working on Hi3 Tom Henderson Important: Came into meeting with concern over lack of killer app. Now thinking that NAT traversal might be important there; however, discussion of "core HIP" and whether we want one way or multiple ways of binding identity to locator seems to give HIP an identity crisis. Next: Still believe in the power of the id/locator concept, but need to rethink some of HIP fundamental assumptions. Want to continue to progress implementations especially so we can experiment with NAT traversal. Pekka Nikander Important: Discussion on importance of NAT traversal. Thinking of HIP as lowest layer of location independence in the stack. Next: Work on NAT traversal. (Pekka wraps up workshop) Here is my summary of some themes that emerged. lowest layer of location-independence narrow or wider focus Tradeoffs in ID semantics security vs. convenience How to coherently incorporate middleboxes what are the options Killer apps: NAT, FW, IPv4/v6 crossing layer Config and mgmt is a hard problem Ion & Scott: A) PK to ID B) ID to locator Paul: reachability HIP is not needed Meta issues: IETF vs. architectural questions Misc: late binding location vs. security Kevin: What effect will this have on WG and RG? Pekka: -- WG may need to expand charter, registration protocol (not just rendezvous) -- RG: I don't know yet. (end of workshop)