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:

       Additional HIP Web Page

Last Modified: 2008-08-21

Additional information is available at tools.ietf.org/wg/hip

Chair(s):

  • David Ward <dward@cisco.com>

  • Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>

    Internet Area Director(s):

  • Jari Arkko <jari.arkko@piuha.net>
  • Mark Townsley <townsley@cisco.com>

    Internet Area Advisor:

  • Mark Townsley <townsley@cisco.com>

    Mailing Lists:

    General Discussion: hipsec@ietf.org
    To Subscribe: http://www1.ietf.org/mailman/listinfo/hipsec
    Archive: http://www.ietf.org/mail-archive/web/hipsec/index.html

    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:

    HIP Architecture (RFC 4423)
    Host Identity Protocol (RFC 5201)

    There are several 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. |
    +-------------------------------------------------------+

    At this point, the missing elements for running such wide-scale
    experiments are a NAT traversal solution, a description on the
    interactions between legacy (i.e., HIP unaware) applications and HIP,
    and a native API for HIP. Additionally, the working group will
    specify, also in Experimental RFCs, how to build HIP-based
    overlays. HIP-based overlays have received a lot of attention in
    different fora and are seen as a key area for HIP experimentation
    where the benefits HIP brings may be most relevant.

    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 at large.

    In parallel to this working group, there is an IRTF Research Group
    with a broader scope that includes 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:

    o Specify how legacy (i.e., HIP unaware) applications can be made to
    work with HIP.

    o Specify a solution for HIP to traverse legacy (i.e., HIP unaware)
    NATs. This solution will be based on existing NAT traversal mechanisms
    such as ICE (Interactive Connectivity Establishment).

    o Specify a native HIP socket API.

    o Specify a framework to build HIP-based overlays. This framework will
    describe how HIP can perform some of the tasks needed to build an
    overlay and how technologies developed somewhere else (e.g., a peer
    protocol developed in the P2PSIP WG) can complement HIP by performing
    the tasks HIP was not designed to perform.

    o Specify how to generate ORCHIDs from other node identifiers
    including both cryptographic ones (leading to cryptographic
    delegation) and non-cryptographic ones (e.g., identifiers defined by a
    peer protocol).

    o Specify how to carry certificates in the base exchange. This was
    removed from the base HIP spec so that the mechanism is specified in a
    stand-alone spec.

    o Specify how to carry upper-layer data over specified HIP
    packets. These include some of the existing HIP packets and possibly
    new HIP packets (e.g., a HIP packet that occurs outside a HIP base
    exchange).

    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.
    Done  WGLC on the HIP architecture specification
    Done  Submit the HIP architecture specification to the IESG
    Done  WG LC on the base protocol specification
    Done  WG LC on the ESP usage specification
    Done  WGLC the HIP registration extensions specification
    Done  WGLC the HIP DNS resource record(s) specification
    Done  WG LC on the basic HIP rendezvous mechanism specification.
    Done  Submit the ESP usage specification to the IESG for Experimental
    Done  Submit the base protocol specification to the IESG for Experimental
    Done  WG LC on the HIP basic mobility and multi-homing specification.
    Done  Submit the HIP registration extensions specification for Experimental
    Done  Submit the HIP DNS resource record(s) specification to the IESG for Experimental.
    Done  Submit the HIP basic mobility and multihoming specification to the IESG for Experimental.
    Done  Submit the basic HIP rendezvous mechanism specification to the IESG for Experimental.
    Done  WGLC Legacy Application Interworking specification
    Done  Submit the Legacy Application Interworking specification to the IESG
    Dec 2008  WGLC Legacy NAT traversal specification
    Feb 2009  WGLC Native API specification
    Feb 2009  Submit the Legacy NAT traversal specification to the IESG
    Apr 2009  Submit Native API specification to the IESG
    Apr 2009  WGLC Framework for HIP overlays specification
    Apr 2009  WGLC ORCHID generation specification
    Apr 2009  WGLC Certs in HIP base exchange specification
    Apr 2009  WGLC Upper-layer data transport in HIP
    Jul 2009  Recharter or close the WG
    Jul 2009  Submit Framework for HIP overlays specification to the IESG
    Jul 2009  Submit ORCHID generation specification to the IESG
    Jul 2009  Submit Certs in HIP base exchange specification to the IESG
    Jul 2009  Submit Upper-layer data transport in HIP to the IESG

    Internet-Drafts:

    Basic HIP Extensions for Traversal of Network Address Translators (63402 bytes)
    Basic Socket Interface Extensions for Host Identity Protocol (HIP) (42500 bytes)

    Request For Comments:

    Host Identity Protocol (HIP) Architecture (RFC 4423) (60977 bytes)
    Host Identity Protocol (RFC 5201) (240492 bytes)
    Host Identity Protocol (HIP) Domain Name System (DNS) Extensions (RFC 5205) (34799 bytes)
    Host Identity Protocol (HIP) Registration Extension (RFC 5203) (26620 bytes)
    Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) (RFC 5202) (68195 bytes)
    Host Identity Protocol (HIP) Rendezvous Extension (RFC 5204) (30233 bytes)
    End-Host Mobility and Multihoming with the Host Identity Protocol (RFC 5206) (99430 bytes)
    Using the Host Identity Protocol with Legacy Applications (RFC 5338) (34882 bytes)
    IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.

    Return to working group directory.

    Return to IETF home page.