IRTF HIP Research Group T. Henderson Internet-Draft The Boeing Company Intended status: Informational A. Gurtov Expires: January 13, 2011 HIIT July 12, 2010 HIP Experiment Report draft-irtf-hip-experiment-07 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 January 13, 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 January 13, 2011 [Page 1] Internet-Draft HIP Experiment Report July 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 . . . . . . . . . . . 11 2.3.4. Transport protocol issues . . . . . . . . . . . . . . 11 2.3.5. Legacy NAT traversal . . . . . . . . . . . . . . . . . 12 2.3.6. Local management of host identity namespace . . . . . 13 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 . . . . . . . . . . . . . . . . . 16 3.1. Impact on DNS . . . . . . . . . . . . . . . . . . . . . . 16 3.2. HIP aware middleboxes . . . . . . . . . . . . . . . . . . 16 3.3. HIT resolution infrastructure . . . . . . . . . . . . . . 16 3.4. Rendezvous servers . . . . . . . . . . . . . . . . . . . . 17 4. Application Implications . . . . . . . . . . . . . . . . . . . 18 4.1. Static vs. dynamic linking of resolver library . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . 33 Henderson & Gurtov Expires January 13, 2011 [Page 2] Internet-Draft HIP Experiment Report July 2010 1. Introduction This document summarizes the work and experiences of the Host Identity Protocol IRTF Research Group (HIP-RG) from the 2004-09 timeframe. 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 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]. 1.2. Scope The research group has been tasked with producing an "experiment report" documenting the collective experiences and lessons learned from other studies, related experimentation, and designs completed by Henderson & Gurtov Expires January 13, 2011 [Page 3] Internet-Draft HIP Experiment Report July 2010 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) 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). o Exploration of whether introducing an identity/locator mechanism would be architecturally sound, deployed at wide scale. Henderson & Gurtov Expires January 13, 2011 [Page 4] Internet-Draft HIP Experiment Report July 2010 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 January 13, 2011 [Page 5] Internet-Draft HIP Experiment Report July 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 adding 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://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 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 demonstrates that it is also possible to support HIP with a purely kernel-level implementation. Henderson & Gurtov Expires January 13, 2011 [Page 6] Internet-Draft HIP Experiment Report July 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), 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 13, 2011 [Page 7] Internet-Draft HIP Experiment Report July 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 patch could potentially allow all implementations of HIP to run in the userspace and use a common interface towards the kernel. Still, the BEET patch alone does not enable the opportunistic HIP mode when HIP identifiers are used at the IP-based socket API, because there is no way to name the responder host at the onset of socket and Security Association creation. Henderson & Gurtov Expires January 13, 2011 [Page 8] Internet-Draft HIP Experiment Report July 2010 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.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, 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 direciton, a raw socket bound to ESP or a UDP port number may be used to receive HIP-protected packets. HIP signaling packets themselves may be sent and received by a 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, 2) storing HITs in DNS AAAA entries and looking them up by domain name, 3) name Henderson & Gurtov Expires January 13, 2011 [Page 9] Internet-Draft HIP Experiment Report July 2010 resolution service for HITs such as OpenDHT [I-D.ahrenholz-hiprg-dht], 4) a HIT exchange service, or 5) link local broadcast for experiments on the same link. 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, 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 and has a low cost. 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 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. However, the utility of this technique is limited to the local link. Henderson & Gurtov Expires January 13, 2011 [Page 10] Internet-Draft HIP Experiment Report July 2010 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. 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 inconveniences for users who need to install kernel sources and recompile them after patching. 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 of 1 second [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 stated for the purpose of failover, when a host starts using an alternative 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 degrades the performance of reliable transport protocols, such as TCP and SCTP, or the application if unreliable UDP transport protocol is used [RFC4653] [RFC3522]. Henderson & Gurtov Expires January 13, 2011 [Page 11] Internet-Draft HIP Experiment Report July 2010 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 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. Henderson & Gurtov Expires January 13, 2011 [Page 12] Internet-Draft HIP Experiment Report July 2010 2.3.6. 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 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 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 one popular Linux 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. 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, 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 socket API. The LSI is an alias for a host identity and is only meaningful within one host. Note that an IPv4 address Henderson & Gurtov Expires January 13, 2011 [Page 13] Internet-Draft HIP Experiment Report July 2010 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 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. 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. 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. Depending on the installation prefix specified, all implementations may store some files in /etc/hip directory and use the /proc filesystem to report status. While direct conflicts in Henderson & Gurtov Expires January 13, 2011 [Page 14] Internet-Draft HIP Experiment Report July 2010 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 the OpenHIP implementation. Henderson & Gurtov Expires January 13, 2011 [Page 15] Internet-Draft HIP Experiment Report July 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. There is not much experimental evidence with them, however, as early adopters have chosen to typically deploy HIT to IP mappings manually, or to experiment with DHTs. Legacy applications do not query for HIP resource records. 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. It is not clear whether this technique has been experimented with. 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 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.3. HIT resolution infrastructure OpenDHT HIT-to-IP address 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 servers is running on PlanetLab. While a PlanetLab account is required to run the servers, anybody can openly use the provided service. Henderson & Gurtov Expires January 13, 2011 [Page 16] Internet-Draft HIP Experiment Report July 2010 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, throughput, 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 have been a major disturbance in HIP 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. 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. 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. o Offering a rendezvous service in a P2P fashion by HIP hosts. Henderson & Gurtov Expires January 13, 2011 [Page 17] Internet-Draft HIP Experiment Report July 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. Static vs. dynamic linking of resolver library 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. 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 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 January 13, 2011 [Page 18] Internet-Draft HIP Experiment Report July 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. Finally, 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 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 roaming 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 is 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 IPsec 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, Henderson & Gurtov Expires January 13, 2011 [Page 19] Internet-Draft HIP Experiment Report July 2010 about 30% in terms of throughput. With a bulk TCP transfer over 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 a field 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 irritating to see trimmed hex sequences in the netstat output displaying HITs. They prefer understandable 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 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 Henderson & Gurtov Expires January 13, 2011 [Page 20] Internet-Draft HIP Experiment Report July 2010 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 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 13, 2011 [Page 21] Internet-Draft HIP Experiment Report July 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 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 the 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 is 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 its public keys in the reverse DNS or DHT repository, the Henderson & Gurtov Expires January 13, 2011 [Page 22] Internet-Draft HIP Experiment Report July 2010 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 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. HIP could be extended in the future to allow active sessions to migrate identities. Henderson & Gurtov Expires January 13, 2011 [Page 23] Internet-Draft HIP Experiment Report July 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. 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 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) Henderson & Gurtov Expires January 13, 2011 [Page 24] Internet-Draft HIP Experiment Report July 2010 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 13, 2011 [Page 25] Internet-Draft HIP Experiment Report July 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 enables 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. 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. Henderson & Gurtov Expires January 13, 2011 [Page 26] Internet-Draft HIP Experiment Report July 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. 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 January 13, 2011 [Page 27] Internet-Draft HIP Experiment Report July 2010 9. Acknowledgments Miika Komu and Pekka Nikander have provided helpful comments on earlier versions of this draft. Henderson & Gurtov Expires January 13, 2011 [Page 28] Internet-Draft HIP Experiment Report July 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. [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 13, 2011 [Page 29] Internet-Draft HIP Experiment Report July 2010 [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. [RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host Identity Protocol with Legacy Applications", RFC 5338, September 2008. [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 Henderson & Gurtov Expires January 13, 2011 [Page 30] Internet-Draft HIP Experiment Report July 2010 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. [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-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. Henderson & Gurtov Expires January 13, 2011 [Page 31] Internet-Draft HIP Experiment Report July 2010 [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.ahrenholz-hiprg-dht] Ahrenholz, J., "HIP DHT Interface", draft-ahrenholz-hiprg-dht-05 (work in progress), September 2009. [I-D.thaler-mobility-comparison] Thaler, D., "A Comparison of IP Mobility-Related Protocols", draft-thaler-mobility-comparison-02 (work in progress), October 2006. Henderson & Gurtov Expires January 13, 2011 [Page 32] Internet-Draft HIP Experiment Report July 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 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 13, 2011 [Page 33]