IRTF HIP Research Group T. Henderson
Internet-Draft The Boeing Company
Expires: January 15, 2009 A. Gurtov
HIIT
July 14, 2008
HIP Experiment Report
draft-irtf-hip-experiment-04
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2009.
Henderson & Gurtov Expires January 15, 2009 [Page 1]
Internet-Draft HIP Experiment Report July 2008
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 HIP to host
protocol stack, Internet infrastructure, and applications. The
perspective of the network operator, as well as a list of HIP
experiments are presented as well.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. What is HIP? . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Related Work on ID/Locator Split . . . . . . . . . . . . . 5
2. Host Stack Implications . . . . . . . . . . . . . . . . . . . 7
2.1. Modifications to TCP/IP stack implementations . . . . . . 7
2.1.1. ESP implementation extensions . . . . . . . . . . . . 9
2.1.2. Resolver issues . . . . . . . . . . . . . . . . . . . 10
2.1.3. IPsec management API extensions . . . . . . . . . . . 10
2.1.4. Transport protocol issues . . . . . . . . . . . . . . 11
2.2. Local management of host identity namespace . . . . . . . 12
2.3. Interactions with host firewalls . . . . . . . . . . . . . 13
2.4. Relation to shim6 protocols . . . . . . . . . . . . . . . 13
2.5. IPv4 vs. IPv6 issues . . . . . . . . . . . . . . . . . . . 13
2.6. What have early adoptors learned from experience? . . . . 14
3. Infrastructure Implications . . . . . . . . . . . . . . . . . 16
3.1. Legacy NAT traversal . . . . . . . . . . . . . . . . . . . 16
3.2. Impact on DNS . . . . . . . . . . . . . . . . . . . . . . 16
3.3. HIP aware middleboxes . . . . . . . . . . . . . . . . . . 16
3.4. HIT resolution infrastructure . . . . . . . . . . . . . . 16
3.5. Rendezvous servers . . . . . . . . . . . . . . . . . . . . 17
4. Application Implications . . . . . . . . . . . . . . . . . . . 19
4.1. Static vs. dynamic linking of resolver library . . . . . . 19
4.2. Using legacy API . . . . . . . . . . . . . . . . . . . . . 19
4.3. Using native API . . . . . . . . . . . . . . . . . . . . . 19
5. Network Operator's Perspective . . . . . . . . . . . . . . . . 20
5.1. Management of the host identity namespace . . . . . . . . 20
5.2. Use of ESP encryption . . . . . . . . . . . . . . . . . . 20
5.3. User privacy issues . . . . . . . . . . . . . . . . . . . 20
5.4. Access control lists based on HITs . . . . . . . . . . . . 22
5.5. Firewall issues . . . . . . . . . . . . . . . . . . . . . 22
6. Experimental Basis of this Report . . . . . . . . . . . . . . 24
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Henderson & Gurtov Expires January 15, 2009 [Page 2]
Internet-Draft HIP Experiment Report July 2008
Intellectual Property and Copyright Statements . . . . . . . . . . 30
Henderson & Gurtov Expires January 15, 2009 [Page 3]
Internet-Draft HIP Experiment Report July 2008
1. Introduction
This document summarizes the work and experiences of the Host
Identity Protocol IRTF Research Group (HIP-RG). The HIP-RG was
chartered to explore the possible benefits and consequences of
deploying the Host Identity Protocol architecture [RFC4423] in the
Internet.
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 currently 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].
1.2. Scope
The research group is tasked with producing an "experiment report"
documenting the collective experiences and lessons learned from other
studies, related experimentation, and designs completed by the
Henderson & Gurtov Expires January 15, 2009 [Page 4]
Internet-Draft HIP Experiment Report July 2008
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 is
also 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.
In this report, we summarize the collective experience of early
implementors 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.
o Whereas the two previous sections focus on the implementation and
deployment of the network plumbing to make HIP work, the next two
focus on the impact to users and operators of the network.
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 In Section 6, we list the experimental activities and research
that have contributed to this report.
1.3. Related Work on ID/Locator Split
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. The IRTF HIP research group is tasked to evaluate the impact
of deployment of a HIP or related name space in the Internet. 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 (the first such Standards Track proposal),
with particular deployment and security properties, 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
Henderson & Gurtov Expires January 15, 2009 [Page 5]
Internet-Draft HIP Experiment Report July 2008
[RFC1992].
Most recently, there has been standardization and development efforts
in the IETF and IRTF on shim6 protocols and HIP, and consideration of
ID/Locator solutions within the IRTF Routing Research Group (RRG).
In the academic research community, several related proposals have
been explored, 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].
Henderson & Gurtov Expires January 15, 2009 [Page 6]
Internet-Draft HIP Experiment Report July 2008
2. Host Stack Implications
Our discussion here draws on experience of implementors in adding HIP
to general-purpose computing platforms such as laptops, desktops, and
servers. 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 pass packets through user-space for HIP processing.
The following public HIP implementations are known:
o HIP4BSD (http://www.hip4inter.net)-- FreeBSD kernel modifications
and user-space keying daemon;
o HIPL (http://infrahip.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 Macintosh OS X, plus
a Linux kernel packet processing variant based on an extended
kernel IPsec implementation;
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
demonstrates that it is also possible to support HIP with a purely
kernel-level implementation.
Henderson & Gurtov Expires January 15, 2009 [Page 7]
Internet-Draft HIP Experiment Report July 2008
+--------------------+ +--------------------+
| | | |
| +------------+ | | +------------+ |
| | 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), 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.
Henderson & Gurtov Expires January 15, 2009 [Page 8]
Internet-Draft HIP Experiment Report July 2008
|-----------------------|
-------- | ---------- ----------
| 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 HIT, which is a part of IPv6 address space reserved for
ORCHIDs. IPv4 applications bind to Local Scope Identifier (LSI) that
has significance only within a host. The HIP layer translates
between LSIs and HITs that are still used underneath for HIP base
exchange.
2.1.1. ESP implementation extensions
HIP requires 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 was
integrated to Linux and FreeBSD kernels.
The current strategy that implementors have adopted is to develop a
common IPsec BEET patch for the Linux kernel. The patch could
potentially allow all implementations of HIP to run in the userspace
and use a common clean interface towards the kernel. Still, the BEET
patch introduces problems for the opportunistic HIP mode when HITs
are used at the socket API, because there is no way to name the
responder host at the onset of socket and Security Association
Henderson & Gurtov Expires January 15, 2009 [Page 9]
Internet-Draft HIP Experiment Report July 2008
creation.
Another inconvenience experienced in current Linux implementations
(due to the native IPsec implementation, not HIP specifically) is a
loss 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.1.2. Resolver issues
Much initial experimentation with HIP has involved using HITs
directly in IPv6 socket calls. To do so requires some type of 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, 2) storing HITs in
DNS AAAA entries, 3) name resolution service such as OpenDHT, 4) a
HIT exchange service, or 5) link local broadcast. Opportunistic mode
involves a "leap of faith" to accept and learn of the peer's
identity, in much the same way that ssh works today.
At the time of writing, #1 is only supported by OpenHIP, and #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 in the DNS server. However, using a widely available third-
party DNS service has a low cost. Approach #3 is being progressed
with two independent implementations of 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.
For option #5 we need to trigger some kind of HIP bootstrap message.
The BOS packet used to be present in the early revisions of HIP base
specifications, but was removed from the final specifications due to
insufficient interest. 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
firewall software, that classified broadcasts with unknown protocol
number as intrusion attempts. It is likely that UDP tunneling as in
NAT traversal extensions will fix this problem.
2.1.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
Henderson & Gurtov Expires January 15, 2009 [Page 10]
Internet-Draft HIP Experiment Report July 2008
trusted applications to access the IPsec key engine in the operating
system.
HIP-related extensions to PF_KEY interface define a new protocol
IPPROTO_HIP. Their main functionality is replacing TCP and UDP
checksum with a HIP checksum in incoming and outgoing packets.
PF_KEY extensions are implemented as a patch to the Linux kernel,
which creates certain inconviences for users who need to install
kernel sources and recompile them after patching.
2.1.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 of 1
second [RFC2988] that unnecessarily delays the application. A loss
of a UDP packet can cause even longer timeouts in application.
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 timeouts values at the transport layer or,
alternatively, drop the original or retransmitted duplicate packet
The multihoming support in [RFC5206] is stated for the purpose of
failover, when a host starts using a spare locator when a current
locator fails. A host deploying multihoming for load balancing can
simultaneously transmit data from several locators to utilize
bandwidth over parallel network paths or to reduce the latency. Such
a scenario creates several issues at the transport layer, related to
congestion control and error recovery. In particular, if packets
from a single TCP connection are sent over different paths, they can
experience different propagation delays.
When packets take different paths to reach the destination, they can
arrive in a different order than transmitted, an effect known as
packet reordering. Packet reordering easily confuses reliable
transport protocols, such as TCP and SCTP, or the application if
unreliable UDP transport protocol is used [RFC4653] [RFC3522].
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 timeout expires, the sender retransmits all
Henderson & Gurtov Expires January 15, 2009 [Page 11]
Internet-Draft HIP Experiment Report July 2008
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 unnecessary 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 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 can 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.
Different network paths can have different Maximum Transmission Unit
(MTU) sizes. Transport protocols perform MTU size 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.
(CELP, MAST) TODO
2.2. Local management of host identity namespace
One issue not being addressed by most experimental implementations is
how to manage 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 native API to control multiple
host identities (refer to Karlsson's Master's thesis).
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
Henderson & Gurtov Expires January 15, 2009 [Page 12]
Internet-Draft HIP Experiment Report July 2008
privileges. This may not be a sufficient level of protection, as
keys could be read directly from the disk or e.g. some application
with set-user-id flag. 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 passkey in memory (like in SSL
certificates on servers, that ask for a password when booting Linux).
2.3. 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 one popular
distribution has 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. Relation to shim6 protocols
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. This WG 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 enables referrals. Shim6 relies on
cryptographically generated IPv6 addresses to solve the address
ownership problem.
HIP and shim6 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. 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.
2.5. IPv4 vs. IPv6 issues
HIP has been oriented towards IPv6 deployment, but many
implementations have added support also 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,
Henderson & Gurtov Expires January 15, 2009 [Page 13]
Internet-Draft HIP Experiment Report July 2008
although are not routable on the IP layer. Therefore a mapping
between HITs and routable IP addresses is necessary at the HIP layer,
unless an overlay network is avaible to route packets based on HITs.
For IPv4 applications, a 32-bit Local Scope Identifier (LSI) is
necessary at the socket 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.
HIP makes it possible to use IPv6 applications over IPv4 network and
vice versa. Interfamily part of BEET patch in the Linux kernel was
found more difficult to complete compared with the single-family
processing.
TODO: Interfamily handovers
2.6. What have early adoptors 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 to kernel.
The experience with attempting to integrate the HIPL kernel-based
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 signalling daemon 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.
Opportunities for misconfiguration of the Linux kernel have been a
side effect of the need to patch the kernel. Mistakenly disabling a
configuration option or compiling a feature as a module instead of
statically caused many installation problems. Some scripts that
could verify that the configuration is appropriate could help to
solve this problem, as could fully user-space test implementations.
Installing several HIP implementations onto a single machine creates
some complications. All implementations store some files in /etc/hip
Henderson & Gurtov Expires January 15, 2009 [Page 14]
Internet-Draft HIP Experiment Report July 2008
directory and use /proc system to report the status. While direct
conflicts in filenames were luckily avoided, it might have been
better to coordinate from the beginning so that different
implementations, for example, use different subdirectories. However,
we expect this issue to be of significance only to HIP developers but
not for an average user. 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 own versions of TAP drivers
which might conflict with the driver used by OpenHIP implementation.
Henderson & Gurtov Expires January 15, 2009 [Page 15]
Internet-Draft HIP Experiment Report July 2008
3. Infrastructure Implications
This section focuses on generic infrastructure issues, and is related
also to a later section on operator issues (Section Section 5.
3.1. Legacy NAT traversal
Legacy NAT traversal is being implemented for several HIP
implementations according to the NAT traversal draft under
development in the HIP WG. 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.
3.2. Impact on DNS
[RFC5205] Initially, HITs were expected to be stored as AAAA entries
in DNS. This is a source of potential confusion for HIP unaware
applications that cannot distinguish between a HIT and a valid IPv6
address.
What is the impact of HIP resource records on DNS? DNS extensions
are currently under development by NEC Eurolabs.
3.3. HIP aware middleboxes
A design of a HIP registration protocol for architectured NATs has
been completed and published. Performance measurement results with a
prototype are available, but experimentation on a wide scale is still
missing. [RFC5207].
As argued by Aura et al. [paper.hipanalysis], the encryption of the
Responder HI prevents policy-based NAT and firewall support for HIP.
The catch is that when the HI is encrypted, middle boxes in the
network cannot verify the signature on I2 and, thus, cannot safely
create a state for the HIP association. On the other hand, if the HI
is not encrypted, a stateful middle box like a NAT can process I2 and
create a protocol state for the session. It may be possible to push
the I1/R1 exchange into the firewall and to filter false puzzle
solutions at the firewall. The encryption of HI-I prevents such
middle-box implementations.
3.4. HIT resolution infrastructure
OpenDHT resolution has been implemented by Aalborg University,
Denmark and by Boeing for OpenHIP. (Add references).
The prototype of the Host Identity Indirection Infrastructure (Hi3)
has been implemented using OpenHIP and i3 software. A set of 25 i3
Henderson & Gurtov Expires January 15, 2009 [Page 16]
Internet-Draft HIP Experiment Report July 2008
servers is running on PlanetLab. While a PlanetLab account is
required to run the servers, anybody can openly use the provided
service.
The main idea 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 are
being executed, comparing the association setup latency, throughout
and RTT of Hi3 with plain IP, HIP and i3.
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. Fortunately, these shortcomings are being addressed.
NATs and firewalls were a major disturbing factor in execution of
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.5. Rendezvous servers
A rendezvous server (RVS) [RFC5204] has been implemented by HIIT for
HIPL, [RFC5204] and an implementation also exists for OpenHIP.
Initial experimentation with the HIPL implementation produced the
following observations.
o RVS is essential for fast initial contact; DynDNS is not as fast
yet.
o RVS improves fault tolerance for multihoming.
o Registration of a HIP host to RVS loads the host significantly.
Following advanced concepts need further study.
o Multiple RVS per host for fault tolerance (e.g. one rendezvous
node crashes). An algorithm for selecting the best RVS.
Henderson & Gurtov Expires January 15, 2009 [Page 17]
Internet-Draft HIP Experiment Report July 2008
o Load balancing. A RVS server could distribute I1s to different
responders if the responder's identity is shared or opportunistic
HIP is used.
o Offering a rendezvous service in a P2P fashion by HIP hosts.
Henderson & Gurtov Expires January 15, 2009 [Page 18]
Internet-Draft HIP Experiment Report July 2008
4. Application Implications
4.1. Static vs. dynamic linking of resolver library
Using HIPL, several legacy applications were shown to work without
changes using dynamic re-linking of the resolver library. This way,
Firefox web browser successfully worked with an Apache web server.
The re-linking just requires configuring a LD_PRELOAD system variable
that can be easily done in a user shell profile file or as a start-up
wrapper for an application.
4.2. Using legacy API
OpenHIP legacy API allows using most HIP-unaware applications in a
transparent way [I-D.ietf-hip-applications].
4.3. Using native API
Several applications, including telnet and FTP, have been ported to
use the native HIP API in HIPL. 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].
Henderson & Gurtov Expires January 15, 2009 [Page 19]
Internet-Draft HIP Experiment Report July 2008
5. Network Operator's Perspective
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 identitity 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
own AAA databases and network firewalls. Finally, the users would
not need to be concerned with technical details of host identity
management.
The operator may use Public Key Infrastructure (PKI) to certify host
identities of its customers. Then, it uses the private key of
operator's Certificate Authority to sign the public key of its
customers. This way, third parties possesing the public key of CA
can verify the customer's host identity and use this information e.g.
for admission control to roaming. Such practice raises the security
level of HIP when self-signed host identities are used.
When the operator is not using PKI nor DNSSEC host names, the problem
of securely exchanging of host identities remains. When HIP is used
in opportunistic mode, a man-in-the-midlle can still intercept the
exchange and replace the host identities with its own. Signalling of
SIP protocol could be used to deliver host identities if it is
secured by existing mechanisms in operator's network.
5.2. Use of ESP encryption
(Reference the Dietz draft here) Discussion regarding 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 IPsec issue. 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 WiFi without HIP
was producing 4.86 Mbps, while over ESP security assosiations set up
by HIP it was 3.27 Mbps.
5.3. 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
Henderson & Gurtov Expires January 15, 2009 [Page 20]
Internet-Draft HIP Experiment Report July 2008
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 eliminate
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 to the
Initiator, the Responder's identity will be revealed to third
parties. Therefore, the public key is sent encrypted in its second
message of the base exchange. The Initiator cannot determine the
identity of the Responder after receiving the last message of the key
exchange. As the 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.
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 a requirement that cannot be
easily implemented in practice. The BLIND framework provides
protection from active and passive attackers using a modified two-
round-trip Diffie Hellman key exchange protocol. If the host avoids
storing their public keys in the reverse DNS or DHT repository, the
framework achieves full location and identity privacy.
A natural 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
Henderson & Gurtov Expires January 15, 2009 [Page 21]
Internet-Draft HIP Experiment Report July 2008
must be changed simultaneously at all protocol layers, otherwise an
adversary could still link the new identifier through looking at the
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 in 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.
5.4. 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.
5.5. Firewall issues
HIIT has implemented a 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-grain protection. However, their performance can
be high 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
registration and authentication from 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
Henderson & Gurtov Expires January 15, 2009 [Page 22]
Internet-Draft HIP Experiment Report July 2008
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 register with its own firewall and afterward with the
Responder's firewall.
Henderson & Gurtov Expires January 15, 2009 [Page 23]
Internet-Draft HIP Experiment Report July 2008
6. Experimental Basis of this Report
This report is derived from reported experiences and research results
of early adoptors, implementors, and research activities. In
particular, a number of implementations have been in development
since 2002 (Section Section 2). The following is a possibly
incomplete list of 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)
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)
Henderson & Gurtov Expires January 15, 2009 [Page 24]
Internet-Draft HIP Experiment Report July 2008
7. Acknowledgments
Miika Komu has provided helpful comments on earlier versions of this
draft.
Henderson & Gurtov Expires January 15, 2009 [Page 25]
Internet-Draft HIP Experiment Report July 2008
8. 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.
[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.
[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.
Henderson & Gurtov Expires January 15, 2009 [Page 26]
Internet-Draft HIP Experiment Report July 2008
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
Management API, Version 2", RFC 2367, July 1998.
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm
for TCP", RFC 3522, April 2003.
[RFC4653] Bhandarkar, S., Reddy, A., Allman, M., and E. Blanton,
"Improving the Robustness of TCP to Non-Congestion
Events", RFC 4653, August 2006.
[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.
[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
Henderson & Gurtov Expires January 15, 2009 [Page 27]
Internet-Draft HIP Experiment Report July 2008
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.
[book.hip]
Gurtov, A., "Host Identity Protocol (HIP): Towards the
Secure Mobile Internet", Wiley and Sons, 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.
[I-D.nikander-esp-beet-mode]
Melen, J. and P. Nikander, "A Bound End-to-End Tunnel
(BEET) mode for ESP", draft-nikander-esp-beet-mode-08
(work in progress), November 2007.
[I-D.ietf-hip-applications]
Henderson, T., Nikander, P., and M. Komu, "Using HIP with
Legacy Applications", draft-ietf-hip-applications-02 (work
in progress), November 2007.
Henderson & Gurtov Expires January 15, 2009 [Page 28]
Internet-Draft HIP Experiment Report July 2008
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
Advanced Research Unit (ARU)
P.O. Box 9800
Helsinki FIN-02015-HUT
FINLAND
Phone: +358 9 451 1
Email: gurtov@cs.helsinki.fi
Henderson & Gurtov Expires January 15, 2009 [Page 29]
Internet-Draft HIP Experiment Report July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Henderson & Gurtov Expires January 15, 2009 [Page 30]
