Host Identity Protocol (hip) Internet Drafts
| Basic HIP Extensions for Traversal of Network Address Translators and Firewalls | |||||||||||||||||
|
The Host Identity Protocol (HIP) provides a new namespace that can be used for uniquely identifying hosts. Existing HIP experimental specifications do not specify protocol operations across Network Address Translators (NATs). This document specifies NAT traversal extensions for HIP. The HIP shim layer is located between the network and transport layer, the extensions can also provide a more general-purpose NAT traversal support for higher-layer networking applications. The extensions are based on the use of the The Interactive Connectivity Establishment (ICE) methodology to discover a working path between two end-hosts. Using the specified extensions, two HIP-capable hosts are able to communicate with each other even when both nodes are behind NATs or firewalls. | ||||||||||||||||
| Basic Socket Interface Extensions for Host Identity Protocol (HIP) | |||||||||||||||||
|
This document defines extensions to the current sockets API for Host Identity Protocol (HIP). The extensions focus on the use of public- key based identifiers discovered via DNS resolution, but define also interfaces for manual bindings between HITs and locators. With the extensions, the application can also support more relaxed security models where the communication can be non-HIP based, according to local policies. The extensions in document are experimental and provide basic tools for futher experimentation with policies. | ||||||||||||||||
| Using the Host Identity Protocol with Legacy Applications | |||||||||||||||||
|
This document is an informative overview of how legacy applications can be made to work with the Host Identity Protocol (HIP). HIP proposes to add a cryptographic name space for network stack names. From an application viewpoint, HIP-enabled systems support a new address family of host identifiers, but it may be a long time until such HIP-aware applications are widely deployed even if host systems are upgraded. This informational document discusses implementation and Application Programming Interface (API) issues relating to using HIP in situations in which the system is HIP-aware but the applications are not, and is intended to aid implementors and early adopters in thinking about and locally solving systems issues regarding the incremental deployment of HIP. | ||||||||||||||||
 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
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: 2007-09-26
Additional information is available at tools.ietf.org/wg/hip
Chair(s):
Internet Area Director(s):
Internet Area Advisor:
Mailing Lists:
General Discussion: hipsec@ietf.orgTo 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 ofseparating 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).
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. | |
| 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. | |
| Jan 2007 | WGLC Legacy NAT traversal specification | |
| Jan 2007 | WGLC Legacy Application Interworking specification | |
| Jan 2007 | WGLC Native API specification | |
| Mar 2007 | Submit the Legacy NAT traversal specification to the IESG | |
| Mar 2007 | Submit the Legacy Application Interworking specification to the IESG | |
| Mar 2007 | Submit Native API specification to the IESG | |
| Apr 2007 | Recharter or close the WG |
Internet-Drafts:
Basic HIP Extensions for Traversal of Network Address Translators and Firewalls (58470 bytes)Basic Socket Interface Extensions for Host Identity Protocol (HIP) (42383 bytes)
Using the Host Identity Protocol with Legacy Applications (42857 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)
IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.
Return to working group directory. 
