2.3.5 Host Identity Protocol (hip)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       http://hip.piuha.net/ -- Additional HIP Web Page
NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-05-18

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

+-------------------------------------------------------+ | 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).

Goals and Milestones:
Mar 04  WG LC on the base protocol specification
Mar 04  First version of the HIP basic mobility and multi-homing mechanism specification.
Mar 04  First version of the HIP DNS resource record(s) specification.
Apr 04  Complete the base protocol specification and submit it to the IESG for Experimental
Apr 04  First version of the HIP basic rendezvous mechanism specification.
Aug 04  WG LC on the HIP DNS resource record(s) specification.
Sep 04  Submit the HIP DNS resource record(s) specification to the IESG for Experimental.
Nov 04  WG LC on the HIP basic mobility and multi-homing specification.
Nov 04  WG LC on the basic HIP rendezvous mechanism specification.
Dec 04  Submit the HIP basic mobility and multihoming specification to the IESG for Experimental.
Dec 04  Submit the basic HIP rendezvous mechanism specification to the IESG for Experimental.
Jan 05  Recharter or close the WG.
  • - draft-ietf-hip-base-00.txt
  • No Request For Comments

    Current Meeting Report

    60th IETF HIP Minutes Minutes, HIP WG, 60th IETF

    Notes by Thomas Henderson, Gabriel Montenegro, and Andrew McGregor.
    Minutes edited by Gonzalo Camarillo.
    Meeting chaired by Gonzalo Camarillo and David Ward.

    HIP Meeting, Thursday, August 5, 2004, 0900-1130

    Topic: Status
    Slides presented: pres-ietf60-hip-chairs.ppt
    Discussions led by: Chairs

    Issue: We are behind schedule. We need to update our milestones.

    Topic: Base Spec
    Slides presented: pres-ietf60-hip-base-spec-jokela.ppt
    Relevant document: draft-ietf-hip-base-00.txt
    Discussions led by:  Petri Jokela

    Issue: most of the open issues closed. Feedback is requested on the few minor ones that are still open in the issue tracker at http://hip4inter.net. In particular, the issue about one hip host losing state while the other stays up (close-ack message), the LSI space allocation issue, and the notification data field issue.

    Information: interop text among three implementations (Ericsson,Boeing, and HUT) carried out succesfully during the week of the IETF.

    Topic: Making HIP Multi6 Friendly
    Slides presented: pres-ietf60-hip-multi6-henderson.ppt
    Relevant document: draft-nikander-multi6-hip-01.txt
    Discussions led by:  Thomas Henderson

    Information: HIP problems from a multi6 perspective: non-standard (experimental) approach, absence of supporting infrastructure (dns, identifier lookup), HIP handshake too heavywheight, IPsec mandatory too heavy, HIT's as app level id's may break referrals, privacy concerns with non-ephemeral identifiers.
    Issue: HIP may be adopted as a multi 6 solution or be cherry-picked. So, should any changes be made to HIP to address multi6?
    Conclusion: We will not make important changes to make HIP multi6 friendly. We will finish the the charter as planned (although we will finish it a little later than initially planned).

    Topic: Backwards Compatible API
    Slides presented: pres-ietf60-hip-legacy-api-komu.pdf
    Discussions led by:  Miika Komu

    Issue: Prons and cons of using a HIP native API versus using a transparent API (i.e., the resolver spoofs the IP address returned to applicationand returns a HIT instead).
    Conclusion: needs list discussion.
    Observation: native APIs are discussed in the research group.

    Topic: Mobility and Multihoming
    Slides presented: pres-ietf60-hip-mm-henderson.ppt
    Relevant document: draft-nikander-hip-mm-02.txt
    Discussions led by:  Thomas Henderson

    Issue: should we adopt this draft as a WG item?
    Conclusion: strong consensus to adopt it.

    Topic: DNS Issues
    Slides presented: pres-ietf60-hip-dns-laganier.pdf
    Relevant document: draft-nikander-hip-dns-00.txt
    Discussions led by:  Julien Laganier

    Issue: need DNS experts to have a look at the draft.
    Conclusion: Rob Austein offers his help.

    Issue: should we adopt this draft as a WG item?
    Conclusion: strong consensus to adopt it.

    Topic: Rendezvous
    Slides presented: pres-ietf60-hip-rvs-laganier.pdf
    Relevant document: draft-eggert-hip-rvs-00.txt
    Discussions led by:  Julien Laganier

    Issue: should we adopt this draft as a WG item?
    Conclusion: strong consensus to adopt it.

    Action Items
    • Chairs to update the dates of the milestones.
    • Editor of draft-nikander-hip-mm-02.txt to release a new version as a WG item.
    • Editor of draft-nikander-hip-dns-00.txt to release a new version as a WG item.
    • Editor of draft-eggert-hip-rvs-00.txt to release a new version as a WG item.
    Detailed Discussions

    Topic: Base Spec

    No comments from the floor

    Topic: Making HIP Multi6 Friendly

    Gonzalo: Should we extend the work on the base spec by 6 months to tailor hip to multi6?
    Margaret: I have a dilemma. HIP is experimental. Have all the challenges been solved? How does this fit will multi6?
    Gonzalo: This is a chicken and egg problem. hip cannot mandate something which multi6 cannot use.
    Margaret: multi6 is working with different concerns (e.g., routing table expansion).  I am worried about tying these 2 together. We need more comments. What is the essential attribute of HIP. Is it to get IPSec working or for creating locator based agility?
    Eric fleischmann: When bob proposed hip everyone was intrigued. Since then there have been a bunch of incomplete clones in the IETF as hip standardization as been too slow. It is wrong to share the fate with another WG.
    Tim Sheperd: The value of hip is that it can solve a lot of problems. We should finish base spec as planned. People can write drafts in parallel to extend hip for other purposes. I believe we should not make changes unless they are exceedingly simple. We can cooperate with the multi6 design team on applying hip to multi6.
    Andrew: Issues may be complex to address. DH is main cause of heavy nature of HIP. It can be simplified. Lookups and referrals are harder to solve.
    jak: I like hip for the security properties. I would not compromise on those. It is better to have a lightweight subset for people who need it.
    Bob: Security features are essential. If multi6 wants a lightweight solution we can leverage the hip work and come up with a solution (like WIMP). It is not right to couple hip and multi6.
    Tom: Agrees with the commentors. Keep hip and multi6 decoupled.

    jak: issues with HITs and ip addresses getting out of sync.
    Tom: Yes. There are issues. But I do not know how to get around them
    jak: Can use CGAs to prevent accidental miscommunications.
    Erik: The IP addresses are from the DNS. So there should be no issues. That is where you want to be reachable. Leave the address and you cannot be reached.

    Topic: Backwards Compatible API

    Erik: Does referral based API use oppurtunistic mode?
    Miika: That is natural but is not required.
    Michael Smith: Want to know about policy rules for the referral API?
    Miika: rule that matches an ip address triggers hip
    Michael: Can HITs and IP addresses collide? In oppurtunistic hip we do not know the identity of the responder.
    Tom: If you use DHCP we can have cases where we do not have a HIT/IP addr binding?
    Pekka (on the phone): Nothing related to API that changes rules used for IPsec.  Difference in API is what the application sees.  Then all firewalling rules and IPsec rules are based on HIT.

    Topic: Mobility and Multihoming

    Tom: Do we really need multiple SAs for multiple addresses? Should we work on tuning the replay protection window from RTT estimates?
    Erik: Worried about TCP issues with reordering when multiple addresses are used simultaneously.
    Tom: Cites SCTP.
    Erik: I want a round robin scheme.
    Tom: We can use multiple SAs, but we DONT HAVE to.
    Hillary: How does readdressing work when both the peers move simultaneously?
    Tom: We have not checked this in detail. This will be addressed in the policy considerations section (e.g., using a rendezvous server).
    Hillary: We need to make this work as a failover mode.

    Topic: DNS Issues

    Julien: Need more info from people who know DNS well
    Tom: Is it possible that there are parallel FQDN->IP and FQDN->HI mappings?
    Andrew: Have a bunch of A records and the HIP RRs side by side. This requires least changes to DNS

    Topic: Rendezvous

    Pekka (thru Lars): Comment from pekka saying location privacy is a difficult issue and must be moved to HIPRG
    Gonzalo: I agree
    Erik: Is there anything preventing multiple RVSs?
    Julien: No. You can have many and the one with the highest preference in DNS is used
    Brajesh Kumar: Is RVS signle point of failure? No


    Making HIP multi6 friendly
    Backwards Compatible API
    HIP-mm update
    HIP Rendezvous Extensions
    HIP DNS Extensions