IRTF HIP Research Group T. Henderson
Internet-Draft The Boeing Company
Intended status: Informational A. Gurtov
Expires: February 6, 2011 HIIT
August 5, 2010
HIP Experiment Report
draft-irtf-hip-experiment-09
Abstract
This document is a report from the IRTF HIP research group
documenting the collective experiences and lessons learned from
studies, related experimentation, and designs completed by the
research group. The documents summarizes implications of adding HIP
to host protocol stacks, Internet infrastructure, and applications.
The perspective of a network operator, as well as a list of HIP
experiments, are presented as well.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 6, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Henderson & Gurtov Expires February 6, 2011 [Page 1]
Internet-Draft HIP Experiment Report August 2010
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. What is HIP? . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Organization . . . . . . . . . . . . . . . . . . . . . . . 5
2. Host Stack Implications . . . . . . . . . . . . . . . . . . . 6
2.1. Modifications to TCP/IP stack implementations . . . . . . 6
2.1.1. ESP implementation extensions . . . . . . . . . . . . 8
2.2. User-space implementations . . . . . . . . . . . . . . . . 9
2.3. Issues common to both implementation approaches . . . . . 9
2.3.1. User-space handling of HITs . . . . . . . . . . . . . 9
2.3.2. Resolving HITs to addresses . . . . . . . . . . . . . 10
2.3.3. IPsec management API extensions . . . . . . . . . . . 10
2.3.4. Transport protocol issues . . . . . . . . . . . . . . 11
2.3.5. Legacy NAT traversal . . . . . . . . . . . . . . . . . 12
2.3.6. Local management of host identity namespace . . . . . 12
2.3.7. Interactions with host firewalls . . . . . . . . . . . 13
2.4. IPv4 vs. IPv6 issues . . . . . . . . . . . . . . . . . . . 13
2.5. What have early adopters learned from experience? . . . . 14
3. Infrastructure Implications . . . . . . . . . . . . . . . . . 15
3.1. Impact on DNS . . . . . . . . . . . . . . . . . . . . . . 15
3.2. HIP aware middleboxes . . . . . . . . . . . . . . . . . . 15
3.3. HIT resolution infrastructure . . . . . . . . . . . . . . 15
3.4. Rendezvous servers . . . . . . . . . . . . . . . . . . . . 16
3.5. Hybrid DNS-DHT resolution . . . . . . . . . . . . . . . . 17
4. Application Implications . . . . . . . . . . . . . . . . . . . 18
4.1. Non-intrusive HIP insertion . . . . . . . . . . . . . . . 18
4.2. Using a native HIP API . . . . . . . . . . . . . . . . . . 18
4.3. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 18
5. Network Operator's Perspective . . . . . . . . . . . . . . . . 19
5.1. Management of the host identity namespace . . . . . . . . 19
5.2. Use of ESP encryption . . . . . . . . . . . . . . . . . . 19
5.3. Access control lists based on HITs . . . . . . . . . . . . 20
5.4. Firewall issues . . . . . . . . . . . . . . . . . . . . . 20
6. User Privacy Issues . . . . . . . . . . . . . . . . . . . . . 22
7. Experimental Basis of this Report . . . . . . . . . . . . . . 24
8. Related Work on ID/Locator Split . . . . . . . . . . . . . . . 26
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Henderson & Gurtov Expires February 6, 2011 [Page 2]
Internet-Draft HIP Experiment Report August 2010
1. Introduction
This document summarizes the work and experiences of the Host
Identity Protocol IRTF Research Group (HIP-RG) from the 2004-10
timeframe. The HIP-RG was chartered to explore the possible benefits
and consequences of deploying the Host Identity Protocol architecture
[RFC4423] in the Internet, and to explore extensions to HIP.
1.1. What is HIP?
The Host Identity Protocol architecture introduces a new name space,
the "host identity" name space, to the Internet architecture. The
express purpose of this new name space is to allow for the decoupling
of identifiers (host identities) and locators (IP addresses) at the
internetworking layer of the architecture. The contributors to HIP
have expected that HIP will enable alternative solutions for several
of the Internet's challenging technical problems, including
potentially host mobility, host multihoming, site multihoming, IPv6
transition, and network-level security. Although there have been
many architectural proposals to decouple identifiers and locators
over the past 20 years, HIP is one of the most actively developed
proposal in this area.
The Host Identity Protocol itself provides a rapid exchange of host
identities (public keys) between hosts and uses a Sigma-compliant
Diffie-Hellman key exchange to establish shared secrets between such
endpoints [RFC5201]. The protocol is designed to be resistant to
Denial-of-Service (DoS) and Man-in-the-middle (MitM) attacks, and
when used together with another suitable security protocol, such as
Encapsulated Security Payload (ESP) [RFC4303], it provides encryption
and/or authentication protection for upper layer protocols such as
TCP and UDP, while enabling continuity of communications across
network layer address changes.
A number of experimental RFC specifications were published by the
IETF's HIP Working Group, including the HIP base protocol [RFC5201],
ESP encapsulation [RFC5202], registration extensions [RFC5203], HIP
rendezvous servers [RFC5204], DNS resource records [RFC5205], and
mobility management [RFC5206]. Host identities are represented as
ORCHIDs [RFC4853] in Internet protocols. Additionally, the research
group published one RFC on requirements for traversing NATs and
firewalls [RFC5207] and the working group later published
specification text for legacy NAT traversal [RFC5770].
1.2. Scope
The research group has been tasked with producing an "experiment
report" documenting the collective experiences and lessons learned
Henderson & Gurtov Expires February 6, 2011 [Page 3]
Internet-Draft HIP Experiment Report August 2010
from other studies, related experimentation, and designs completed by
the research group. The question of whether the basic identifier/
locator split assumption is valid falls beyond the scope of this
research group. When indicated by its studies, the HIP RG can
suggest extensions and modifications to the protocol and
architecture. It has also been in scope for the RG to study, in a
wider sense, the consequences and effects that wide-scale adoption of
any type of separation of the identifier and locator roles of IP
addresses is likely to have.
During the timeframe of this report (2004-09), several research
projects and open source software projects were formed to study HIP.
These projects have been developing software enabling HIP to be used
according to the experimental RFCs as well as supporting extensions
not yet specified by RFCs.
The research group has been most active in two areas. First and
foremost, the research group has studied extensions to the HIP
protocol that went beyond the scope and charter of the IETF HIP
working group and the set of RFCs (RFC 5201-5206) initially published
in April 2008. Some of this work (NAT traversal, certificate formats
for HIP, legacy application support, and a native sockets API for
HIP) ultimately flowed into the IETF HIP working group upon its
recharter in 2008. Other extensions (e.g. HIP in the i3 overlay,
use of distributed hash tables for HIT-based lookups, mobile router
extensions, etc.) are either still being worked on in the research
group or have been abandoned. Most of the energy of the research
group during this time period has been in studying extensions of HIP
protocols or the application of HIP to new problem domains (such as
the Internet of Things). Second, the research group has discussed
the progress and outcome of the implementations and experiments
conducted so far, as well as discussing perspectives from different
participants (end users, operators, enterprises) on HIP deployment.
It is this latter category of work (and not the extensions to HIP) on
which this report is focused.
Finally, the research group was chartered to study, but did not
rigorously study (due to lack of inputs), the following questions:
o Objective comparisons of HIP with other mechanisms (although the
research group did hold some discussions concerning the relation
of HIP to other efforts such as the End-Middle-End (EME) research
group, the Routing research group (RRG) and shim6-based
protocols).
o Large scale deployments (thousands of hosts or greater).
Henderson & Gurtov Expires February 6, 2011 [Page 4]
Internet-Draft HIP Experiment Report August 2010
o Exploration of whether introducing an identity/locator mechanism
would be architecturally sound, deployed at wide scale.
o Changes to the HIP baseline architecture and protocol, or other
identity/locator separation architectures.
1.3. Organization
In this report, we summarize the collective experience of early
implementers and adopters of HIP, organized as follows:
o Section 2 describes the implications of supporting HIP on an end-
host.
o Section 3 covers a number of issues regarding the deployment of
and interaction with network infrastructure, including middlebox
traversal, name resolution, ACLs, and HIP infrastructure such as
rendezvous servers.
Whereas the two previous sections focus on the implementation and
deployment of the network plumbing to make HIP work, the next three
focus on the impact on users and operators of the network.
o Section 4 examines how the support of HIP in the host and network
infrastructure affects applications; whether and how HIP provides
benefits or drawbacks to HIP-enabled and legacy applications.
o Section 5 provides an operator's perspective on HIP deployment.
o Section 6 discusses user privacy issues.
In closing, in Section 7, we list the experimental activities and
research that have contributed to this report, and in Section 8 we
briefly summarize related work.
Henderson & Gurtov Expires February 6, 2011 [Page 5]
Internet-Draft HIP Experiment Report August 2010
2. Host Stack Implications
HIP is primarily an extension to the TCP/IP stack of Internet hosts,
and in this section we summarize some experiences that several
implementation groups have encountered in developing this extension.
Our discussion here draws on experience of implementers in adding HIP
to general-purpose computing platforms such as laptops, desktops,
servers, and PDAs. There are two primary ways to support HIP on such
an end host. The first is to make changes to the kernel
implementation to directly support the decoupling of identifier and
locator. Although this type of modification has data throughput
performance benefits, it is also the more challenging to deploy. The
second approach is to implement all HIP processing in user-space, and
configure the kernel to route packets through user-space for HIP
processing.
The following public HIP implementations are known and actively
maintained:
o HIP4BSD (http://www.hip4inter.net)-- FreeBSD kernel modifications
and user-space keying daemon;
o HIPL (http://hipl.hiit.fi)-- Linux kernel and user-space
implementation;
o OpenHIP (http://www.openhip.org)-- User-space keying daemon and
packet processing for Linux, Windows XP and Vista, and Apple OS X.
In the following, we first describe issues specific to the way in
which HIP is added to a stack, then we discuss general issues
surrounding both implementation approaches.
2.1. Modifications to TCP/IP stack implementations
In this section, we focus on the support of HIP assuming the
following:
o HIP is implemented by directly changing the TCP/IP stack
implementation
o Applications (using the sockets API) are unaware of HIP
A common way to partition the HIP implementation is to implement a
keying daemon in user-space that interacts with kernel-level support
for ESP, as shown in Figure 1. However, the HIPL project has
demonstrated that it is also possible to support HIP with a purely
kernel-level implementation.
Henderson & Gurtov Expires February 6, 2011 [Page 6]
Internet-Draft HIP Experiment Report August 2010
+--------------------+ +--------------------+
| |
| |
| +------------+ | | +------------+ |
| | Key | | HIP | | Key | |
| | Management | <-+-----------------------+-> | Management | |
| | Process | | | | Process | |
| +------------+ | | +------------+ |
| ^ | | ^ |
| | | | | |
| v | | v |
| +------------+ | | +------------+ |
| | IPsec- | | ESP | | IPsec- | |
| | extended | | | | extended | |
| | Stack | <-+-----------------------+-> | Stack | |
| | | | | | | |
| +------------+ | | +------------+ |
| | | |
| | | |
| Initiator | | Responder |
+--------------------+ +--------------------+
Figure 1: HIP deployment model
Figure 2 summarizes the main implementation impact of supporting HIP,
and is discussed further in subsequent sections. To enable HIP
natively in an implementation requires extensions to the key
management interface (here depicted as PF_KEY API [RFC2367]) with the
security association database (SAD) and security policy database
(SPD). It also requires changes to the ESP implementation itself to
support BEET-mode processing [I-D.nikander-esp-beet-mode], extensions
to the name resolution library, and (in the future) interactions with
transport protocols to respond correctly to mobility and multihoming
events [I-D.dawkins-trigtran-framework].
Henderson & Gurtov Expires February 6, 2011 [Page 7]
Internet-Draft HIP Experiment Report August 2010
|-----------------------|
-------- | ---------- ----------
| HIP |-- ----| App v6 | | App v4 |
-------- | | ---------- ----------
| | | | HIT | LSI
| ------------ | AF_INET6 | AF_INET
| | resolver | | |
| ------------ | sockets API | user-space
--|-------------------|-------------------------------
| sockets and | | kernel
| PF_KEY API --------- |
|-------------> |TCP/UDP|<-----------
| ---------
| |
---------- ---------
| SAD/SPD|<-----> | ESP | {HIT_s, HIT_d} <-> SPI
---------- --------- {HIT_s, HIT_d, SPI} <-> {IP_s, IP_d, SPI}
|
---------
| IP |
---------
Figure 2: Overview of typical implementation changes to support HIP
Legacy applications can continue to use the standard AF_INET6 (for
IPv6) and AF_INET (for IPv4) socket API. IPv6 applications bind
directly to a Host Identity Tag (HIT), which is a part of IPv6
address space reserved for ORCHIDs. IPv4 applications bind to a
Local Scope Identifier (LSI) that has significance only within a
host; the HIP layer translates between LSIs and HITs and IP addresses
that are still used underneath for HIP base exchange.
2.1.1. ESP implementation extensions
HIP uses a Bound End-to-End Tunnel (BEET) mode of ESP operation,
which mixes tunnel-mode semantics with transport-mode syntax. BEET
is not supported by all operating system distributions at present, so
kernel modifications might be needed to obtain true kernel support
using existing IPsec code. At the time of writing, the BEET mode has
been integrated to Linux and FreeBSD kernels.
The HIPL project has contributed an IPsec BEET patch for the Linux
kernel. The kernel-level support could potentially allow all
implementations of HIP to run in the userspace and use a common
interface towards the kernel.
One inconvenience experienced in current Linux implementations (due
to the native IPsec implementation, not HIP specifically) is a loss
Henderson & Gurtov Expires February 6, 2011 [Page 8]
Internet-Draft HIP Experiment Report August 2010
of the first data packet that triggers the HIP association
establishment. Instead, this packet should be cached and transmitted
after the association is established.
2.2. User-space implementations
HIP can be implemented entirely in user-space, an approach that is
essential for supporting HIP on hosts for which operating system
modifications are not possible. Even on modifiable operating
systems, there is often a significant deployment advantage in
deploying HIP only as a user-space implementation. All three open-
source implementations provide user-space implementations including
packaging (RPMs, DEBs, self-extracting installers) typical of
application deployment on the target systems.
When HIP is deployed in user-space, some technique is necessary to
identify packets that require HIP processing and divert them to user-
space for such processing, and to re-inject them into the stack for
further transport protocol processing. A commonly used technique is
to deploy a virtual device in the kernel such as a TAP device,
although operating systems may provide other means for diverting
packets to user-space. Routing or packet filtering rules must be
applied to divert the right packets to these devices.
As an example, the user-space implementation may install a route that
directs all packets with destination addresses corresponding to HITs
or LSIs to such a virtual device. In the user-space daemon, the ESP
header and possibly UDP header is applied, an outer IP address
replaces the HIT, and the packet is resent to the kernel. In the
receive direction, a socket associated to ESP or a UDP port number
may be used to receive ESP-protected packets. HIP signaling packets
themselves may be sent and received by a raw socket bound to the HIP
protocol number or UDP port when UDP encapsulation is used.
2.3. Issues common to both implementation approaches
2.3.1. User-space handling of HITs
Much initial experimentation with HIP has involved using HITs
directly in IPv6 socket calls, without any resolution infrastructure
to learn the HIT based on, for example, a domain name, or to resolve
the IP address. To experiment with HIP using HITs requires some a
priori HIT exchange, in the absence of a resolution service. Manual
exchange of HITs has been a major inconvenience for experimentation.
It can be overcome via 1) opportunistic HIP mode (RFC5201, Section
4.1.6), 2) storing HITs in DNS AAAA entries and looking them up by
domain name, 3) name resolution service for HITs such as OpenDHT
[I-D.irtf-hiprg-dht], or 4) a ad-hoc HIT exchange service to populate
Henderson & Gurtov Expires February 6, 2011 [Page 9]
Internet-Draft HIP Experiment Report August 2010
files on each machine.
At the time of writing, option 1) is only supported by OpenHIP, and
option 2) is only supported by HIP4BSD. Implementing the first
approach in a clean way is challenging, as HITs need to be known when
an application binds or connects to a socket. Approach 2) has been
difficult in practice due to resistance of sysadmins to include AAAA
entries for HITs in the DNS server, and is a non-standards-compliant
use of the resource record. However, using a widely available third-
party DNS service is possible, or support of RFC 5205 DNS extensions.
Approach 3) is being progressed with two independent implementations
of a HIP-OpenDHT interface. At the moment, the easiest way for
enabling experimentation appears to be the approach 4) when a shell
script based on SSH and SCP can connect to a peer machine and copy
HITs to the local configuration files. However, this approach is not
scalable or secure for the long run.
2.3.2. Resolving HITs to addresses
When HIP is used in opportunistic mode, the initiator does not know
the responder's HIT but does know its IP address. In most other
cases, however, the kernel or applications may know the HITs and not
the IP addresses; in this case, an IP address resolution step for
HITs must take place.
A few techniques have been experimented with. First, OpenDHT can
also use HITs as keys for IP address records. Second, work by
Ponomarev has shown that the reverse DNS tree may be used for reverse
lookups of the ORCHID space [I-D.ponomarev-hip-hit2ip]. Third, the
need for resolution may trigger some type of HIP bootstrap message,
similar in some sense to an ARP message (to resolve the HIT). The
BOS packet used to be present in the early revisions of the HIP base
specifications, but was removed from the final specifications due to
insufficient interest at the time. The HIPL implementation currently
sends an I1 to a link broadcast IP address if it doesn't know the IP
address of the peer. It has triggered warnings in some Windows hosts
running antivirus software, that classified broadcasts with unknown
protocol number as intrusion attempts. The utility of this technique
is limited to the local link.
2.3.3. IPsec management API extensions
A generic key management API for IP security is known as PF_KEY API
[RFC2367]. PK_KEY is a socket protocol family that can be used by
trusted applications to access the IPsec key engine in the operating
system. Users of this interface typically need sysadmin privileges.
HIP-related extensions to the PF_KEY interface define a new protocol
Henderson & Gurtov Expires February 6, 2011 [Page 10]
Internet-Draft HIP Experiment Report August 2010
IPPROTO_HIP. Their main functionality is replacing TCP and UDP
checksum with a HIP-compatible checksum (because the transport
pseudoheader is based on HITs) in incoming and outgoing packets.
PF_KEY extensions are implemented as a patch to the Linux kernel,
which creates certain inconveniences for users who do not want to
rebuild their kernel.
2.3.4. Transport protocol issues
When an application triggers a HIP base exchange through the
transport protocol, the first data packet can be lost unless the HIP
and IPsec implementation is able to buffer the packet until the base
exchange completes and IPsec SAs are set up. The loss of the data
packet, when it is a TCP SYN packet, results into TCP timeout
[RFC2988] that unnecessarily delays the application. A loss of a UDP
packet can cause even longer timeouts in applications. Therefore, it
was found to be important for HIP implementations to support the
buffering of the packet. On the other hand, if the HIP base exchange
takes longer than 1 second, which is the case on lightweight devices,
a spurious timeout can occur at the transport layer. The HIP
implementation could prevent this scenario by manipulating timeout
values at the transport layer or, alternatively, drop the original or
retransmitted duplicate packet.
The multihoming support in [RFC5206] is intended for the purpose of
failover, when a host starts using an alternative locator when a
current locator fails. However, a host could used this multihoming
support for load balancing across different locators. Multihoming in
this manner could potentially cause issues with transport protocol
congestion control and loss detection mechanisms. However, no
experimental results from using HIP multihoming in this capacity have
been reported.
The use of paths with different characteristics can also impact the
estimate of a retransmission timer at the sender's transport layer.
TCP uses a smoothed average of the path's Round Trip Time and its
variation as the estimate for a retransmission timeout. After the
retransmission timer expires, the sender retransmits all outstanding
packets in go-back-N fashion.
When multihoming is used for simultaneous data transmission from
several locators, there can easily be scenarios when the
retransmission timeout does not correspond to the actual value. When
packets simply experience different RTT, its variation is high, which
sets the retransmission timeout value unnecessarily high. When
packets are lost, the sender waits excessively long before
retransmitting. Fortunately, modern TCP implementations deploying
Selective Acknowledgments (SACK) and Limited Transmit are not relying
Henderson & Gurtov Expires February 6, 2011 [Page 11]
Internet-Draft HIP Experiment Report August 2010
on retransmission timeouts except when most outstanding packets are
lost.
Load balancing among several paths requires some estimate of each
path's capacity. The TCP congestion control algorithm assumes that
all packets flow along the same path. To perform load balancing, the
HIP layer can attempt to estimate parameters such as delay,
bandwidth, and loss rate of each path. A HIP scheduler could then
distribute packets among the paths according to their capacity and
delay, to maximize overall utilization and minimize reordering. The
design of the scheduler is a topic of current research work; none are
reported to exist. Different network paths can have different
Maximum Transmission Unit (MTU) sizes. Transport protocols perform
MTU discovery typically only in the beginning of a connection. As
HIP hides mobility from the transport layer, it can happen that
packets on the new path get fragmented without knowledge of the
transport protocol. To solve this problem, the HIP layer could
inform the transport layer of mobility events. This method, known as
transport triggers, is still under research although initial
specification attempts have been made in the IETF.
2.3.5. Legacy NAT traversal
Legacy NAT traversal for outbound-initiated connections to a publicly
addressed responder has been implemented by all three HIP
implementations; two (HIPL and HIP4BSD) implement ICE techniques for
inbound NAT traversal. UDP encapsulation is now the default mode of
HIP operation for OpenHIP's IPv4 HIP implementation. Finding an IPv6
NAT implementation for experiments has been difficult. NAT traversal
is expected to be a major mode of HIP operation in the future.
2.3.6. Local management of host identity namespace
One issue not being addressed by some experimental implementations is
how to perform source HIT selection across possibly multiple host
identities (some may be unpublished). This is akin to source address
selection for transport sockets. How much HIP policy to expose to
users is a user interface issue. Default or automatic configuration
guesses might have undesirable privacy implications for the user.
HIIT has implemented an extension of the native HIP API to control
multiple host identities [thesis.karlsson].
There are security and privacy issues with storing private keys
securely on a host. Current implementations simply store private
keys in a file that is readable only by applications with root
privileges. This may not be a sufficient level of protection, as
keys could be read directly from the disk or e.g. some application
Henderson & Gurtov Expires February 6, 2011 [Page 12]
Internet-Draft HIP Experiment Report August 2010
with set-user-id flag. Keys may be stored on a trusted platform
module (TPM) but there are no reported HIP experiments with such a
configuration. In a Boeing pilot project, temporary certificates are
planned to be generated from a key on a USB SIM chip and used in the
HIP base exchange. Use of certificates in HIP requires extensions to
the HIP specifications. Another option is encrypting keys on disks
and keeping a passkey in memory (like in SSL certificates on servers,
that ask for a password when booting Linux).
2.3.7. Interactions with host firewalls
HIP is presently an experimental protocol, and some default firewall
configuration scripts on popular Linux distributions do not permit
such traffic. Determining which rules to modify without compromising
other performance can be tricky; the default rule set on a previous
SuSE Linux distribution was discovered to contain over one hundred
rules. Moreover, it may be the case that the end user has no control
over the firewall settings, if administered by an enterprise IT
department.
2.4. IPv4 vs. IPv6 issues
HIP has been oriented towards IPv6 deployment, but all
implementations have also added support for IPv4. HIP supports IPv6
applications well, as the HITs are used from the general IPv6 address
space using the ORCHID prefix. HITs are statistically unique,
although are not routable at the IP layer. Therefore a mapping
between HITs and routable IP addresses is necessary at the HIP layer,
unless an overlay network is available to route packets based on
HITs.
For IPv4 applications, a 32-bit Local Scope Identifier (LSI) is
necessary at the sockets API. The LSI is an alias for a host
identity and is only meaningful within one host. Note that an IPv4
address may be used as an LSI if it is configured to refer to a
particular host identity on a given host, or LSIs may be drawn from
an unallocated IPv4 address range, but lack of coordination on the
LSI space may hinder implementation portability.
HIP makes it possible to use IPv6 applications over the IPv4 network
and vice versa. The interfamily portion of the BEET patch in the
Linux kernel was found more difficult to complete compared with the
single-family processing, and is presently not part of Linux kernel.
All three open source HIP implementations have demonstrated some form
of interfamily handoff support.
Henderson & Gurtov Expires February 6, 2011 [Page 13]
Internet-Draft HIP Experiment Report August 2010
2.5. What have early adopters learned from experience?
Implementing HIP in current stacks or as overlays on unmodified
stacks has generally been successful. Below are some caveats and
open issues.
Experimental results comparing kernel vs. userspace HIP
implementations in terms of performance and DoS resilience would be
useful. If the kernel implementation is shown to perform
significantly better than the userspace implementation, it may be a
sufficient justification to incorporate HIP within the kernel.
However, experiences on general purpose laptops and servers suggests
that for typical client use of HIP, user-space implementations
perform adequately.
The experience with attempting to integrate the HIPL kernel-based
keying implementation to the official Linux kernel has been
unsuccessful. Although counter-examples exist, e.g. SCTP is a large
unit in the kernel, the Linux community resisted incorporating the
HIP code. The kernel developers felt that since MIP and IKE are
implemented as user-space signaling daemons in Linux, that should be
an approach for HIP too. Furthermore, the kernel-patch was somewhat
big, affecting the kernel in many places and having several
databases. The Linux kernel maintainers did eventually accept the
BEET patch.
Some users have been explicitly asking about co-existence of HIP with
other VPN and Mobile IP software. E.g., on Windows those tend to
install their own versions of TAP drivers which might conflict with
the driver used by the OpenHIP implementation. There may also be
issues due to lack of coordination leading to unintended HIP-over-VPN
sessions, or lack of coordination of the ESP SPI space. However,
these types of conflicts are only speculation and were not reported
to the research group; only some positive reports of HIP and VPN
software properly coexisting have been reported by the HIPL group.
Henderson & Gurtov Expires February 6, 2011 [Page 14]
Internet-Draft HIP Experiment Report August 2010
3. Infrastructure Implications
This section focuses on the deployment of infrastructure to support
HIP hosts.
3.1. Impact on DNS
HIP DNS extensions [RFC5205] were developed by NEC Eurolabs and
contributed to OpenHIP, and were also developed by the HIPL project,
both for the BIND9 DNS server. Legacy applications do not query for
HIP resource records, but DNS proxies (local resolvers) interpose
themselves in the resolution path and can query for HI records. The
DNS proxy for HIPL uses binary blob format to store the HIP resource
records; this means that no changes to the DNS server are required.
There have been no studies reported on the impact of RFC 5205 changes
to HIP on the existing DNS. There have been some studies on using
DNS to store HITs in the reverse tree [I-D.ponomarev-hip-hit2ip].
3.2. HIP aware middleboxes
A design of a HIP registration protocol for architectured NATs (NATs
that are HIP aware and use HIP identifiers to distinguish between
hosts) has been completed and published as RFC 5204. Performance
measurement results with a prototype are available, but
experimentation on a wide scale is still missing. RFC 5207 provides
a problem statement for HIP-aware NATs and middleboxes [RFC5207].
As argued by Aura et al. [paper.hipanalysis], the encryption of the
Initiator HI prevents policy-based NAT and firewall support, and
middlebox authentication, for HIP. The catch is that when the HI is
encrypted, middleboxes in the network cannot verify the signature of
the I2 and, thus, cannot safely create a state for the HIP
association. On the other hand, if the HI is not encrypted, a
stateful middlebox can process the I2 and create protocol state for
the session.
3.3. HIT resolution infrastructure
OpenDHT HIT-to-IP address resolution has been implemented by Aalborg
University, Denmark and by Boeing for OpenHIP [I-D.irtf-hiprg-dht].
The prototype of the Host Identity Indirection Infrastructure (Hi3)
has been implemented using OpenHIP and i3 software. A set of 25 i3
servers was running on PlanetLab for several years. While a
PlanetLab account is required to run the servers, anybody can openly
use the provided service.
Henderson & Gurtov Expires February 6, 2011 [Page 15]
Internet-Draft HIP Experiment Report August 2010
The main idea of Hi3 is to transmit HIP control packets using the i3
system as a lookup and rendezvous service, while transmitting data
packets efficiently end-to-end using IPsec. Performance measurements
were conducted comparing the association setup latency, throughput,
and RTT of Hi3 with plain IP, HIP and i3 [paper.hi3]
One difficulty has been with debugging the i3 system. In some cases
the messages did not traverse i3 correctly; due to its distributed
nature and lack of tracing tools, making the system work has been
challenging.
NATs and firewalls have been a major disturbance in Hi3 experiments.
Many networks did not allow incoming UDP packets to go through,
therefore, preventing messages from i3 servers to reach the client.
So far the Hi3 system has been evaluated on a larger scale only
analytically. The problem is that running a larger number of clients
to create a sufficient load for the server is difficult. A cluster
on the order of a hundred Linux servers is needed for this purpose.
Contacts to a State Supercomputer Centre in Finland have not been
successful so far. A possible opportunity is to use one of existing
Emulab installations, e.g. in Utah for these tests.
3.4. Rendezvous servers
A rendezvous server (RVS) [RFC5204] has been implemented by HIIT for
HIPL, [RFC5204] and an implementation also exists for OpenHIP. The
concept has been extended to a relay server in [RFC5770]. Initial
experimentation with the HIPL implementation produced the following
observations.
o RVS may be better than dynamic DNS updates for hosts that change
their address rapidly.
o Registration of a HIP host to RVS costs a base exchange.
o Sending of UPDATE and CLOSE packets through rendezvous servers is
advised; RVS handling of UPDATE messages can typically solve the
double jump mobility problem.
The following advanced concepts need further study.
o Multiple RVS per host for fault tolerance (e.g. one rendezvous
node crashes), and an algorithm for selecting the best RVS.
o Load balancing. A RVS server could distribute I1s to different
responders if the responder's identity is shared or opportunistic
HIP is used.
Henderson & Gurtov Expires February 6, 2011 [Page 16]
Internet-Draft HIP Experiment Report August 2010
o Offering a rendezvous service in a P2P fashion by HIP hosts.
3.5. Hybrid DNS-DHT resolution
In addition to pure DNS and pure DHT HIP name resolution, a hybrid
approach combining standard DNS interface for clients with last-hop
DHT resolution was developed. The idea is that the benefits of DNS
solution (wide deployment, support for legacy applications) could be
combined with advantages of DHT (fault tolerance, efficiency in
handling flat data keys). The DHT is typically run internally by the
organization managing the last-hop DNS zone and the DNS server. That
way, the HITs belonging to that organization could be stored locally
by the organization that improves deployability of the resolution
system. However, organizations could also share a DHT between
themselves, or connect their DNS servers to a publicly available DHT,
such as OpenDHT. The benefit of running a DHT on a local server
cluster compared to a geographically spread DHT is also higher
performance due to decreased internal DHT latencies.
The system was prototyped by modifying the BIND DNS server to
redirect the queries for HITs to a DHT server. The interface was
implemented in XML according to specifications [ref Jeff draft]. The
system is completely backward compatible to legacy applications since
the standard DNS resolver interface is used.
Performance of the system was evaluated by performing a rapid
sequence of requests for querying and updating the HIT to IP address
mapping. The request rate was varied from 1 to 200 requests per
second. The average latency of one query request was less than 50 ms
and the secured updated latency less than 100 ms with low request
rate. However, the delay was raising exponentially with the request
rate reaching 1 sec for 200 rps (update rate 0) and almost 2 sec
(update rate 0.5). Furthermore, the maximum delayed exceeded the
mean by several times.
Based on experiments, a multi-processor system could handle more than
1000 queries per second. The latencies are dominated by the DHT
resolution delay, and the DNS component is rather small. This is
explained by the relative inefficiency of used DHT implementation
(Bamboo) and could be definitely improved in future.
Henderson & Gurtov Expires February 6, 2011 [Page 17]
Internet-Draft HIP Experiment Report August 2010
4. Application Implications
In a deployed HIP environment, applications may be HIP-aware or HIP-
unaware. RFC5338 [RFC5338] describes various techniques to allow HIP
to support unmodified applications. Below are listed some additional
application considerations.
4.1. Non-intrusive HIP insertion
One way to support legacy applications that use dynamic linking is to
dynamically interpose a modified resolver library. Using HIPL,
several legacy applications were shown to work without changes using
dynamic re-linking of the resolver library. For example, Firefox web
browser successfully worked with an Apache web server. The re-
linking just requires configuring a LD_PRELOAD system variable that
can be performed in a user shell profile file or as a start-up
wrapper for an application. This provides the user with fine-grained
policy control over which applications use HIP, which could
alternately be considered a benefit or a drawback dependingg on
whether the user is burdened with such policy choices. The technique
was also found to be sensitive to loading LD_PRELOAD twice, in which
case the order of linking dynamic libraries must be coded carefully.
Another way to transparently use HIP is via local application proxies
(e.g. squid web proxy) that are modified to be HIP-aware.
4.2. Using a native HIP API
Several applications, including telnet and FTP, have been ported to
use a native HIP API in the HIPL project. A concern that FTP would
not work due to the problem of application referral, i.e. passing the
IP address within application messages, was solved. FTP is shown to
work well in the passive and active modes [paper.namespace].
4.3. Latency
Some applications may be sensitive to additional RTTs or processing
due to HIP resolutions or the protocol itself. For instance, page
load speed for web browsers is a critical metric for browser
designers. Some applications or deployments may not wish to trade
application speed for the security and mobility management that HIP
offers.
Henderson & Gurtov Expires February 6, 2011 [Page 18]
Internet-Draft HIP Experiment Report August 2010
5. Network Operator's Perspective
There is no known deployment of HIP by a data service provider.
However, some issues regarding HIP have been brought to the HIP
research group by a network provider and are summarized below and in
[I-D.dietz-hip-operator-issues].
5.1. Management of the host identity namespace
When a network operator deploys HIP for its customers, several issues
with management of host identities arise. The operator may prefer to
generate the host identity itself rather than let each host create
the identities. Several factors can create such a need. Public-
private key generation is a demanding operation that can take tens of
seconds on a lightweight device, such as a mobile phone. After
generating a host identity, the operator can immediately insert it to
its own AAA databases and network firewalls. This way, the users
would not need to be concerned with technical details of host
identity management.
The operator may use a Public Key Infrastructure (PKI) to certify
host identities of its customers. Then, it uses the private key of
operator's Certificate Authority (CA) to sign the public key of its
customers. This way, third parties possessing the public key of the
CA can verify the customer's host identity and use this information
e.g. for admission control to infrastructure. Such practice raises
the security level of HIP when self-signed host identities are used.
When the operator is using neither PKI nor DNSSEC host names, the
problem of securely exchanging host identities remains. When HIP is
used in opportunistic mode, a man-in-the-middle can still intercept
the exchange and replace the host identities with its own. The
signaling provided by the SIP protocol could be used to deliver host
identities if it were secured by existing mechanisms in operator's
network.
5.2. Use of ESP encryption
The research group has discussed whether operators can provide
"value-added" services and priority, and comply with wiretapping
laws, if all sessions are encrypted. This is not so much a HIP issue
as a general end-to-end encryption issue.
The processing power of mobile devices also must be considered. One
study evaluated the use of HIP and ESP on lightweight devices (Nokia
N770 Internet Tablets having 200 MHz processors) [paper.mobiarch].
The overhead of using ESP on such platform was found to be tolerable,
about 30% in terms of throughput. With a bulk TCP transfer over
Henderson & Gurtov Expires February 6, 2011 [Page 19]
Internet-Draft HIP Experiment Report August 2010
WiFi, transfer without HIP was producing 4.86 Mbps, while over ESP
security associations set up by HIP it was 3.27 Mbps.
5.3. Access control lists based on HITs
A firewall typically separates an organization's network from the
rest of the Internet. An Access Control List (ACL) specifies packet
forwarding policies in the firewall. Current firewalls can filter
out packets based on IP addresses, transport protocol, and port
values. These values are often unprotected in data packets and can
be spoofed by an attacker. By trying out common well-known ports and
a range of IP addresses, an attacker can often penetrate the firewall
defenses.
Furthermore, legacy firewalls often disallow IPsec traffic and drop
HIP control packets. HIP allows the ACLs to be protected based on
packet exchanges that may be authenticated by middleboxes. However,
HITs are not aggregatable, so ACLs may be longer when using HITs and
harder to deal with by human users.
Some system administrators find it annoying to see trimmed
hexadecimal sequences in the netstat output displaying HITs. They
prefer domain names and also have reverse zones (locally) for
[RFC1918] addresses from another network with thousands of hosts
which nobody could remember by heart.
Additionally, operators would like to grant access to the clients
from domains such as example.com regardless of their current locators
or HITs. This is difficult without a forward confirmed reverse DNS
to use for reputation purposes.
5.4. Firewall issues
HIIT has implemented a userspace HIP firewall based on Linux iptables
[thesis.vehmersalo]. Firewalls can be stateless, filtering packets
based only on the ACL, and stateful, which can follow and remember
packet flows. Stateless firewalls are simple to implement but
provide only coarse-grained protection. However, their performance
can be efficient since packet processing requires little memory or
CPU resources. A stateful firewall determines if a packet belongs to
an existing flow or starts a new flow. A flow identifier combines
information from several protocol headers to classify packets. A
firewall removes the state when the flow terminates (e.g., a TCP
connection is closed) or after a timeout. A firewall can drop
suspicious packets that fail a checksum or contain sequence numbers
outside of the current sliding window. A transparent firewall does
not require that hosts within the protected network register or even
know of the existence of the firewall. An explicit firewall requires
Henderson & Gurtov Expires February 6, 2011 [Page 20]
Internet-Draft HIP Experiment Report August 2010
registration and authentication of the hosts.
A HIP-aware firewall identifies flows using HITs of communicating
hosts, as well as SPI values and IP addresses. The firewall must
link together the HIP base exchange and consequent IPsec ESP data
packets. The firewall, therefore, must be stateful. During the base
exchange, the firewall learns the SPI values from I2 and R2 packets.
Then, the firewall only allows ESP packets with a known SPI value and
arriving from the same IP address as during the base exchange. If
the correspondent host changes its location and the IP address, the
firewall learns about the changes by following the mobility update
packets.
A HIP host can register to the firewall using the usual procedure
[RFC5203]. The registration enables the host and the firewall to
authenticate each other. In a common case, where the Initiator and
Responder hosts are located behind different firewalls, the Initiator
may need to first register with its own firewall, and afterward, with
the Responder's firewall.
Some researchers have suggested that a firewall for security-critical
environments should get involved in the base exchange and UPDATE
procedures with middlebox-injected echo requests. Otherwise, the
firewall can be circumvented with replay attacks if there is a
compromised node within the network that the firewall is trying to
protect [I-D.heer-hip-middle-auth].
Henderson & Gurtov Expires February 6, 2011 [Page 21]
Internet-Draft HIP Experiment Report August 2010
6. User Privacy Issues
Using public keys for identifying hosts creates a privacy problem as
third parties can determine the source host even if attached to a
different location in the network. Various transactions of the host
could be linked together if the host uses the same public key.
Furthermore, using a static IP address also allows linking of
transactions of the host. Multiplexing multiple hosts behind a
single NAT or using short address leases from DHCP can reduce the
problem of user tracking. However, IPv6 addresses could reduce the
occurrence of NAT translation and cause additional security issues
related to the use of MAC addresses in IPv6 address
autoconfiguration.
All two-round-trip variations of the Diffie Hellman key exchange
using public keys for authentication are vulnerable to identity
theft. The Responder must not generate the shared session key before
receiving two messages from the Initiator, to avoid DoS attacks. If
the Responder sends its public key in the first reply message (R1) to
the Initiator, the Responder's identity will be revealed to third
parties. Therefore, the public key is sent encrypted in the second
message of the base exchange. The Initiator cannot determine the
identity of the Responder until after receiving the last message (R2)
of the key exchange. As a result, an active attacker can find out
the public key and identity of the Initiator by pretending to be a
trusted correspondent host. The Initiator's public key is sent
encrypted in the third message of the Diffie Hellman key exchange and
can be decrypted by an attacker based on the established session key.
DNS records can provide information combining host identity and
location information, the host public key, and host IP address.
Therefore, identity and location privacy are related and should be
treated in an integrated approach. The goal of the BLIND is to
provide a framework for identity and location privacy [paper.blind].
The identity protection is achieved by hiding the actual public keys
from third parties so that only the trusted correspondent hosts can
recognize the keys. Location privacy is achieved by integrating
traffic forwarding with NAT translation and decoupling host
identities from locators. The use of random IP and MAC addresses
also reduces the issue of location privacy shifting the focus to
protecting host identifiers from third parties. This approach is, by
its very nature, incompatible with middlebox authentication.
To prevent revealing the identity, the host public key and its hash
(HIT) can be encrypted with a secret key known beforehand to both
Initiator and Responder. However, this is a requirement that cannot
be easily implemented in practice. The BLIND framework provides
protection from active and passive attackers using a modified HIP
Henderson & Gurtov Expires February 6, 2011 [Page 22]
Internet-Draft HIP Experiment Report August 2010
base exchange. If the host avoids storing its public keys in the
reverse DNS or DHT repository, the framework achieves full location
and identity privacy.
An alternative approach to reducing privacy threats of persistent
identifiers is to replace them with short-lived identifiers that are
changed regularly to prevent user tracking. Furthermore, identifiers
must be changed simultaneously at all protocol layers, or otherwise
an adversary could still link the new identifier by looking at an
identifier at another protocol layer that remained the same after the
change. The HIP privacy architecture that simultaneously changes
identifiers on MAC, IP, and HIP/IPsec layers was developed at TKK
[thesis.takkinen]. The default frequency of changes is every 6 to 10
minutes. Unfortunately, each change causes a delay of 3 seconds, and
possibly loss of data packets, which might be unacceptable for real-
time applications. HIP could be extended in the future to allow
active sessions to migrate identities.
Henderson & Gurtov Expires February 6, 2011 [Page 23]
Internet-Draft HIP Experiment Report August 2010
7. Experimental Basis of this Report
This report is derived from reported experiences and research results
of early adopters, implementers, and research activities. In
particular, a number of implementations have been in development
since 2002 (Section 2).
One production-level deployment of HIP has been reported. Boeing has
described how it uses HIP to build layer-2 VPNs over untrusted
wireless networks [I-D.henderson-hip-vpls]. This use case is not a
traditional end-host-based use of HIP but rather is one that uses
HIP-aware middleboxes to create ESP tunnels on-demand between
provider-edge (PE) devices.
The InfraHIP II project is deploying HIP infrastructure (test
servers, rendezvous and relay servers) in the public Internet.
The following is a possibly incomplete list of past and current
research activities related to HIP.
o Boeing (T. Henderson, J. Ahrenholz, J. Meegan. OpenHIP
implementation, Secure Mobile Architecture)
o NomadicLab, Ericsson (P. Jokela, P. Nikander, J. Melen. BSD HIP
implementation)
o HIIT (A. Gurtov, M. Komu, A. Pathak, D. Beltrami. HIPL, legacy
NAT traversal, firewall, i3, native API)
o UCB (D. Joseph, HIP proxy implementation)
o Laboratory of Computer Architecture and Networks, Polytechnic
School of University of Sao Paulo, Brazil (T. Carvalho, HIP
measurements, Hi3)
o Telecom Italia (M. Morelli, comparing existing HIP
implementations)
o NEC Heidelberg (L. Eggert, M. Esteban, V. Schmitt working on RVS
implementation, DNS, NAT traversal)
o U. of Hamburg-Harburg (M. Shanmugam, A. Nagarajan, HIP
registration protocol)
o U. of Tuebingen (K. Wehrle, T. Lebenslauf to work on Hi3 or HIP-
OpenDHT)
Henderson & Gurtov Expires February 6, 2011 [Page 24]
Internet-Draft HIP Experiment Report August 2010
o University of Parma (UNIPR), Department of Information Engineering
Parma, Italy. N. Fedotova (HIP for P2P)
o Siemens (H. Tschofenig, HIP middleboxes)
o Denmark (Aalborg University, Lars Roost, Gustav Haraldsson, Per
Toft, HIP evaluation project, OpenDHT-HIP interface)
o Microsoft Research, Cambridge (T. Aura, HIP analysis)
o MIT (H. Balakrishnan. Delegation-Oriented Architecture)
o Huawei Ltd, hierarchical HIP architecture, HIP proxy, key
revocation (D. Zhang, X. Xu)
Henderson & Gurtov Expires February 6, 2011 [Page 25]
Internet-Draft HIP Experiment Report August 2010
8. Related Work on ID/Locator Split
This section briefly summarizes the related work on ID/locator split
with particular focus on recent IETF and IRTF activity. In the
academic research community, several related proposals were explored
prior to the founding of this research group, such as the Internet
Indirection Infrastructure (i3) [paper.i3], IPNL [paper.layered],
DataRouter [paper.datarouter], Network Pointers [paper.netpointers],
FARA [paper.fara], and TRIAD [paper.triad].
The topic of whether a new name space is needed for the Internet is
controversial. The Name Space Research Group (NSRG) at the IRTF was
not able to reach consensus on the issue, nor even to publish a final
report. Yet, there seems to be little disagreement that, for many
scenarios, some level of indirection from network name to network
location is essential or highly desirable to provide adequate
service. Mobile IP [RFC3775] is one example that reuses an existing
name space for host naming. Since Mobile IP was finalized, many new
variants to providing this indirection have been suggested. Even
prior to Mobile IP, the IETF has published informational documents
describing architectures separating network name and location,
including the work of Jerome Saltzer [RFC1498], and Nimrod [RFC1992].
Most recently, there has been standardization and development efforts
in the IETF and IRTF as follows:
o The Site Multihoming in IPv6 (multi6) WG documented the ways that
multihoming is currently implemented in IPv4 networks and
evaluated several approaches for advanced multihoming. The
security threats and impact on transport protocols were covered
during the evaluation. The work continued in another WG, Site
Multihoming by IPv6 Intermediation (shim6), which focusing on
specifications of one selected approach [I-D.ietf-shim6-proto].
shim6 uses the approach of inserting a shim layer between the IP
and the transport layers that hides effects of changes in the set
of available addresses. The applications are using one active
address that supports referrals. Shim6 relies on
cryptographically generated IPv6 addresses to solve the address
ownership problem. HIP and shim6 are architecturally similar and
use a common format for control packets. HIP specifications
define only simple multihoming scenarios leaving such important
issues as interface selection untouched. Shim6 offers
complementary functionality that can be be reused in HIP
[I-D.oliva-hiprg-reap4hip]. The OpenHIP implementation integrates
HIP and shim6 protocols in the same framework, with the goal of
allowing HIP to reuse the shim6 failure detection protocol.
Furthermore, HIP and shim6 socket APIs have been jointly designed
[I-D.ietf-hip-native-api] [I-D.ietf-shim6-multihome-shim-api].
Henderson & Gurtov Expires February 6, 2011 [Page 26]
Internet-Draft HIP Experiment Report August 2010
o The IRTF Routing Research Group (RRG) has explored a class of
solutions to the global routing scalability problem that involve
either separation of the existing IP address space into those used
for identifiers and locators as in LISP ([I-D.ietf-lisp]) and Six/
One Router ([I-D.vogt-rrg-six-one]), and those advocating a fuller
separation of these roles including ILNP ([I-D.rja-ilnp-intro]),
and RANGI ([I-D.xu-rangi]).
o The End-Middle-End research group considered the potential for an
explicit signaling and policy control plane for middleboxes and
endpoints [I-D.irtf-eme-francis-nutss-design], and at a joint
meeting at IETF 69, the HIP and EME research groups discussed
whether the EME framework could help HIP with middlebox traversal.
o The IETF Multipath TCP working group is developing mechanisms to
simultaneously use multiple paths in a regular TCP session. The
MPTCP solution aims to solve the multihoming problem also
addressed by HIP but by solving it for TCP specifically.
o The Unmanaged Internet Protocol bears several similarities to the
HIP architecture, such as the focus on identifiers that are not
centrally managed that are also based on a cryptographic hash of a
node's public key [thesis.ford].
o Apple Back To My Mac service provides secure connections between
hosts using IPsec between a pair of host identifiers. However,
the host identifier is reported to be an IPv6 ULA address rather
than a HIP identifier [I-D.zhu-mobileme-doc]
Although the HIP research group has not formally tried to compare HIP
with other ID/locator split approaches, such discussions have
occurred on other lists such as the Routing research group mailing
list, and a comparison of HIP's mobility management solution with
other approaches was published in [I-D.thaler-mobility-comparison].
Henderson & Gurtov Expires February 6, 2011 [Page 27]
Internet-Draft HIP Experiment Report August 2010
9. Acknowledgments
Miika Komu and Pekka Nikander have provided helpful comments on
earlier versions of this draft. We also thank Dacheng Zhang for
contributions on hierarchical HIP architectures.
Henderson & Gurtov Expires February 6, 2011 [Page 28]
Internet-Draft HIP Experiment Report August 2010
10. References
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008.
[RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the
Encapsulating Security Payload (ESP) Transport Format with
the Host Identity Protocol (HIP)", RFC 5202, April 2008.
[RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity
Protocol (HIP) Registration Extension", RFC 5203,
April 2008.
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 5204, April 2008.
[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol
(HIP) Domain Name System (DNS) Extensions", RFC 5205,
April 2008.
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
Host Mobility and Multihoming with the Host Identity
Protocol", RFC 5206, April 2008.
[RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and
Firewall Traversal Issues of Host Identity Protocol (HIP)
Communication", RFC 5207, April 2008.
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keranen, "Basic Host Identity Protocol (HIP) Extensions
for Traversal of Network Address Translators", RFC 5770,
April 2010.
[RFC4853] Housley, R., "Cryptographic Message Syntax (CMS) Multiple
Signer Clarification", RFC 4853, April 2007.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
Henderson & Gurtov Expires February 6, 2011 [Page 29]
Internet-Draft HIP Experiment Report August 2010
[RFC1498] Saltzer, J., "On the Naming and Binding of Network
Destinations", RFC 1498, August 1993.
[RFC1992] Castineyra, I., Chiappa, N., and M. Steenstrup, "The
Nimrod Routing Architecture", RFC 1992, August 1996.
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
Management API, Version 2", RFC 2367, July 1998.
[RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host
Identity Protocol with Legacy Applications", RFC 5338,
September 2008.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[paper.i3]
Stoica, I., Adkins, D., Zhuang, S., Shenker, S., and S.
Surana, "Internet Indirection Infrastructure (i3)",
Proceedings of ACM SIGCOMM, August 2002.
[paper.layered]
Balakrishnan, H., Lakshminarayanan, K., Ratnasamy, S.,
Shenker, S., Stoica, I., and M. Walfish, "A Layered Naming
Architecture for the Internet", Proceedings of ACM
SIGCOMM, August 2004.
[paper.datarouter]
Touch, J. and V. Pingali, "DataRouter: A Network-Layer
Service for Application-Layer Forwarding", Proceedings of
International Workshop on Active Networks (IWAN),
December 2003.
[paper.netpointers]
Tschudin, C. and R. Gold, "Network Pointers", ACM
Computer Communications Review, January 2003.
[paper.fara]
Clark, D., Braden, R., Falk, A., and V. Pingali, "FARA:
Reorganizing the Addressing Architecture", Proceedings of
ACM SIGCOMM FDNA Workshop, August 2003.
[paper.triad]
Cheriton, D. and M. Gritter, "TRIAD: A New Next-
Generation Internet Architecture", Unpublished, available
at Citeseer, July 2000.
Henderson & Gurtov Expires February 6, 2011 [Page 30]
Internet-Draft HIP Experiment Report August 2010
[paper.blind]
"BLIND: A Complete Identity Protection Framework for End-
points", Proc. of the Twelfth International Workshop on
Security Protocols, April 2004.
[paper.hipanalysis]
Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of the
HIP Base Exchange Protocol", Proc. of the 10th
Australasian Conference on Information Security and
Privacy (ACISP), July 2005.
[paper.namespace]
Komu, M., Tarkoma, S., Kangasharju, J., and A. Gurtov,
"Applying a Cryptographic Namespace to Applications",
Proc. of First International ACM Workshop on Dynamic
Interconnection of Networks, September 2005.
[paper.mobiarch]
Khurri, A., Vorobyeva, E., and A. Gurtov, "Performance of
Host Identity Protocol on Lightweight Hardware",
Proceedings of ACM MobiArch, August 2007.
[paper.hi3]
Gurtov, A., Korzon, D., Lukyanenko, A., and P. Nikander,
"Hi3: An Efficient and Secure Networking Architecture for
Mobile Hosts", Unpublished, available at Citeseer,
June 2008.
[thesis.takkinen]
Takkinen, L., "Host Identity Protocol Privacy Management",
Master thesis, TKK, March 2006.
[thesis.vehmersalo]
Vehmersalo, E., "Host Identity Protocol Enabled Firewall:
A Prototype Implementation and Analysis", Master thesis,
TKK, September 2005.
[thesis.karlsson]
Karlsson, N., "Enabling Multiple Host Identities on
Linux", Master thesis, Helsinki University of Technology,
September 2005.
[thesis.ford]
Ford, B., "UIA: A Global Connectivity Architecture for
Mobile Personal Devices", Doctoral thesis, Massachusetts
Institute of Technology, September 2008.
[I-D.nikander-esp-beet-mode]
Henderson & Gurtov Expires February 6, 2011 [Page 31]
Internet-Draft HIP Experiment Report August 2010
Melen, J. and P. Nikander, "A Bound End-to-End Tunnel
(BEET) mode for ESP", draft-nikander-esp-beet-mode-09
(work in progress), August 2008.
[I-D.ietf-shim6-proto]
Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", draft-ietf-shim6-proto-12 (work
in progress), February 2009.
[I-D.vogt-rrg-six-one]
Vogt, C., "Six/One: A Solution for Routing and Addressing
in IPv6", draft-vogt-rrg-six-one-01 (work in progress),
November 2007.
[I-D.irtf-eme-francis-nutss-design]
Francis, P., "An EME Signaling Protocol Design",
draft-irtf-eme-francis-nutss-design-00 (work in progress),
April 2007.
[I-D.ponomarev-hip-hit2ip]
Ponomarev, O. and A. Gurtov, "Embedding Host Identity Tags
Data in DNS", draft-ponomarev-hip-hit2ip-04 (work in
progress), July 2009.
[I-D.xu-rangi]
Xu, X., "Routing Architecture for the Next Generation
Internet (RANGI)", draft-xu-rangi-01 (work in progress),
July 2009.
[I-D.rja-ilnp-intro]
Atkinson, R., "ILNP Concept of Operations",
draft-rja-ilnp-intro-02 (work in progress), December 2008.
[I-D.ietf-lisp]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-05 (work in progress), September 2009.
[I-D.dietz-hip-operator-issues]
Dietz, T., "Issues of HIP in an Operators Networks",
draft-dietz-hip-operator-issues-00 (work in progress),
October 2005.
[I-D.irtf-hiprg-dht]
Ahrenholz, J., "HIP DHT Interface",
draft-irtf-hiprg-dht-00 (work in progress), June 2010.
[I-D.thaler-mobility-comparison]
Henderson & Gurtov Expires February 6, 2011 [Page 32]
Internet-Draft HIP Experiment Report August 2010
Thaler, D., "A Comparison of IP Mobility-Related
Protocols", draft-thaler-mobility-comparison-02 (work in
progress), October 2006.
[I-D.dawkins-trigtran-framework]
Dawkins, S., "Framework and Requirements for TRIGTRAN",
draft-dawkins-trigtran-framework-00 (work in progress),
February 2003.
[I-D.henderson-hip-vpls]
Henderson, T., Venema, S., and D. Mattes, "HIP-based
Virtual Private LAN Service (HIPLS)",
draft-henderson-hip-vpls-00 (work in progress),
February 2010.
[I-D.oliva-hiprg-reap4hip]
Oliva, A. and M. Bagnulo, "Fault tolerance configurations
for HIP multihoming", draft-oliva-hiprg-reap4hip-00 (work
in progress), July 2007.
[I-D.ietf-hip-native-api]
Komu, M. and T. Henderson, "Basic Socket Interface
Extensions for Host Identity Protocol (HIP)",
draft-ietf-hip-native-api-12 (work in progress),
January 2010.
[I-D.ietf-shim6-multihome-shim-api]
Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto,
"Socket Application Program Interface (API) for
Multihoming Shim", draft-ietf-shim6-multihome-shim-api-13
(work in progress), February 2010.
[I-D.zhu-mobileme-doc]
Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,
"Understanding Apple's Back to My Mac Service",
draft-zhu-mobileme-doc-01 (work in progress), March 2010.
[I-D.heer-hip-middle-auth]
Heer, T., Wehrle, K., and M. Komu, "End-Host
Authentication for HIP Middleboxes",
draft-heer-hip-middle-auth-02 (work in progress),
February 2009.
Henderson & Gurtov Expires February 6, 2011 [Page 33]
Internet-Draft HIP Experiment Report August 2010
Authors' Addresses
Tom Henderson
The Boeing Company
P.O. Box 3707
Seattle, WA
USA
Email: thomas.r.henderson@boeing.com
Andrei Gurtov
HIIT
Helsinki Institute for Information Technology
Aalto University
P.O. Box 19800
Helsinki FIN-00076
FINLAND
Phone: +358 9 451 1
Email: gurtov@cs.helsinki.fi
Henderson & Gurtov Expires February 6, 2011 [Page 34]
