|
Minutes compiled by Andrew McGregor and Jeff Ahrenholz Meeting convened at 1PM, co-chaired by Tom Henderson and Pekka Nikander. 57 people signed the attendance sheets. 1. Agenda bashing ----------------- - move discussion of Experiment Report forward in agenda - add presentation by Pekka Nikander on HIP locators - agenda accepted by meeting attendees 2. Research group status ------------------------ - RG charter is to evaluate the benefit/impact of deploying HIP, report to IESG. - Therefore deployment experience and analysis in real networks. - Can have RG documents, chartered for HIP experiment report. 3. Review of HIP workshop results ---------------------------------- (see slides for more details) - Small workshop, with high-quality discussion. 1) Applying and deploying ID/LOC split. 2) Overlays, rendezvous, middleboxen and delegation 3) General architectural directions Conclusions from session 1 (deploying HIP): - Managing HIP is non-trivial - Middlebox traversal is important - No single "killer app" was identified Issues discussed from session 2 (overlays) - Rendezvous: overlay vs name resolution techniques - how to bootstrap? (how to find a first infrastructure node in the overlay) - Routing: source routing vs middleboxen (how much state in network vs. in packets)? - Debugging? (how to debug, e.g. if you can't reach an identifier) - Identifier types - late binding and resolution Issues discussed in session 3 - different types of identifiers (i3 flat identifiers, Boneh-Franklin cryptosuite) - different architectural approaches (FARA, NIMROD, i3, etc.) - general late binding and resolution issues Summary: - Value seen in having a "lowest location-independent identity" sublayer in the architecture (some called this "layer 3.5" although Tim Shepard objected to that terminology) -- but are specific benefits to enough applications enough to warrant deployment? - Recognize that HIP includes: A) key to identifier binding B) identifier to locator binding and these need not be coupled, and different solutions are possible for A) - What is core HIP? What are the essential features/functions? HIP needs to distinguish what are its core features and make sure those are clean and well defined. Comments: Tim Sheperd: Should locator to identifier binding be symmetric? DNS bindings are not (hard to put things in). Perhaps the user already has the locator, or uses DNS. Tom Henderson: Our implementation has required consideration of this. Gabriel Montenegro: HIP uses bare keys. Certs interesting, maybe with dates, URLs for OSCP servers, and all sorts of other information. Pekka Nikander: Many participants at the workshop wanted semantic-free identifiers, not even just the public key. Keith Moore: Killer apps are non-issues, esp. NAT traversal... existing NATs will be obsolete by the time HIP becomes widespread. Pekka Savola: Good point, get critical mass of deployed HIP so that then is invisible to users. Tom Henderson: Two issues here-- i) want to get people to start using the software, so we can evaluate it, and ii) HIP is a very general architectural solution, but to get it agreed upon, it needs to convey compelling enough benefit to at least some important applications to warrant the change. Pekka Savola: Following Keith's argument, I don't know whether we are at the point where we can say we have learned something from IPv6 transition, but with IPv6, you have to be able to build a base of deployment that is invisible to user. Pekka Nikander: I think it is the opposite of IPv6 deployment. There, you had to upgrade all of the routers. In HIP, we do not need to change the routers. Changing routers is a significant barrier. Pekka Savola: OK, I kind of agree with that. But on one particular point, even though user upgrades operating system, application developers need to know the HIP API. IPv6 aware apps are not that widespread. Pekka N: Most legacy apps "just work" with HIP; awareness of HIP will require specific API. Tom H: Workshop materials will be posted at HIP-RG supplemental page. 4. Experiment report (draft-irtf-hip-experiment-00.txt) -------------------------------------------------------- - This is a skeleton of the first RG document we are chartered to do. - Contributions requested, presently only an outline 5. New locators for HIP (Pekka Nikander) ---------------------------------------- (see slides for more details) Pekka N: This is follow-up of yesterday's PATH (Preferred Alternatives for Tunneling HIP) discussion. May want to revise the concept of locator that we have. Basic assumption with IP address is you can send any type of packet to the address. Proposing that at the minimum we have locators of form <IP, UDP Port> or <IP, proto, port>. Dave Crocker: How do you know what to do if you are an endpoint? Pekka N: You still need specification saying what to do. e.g., if you have HIP packets and you want to send them to this certain server. Keith Moore: That's like answering which address do you want to use when you get multiple from DNS. Dave C: OK. This may be the only thing that we can do. Gabriel N: This is intended to work for NATs, but have you thought about expanding this to consider services, e.g., may span a range of ports, something more general. Pekka N: Don't see immediate need to go there, lets try to solve the 80% problem first. Pekka N: OK, next step would be also to split the type of locators-- some may work only for HIP traffic (such as non-data-forwarding RVS). Keith Moore: You definitely need a type of locator-- I can already see situations that would go beyond what you have there. Pekka S: What kind of assumptions do you have for the middleboxes to support this? Pekka N: The drafts and mailing list discussions will later address this. (research group consensus was this was a good idea) Pekka N: Spec changes therefore: mobility management needs locator types, also DNS draft needs modified. Also define HIP/UDP, REA locator types, use packet formats and RVS when behind NAT. Tom H: Follow up these on WG list instead of RG? Pekka N: Yes. Just wanted to start discussion here. Lars Eggert: This looks like policy routing, and it could get complex. Pekka N: Yes, it is-- that's why I don't know if this is a good idea. 6. Lars Eggert, draft-eggert-hiprg-rr-prob-desc-00.txt HIP Resolution and Rendezvous Problem Description ------------------------------------------------------- (see slides for more detail) Lars Eggert: Draft doesn't propose any specific solution. Let's talk about what the problems and the issues are. Terminology. Some issues: Issue 1: DNS dependency for FQDN resolution Issue 2: Direct communication (know HIT but not locator) Issue 3: Reverse lookup IP->HIT->FQDN Gonzalo Camarillo: IP to HIT resolution? Why not contact the IP address directly and get the HIT? Lars: Well, this is just like what you can do in DNS. Julien Laganier: You cannot easily ask a peer "what is your FQDN" though. Tim Shepard: What are we supposed to get out of this? Is this a proposal or not? Hannes: Back to Gonzalo's point, there are different security issues whether you ask a peer for its HIT or look it up. Gonzalo: HIT to FQDN might help some applications that have embedded DNS clients. Pekka N: I don't believe in reverse lookup in DNS; HITs are flat random numbers, which is not nice for DNS. Lars: I'm not proposing to do this with the DNS, but if a proposal supports it, lets know it. Gabriel: Mechanism is a separate question from the desired functionality Pekka N: Why is reverse lookup useful? My philosopy seems different from yours-- I want to keep it simple and get it out. Lars: NAT traversal is getting complex... we tend to be giving up some of the thinking in this work and going for specific solutions too soon. Tim: I'd like to question one of your points "Reverse lookups are useful". Are reverse lookups useful? Please explain? Lars: Do reverse lookups in IP all the time, for debugging. SSL does it, for instance. Tim: broken reverse zones are a nuisance, and provide no security. Lars: Certs are based on domains, maybe wrong, but that's how it is. Maybe I should say "reverse lookups are used" rather than "useful" Julian: Could be useful for debugging Pekka S: Reverse lookups are often used as ACLs. Dave Crocker: One of neat things about internet architecture is how simple and clean the core is. Very streamlined core, although it is now surrounded by complexity. Now, the question of "what relies on DNS?" This is an example of a core decision. It might be a horrible thing to make HIP depend on that. Reverse lookups are poorly maintained operationally. Keith: Slightly stronger statement than Dave's: HIP is extremely useful without DNS. In practice the less DNS reliance, the better for everyone. (applauase) Lars Eggert: Issue 4: Can we use HIP for DNS rendezvous and secure DNS? Tim: Why? Lars: Mobile networks, for instance. Pekka N: This strikes me as a hammer looking for nails. Probably not the right thing-- too heavyweight. Lars: HIP is supposed to be layer 3.5, why not use it for this? Keith Moore: HIP should be orthogonal to DNS. Must have at least one locator for the host you want to talk to. HIP should treat DNS like any other host. HIT to locator mappings is a problem that HIP should not even try to solve. Tim: What is a 3.5 layer protocol? Don't like the terminology. Lars: - Issue 5.1: middleboxen - Issue 5.2: Location privacy - Issue 5.3: Mobility and multihoming - Issue 5.4: Legacy interop Pekka N: I suggest we let this evolve... fairly sure we're missing something. Also, think DNS and RVS are not related. Tim S: Having trouble working out how location privacy works. Keith Moore?: Just use a middlebox Pekka N: This is not core HIP. Keith: It's worthwhile to ask the question "What belongs in HIP?" Tom Henderson: Let's move this to list-- could end up contributing to Experiment Report. 7. Hannes Tschofenig, draft-tschofenig-hip-natfw-traversal-00.txt NAT and Firewall Traversal for HIP ----------------------------------------------------------------- (see slides for more detail) - This is a report from some work from Ambient Networks project. - This is the case where the middlebox is HIP aware; a list of what HIP-aware NAT/FW need to be able to do. Martin: Why would someone extend middleboxes again for a new protocol? NSIS for example provides a more generic support. Hannes: There is a difference between this work and NSIS work. We've been exploring this design space in NSIS but there might be some good feedback from HIP RG/WG. - Interception at NAT, establish some state at NAT-- one such proposal was SPINAT, and some other references - Authorization at the NAT. - Dynamic discovery of middlebox - Registration procedure properties - More complicated scenarios that include firewalls. Possible solutions? Pekka S: Observations-- now that there is consensus that NAT traversal is required, it strikes me that this might be something that doesn't require going forward with high priority. Firewalls can be handled with rules and more general mechanisms; NATs might not be upgraded in any case. Hannes: There are different security problems. There are some scenarios where you can't use only legacy NAT traversal to achieve the same results. e.g. you can't just use STUN to achieve the same results as in rendezvous servers, overlays, etc. Jari: What type of authorization are you looking at? Hannes: You might have registered to a particular network and you want to be sure that you are able to create some state. Jari: This is somewhat lower in the stack Hannes: Haven't gotten into more complicated authorization decisions yet; I don't want to go down this path. Tim: When discussing Teredo and other mechnisms, it seems that these mechanisms are only temporary until you can replace NAT. That strikes me as a much more optimistic view of the future. This talk has been fairly pessimistic, in that it is about who can control what... we need to consider thinking more about future networks that don't have to use these midlleboxes. Hannes: Sorry if talk gave you depressing future. Most people use middleboxes as how they are today. This new type of middlebox may be something more positive, like a mobility anchor. Tom: To respond to whether HIP-specific middleboxes are needed, we have been considering whether it is possible to build a HIP-aware firewall that did not require explicit registration-- could look up the information by snooping the HIP packets. However, I wonder whether there still is any hope for such operation-- will we ultimately end up with a more explicit firewall design that requires registration in most cases? Hannes: Registration is not mandatory. Other signaling is up to further discussion, it's a different migration path. Should be discovered automatically. Pekka S: Responding to Tim, I would have used optimistic/pessimistic in the opposite order. If you are pessimistic, you don't expect NAT to be upgraded. This is one of the mistakes we made in IPv6-- we wanted the first hop routers to support the features in some way. Keith Moore: Avoid the use of "middlebox" term as much as possible... confusing. Also, make the world a better place when designing extensions to stuff. In this case, remember the principle of "separation of function." One problem with NATs is the tendency to assume that the NAT needs to know everything about every protocol that traverses it. The right thing to say is: "This is transparent to NAT" 8. Hannes Tschofenig, draft-tschofenig-hiprg-host-identities-00.txt Exchanging Host Identities in SIP ----------------------------------------------------------------- (see slides for more detail) - This talk is about whether SIP can benefit from HIP and vice versa? Gonzalo: On one of the first slides, you are talking about how SIP can benefit from HIP-- think about vice versa as well. Hannes: If we provide a sound story for NAT traversal, HIP-aware NATs, that may be one way. Gonzalo: We could be waiting years for these HIP-aware middleboxes, but SIP is happing now, and SIP didn't require that NATs be upgraded. Could use HITs for instance identifiers. Jari: Looking at SIP security, one thing is that SIP architecture uses a lot of nodes-- making sure all of these things match is tricky-- binding between all of them might not be easy, unless there was an API apps could use-- but how would you do that in HIP? I don't know. Experience from IPsec side is that the lack of visibility to apps/APIs has been problematic. Gonzalo: Another thing-- how to change certificates? How to change the one you use in HIP and the one used in SIP. Link the two, perhaps as Jari was saying. Also, HIP without IPsec could be good because there is more efficient S-RTP. Hannes: HIP can't establish security associations without IPsec associations. 9. Final comments (Tom Henderson) ---------------------------------- - three current public implementations of HIP available, and status briefed Questions to group: - how many people are interested in running HIP software? (many hands) - how many people have been put off by lack of maturity? (one hand) - how many people favor continuing on Friday afternoon as a regular slot? (some support voiced, no dissention) Tom noted that the last question should be raised on the list for the benefit of those people who don't find it convenient (and weren't actually present to voice opinion) Meeting adjourned at 3:25 PM. |