InfraHIP
Miika Komu 

Host Identity Protocol (HIP) provides end-host mobility and end-to-end
security to the Internet architecture. HIP accomplishes this task
using a single, integrated protocol layer that operates between the
transport and network layers. The new HIP layer introduces an
identity, called Host Identity (HIs), for each end-host. The HIs are
used at the application and transport layers instead of IP
addresses. As a consequence, the upper layers of the networking stack
are isolated from location changes of the host, which allows the host
to take care of the mobility transparently on behalf of the upper
layers. This may also boost IPv6 deployment because applications
become more isolated from the network layer details.

The separation of identity and location is commonly referred as the
identity/locator split. The split creates a new namespace that
disambiguites the "who" from "where". The identities in the new
namespace are based on public keys and are created by the end-hosts by
themselves which makes identity theft computationally very
difficult. The identities can be used for public-key based
authentication in HIP enabled firewalls and in access control lists at
the application layer.

InfraHIP project at the Helsinki Institute of Information Technology
(HIIT) participates in the standardization, research and development
of HIP. The standardization forum for HIP is the Internet Engineering
Task Force (IETF). The current challenge presented by the IETF and
research community is the deployment of HIP. Thus, InfraHIP project
focuses on test deployment of HIP to find the "killer application" and
to report on the effects of the identity/locator split in
practice. The goal of the experimentation is to understand the effect
of the split to the networking software, end-hosts and middleboxes in
practice.

As an example of a potential problem of the identity/locator split,
let's consider that a host or application loses track of the locator
corresponding to an identity. As the identities in HIP are based on
non-routable public keys, it may not be possible to route packets to
the host anymore. Looking up flat identifiers from DNS is not possible
because DNS is based on hierarchical identifiers, such IP addresses
and Fully Qualified Domain Names (FQDNs). HIP community has proposed
overlays as mechanism as a solution to this problem. Overlays are not
limited to hierarchical information and can be used for looking up or
even routing packets based on flat identifiers. Although this seems to
be an obvious solution to the problem at least in theory, it has not
been investigated yet in practical HIP deployments yet.

To facilitate HIP deployment, InfraHIP project has developed a HIP
implementation, called Host Identity Protocol for Linux (HIPL). It
supports the core protocol and several extensions.  HIP uses a new
optimized IPsec mode, called Bound-End-to-End-Mode (BEET), to protect
application traffic. The project has implemented and contributed BEET
code to the standard Linux kernel. The symmetric keys for BEET are
derived using the base exchange which is a Diffie-Hellman key
exchange.  Opportunistic base exchange can be used in ad-hoc
environments without identifier look-up support from the
infrastructure. It is used to contact a host without the knowledge of
the peer identifier, but on the expense of weaker security
properties. The mobility and multihoming extensions allow a host to
change locators dynamically without breaking transport layer
connections. Rendezvous server extensions are used to provide a stable
contact point for rapidly moving hosts. Network Address Translation
(NAT) extensions take advantage of identity/locator split by providing
addressing and data transfer for hosts that are located in private
addressing realms. Privacy extensions (BLIND) hide the public key
information from outsiders.  HIP enabled firewall authenticates
end-hosts and uses public-key or hash based access control lists to
enforce access to hosts or networks.

To summarize, the next challenge for the identity/locator split of HIP
is to use it in real life deployments. The research question that we
try to answer is that what is the effect of the identity/locator split
in practice for existing networking software and middleboxes. We have
implemented various HIP extensions to meet the potential obstacles in
deploying HIP but they have not been experimented yet in practice. We
invite also you to participate the HIP experiment to try the next
generation Internet architecture!