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.

Agenda

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)
    - http://hipl.hiit.fi/hipl/hip-native-api-snapshot-20040708.pdf
 
  o HIP over Network Address Translators     M. Stiemerling  (15 minutes)
    - draft-stiemerling-hip-nat-01


  o HIP rendezvous concepts                  L. Eggert       (15 minutes)
    - draft-eggert-hip-rendezvous-01
     
  o A Layered Naming Architecture for the Internet
    - http://www.acm.org/sigs/sigcomm/sigcomm2004/papers.html#A_Layered_Naming
    - 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)
    - draft-nikander-hiprg-hi3-00.txt
 
  o Open mike

Presentations

The minutes below do not attempt to summarize the slide presentations but only the subsequent questions and discussion.

1. HIP RG overview (Tom Henderson)

Slides

Tom Henderson: any questions?... (none)

2. HIP Native API (Julien Laganier)

Slides

Lars Eggert: Why are you binding to a src interface rather than address?

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

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)

Slides

-- 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 relevant RFCs.

Tom: Does this provide mechanism to learn your public address?

Tim: Inside hosts just do IPv6. Embedded in the /48 prefix is the IPv4 address.

4. HIP and Rendezvous Servers (Lars Eggert)

Slides

-- Most significant change is location privacy ideas due to Marco Liebsch.

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)

Slides

- this is a position paper being presented at ACM Sigcomm in a few weeks.

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

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 step

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)

Slides

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)

Slides

Lars: Hidden IP addresses don’t only provide location privacy-- they protect attackers

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 architecture 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 network. Are 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 already.

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.