2.9.2 Host Identity Protocol (HIP)



Chair(s):
The HIP RG co-chairs are
Pekka Nikander <pekka.nikander@nomadiclab.com>
Tom Henderson <thomas.r.henderson@boeing.com>.

Mailing List
The RG's mailing list is hipsec-rg@honor.trusecure.com. You must be a list member to send mail to the list. To subscribe or access the archives, visit http://honor.trusecure.com/mailman/listinfo/hipsec-rg.
Background

The current Internet architecture is based on using IP addresses in two distinctive roles.

Due to increasing mobility and multi-homing requirements, together with other issues like IPv4 address scarcity, this dual role of IP addresses is becoming problematic. The generic phenomenon was previously studied by the IRTF NameSpace Research Group (NSRG), and the questions studied there are outside of the scope of this group.

The Host Identity Protocol (HIP) has been developed alongside the IETF and the IRTF for a few years. Its development has been partially based on the discussions that took place within the NSRG. Basically, HIP is a concrete proposal for adding a new name space to the TCP/IP stack. The new name space consist of Host Identifiers, which are cryptographic public keys. The HIP architecture adds a new layer between the IP layer and the transport layer, thereby decoupling the layers from each other, and splitting the dual roles of IP addresses. When HIP is used, IP addresses function as pure locators. Instead of IP addresses, the applications use Host Identifiers to name peer hosts. More concise representations of Host Identifiers -- 128-bit Host Identity Tags (HITs) and 32-bit Local Scope Identifiers (LSIs) -- have been defined to represent host identities in IPv6- or IPv4-sized address structures, respectively, allowing most, but not all, legacy applications to work unmodified on top of HIP.

The IETF Host Identity Protocol working group has been chartered to complete the short term engineering work on HIP, including the base protocol specification, basic mobility & multi-homing, basic rendezvous service, and the basic DNS records needed to store HIP related information.

Charter

The primary goal of the HIP Research Group is to study the proposed Host Identity Protocol and architecture, including potential effects on the Internet. When indicated by its studies, the HIP RG can suggest extensions and modifications to the protocol and architecture. It is also in scope for the RG to study, in a wider sense, the consequences and effects that wide-scale adoption of any type of separation of the identifier and locator roles of IP addresses is likely to have. With regard to this latter, the research group is tasked with producing an experiment report providing input to the IETF on mechanisms for separating the identifier and locator nature of IP addresses. That is, given the assumption that some kind of identifier and locator separation should be adopted, the research group will provide an analysis on baseline architectures and mechanisms upon which standardizing such a separation could be based.

The question of whether the basic identifier/locator split assumption is valid falls beyond the scope of this research group. The group's work is based on the assumption that such a separation is needed in one form or another, and the group must not spend excessive time discussing whether such a separation of roles is needed or not. On the other hand, it is fine to discuss the technical drawbacks that such a separation might have and ways to ameliorate these.

Within the primary guildelines discussed above, the range of topics included within the scope of the research group spans:

As discussed above, the research group is tasked with producing an "experiment report" documenting the collective experiences and lessons learned from other studies, related experimentation, and designs completed by the research group. This might include the following:

An initial version of the experiment report is targeted for the second quarter of 2005, and the final version for the second quarter of 2006.

Relationship to the IETF working groups

The RG works closely with the Host Identity Protocol (HIP) working group. The RG work is in addition related to the following working groups, in rough order of relevance:

Membership

The RG operates in an open fashion (meetings & mailing list), though may occasionally form closed subgroups to facilitate the development of specific work items.

Meetings

The intent is for the RG to meet in co-location with the triannual IETF meetings.

Current Meeting Report

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.

Slides

Agenda
Native HIP API
HIP and NAT
Design Aspects of HIP Rendezvous Mechanisms
A Layered Naming Architecture
Internet Indirection Infrastructure
Host Identity Indirection Infrastructure - Hi3