Host Identity Protocol Research Group (hiprg)
These are the minutes for the IRTF Host
Identity Protocol Research Group (hiprg) meeting, held at IETF-60 on
August 6, 2004, in San Diego. Thanks to Tim Shepard, Andrew McGregor,
and Julien Laganier for their contribution to these minutes. 83 people
signed the pink attendance sheets.
The meeting agreed to the following agenda, after moving Jari Arkko
to the last slot of the session:
o Administrivia/Agenda Tom Henderson (5 minutes)
o Review of HIPRG charter and work plan Tom Henderson (20 minutes)
o HIP native API Laganier/Komu (15 minutes)
o HIP over Network Address Translators M. Stiemerling (15 minutes)
o HIP rendezvous concepts L. Eggert (15 minutes)
o A Layered Naming Architecture for the Internet
- Combining HIP and i3 K. Lakshminarayanan (10 min)
- Flat Names in a Delegation-Oriented Architecture M. Walfish (10 min)
o Host Identity Indirection Infrastructure (Hi3) J. Arkko (20 minutes)
o Open mike
The minutes below do not attempt to summarize the slide presentations
but only the subsequent questions and discussion.
1. HIP RG overview (Tom Henderson)
Tom Henderson: any questions?... (none)
2. HIP Native API (Julien Laganier)
Lars Eggert: Why are you binding to a src interface rather than
Julien: Ask Miika for motivation.
Kevin Fall: Have you thought about running apps over a non-IP
environment? Will we have the transport to plug into this?
Julien: Pseudoheaders in HIP use the HITs.
Joe Touch: Binding to interfaces doesn’t make sense. Interfaces have
multiple IP addresses. A single host identity must be able to bind to a
particular IP address, for policy reasons.
Tim Shepard: What if no DNS? Nervous about building in dependencies on
Julien: use /etc/hosts. Can fall back to opportunistic mode too.
Andrew McGregor: Agree about not binding to an interface. You may want
to bind to a HIT and use a setsockopt() to associate a locator with it.
Kevin: Thought of a better way to ask my previous question. Can HIP run
on other networks?
Julien: haven’t thought about this. (no discussion)
??: Why are you using DNS to bootstrap this system? How to find the DNS
server? I think that using DNS is a bad idea.
More questions? See http://hipl.hiit.fi/hipl/
3. HIP over NATs (Martin Stiemerling)
-- main changes since last time-- added section on HIP-unaware NATs
Tim Shepard: Suggest that you look at RFC 3056/3068 approach for 6-to-4
NATting as an approach for HIP NATs. Use IPv4 anycast to traverse. This
approach is not HIP-specific. Would be happy to point author to the
Tom: Does this provide mechanism to learn your public address?
Tim: Inside hosts just do IPv6. Embedded in the /48 prefix is the IPv4
4. HIP and Rendezvous Servers (Lars Eggert)
-- Most significant change is location privacy ideas due to Marco
Lars: Should we keep this draft together or split apart (maybe split
the privacy concepts out)? Draft is getting kind of big.
Julien: In favor of splitting documents.
Andrew: Observation: Location privacy is about the only sane reason for
using a NAT.
5. Delegation (Mike Walfish)
- this is a position paper being presented at ACM Sigcomm in a few
Joe Touch: Names resolve to delegates? Aren’t they really talking to
the host? If names resolve to delegates, are the delegates not the
endpoint? The indirection here has no real meaning.
Mike: need to have delegation in the architecture..
Lars: In your picture of cascading NATs, what if NAT translates the
Hannes Tschofenig: Look at the literature on this topic.
Mike: Do you mean the MIDCOM stuff?
Hannes: Yes, and ...
Melinda Shore: the main problem with NAT is that it doesn’t translate
an address. NATs don’t have presence on the Internet ...
Mike: we are advocating that we explicitly put NAT in the resolution
Melinda: decoupling service identifier helps a lot (better than port
numbers), so this would be a positive step.
Hannes: Security problems of NAT firewall signaling. Since there is a
separate protocol for this, it might cause security problems.
Mike: We have a tech report coming out in December that is explicitly
concerned with security.
Julien: Why not use application IDs instead of service level IDs? Why
do you have two?
Mike: Might be misunderstanding? (Yes). Proposing that same resolution
system use to serve both name spaces.
Kevin Fall: IP addresses and names went hierarchical in the 1980s. Why
flat now? Is this overkill?
Mike: So can have persistence irrespective of moves.
Kevin: Hierarchical spaces easier to administer.
Mike: Granted. But I don’t think that humans should administer this.
Kevin: Indirection is presently useful. Your indirection point is your
mail server and the identifier is the address. The time needed for
delivery is greater than for I3 (...)
6. i3 project (Karthik Lakshminarayanan)
Jari Arkko: What about security aspects of this? Do you have assumption
of security between a host and an I3 server
Karthik: eavesdropping in i3 is easy. For this an other reasons, we
need to secure the infrastructure. There are a number of crypto
primitives in a project known as secure i3-- written up in a UCB
Technical Report. The ID's is derived from the key, so you can
trivially establish SA (Id is a hash of the key).
7. Hi3 architecture (HIP and secure-i3) (Jari Arkko)
Lars: Hidden IP addresses don’t only provide location privacy-- they
Jari: Yes, but do you care as much if you are able to deflect attacks?
Joe: Previous speaker pointed out DataRouter project. In that project,
we provide a way to implement, via IP options, strings and string
substitution rules. Gives you an overlay with the performance of the
network layer. I’ll send a pointer to the list.
(editor’s note: see http://www.isi.edu/touch/pubs/iwan2003/)
Karthik: Why do you need middleboxes when you have i3?
Jari: May be possible to combine the two.
Hannes: I like this I-D because it reuses HIP and applies it to
overlays. You can see from some papers that P2P folks try to
reuse HIP work so I
think you're on the right track. Interesting thing: New Internet
looks a lot like MPLS-type things.
George Jones: I’m putting my black hat on now. Thinking of how to break
this. i) if you are going through middleboxes, these are opportunities
for attack, ii) you are offloading DoS protection onto the core of the
they going to want to pay for and maintain such infrastructure? Some of
these solutions just seem to be shifting the problem around.
Jari: i) the middleboxes functions can be distributed to lower the
impact of attack on a single one
Hannes: (in support of Jari) this improves the situation without trying
to solve all problems. The puzzle-cookie can provide some resilience,
and I3 also by hiding IP addresses.
Martin: ? (something about NAT)
Tom (chair): We’ve had three presentations now on richer architecture
concepts that make more use of overlays, indirection, privacy. Is the
RG interested in prioritizing this work? Or should other issues (like
APIs and NATs) take priority. (Some show of hands in support of
focusing on these architectural issues now).
8. Open mike
Aaron Falk: Speaking of applications, it may be useful to talk to the
SIP people, who are using IP addresses to identify infrastructure, and
see if HIP might be of use to them.
Tom: Yes, have had some discussions this week-- would be interesting to
see what aspects of HIP functionality that SIP has already implemented,
and what of HIP that SIP would use if HIP service were available.
Tom (chair): Any interest in participating in a HIP research workshop
prior to next IETF meeting (on Saturday)? (about 20-30 hands). Interest
in presenting? (maybe 5-8 hands)
Joe: Tacking onto IETF is generally bad because the week is very long
Tim, Andrew, others?: Yes, but many of us have travel budgets and time
constraints that make it convenient.
Avri Doria: We are also talking about such things in our RG and might
want to consider coordinating these type of things.