WG Review: Host Identity Protocol (hip)

[The IESG <[e-mail]>]

A new IETF working group has been proposed in the Internet Area.  The IESG has not made 
any determination as yet.  The following description was submitted, and is provided 
for informational purposes only.  Please send your comments to the IESG mailing list 
([e-mail]) by February 18th.

     Host Identity Protocol (hip)
     ----------------------------

     Current Status: Proposed Working Group

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