2.3.7 Host Identity Protocol (hip)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional HIP Web Page

Last Modified: 2005-01-17


David Ward <dward@cisco.com>
Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>

Internet Area Director(s):

Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Margaret Wasserman <margaret@thingmagic.com>

Mailing Lists:

General Discussion: hipsec@honor.trusecure.com
To Subscribe: hipsec-request@honor.trusecure.com
In Body: With a subject line: subscribe
Archive: http://honor.trusecure.com/pipermail/hipsec/

Description of Working Group:

The Host Identity Protocol (HIP) provides a method of
separating the end-point identifier and locator roles of
IP addresses. It introduces a new Host Identity (HI)
name space, based on public keys. The public keys are
typically, but not necessarily, self generated.

The specifications for the architecture and protocol
details for these mechanisms consist of:

        draft-moskowitz-hip-arch-05.txt (at RFC editor) and
        draft-moskowitz-hip-08.txt (soon -09.txt)

There are five publicly known, interoperating
implementations, some of which are open source.

Currently, the HIP base protocol works well with any pair
of co-operating end-hosts. However, to be more useful
and more widely deployable, HIP needs some support from
the existing infrastructure, including the DNS, and a new
piece of infrastructure, called the HIP rendezvous

| The purpose of this Working Group is to define the    |
| minimal infrastructure elements that are needed for  |
| HIP experimentation on a wide scale.                  |

In particular, the objective of this working group is to
complete the base protocol specification, define one or
more DNS resource records for storing HIP related data,
to complete the existing work on basic mobility and
multi-homing, and produce Experimental RFCs for these.

Note that even though the specifications are chartered
for Experimental, it is understood that their quality and
security properties should match the standards track
requirements. The main purpose for producing
Experimental documents instead of standards track ones
are the unknown effects that the mechanisms may have on
applications and on the Internet in the large.

It is expected that there will be a roughly parallel,
though perhaps considerably broader, IRTF Research Group
that will include efforts both on developing the more
forward looking aspects of the HIP architecture and on
exploring the effects that HIP may have on the applications
and the Internet.

The following are charter items for the working group:

1) Complete the HIP base protocol specification.
  Starting point: draft-moskowitz-hip-08.txt (or newer)

2) Complete the basic mobility and multi-homing support for HIP.
  Starting point: draft-nikander-hip-mm-01.txt (or newer)

While this work partially overlaps the work in Mobile
IP and Multi6 Working Groups, it is very different in
the sense that is based on the Experimental HIP
specification, and cannot function without it.

3) Define one or more new DNS Resource Records for
  storing HIP related data, such as Host Identifiers and
  Host Identity Tags (HITs). This task explicitly
  excludes the task of defining reverse DNS entries
  based on HITs.

4) Define a basic HIP rendezvous mechanism.

  A basic HIP rendezvous server allows mobile and
  non-mobile HIP hosts to register their current IP
  addresses at the server. Other hosts can then send
  the initial I1 packets to the rendezvous server, which
  forwards the packets to the HIP host's current address.

  This task explicitly excludes solving more general
  problems, such as the referral problem. Also excluded
  is the problem of finding the right rendezvous server.
  It is expected that the DNS records will be used for that.

  The Working Group bases all the work on the HIP achitecture
  specification (as defined above).

5) Complete the HIP Architecture specification
  Starting point: draft-moskowitz-hip-arch-06.txt

Goals and Milestones:

Done  First version of the HIP basic mobility and multi-homing mechanism specification.
Done  First version of the HIP DNS resource record(s) specification.
Done  First version of the HIP basic rendezvous mechanism specification.
Dec 04  WGLC on the HIP architecture specification
Jan 05  Submit the HIP architecture specification to the IESG
Mar 05  WG LC on the base protocol specification
Mar 05  WG LC on the base protocol specification
Apr 05  Complete the base protocol specification and submit it to the IESG for Experimental
Done  WG LC on the HIP basic mobility and multi-homing specification.
Apr 05  WG LC on the basic HIP rendezvous mechanism specification.
May 05  Submit the HIP DNS resource record(s) specification to the IESG for Experimental.
May 05  Submit the HIP basic mobility and multihoming specification to the IESG for Experimental.
May 05  Submit the basic HIP rendezvous mechanism specification to the IESG for Experimental.
May 05  Recharter or close the WG.


  • draft-ietf-hip-base-02.txt
  • draft-ietf-hip-arch-02.txt
  • draft-ietf-hip-mm-01.txt
  • draft-ietf-hip-dns-01.txt
  • draft-ietf-hip-rvs-01.txt

    No Request For Comments

    Current Meeting Report

    Minutes HIP WG at IETF 62

    Minutes edited by Gonzalo Camarillo
    Based on notes by Miika Komu and Christian Vogt
    Meeting chaired by Gonzalo Camarillo and David Ward

    WEDNESDAY, March 9, 2005, 1300-1500

    Topic: Agenda Bash
    by chairs

    There were no comments on the agenda.

    Architecture draft: there was consensus in the room to address the IESG comments and publish this document as a snapshot of our understanding of the HIP architecture in 2003. In the future, nothing prevents us to review this work, but at this point we only want to publish this snapshot and focus on the rest of our charter items.

    Topic: Base spec
    Discussions led by: Pekka Nikander
    Relevant documents: draft-ietf-hip-base-02.txt

    Publishing these two drafts is the highest priority of the WG.

    Pekka will discuss how to use multiple hash functions on the list. The hash function being used may be identified using the top most bits of the HITs.

    There were discussions on how to support devices that will not use IPsec but may want to use HIP mobility (e.g., VoIP devices using SRTP). The feedback received from the IESG so far is that we need a MUST implement in the spec for interoperability reasons. The chairs need to ask the security ADs what they think about allowing HIP to use IPsec with null encryption. Further discussions needed on the list.

    Consensus in the room to take the current ESP draft as a WG item.

    Topic: Generalising HIP
    Discussion led by: Thomas Henderson
    Relevant document: draft-henderson-hip-generalize-00.txt

    The focus of the WG is on stabilizing the spec. Generalising is good, but for the future.

    Pekka Nikander's proposal: study what it takes to introduce proposal number one (other identifiers) and to allow an easy introduction of new packets at a later point so that people can reuse HIP. If it can be done and still WGLC the document before Paris, we do it. Thomas accepted the proposal.

    Topic: Using HIP with Legacy Applications
    Discussions led by: Thomas Henderson
    Relevant document: draft-henderson-hip-applications-00.txt

    Until we finish some of our current charter items, the WG will not take any new WG items. Thomas will take this work to the research group.

    Topic: Credit-Based Authorization for HIP Mobility with Concurrent
    IP-Address Tests
    Discussions led by: Christian Vogt
    Relevant document: draft-vogt-hip-credit-based-authorization-00.txt

    Until we finish some of our current charter items, the WG will not take any new WG items. The WG will study whether it makes sense to incorporate some of these ideas to the mobility draft.

    Topic: End-Host Mobility and Multi-Homing
    Discussions led by: Thomas Henderson
    Relevant document: draft-ietf-hip-mm-01.txt

    Thomas has a volunteer to work on the security section of the draft. We need more implementation experience with this spec.

    Topic: HIP Registration Extensions
    Discussions led by: Julien Laganier
    Relevant document: draft-koponen-hip-registration-00.txt

    Only a few people had read the document. More people should read it.

    Topic: HIP Rendezvous Servers Extensions
    Discussions led by: Julien Laganier
    Relevant document: draft-ietf-hip-rvs-01.txt

    Hannes will send comments on this draft to the list and discuss it in the research group meeting.

    Topic: HIP DNS Extensions
    Discussions led by: Julien Laganier
    Relevant document: draft-ietf-hip-dns-01.txt

    Further discussions on the list needed on the issue of sending an I1 to a HIT and receiving a different one in a R1. Doing this may not be a good idea.

    End of the meeting.

    The following is a detailed log of the conversations that took place during the meeting.

    Pekka Nikander: base spec

    Pekka: What would we do with SHA? The weakness in the SHA-1 is that is more not so secure. There is no hurry with this. Alternative solutions: use SHA-256 or HMAC to create a HIT. Probably 90 bits would enough, so 128 is more than enough. Or use multiple hash functions: my proposal is that we encode the hashing function to the topmost bits in a HIT. Now if we do this, we can code this so that the HIT prefix prevents collisions with IPv6 addresses. Feedback? Suggest defining the exact number of bits on the mailing list. I see some nods, so I think it is ok.

    Pekka: Update the implementations. DL May.

    Pekka Nikander: hip esp draft

    Pekka: ESP still mandatory. Discuss on the mailing list.

    Pekka: open issues. Is it useful to model this this way. Some people said that it is not currently written good enough. Second question, is this a must implement?

    Gonzalo: MUST implement (for IESG)

    Thomas: I have been arguing about the must-use ESP. Some people use light weight devices. Make ESP-NULL mandatory?

    Gonzalo: definitely need a common ground. May have two implementations that do not interoperate. IESG feedback was this.

    Pekka: the ESP-NULL is only for testing. We can say that we are not doing IPsec to avoid conflicts with IPsec specs. We have to discuss with the security ADs.

    Jari Arkko: it is probably a problem that we are not using standard ESP.

    Pekka: I don't have a opinion on the ESP-NULL.

    Thomas: HER and HES have a one-to-one mapping, so it is a unnecessary abstraction?

    Arkko: don't use the conceptual layers if don't need them.

    Pekka: the next steps. Do people feel that it is well baked? Can we adapt this as a working group item?

    Gonzalo: we wanted to go through the formal procedure. Ask the working group. Please HUM now if you want this as a working group item. Nobody opposed.

    Thomas Henderson: Generalizing HIP

    Gonzalo: Opinions?

    Pekka: not directly answering to this. Let's take a step back. Two related issues in the draft. First, we can make some changes that make the protocol multipurpose. Second, we can define packet formats in a separate draft. I don't understand whether Tom wants just the other or both of these. Keep the base spec as it is, and not make HIP a profile of a carrier protocol. Doing another split requires rechartering. Encourage completing the base spec, so that other people can reference to it. Keep HIP as a separate protocol and do not generalize it.

    Hannes: some of things you show on the slides require big modifications. Don't think this a good idea. There more categories to be worried about (resolving issues etc).

    Thomas: one motivation is to find a good transition mechanism for HIP. Other people are interested in HIP, but some features are not required from them like for example non-routable identifiers.

    Tim Sheppard: what do you hope, do you think that we can do this before Paris?

    Thomas: Yes. We don't change the current design but rather the wordings in the draft. It does not change how the protocol is implemented, so implementing can be done easily.

    Tim: can the implementors make this in time?

    Gonzalo: (missed this comment)

    Tim: lot of value in getting base spec done.

    Gonzalo: Let's keep in the Paris schedule.

    Kempf: the problem with profiles is interoperability. If you don't have synchronized implementations, it is a problem. I was getting a feeling the last time that people want a stable spec.

    Nikander: I have a concrete proposals. Do #1: the write-up. There is room for non-HIP specifiers. Currently the HIP length is fixed, but should be some alternative fixed sizes. What comes to the other proposals, we can renumber the packets. This way, other people can reuse HIP protocol. Move everything else to the RG, edit and make a separate document.

    Tom: Pekka's proposal was good, so I'll do this.

    Thomas Henderson: API draft

    Pekka Savola: is this API something that is really required in the base spec? It delays the finalizing of the base spec.

    Thomas: it will not delay base space, this is a separate draft.

    Gonzalo: the main point is to get the base space completed.

    Keith: this will break applications. Does not work.... not much use if it is transparent.

    Pekka: the purpose of this wg is to experiment. I don't know if it works but it has some value. The purpose is to get an API that works without recompilation.

    Keith: this is not engineering. It does not work. We are recommending and building systems that actually work.

    Tim: disagree. Experimentation is essential too.

    Ward: I must remind the charter has not changed during the meeting.

    Tom: I wanted a home for this draft. Maybe RG is a better place. I was not going to ask whether this comes a WG action item. I am fine in doing this in RG. I'll raise the issue on the mailing list.

    Vogt: Credit Base Authorization

    Vogt: interest to wg after the base spec is published? Add to mm draft?

    Julien: another simpler approach with only one RTT. Do the reachability check in parallel?

    Vogt: earlier discussion about this. Reregistration attack...

    Pekka: the proposal sounds good. But consider keeping the WG charter focused.

    Thomas: hip mm

    Thomas: discuss on the mailing list. Need some implementation experience. Security section needs work and a person has volunteered. Finished around November.

    Julien: registration extensions

    Julien: adopt this as a WG item?

    Gonzalo: who has read this? (only few hands rise). Suggest that more people read this before making the decision.

    Julien: HIP rendezvous extensions

    Julien: here is a basic protocol scenario.

    Pekka: I suggest telling the rendezvous type already in the registration parameter.

    Julien: Tunneling encapsulation feedback? Is it really necessary?

    Hannes: What do you want to tunnel?

    Julien: You may have an IPsec SA and send HIP messages in the tunnel.

    Hannes: Will send some comments on the list.

    Pekka: Running out time. I get the feeling that the previous (not this) is not well baked yet. Take the issue up on the RG meeting.

    Hannes: Align rendezvous and NAT signalling.

    Julien: DNS extensions

    Pekka: Just a clarifying question. DNS RR in I1 and also in R1.

    Julien: You say that it is bad to initiate to one HIT with I1 and receive a different in R1?

    Tim: The other end drops it.

    Julien: We have to discuss it further on the mailing list.


    Status and Agenda Bash
    Base spec
    ESP transform in HIP
    Generalizing the HIP base protocol
    Using HIP with Legacy Applications
    End-Host Mobility and Multi-Homing
    Credit-Based Authorization for HIP Mobility with Concurrent IP-Address Tests
    HIP Registration Extensions
    HIP Rendezvous Servers Extensions
    HIP DNS Extensions