Minutes compiled by Andrew McGregor and Jeff Ahrenholz
Meeting convened at 1PM, co-chaired by Tom Henderson and
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
- different architectural approaches (FARA, NIMROD, i3, etc.)
- general late binding and resolution issues
- 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
- 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
- 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.
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
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
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,
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.
Lars Eggert: Issue 4: Can we use HIP for DNS rendezvous and secure DNS?
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.
- 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
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.