doc: Add RFC documents

1 files changed, 1963 insertions, 0 deletions

diff --git a/doc/rfc/rfc6538.txt b/doc/rfc/rfc6538.txt
new file mode 100644
index 0000000..5257e8f
--- /dev/null
+++ b/doc/rfc/rfc6538.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+Internet Research Task Force (IRTF)                         T. Henderson
+Request for Comments: 6538                            The Boeing Company
+Category: Informational                                        A. Gurtov
+ISSN: 2070-1721                                       University of Oulu
+                                                              March 2012
+
+
+           The Host Identity Protocol (HIP) Experiment Report
+
+Abstract
+
+   This document is a report from the IRTF Host Identity Protocol (HIP)
+   research group documenting the collective experiences and lessons
+   learned from studies, related experimentation, and designs completed
+   by the research group.  The document 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.  Portions of this
+   report may be relevant also to other network overlay-based
+   architectures or to attempts to deploy alternative networking
+   architectures.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Research Task Force
+   (IRTF).  The IRTF publishes the results of Internet-related research
+   and development activities.  These results might not be suitable for
+   deployment.  This RFC represents the consensus of the IRTF HIP
+   Research Group of the Internet Research Task Force (IRTF).  Documents
+   approved for publication by the IRSG are not a candidate for any
+   level of Internet Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6538.
+
+Copyright Notice
+
+   Copyright (c) 2012 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
+
+
+
+
+Henderson & Gurtov            Informational                     [Page 1]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. What is HIP? ...............................................3
+      1.2. Terminology ................................................4
+      1.3. Scope ......................................................4
+      1.4. 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. Opportunistic Mode .................................10
+           2.3.3. Resolving HITs to Addresses ........................12
+           2.3.4. IPsec Management API Extensions ....................12
+           2.3.5. Transport Protocol Issues ..........................12
+           2.3.6. Legacy NAT Traversal ...............................14
+           2.3.7. Local Management of Host Identity Namespace ........14
+           2.3.8. Interactions with Host Firewalls ...................15
+      2.4. IPv4 versus IPv6 Issues ...................................15
+      2.5. What Have Early Adopters Learned from Experience? .........16
+   3. Infrastructure Implications ....................................17
+      3.1. Impact on DNS .............................................17
+      3.2. HIP-Aware Middleboxes .....................................17
+      3.3. HIT Resolution Infrastructure .............................18
+      3.4. Rendezvous Servers ........................................18
+      3.5. Hybrid DNS-DHT Resolution .................................19
+   4. Application Implications .......................................20
+      4.1. Non-Intrusive HIP Insertion ...............................20
+      4.2. Referrals .................................................20
+      4.3. Latency ...................................................21
+   5. Network Operator's Perspective .................................21
+      5.1. Management of the Host Identity Namespace .................21
+      5.2. Use of ESP Encryption .....................................22
+      5.3. Access Control Lists Based on HITs ........................22
+      5.4. Firewall Issues ...........................................23
+   6. User Privacy Issues ............................................24
+   7. Experimental Basis of This Report ..............................25
+   8. Related Work on ID-Locator Split ...............................27
+   9. Security Considerations ........................................28
+   10. Acknowledgments ...............................................28
+   11. Informative References ........................................29
+
+
+
+
+Henderson & Gurtov            Informational                     [Page 2]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+1.  Introduction
+
+   This document summarizes the work and experiences of the IRTF's Host
+   Identity Protocol research group (HIP-RG) in the 2004-2009 time
+   frame.  The HIP-RG was chartered to explore the possible benefits and
+   consequences of deploying the Host Identity Protocol architecture
+   [RFC4423] in the Internet and to explore extensions to HIP.
+
+   This document was developed over several years as the main charter
+   item for the HIP research group, and it has received inputs and
+   reviews from most of the active research group participants.  There
+   is research group consensus to publish it.
+
+1.1.  What is HIP?
+
+   The Host Identity Protocol architecture introduces a new namespace,
+   the "host identity" namespace, to the Internet architecture.  The
+   express purpose of this new namespace 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, NAT traversal, 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 proposals in this area [book.gurtov].
+
+   The Host Identity Protocol itself provides a rapid exchange of host
+   identities (public keys) between hosts and uses a Diffie-Hellman key
+   exchange that is compliant with Sigma ("SIGn-and-MAc") 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
+   Overlay Routable Cryptographic Hash Identifiers (ORCHIDs) [RFC4843]
+   in Internet protocols.  Additionally, the research group published
+   one RFC on requirements for traversing NATs and firewalls [RFC5207]
+
+
+
+
+Henderson & Gurtov            Informational                     [Page 3]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   and the working group later published specification text for legacy
+   NAT traversal [RFC5770].  As of this writing, work has commenced on
+   moving the above specifications to Standards Track status.
+
+1.2.  Terminology
+
+   The terms used in this document are defined elsewhere in various
+   documents.  In particular, readers are suggested to review Section 3
+   of [RFC4423] for a listing of HIP-specific terminology.
+
+1.3.  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
+   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, what 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 period of time when the bulk of this report was drafted
+   (2004-2009), several research projects and open source software
+   projects were formed to study HIP.  These projects have been
+   developing software enabling HIP to be interoperable 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 HIP that went
+   beyond the scope and charter of the IETF HIP working group and the
+   set of RFCs (RFC 5201-5206) initially published in April 2008.  Some
+   of this work (NAT traversal, certificate formats for HIP, legacy
+   application support, and a native sockets API for HIP) ultimately
+   flowed into the IETF HIP working group upon its recharter in 2008.
+   Other extensions (e.g., HIP in the Internet Indirection
+   Infrastructure (i3) overlay, use of distributed hash tables for HIT-
+   based (Host Identity Tag) 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 HIPs 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,
+
+
+
+Henderson & Gurtov            Informational                     [Page 4]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   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 issues:
+
+   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.
+
+   o  Changes to the HIP baseline architecture and protocol or other
+      identity-locator separation architectures.
+
+1.4.  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, Access Control Lists (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.
+
+
+
+
+
+
+Henderson & Gurtov            Informational                     [Page 5]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   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.
+
+2.  Host Stack Implications
+
+   HIP is primarily an extension to the TCP/IP stack of Internet hosts,
+   and, in this section, we summarize some experiences that several
+   implementation groups have encountered in developing this extension.
+   Our discussion here draws on experience of implementers in adding HIP
+   to general-purpose computing platforms such as laptops, desktops,
+   servers, and PDAs.  There are two primary ways to support HIP on such
+   an end host.  The first is to make changes to the kernel
+   implementation to directly support the decoupling of identifier and
+   locator.  Although this type of modification has data throughput
+   performance benefits, it is also the more challenging to deploy.  The
+   second approach is to implement all HIP processing in the user-space
+   and configure the kernel to route packets through user-space for HIP
+   processing.
+
+   The following public HIP implementations are known and actively
+   maintained:
+
+   o  HIP4BSD (http://www.hip4inter.net) -- FreeBSD kernel modifications
+      and user-space keying daemon;
+
+   o  HIPL (http://hipl.hiit.fi) -- Linux kernel and user-space
+      implementation;
+
+   o  OpenHIP (http://www.openhip.org) -- User-space keying daemon and
+      packet processing for Linux, Windows XP/Vista/7, 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.
+
+
+
+
+
+
+Henderson & Gurtov            Informational                     [Page 6]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   A HIP implementation typically consists of a key management process
+   that coordinates with an IPsec-extended stack, as shown in Figure 1.
+   In practice, HIP has been implemented entirely in the user-space,
+   entirely in the kernel, or as a hybrid with a user-space key
+   management process and a kernel-level ESP.
+
+    +--------------------+                       +--------------------+
+    |                    |                       |                    |
+    |                    |                       |                    |
+    |   +------------+   |                       |   +------------+   |
+    |   |    Key     |   |         HIP           |   |    Key     |   |
+    |   | Management | <-+-----------------------+-> | Management |   |
+    |   |  Process   |   |                       |   |  Process   |   |
+    |   +------------+   |                       |   +------------+   |
+    |         ^          |                       |         ^          |
+    |         |          |                       |         |          |
+    |         v          |                       |         v          |
+    |   +------------+   |                       |   +------------+   |
+    |   |   IPsec-   |   |        ESP            |   |   IPsec-   |   |
+    |   |  Extended  |   |                       |   |  Extended  |   |
+    |   |   Stack    | <-+-----------------------+-> |   Stack    |   |
+    |   |            |   |                       |   |            |   |
+    |   +------------+   |                       |   +------------+   |
+    |                    |                       |                    |
+    |                    |                       |                    |
+    |     Initiator      |                       |     Responder      |
+    +--------------------+                       +--------------------+
+
+                      Figure 1: HIP Deployment Model
+
+   Figure 2 summarizes the main implementation impact of supporting HIP,
+   and is discussed further in subsequent sections.  To enable HIP
+   natively in an implementation requires extensions to the key
+   management interface (here depicted as PF_KEY API [RFC2367]) with the
+   security association database (SAD) and security policy database
+   (SPD).  It also requires changes to the ESP implementation itself to
+   support BEET-mode (Bound End-to-End Tunnel) processing [BEET-MODE],
+   extensions to the name resolution library, and (in the future)
+   interactions with transport protocols to respond correctly to
+   mobility and multihoming events [TCP-RLCI].
+
+
+
+
+
+
+
+
+
+
+
+Henderson & Gurtov            Informational                     [Page 7]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+                  |-----------------------|
+    --------      |   ----------     ----------
+    | 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) sockets 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 from LSIs and HITs to the 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 adopted to vanilla Linux and FreeBSD kernels.
+
+   The HIPL project has contributed an IPsec BEET patch for the Linux
+   kernel.  The kernel-level support could potentially allow all Linux
+   implementations of HIP to run in the user-space and use a common
+   interface towards the kernel.
+
+
+
+
+
+
+Henderson & Gurtov            Informational                     [Page 8]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   One inconvenience experienced in current Linux IPsec implementation
+   (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 the 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 and binary
+   packages (RPMs, DEBs, self-extracting installers) typical of
+   application deployment on the target systems.
+
+   When HIP is deployed in the user-space, some technique is necessary
+   to identify packets that require HIP processing and divert them to
+   the 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
+   network tap (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 the UDP header is applied, an outer IP address
+   replaces the HIT, and the packet is re-sent to the kernel.  In the
+   reverse direction, a socket associated to ESP or a UDP port number
+   may be used to receive ESP-protected packets.  HIP signaling packets
+   themselves may be sent and received by a raw socket bound to the HIP
+   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 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 (RFC 5201, Section
+
+
+
+Henderson & Gurtov            Informational                     [Page 9]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   4.1.6), 2) storing HITs in DNS AAAA entries and looking them up by
+   domain name, 3) name resolution service for HITs such as OpenDHT
+   [RFC6537], 4) an ad hoc HIT exchange service to populate files on
+   each machine, or 5) support for DNS extensions described in RFC 5205.
+
+   Over time, support for these techniques has varied.  The HIPL project
+   has experimented with all of them.  OpenHIP lacks support for option
+   2, and HIP4BSD lacks support for options 1 and 3.
+
+   Implementing opportunistic HIP mode 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.  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 approach 4 when a shell script based on
+   Secure SHell (SSH) and Secure Copy (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.  HIPL
+   developers have had positive experiences with alternative 5.
+
+2.3.2.  Opportunistic Mode
+
+   In opportunistic mode, the Initiator starts a base exchange without
+   knowledge of the Responder's HIT.  The main advantage of the
+   opportunistic mode is that it does not require additional lookup
+   infrastructure for HIs [RFC5205] [RFC6537].
+
+   The opportunistic mode also has a few disadvantages.  First, the
+   Initiator may not identify the Responder uniquely just based on the
+   IP address in the presence of private address realms [RFC5770].
+   Second, the Initiator has to settle for a "leap of faith"; that is,
+   assume there is no man-in-the-middle attack.  However, this can be
+   partially mitigated by using certificates at the Responder side
+   [RFC6253] or by prompting the user using a graphical interface to
+   explicitly accept the connection [paper.usable-security].
+
+   The opportunistic mode requires only minor changes in the state
+   machine of the Responder and small changes for the Initiator
+   [paper.leap-of-faith].  While the Responder can just select a
+   suitable HIT upon receiving the first HIP base exchange packet (known
+   as an "I1") without a predefined HIT for the Responder, the Initiator
+   should be more careful in processing the first packet from the
+   Responder, known as the "R1".  For example, the Initiator should make
+   sure that it can disambiguate simultaneously initiated opportunistic
+   base exchanges from each other.
+
+
+
+
+Henderson & Gurtov            Informational                    [Page 10]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   In the context of the HIPL project, the opportunistic mode has been
+   successfully applied at the HIP layer for service registration
+   [RFC5203].  HIP4BSD implemented opportunistic mode successfully with
+   small modifications to the FreeBSD socket layer to support
+   opportunistic mode.  However, the Linux implementation was more
+   challenging, as described below.
+
+   The HIPL project experimented with opportunistic mode by interposing
+   a shim at two different layers.  In the first approach, an API-based
+   shim was implemented to capture socket calls from the application.
+   This was somewhat complicated to implement and explicitly enabling an
+   individual application (or groups of applications) to use the
+   opportunistic mode was required.  In the second approach
+   [paper.leap-of-faith], the shim was placed between the network and
+   transport layers.  Upon successful base exchange, the shim translated
+   IP-based packet flows to HIT-based packet flows by re-injecting the
+   translated packets back to the networking stack.
+
+   Unless bypassed for DNS, both of the opportunistic mode
+   implementation approaches in HIPL subjected the application(s) to
+   undergo opportunistic mode procedures also for DNS requests.  Both
+   approaches also implemented an optional "fall back" to non-HIP base
+   connectivity if the peer did not support HIP.  The detection of peer
+   support for HIP was based on timeouts.  To avoid timeouts completely
+   and to reduce the delay to a single Round-Trip Time (RTT) for TCP,
+   the project also experimented with TCP-specific extensions
+   [thesis.bishaj].
+
+   The OpenHIP project experimented with opportunistic mode through the
+   use of an opportunistic (-o) option.  For the Responder, this option
+   determines whether or not HIP accepts I1s received with a zeroed
+   receiver's HIT.  On the Initiator's side, this option allows one to
+   configure a name and LSI in the known Host Identities file.  When the
+   HIT field is missing, an I1 is sent with a zeroed receiver's HIT.
+   The LSI is needed by an IPv4 application to trigger the association.
+   Note that, normally, the LSI used is based on the bottom 24 bits of
+   the HIT, but in the case of opportunistic mode, the HIT is unknown;
+   thus, the LSI may differ from the HIT.
+
+   As a summary of the opportunistic mode experimentation, it is
+   possibly best suited for HIP-aware applications.  Either it can be
+   used by HIP itself in registration extensions or by native HIP
+   applications [RFC6317].  This way, the inherent security trade-offs
+   of the opportunistic mode are explicitly visible to the user through
+   the HIP-aware application.
+
+
+
+
+
+
+Henderson & Gurtov            Informational                    [Page 11]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+2.3.3.  Resolving HITs to Addresses
+
+   When HIP is used in opportunistic mode, the Initiator does not know
+   the Responder's HIT, but it does know its IP address.  In most other
+   cases, however, the kernel or applications may know the HITs and not
+   the IP addresses; in these cases, 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 [HIT2IP].  Third, the need for resolution
+   may trigger some type of HIP bootstrap message, similar in some sense
+   to an Address Resolution Protocol (ARP) message (to resolve the HIT).
+   The bootstrap (BOS) packet used to be present in the early revisions
+   of the HIP base specifications, but it was removed from the final
+   specifications due to insufficient interest at the time.  The HIPL
+   implementation currently sends an I1 to a link broadcast IP address
+   if it doesn't know the IP address of the peer.  It has triggered
+   warnings in some Windows hosts running antivirus software that
+   classified broadcasts with unknown protocol number as intrusion
+   attempts.  The utility of this technique is limited to the local
+   link.
+
+2.3.4.  IPsec Management API Extensions
+
+   A generic key management API for IP security is known as PF_KEY API
+   [RFC2367].  PK_KEY is a socket protocol family that can be used by
+   trusted applications to access the IPsec key engine in the operating
+   system.  Users of this interface typically need sysadmin privileges.
+
+   HIP-related extensions to the PF_KEY interface define a new protocol
+   IPPROTO_HIP.  Their main functionality is replacing the TCP and UDP
+   checksum with a HIP-compatible checksum (because the transport
+   pseudoheader is based on HITs) in incoming and outgoing packets.
+   Recent Linux kernel versions do not require patching for these
+   extensions.
+
+2.3.5.  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 in TCP timeout [RFC6298]
+   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
+
+
+
+Henderson & Gurtov            Informational                    [Page 12]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   buffering of the packet.  On the other hand, if the HIP base exchange
+   or UPDATE 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,
+   dropping the original or retransmitted duplicate packet.
+
+   The multihoming support in [RFC5206] is intended for the purpose of
+   failover, when a host starts using an alternative locator when a
+   current locator fails.  However, a host could used this multihoming
+   support for load balancing across different locators.  Multihoming in
+   this manner could potentially cause issues with transport protocol
+   congestion control and loss detection mechanisms.  However, no
+   experimental results from using HIP multihoming in this capacity have
+   been reported.
+
+   The use of paths with different characteristics can also impact the
+   estimate of a retransmission timer at the sender's transport layer.
+   TCP uses a smoothed average of the path's Round-Trip Time and its
+   variation as the estimate for a retransmission timeout.  After the
+   retransmission timer expires, the sender retransmits all outstanding
+   packets in go-back-N fashion.
+
+   When multihoming is used for simultaneous data transmission from
+   several locators, there can easily be scenarios when the
+   retransmission timeout does not correspond to the actual value.  When
+   packets simply experience different RTT, its variation is high, which
+   sets the retransmission timeout value unnecessarily high.  When
+   packets are lost, the sender waits excessively long before
+   retransmitting.  Fortunately, modern TCP implementations deploying
+   Selective Acknowledgments (SACKs) 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 the 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
+
+
+
+Henderson & Gurtov            Informational                    [Page 13]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   inform the transport layer of mobility events.  Protocols to support
+   such notifications to the transport layer have been proposed to the
+   IETF in the past, including transport triggers [TRIGTRAN],
+   lightweight mobility detection and response (LMDR) [LMDR], and TCP
+   response to connectivity change [TCP-RLCI].
+
+2.3.6.  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 Interactive
+   Connectivity Establishment (ICE) techniques [RFC5770] for inbound NAT
+   traversal.  It has also been reported that the use of Teredo
+   [RFC4380] over HIP was simpler than the modifications required for
+   ICE techniques because Teredo effectively manifests itself as a
+   routable, virtual locator to the system.  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.  In addition, the initial implementations of NAT
+   traversal for HIP based on ICE techniques proved to be complicated to
+   implement or integrate, and a native NAT traversal mode is now under
+   development for HIP [NAT-TRAVERSAL].  NAT traversal is expected to be
+   a major mode of HIP operation in the future.
+
+2.3.7.  Local Management of Host Identity Namespace
+
+   One issue not being addressed by some experimental implementations is
+   how to perform source HIT selection across possibly multiple host
+   identities (some may be unpublished).  This is akin to source address
+   selection for transport sockets.  How much HIP policy to expose to
+   users is a user interface issue.  Default or automatic configuration
+   guesses might have undesirable privacy implications for the user.
+
+   Helsinki University of Technology (TKK, now Aalto) has implemented an
+   extension of the native HIP API to control multiple host identities
+   [thesis.karlsson].  A problem with Linux routing and multiple
+   identities was discovered by the HIPL development group.  As Linux
+   routing is based on longest prefix match, having multiple HITs on
+   virtual devices is problematic from the viewpoint of access control
+   because the stack selects the source HIT based on the destination
+   HIT.  A coarse-grained solution for this is to terminate the longest
+   prefix match for ORCHIDs in the Linux networking statck.  However, a
+   more fine-grained solution tries to return a source HIT matching to
+   the algorithm used for generating the destination HIT in order to
+   facilitate compatibility with new algorithms standardized in the
+   future.
+
+
+
+
+
+Henderson & Gurtov            Informational                    [Page 14]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   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 a set-user-id flag.  Keys may be stored on a trusted platform
+   module (TPM), but there are no reported HIP experiments with such a
+   configuration.  In a Boeing pilot project, temporary certificates
+   were 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 [RFC6253].  Another option is encrypting keys on disks
+   and keeping a passkey in memory (like in Secure Socket Layer (SSL)
+   certificates on servers, that ask for a password when booting Linux).
+
+2.3.8.  Interactions with Host Firewalls
+
+   HIP is presently an experimental protocol, and some default firewall
+   configuration scripts on popular Linux distributions do not permit
+   the HIP number.  Determining which rules to modify without
+   compromising other policies can be tricky; the default rule set on a
+   previous SuSE Linux distribution was discovered to contain over one
+   hundred rules.  Moreover, it may be the case that the end user has no
+   control over the firewall settings, if administered by an enterprise
+   IT department.  However, the use of HIP over UDP has alleviated some
+   of these concerns.  When using HIP over UDP, the firewall needs to
+   allow outbound UDP packets and responses to them.
+
+2.4.  IPv4 versus IPv6 Issues
+
+   HIP has been oriented towards IPv6 deployment, but all
+   implementations have also added support for IPv4.  HIP supports IPv6
+   applications well, as the HITs are used from the general IPv6 address
+   space using the ORCHID prefix.  HITs are statistically unique,
+   although they 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 or broadcast technique is available to
+   route packets based on HITs.
+
+   For IPv4 applications, a 32-bit Local Scope Identifier (LSI) is
+   necessary at the sockets API.  The LSI is an alias for a host
+   identity and is only meaningful within one host.  Note that an IPv4
+   address may be used as an LSI if it is configured to refer to a
+   particular host identity on a given host, or LSIs may be drawn from
+   an unallocated IPv4 address range, but lack of coordination on the
+   LSI space may hinder implementation portability.
+
+
+
+
+
+
+Henderson & Gurtov            Informational                    [Page 15]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   HIP makes it possible to use IPv6 applications over the IPv4 network
+   and vice versa.  This has been called "interfamily operation"
+   (flexibility between different address families) and is enabled by
+   the fact that the transport pseudoheader is always based on HITs
+   regardless of whether the application or the underlying network path
+   is based on IPv4.  All three open source HIP implementations have
+   demonstrated some form of interfamily handoff support.  The
+   interfamily portion of the BEET patch in the Linux kernel was found
+   more difficult to complete compared with the single-family
+   processing.
+
+   HIP also provides the potential to perform cross-family support,
+   whereby one side of a transport session is IPv6 based and another is
+   IPv4 based [paper.handovers].
+
+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 a kernel versus user-space HIP
+   implementations in terms of performance and DoS resilience would be
+   useful.  If the kernel implementation is shown to perform
+   significantly better than the user-space 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.
+
+   Although the HIPL kernel-based keying implementation was submitted to
+   the Linux kernel development process, the implementation was not
+   accepted.  The kernel developers felt that since Mobile IP (MIP) and
+   the Internet Key Exchange Protocol (IKE) are implemented as user-
+   space signaling daemons in Linux, that should be the approach for
+   HIP, too.  Furthermore, the kernel patch was somewhat big, affecting
+   the kernel in many places and having several databases.  The Linux
+   kernel maintainers did eventually accept the BEET patch.
+
+   Some users have been explicitly asking about the coexistence of HIP
+   with other VPN and Mobile IP software.  On Windows, VPN clients tend
+   to install their own versions of TAP drivers that might conflict with
+   the driver used by the OpenHIP implementation.  There may also be
+   issues due to lack of coordination leading to unintended HIP-over-VPN
+   sessions or lack of coordination of the ESP Security Parameter Index
+   (SPI) space.  However, these types of conflicts are only speculation
+
+
+
+
+
+Henderson & Gurtov            Informational                    [Page 16]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   and were not reported to the research group; only some positive
+   reports of HIP and VPN software properly coexisting have been
+   reported by the HIPL group.
+
+   With legacy applications, LSI support is important because IPv6 is
+   not widely used in applications.  The main issues in getting
+   applications to work well over HIP have been related to bugs in the
+   implementations themselves, or latency related issues (such as TCP
+   timeouts due to Linux IPsec implementation).  There have been no
+   major obstacles encountered in practice, and there has also been some
+   experience in using HIP with native applications [paper.p2psip].
+
+3.  Infrastructure Implications
+
+   This section focuses on the deployment of infrastructure to support
+   HIP hosts.
+
+3.1.  Impact on DNS
+
+   HIP DNS extensions [RFC5205] were developed by NEC Eurolabs and
+   contributed to OpenHIP and were also developed by the HIPL project,
+   both for the BIND9 DNS server.  Legacy applications do not query for
+   HIP resource records, but DNS proxies (local resolvers) interpose
+   themselves in the resolution path and can query for HI records.  The
+   BIND 9 deployment for HIPL uses binary blob format to store the HIP
+   resource records; this means that no changes to the DNS server are
+   required.
+
+   There have been no studies reported on the impact of changes based on
+   [RFC5205] to HIP on the existing DNS.  There have been some studies
+   on using DNS to store HITs in the reverse tree [HIT2IP].
+
+3.2.  HIP-Aware Middleboxes
+
+   A design of a HIP registration protocol for architectured NATs (NATs
+   that are HIP aware and use HIP identifiers to distinguish between
+   hosts) has been completed and published as RFC 5204.  Performance
+   measurement results with a prototype are available, but
+   experimentation on a wide scale is still missing.  RFC 5207 provides
+   a problem statement for HIP-aware NATs and middleboxes [RFC5207].
+
+   As argued by Aura, et al. [paper.hipanalysis], the encryption of the
+   Initiator Host Identity (HI) prevents policy-based NAT and firewall
+   support, and middlebox authentication, for HIP.  The catch is that
+   when the HI is encrypted, middleboxes in the network cannot verify
+   the signature of the second base exchange packet from the Initiator
+
+
+
+
+
+Henderson & Gurtov            Informational                    [Page 17]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   (I2) and, thus, cannot safely create a state for the HIP association.
+   On the other hand, if the HI is not encrypted, a stateful middlebox
+   can process the I2 and create protocol state for the session.
+
+3.3.  HIT Resolution Infrastructure
+
+   OpenDHT HIT-to-IP address resolution has been implemented by Aalborg
+   University, Denmark, Helsinki Institute for Information Technology
+   for HIPL, and by Boeing for OpenHIP [RFC6537].
+
+   The prototype of the Host Identity Indirection Infrastructure (Hi3)
+   has been implemented using OpenHIP and HIPL.  A set of 25 i3 servers
+   was running on PlanetLab for several years.  While a PlanetLab
+   account is required to run the servers, anybody could openly use the
+   provided service.
+
+   The main idea of Hi3 is to transmit HIP control packets using the i3
+   system as a lookup and rendezvous service, while transmitting data
+   packets efficiently end-to-end using IPsec.  Performance measurements
+   were conducted comparing the association setup latency, throughput,
+   and RTT of Hi3 with plain IP, HIP, and i3 [paper.hi3].
+
+   One difficulty has been with debugging the i3 system.  In some cases,
+   the messages did not traverse i3 correctly, due to its distributed
+   nature and lack of tracing tools.  Making the system work has been
+   challenging.  Further, since the original research work was done, the
+   i3 servers have gone offline.
+
+   NATs and firewalls have been a major disturbance in Hi3 experiments.
+   Many networks did not allow incoming UDP packets to go through,
+   therefore, preventing messages from i3 servers to reach the client.
+
+   So far, the Hi3 system has been evaluated on a larger scale only
+   analytically.  The problem is that running a larger number of clients
+   to create a sufficient load for the server is difficult.  A cluster
+   on the order of a hundred Linux servers is needed for this purpose.
+   Contacts to a State Supercomputer Centre in Finland have not been
+   successful so far.  A possible option is to use one of the 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, and an implementation also exists for OpenHIP.  The concept has
+   been extended to a relay server in [RFC5770].  Initial
+   experimentation with the HIPL implementation produced the following
+   observations:
+
+
+
+
+Henderson & Gurtov            Informational                    [Page 18]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   o  RVS may be better than dynamic DNS updates for hosts that change
+      their address rapidly.
+
+   o  Registration of a HIP host to RVS costs a base exchange.
+
+   o  UPDATE and CLOSE packets sent through rendezvous servers is
+      advised; RVS handling of UPDATE messages can typically solve the
+      double jump [MULTI-HOMED] mobility problem.
+
+   The following advanced concepts need further study:
+
+   o  Multiple RVSs per host for fault tolerance (e.g., one rendezvous
+      node crashes) and an algorithm for selecting the best RVS.
+
+   o  Load balancing.  An 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.
+
+3.5.  Hybrid DNS-DHT Resolution
+
+   In addition to pure DNS and pure DHT HIP name resolution, a hybrid
+   approach combining the standard DNS interface for clients with last-
+   hop DHT resolution was developed.  The idea is that the benefits of
+   DNS solution (wide deployment, support for legacy applications) could
+   be combined with advantages of DHT (fault tolerance, efficiency in
+   handling flat data keys).  The DHT is typically run internally by the
+   organization managing the last-hop DNS zone and the DNS server.  That
+   way, the HITs belonging to that organization could be stored locally
+   by the organization that improves deployability of the resolution
+   system.  However, organizations could also share a DHT between
+   themselves or connect their DNS servers to a publicly available DHT,
+   such as OpenDHT.  The benefit of running a DHT on a local server
+   cluster compared to a geographically spread DHT is higher performance
+   due to decreased internal DHT latencies.
+
+   The system was prototyped by modifying the BIND DNS server to
+   redirect the queries for HITs to a DHT server.  The interface was
+   implemented in XML according to specifications [RFC6537].  The system
+   is completely backward compatible to legacy applications since the
+   standard DNS resolver interface is used.
+
+   Performance of the system was evaluated by performing a rapid
+   sequence of requests for querying and updating the HIT-to-IP address
+   mapping.  The request rate was varied from 1 to 200 requests per
+   second.  The average latency of one query request was less than 50 ms
+   and the secured updated latency less than 100 ms with a low request
+
+
+
+Henderson & Gurtov            Informational                    [Page 19]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   rate.  However, the delay was increasing exponentially with the
+   request rate, reaching 1 second for 200 requests per second (update
+   rate 0) and almost 2 seconds (update rate 0.5).  Furthermore, the
+   maximum delay exceeded the mean by several times.
+
+   Based on experiments, a multi-processor system could handle more than
+   1000 queries per second.  The latencies are dominated by the DHT
+   resolution delay, and the DNS component is rather small.  This is
+   explained by the relative inefficiency of used DHT implementation
+   (Bamboo) and could be definitely improved in the future.
+
+4.  Application Implications
+
+   In a deployed HIP environment, applications may be HIP aware or HIP
+   unaware.  RFC 5338 [RFC5338] describes various techniques to allow
+   HIP to support unmodified applications.  Some additional application
+   considerations are listed below.
+
+4.1.  Non-Intrusive HIP Insertion
+
+   One way to support legacy applications that use dynamic linking is to
+   dynamically interpose a modified resolver library.  Using HIPL,
+   several legacy applications were shown to work without changes using
+   dynamic re-linking of the resolver library.  For example, the Firefox
+   web browser successfully worked with an Apache web server.  The re-
+   linking just requires configuring an LD_PRELOAD system variable that
+   can be performed in a user shell profile file or as a start-up
+   wrapper for an application.  This provides the user with fine-grained
+   policy control over which applications use HIP, which could
+   alternately be considered a benefit or a drawback depending on
+   whether the user is burdened with such policy choices.  The technique
+   was also found to be sensitive to loading LD_PRELOAD twice, in which
+   case the order of linking dynamic libraries must be coded carefully.
+
+   Another method for transparently using HIP, which has no reported
+   implementation experience, is via local application proxies (e.g.,
+   squid web proxy) that are modified to be HIP aware.  Discussion of
+   proxies for HIP is a current focus of research group activities
+   [HIPRG-PROXIES].
+
+4.2.  Referrals
+
+   A concern that FTP would not work due to the problem of application
+   referrals, i.e., passing the IP address within application messages,
+   was discovered not to be a problem for FTP in practice.  It is shown
+   to work well both in the passive and active modes [paper.namespace].
+   It remains an open question how big problem referrals really are in
+
+
+
+
+Henderson & Gurtov            Informational                    [Page 20]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   the practice.  At least, they do not seem used for the client side
+   because they are behind NATs, and, therefore, client addresses are
+   unsuitable as referrals.
+
+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.
+
+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
+   [HIP-OPERATORS].
+
+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
+   into its own AAA databases and network firewalls.  This way, the
+   users would not need to be concerned with technical details of host
+   identity management.
+
+   The operator may use a Public Key Infrastructure (PKI) to certify
+   host identities of its customers.  Then, it uses the private key of
+   an operator's Certificate Authority (CA) to sign the public key of
+   its customers.  This way, third parties possessing the public key of
+   the CA can verify the customer's host identity and use this
+   information, e.g., for admission control to infrastructure.  Such
+   practice raises the security level of HIP when self-generated host
+   identities are used.
+
+   When the operator is using neither PKI nor DNS Security (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.
+
+
+
+
+
+Henderson & Gurtov            Informational                    [Page 21]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   For instance, the signaling provided by SIP could be used to deliver
+   host identities if it were secured by existing mechanisms in the
+   operator's network.
+
+5.2.  Use of ESP Encryption
+
+   The research group has discussed whether operators can provide
+   "value-added" services and priority, and comply with wiretapping
+   laws, if all sessions are encrypted.  This is not so much a HIP issue
+   as a general end-to-end encryption issue.
+
+   The processing power of mobile devices also must be considered.  One
+   study evaluated the use of HIP and ESP on lightweight devices (Nokia
+   N770 Internet Tablets having 200 MHz processors) [paper.mobiarch].
+   The overhead of using ESP on such a platform was found to be
+   tolerable, 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.
+   A lightweight HIP base exchange for this purpose is being developed
+   at the time of this writing [HIP-DEX].
+
+   It is also possible to use HIP in a NULL encryption configuration if
+   one of SHA1 or MD5 authentication are used.
+
+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 ACLs to be protected based on packet
+   exchanges that may be authenticated by middleboxes.  However, HITs
+   are not aggregatable, so HIT-based ACLs may be longer in length (due
+   to an inability to group hosts with a single entry) and harder to
+   deal with by human users (due to the length of the HIT compared with
+   an IPv4 or IPv6 prefix).
+
+   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 non-repudiation purposes.
+
+
+
+
+Henderson & Gurtov            Informational                    [Page 22]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+5.4.  Firewall Issues
+
+   Helsinki University of Technology (TKK, now Aalto) has implemented a
+   HIP firewall based on Linux iptables [paper.firewall] that operates
+   in user-space.
+
+   In general, firewalls can be stateless, filtering packets based only
+   on the ACL, and stateful, following and remembering packet flows.
+   Stateless firewalls are simple to implement but provide only coarse-
+   grained protection.  However, their performance can be efficient
+   since packet processing requires little memory or CPU resources.  A
+   stateful firewall determines if a packet belongs to an existing flow
+   or starts a new flow.  A flow identifier combines information from
+   several protocol headers to classify packets.  A firewall removes the
+   state when the flow terminates (e.g., a TCP connection is closed) or
+   after a timeout.  A firewall can drop suspicious packets that fail a
+   checksum or contain sequence numbers outside of the current sliding
+   window.
+
+   A transparent firewall does not require that hosts within the
+   protected network register or even know of the existence of the
+   firewall.  An explicit firewall requires registration and
+   authentication of the hosts.
+
+   A HIP-aware firewall operating in the middle 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 subsequent
+   IPsec ESP data packets.  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 host changes its
+   location and the IP address, the firewall, if still on the path,
+   learns about the changes by following the mobility update packets.
+
+   It is possible to implement a stateless, end-host-based firewall to
+   reuse existing higher-layer mechanisms such as access control lists
+   in the system.  In this mode of operation, HITs would be used in the
+   access control lists, and while the base exchange might complete, ESP
+   is not passed to the transport layer unless the HITs are allowed in
+   the access control list.
+
+   A HIP host can register to an explicit firewall using the usual
+   procedure [RFC5203].  The registration enables the host and the
+   firewall to authenticate each other.  In a common case, where the
+   Initiator and Responder hosts are located behind different firewalls,
+   the Initiator may need to first register with its own firewall, and
+   afterward, with the Responder's firewall.
+
+
+
+
+Henderson & Gurtov            Informational                    [Page 23]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   Some researchers have suggested that a firewall for security-critical
+   environments should get involved in the base exchange and UPDATE
+   procedures with middlebox-injected echo requests.  Otherwise, the
+   firewall can be circumvented with replay attacks if there is a
+   compromised node within the network that the firewall is trying to
+   protect [HIP-MIDDLE].
+
+6.  User Privacy Issues
+
+   Using public keys for identifying hosts creates a privacy problem as
+   third parties can determine the source host even if attached to a
+   different location in the network.  Various transactions of the host
+   could be linked together if the host uses the same public key.
+   Furthermore, using a static IP address also allows linking of
+   transactions of the host.  Multiplexing multiple hosts behind a
+   single NAT or using short address leases from DHCP can reduce the
+   problem of user tracking.  However, IPv6 addresses could reduce the
+   occurrence of NAT translation and cause additional privacy issues
+   related to the use of Media Access Control (MAC) addresses in IPv6
+   address autoconfiguration.  HIP does provide for the use of anonymous
+   (unpublished) HITs in cases in which the Initiator prefers to remain
+   anonymous, but the Responder must be willing to accept sessions from
+   anonymous peers.
+
+   With mutual authentication, the HIP Initiator should not have to
+   reveal its identity (public key) to either a passive adversary or an
+   active attacker.  The HIP Initiator can authenticate the Responder's
+   R1 packet before encrypting its host identity with the Diffie-
+   Hellman-generated keying material and sending it in the I2 packet.
+   The authentication step upon receiving an R1 defeats the active
+   attacker (impersonator) of the Responder, and the act of encrypting
+   the identity defeats the passive adversary.  Since the Responder
+   sends its public key unencrypted in the first reply message (R1) to
+   the Initiator, the Responder's identity will be revealed to third-
+   party on-path eavesdroppers.  However, if the Responder authenticates
+   the Initiator and performs access controls before sending the R1, the
+   Responder can avoid disclosing its public key to an active attacker.
+
+   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]
+   [HIP-PRIVACY].  The identity protection is achieved by hiding the
+   actual public keys from third parties so that only the trusted 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
+
+
+
+Henderson & Gurtov            Informational                    [Page 24]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   also reduces the issue of location privacy shifting the focus to
+   protecting host identifiers from third parties.  This approach is, by
+   its very nature, incompatible with middlebox authentication.
+
+   To prevent revealing the identity, the host public key and its hash
+   (HIT) can be encrypted with a secret key known beforehand to both
+   Initiator and Responder.  However, this is a requirement that cannot
+   be easily implemented in practice.  The BLIND framework provides
+   protection from active and passive attackers using a modified HIP
+   base exchange.  If the host avoids storing its public keys in the
+   reverse DNS or DHT repository, the framework achieves full location
+   and identity privacy.
+
+   An alternative approach to reducing privacy threats of persistent
+   identifiers is to replace them with short-lived identifiers that are
+   changed regularly to prevent user tracking.  Furthermore, identifiers
+   must be changed simultaneously at all protocol layers; otherwise, an
+   adversary could still link the new identifier by looking at an
+   identifier at another protocol layer that remained the same after the
+   change.  The HIP privacy architecture that simultaneously changes
+   identifiers on MAC, IP, and HIP/IPsec layers was developed at
+   Helsinki University of Technology (TKK, now Aalto) [thesis.takkinen].
+   HIP could be extended in the future to allow active sessions to
+   migrate identities.
+
+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 [HIPLS].  This use case is not a traditional end-
+   host-based use of HIP, but rather, it is one that uses HIP-aware
+   middleboxes to create ESP tunnels on-demand between provider-edge
+   (PE) devices.
+
+   The InfraHIP II project is deploying HIP infrastructure (test
+   servers, rendezvous and relay servers) in the public Internet.
+
+   The following is a possibly incomplete list of past and current
+   research activities related to HIP.
+
+   o  Boeing Research & Technology (J. Ahrenholz, O. Brewer, J. Fang, T.
+      Henderson, D. Mattes, J. Meegan, R. Paine, S. Venema, OpenHIP
+      implementation, Secure Mobile Architecture)
+
+
+
+Henderson & Gurtov            Informational                    [Page 25]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   o  NomadicLab, Ericsson (P. Jokela, P. Nikander, J. Melen.  BSD HIP
+      implementation)
+
+   o  Helsinki Institute for Information Technology (HIIT) (A. Gurtov,
+      M. Komu, A. Pathak, D. Beltrami.  HIPL, legacy NAT traversal,
+      firewall, i3, native API)
+
+   o  Helsinki University of Technology (TKK, now Aalto) (Janne
+      Lindqvist, Niklas Karlsson, Laura Takkinen, and Essi Vehmersalo.
+      HIP security and firewalls, multiple identities, and privacy
+      management)
+
+   o  University of California, Berkeley (A. 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  University of Hamburg-Harburg (M. Shanmugam, A. Nagarajan, HIP
+      registration protocol)
+
+   o  University 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)
+
+   o  Huawei (D. Zhang, X. Xu, hierarchical HIP architecture, HIP proxy,
+      key revocation)
+
+
+
+
+
+
+Henderson & Gurtov            Informational                    [Page 26]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+8.  Related Work on ID-Locator Split
+
+   This section briefly summarizes the related work on the 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 namespace is needed for the Internet has
+   been controversial.  The Namespace 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 [RFC6275] is one example that reuses an existing
+   namespace 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 have 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 is focusing on
+      specifications of one selected approach [RFC5533].  Shim6 uses the
+      approach of inserting a shim layer between the IP and the
+      transport layers that hides effects of changes in the set of
+      available addresses.  The applications are using one active
+      address that supports referrals.  Shim6 relies on
+      cryptographically generated IPv6 addresses to solve the address
+      ownership problem.  HIP and shim6 are architecturally similar and
+      use a common format for control packets.  HIP specifications
+      define only simple multihoming scenarios leaving such important
+      issues as interface selection untouched.  Shim6 offers
+      complementary functionality that can be reused in HIP [REAP4HIP].
+      The OpenHIP implementation integrates HIP and shim6 protocols in
+      the same framework, with the goal of allowing HIP to reuse the
+      shim6 failure detection protocol.  Furthermore, HIP and shim6
+      socket APIs have been jointly designed [RFC6317] [RFC6316].
+
+
+
+
+Henderson & Gurtov            Informational                    [Page 27]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   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 [LISP] and Six/One Router
+      [SIX-ONE] and those advocating a fuller separation of these roles
+      including ILNP [ILNP] and RANGI [RANGI].
+
+   o  The End-Middle-End research group considered the potential for an
+      explicit signaling and policy control plane for middleboxes and
+      endpoints [EME]; at a joint meeting at IETF 69, the HIP and EME
+      research groups discussed whether the EME framework could help HIP
+      with middlebox traversal.
+
+   o  The IETF Multipath TCP working group is developing mechanisms to
+      simultaneously use multiple paths in a regular TCP session.  The
+      MPTCP solution aims to solve the multihoming problem also
+      addressed by HIP but by solving it for TCP specifically.
+
+   o  The Unmanaged Internet Protocol bears several similarities to the
+      HIP architecture, such as the focus on identifiers that are not
+      centrally managed that are also based on a cryptographic hash of a
+      node's public key [thesis.ford].
+
+   o  Apple Back To My Mac service provides secure connections between
+      hosts using IPsec between a pair of host identifiers.  However,
+      the host identifier is reported to be an IPv6 Unique Local
+      Addressing (ULA) address rather than a HIP identifier [RFC6281].
+
+   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 [MOBILITY-COMPARISON].
+
+9.  Security Considerations
+
+   This document is an informational survey of HIP-related research and
+   experience.  Space precludes a full accounting of all security issues
+   associated with the approaches surveyed here, but the individually
+   referenced documents may discuss security considerations for their
+   respective protocol component.  HIP security considerations for the
+   base HIP protocol can be found in Section 8 of [RFC5201].
+
+
+
+
+
+
+
+
+
+Henderson & Gurtov            Informational                    [Page 28]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+10.  Acknowledgments
+
+   Miika Komu, Pekka Nikander, Ari Keranen, and Jeff Ahrenholz have
+   provided helpful comments on earlier draft versions of this document.
+   Miika Komu also contributed the section on opportunistic mode.  We
+   also thank Dacheng Zhang for contributions on hierarchical HIP
+   architectures and the Crypto Forum Research Group (Adam Back and Paul
+   Hoffman) for clarification of Diffie-Hellman privacy properties.
+
+11.  Informative References
+
+   [BEET-MODE] Nikander, P. and J. Melen, "A Bound End-to-End Tunnel
+               (BEET) mode for ESP", Work in Progress, August 2008.
+
+   [EME]       Francis, P., Guha, S., Brim, S., and M. Shore, "An EME
+               Signaling Protocol Design", Work in Progress, April 2007.
+
+   [HIP-DEX]   Moskowitz, R., "HIP Diet EXchange (DEX)", Work
+               in Progress, March 2011.
+
+   [HIP-MIDDLE]
+               Hummen, R., Heer, T., Wehrle, K., and M. Komu, "End-Host
+               Authentication for HIP Middleboxes", Work in Progress,
+               October 2011.
+
+   [HIP-OPERATORS]
+               Dietz, T., Brunner, M., Papadoglou, N., Raptis, V., and
+               K.  Kypris, "Issues of HIP in an Operators Networks",
+               Work in Progress, October 2005.
+
+   [HIP-PRIVACY]
+               Zhang, D. and M. Komu, "An Extension of HIP Base Exchange
+               to Support Identity Privacy", Work in Progress,
+               July 2011.
+
+   [HIPLS]     Henderson, T., Venema, S., and D. Mattes, "HIP-based
+               Virtual Private LAN Service (HIPLS)", Work in Progress,
+               September 2011.
+
+   [HIPRG-PROXIES]
+               Zhang, D., Xu, X., Yao, J., and Z. Cao, "Investigation in
+               HIP Proxies", Work in Progress, October 2011.
+
+   [HIT2IP]    Ponomarev, O. and A. Gurtov, "Embedding Host Identity
+               Tags Data in DNS", Work in Progress, July 2009.
+
+
+
+
+
+
+Henderson & Gurtov            Informational                    [Page 29]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   [ILNP]      Atkinson, R., "ILNP Concept of Operations", Work
+               in Progress, July 2011.
+
+   [LISP]      Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
+               "Locator/ID Separation Protocol (LISP)", Work
+               in Progress, November 2011.
+
+   [LMDR]      Swami, Y., Le, K., and W. Eddy, "Lightweight Mobility
+               Detection and Response (LMDR) Algorithm for TCP", Work
+               in Progress, February 2006.
+
+   [MOBILITY-COMPARISON]
+               Thaler, D., "A Comparison of IP Mobility-Related
+               Protocols", Work in Progress, October 2006.
+
+   [MULTI-HOMED]
+               Huitema, C., "Multi-homed TCP", Work in Progress,
+               May 1995.
+
+   [NAT-TRAVERSAL]
+               Keranen, A. and J. Melen, "Native NAT Traversal Mode for
+               the Host Identity Protocol", Work in Progress,
+               January 2011.
+
+   [RANGI]     Xu, X., "Routing Architecture for the Next Generation
+               Internet (RANGI)", Work in Progress, August 2010.
+
+   [REAP4HIP]  Oliva, A. and M. Bagnulo, "Fault tolerance configurations
+               for HIP multihoming", Work in Progress, July 2007.
+
+   [RFC1498]   Saltzer, J., "On the Naming and Binding of Network
+               Destinations", RFC 1498, August 1993.
+
+   [RFC1992]  Castineyra, I., Chiappa, N., and M. Steenstrup, "The
+               Nimrod Routing Architecture", RFC 1992, August 1996.
+
+   [RFC2367]   McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
+               Management API, Version 2", RFC 2367, July 1998.
+
+   [RFC4303]   Kent, S., "IP Encapsulating Security Payload (ESP)",
+               RFC 4303, December 2005.
+
+   [RFC4380]   Huitema, C., "Teredo: Tunneling IPv6 over UDP through
+               Network Address Translations (NATs)", RFC 4380,
+               February 2006.
+
+
+
+
+
+
+Henderson & Gurtov            Informational                    [Page 30]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   [RFC4423]   Moskowitz, R. and P. Nikander, "Host Identity Protocol
+               (HIP) Architecture", RFC 4423, May 2006.
+
+   [RFC4843]   Nikander, P., Laganier, J., and F. Dupont, "An IPv6
+               Prefix for Overlay Routable Cryptographic Hash
+               Identifiers (ORCHID)", RFC 4843, April 2007.
+
+   [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.
+
+   [RFC5338]   Henderson, T., Nikander, P., and M. Komu, "Using the Host
+               Identity Protocol with Legacy Applications", RFC 5338,
+               September 2008.
+
+   [RFC5533]   Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
+               Shim Protocol for IPv6", RFC 5533, June 2009.
+
+   [RFC5770]   Komu, M., Henderson, T., Tschofenig, H., Melen, J., and
+               A.  Keranen, "Basic Host Identity Protocol (HIP)
+               Extensions for Traversal of Network Address Translators",
+               RFC 5770, April 2010.
+
+
+
+
+
+Henderson & Gurtov            Informational                    [Page 31]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   [RFC6253]   Heer, T. and S. Varjonen, "Host Identity Protocol
+               Certificates", RFC 6253, May 2011.
+
+   [RFC6275]   Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
+               Support in IPv6", RFC 6275, July 2011.
+
+   [RFC6281]   Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,
+               "Understanding Apple's Back to My Mac (BTMM) Service",
+               RFC 6281, June 2011.
+
+   [RFC6298]   Paxson, V., Allman, M., Chu, J., and M. Sargent,
+               "Computing TCP's Retransmission Timer", RFC 6298,
+               June 2011.
+
+   [RFC6316]   Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto,
+               "Sockets Application Program Interface (API) for
+               Multihoming Shim", RFC 6316, July 2011.
+
+   [RFC6317]   Komu, M. and T. Henderson, "Basic Socket Interface
+               Extensions for the Host Identity Protocol (HIP)",
+               RFC 6317, July 2011.
+
+   [RFC6537]   Ahrenholz, J., "Host Identity Protocol Distributed Hash
+               Table Interface", RFC 6537, February 2012.
+
+   [SIX-ONE]   Vogt, C., "Six/One: A Solution for Routing and Addressing
+               in IPv6", Work in Progress, October 2009.
+
+   [TCP-RLCI]  Schuetz, S., Koutsianas, N., Eggert, L., Eddy, W., Swami,
+               Y., and K. Le, "TCP Response to Lower-Layer Connectivity-
+               Change Indications", Work in Progress, February 2008.
+
+   [TRIGTRAN]  Dawkins, S., Williams, C., and A. Yegin, "Framework and
+               Requirements for TRIGTRAN", Work in Progress,
+               February 2003.
+
+   [book.gurtov]
+               Gurtov, A., "Host Identity Protocol (HIP): Towards the
+               Secure Mobile Internet", ISBN 978-0-470-99790-1, Wiley
+               and Sons, (Hardcover, p 332), June 2008.
+
+   [paper.blind]
+               Ylitalo, J. and P. Nikander, "BLIND: A complete identity
+               protection framework for end-points", Proc. of
+               the Twelfth International Workshop on Security Protoc
+               ols, April 2004.
+
+
+
+
+
+Henderson & Gurtov            Informational                    [Page 32]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   [paper.datarouter]
+               Touch, J. and V. Pingali, "DataRouter:  A Network-Layer
+               Service for Application-Layer Forwarding",  Proceedings
+               of International Workshop on Active Networks (IWAN),
+               May 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.firewall]
+               Lindqvist, J., Vehmersalo, E., Komu, M., and J. Manner,
+               "Enterprise Network Packet Filtering for Mobile
+               Cryptographic Identities", International Journal of
+               Handheld Computing Research (IJHCR), Volume 1, Issue
+               1, Pages 79-94, January 2010.
+
+   [paper.handovers]
+               Varjonen, S., Komu, M., and A. Gurtov, "Secure and
+               Efficient IPv4/IPv6 Handovers Using Host-Based
+               Identifier-Locator Split",  Proceedings of the 17th
+               International Conference  Software, Telecommunications,
+               and Computer Networks, September 2009.
+
+   [paper.hi3] Gurtov, A., Korzon, D., Lukyanenko, A., and P. Nikander,
+               "Hi3: An Efficient and Secure Networking Architecture for
+               Mobile Hosts", Computer communication, 31 (2008), p.
+               2457- 2467, <http://www.cs.helsinki.fi/u/gurtov/papers/
+               comcom_hi3.pdf>.
+
+   [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.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.
+
+
+
+
+
+Henderson & Gurtov            Informational                    [Page 33]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   [paper.leap-of-faith]
+               Komu, M. and J. Lindqvist, "Leap-of-faith security is
+               enough for IP mobility", Proceedings of the 6th IEEE
+               Conference on Consumer Communications and Networking
+               Conference (CCNC 09), 2009.
+
+   [paper.mobiarch]
+               Khurri, A., Vorobyeva, E., and A. Gurtov, "Performance of
+               Host Identity Protocol on Lightweight Hardware",
+                Proceedings of ACM MobiArch, August 2007.
+
+   [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.netpointers]
+               Tschudin, C. and R. Gold, "Network pointers", ACM SIGCOMM
+               Computer Communications Review, Vol. 33, Issue 1,
+               January 2003.
+
+   [paper.p2psip]
+               Koskela, J., Heikkila, J., and A. Gurtov, "A secure P2P
+               SIP system with SPAM prevention",  ACM Mobile Computer
+               Communications Review, July 2009.
+
+   [paper.triad]
+               Cheriton, D. and M. Gritter, "TRIAD: A New
+               Next-Generation Internet Architecture", July 2000,
+               <http://www-dsg.stanford.edu/triad/triad.ps.gz>.
+
+   [paper.usable-security]
+               Karvone, K., Komu, M., and A. Gurtov, "Usable Security
+               Management with Host Identity Protocol",  Proc. of the
+               IEEE/ACS International Conference on Computer Systems and
+               Applications, May 2009.
+
+   [thesis.bishaj]
+               Bishaj, B., "Efficient Leap of Faith Security with Host
+               Identity Protocol",  Master thesis, Helsinki University
+               of Technology, June 2008.
+
+   [thesis.ford]
+               Ford, B., "UIA:  A Global Connectivity Architecture for
+               Mobile Personal Devices",  Doctoral thesis, Massachusetts
+               Institute of Technology, September 2008.
+
+
+
+
+Henderson & Gurtov            Informational                    [Page 34]
+
+RFC 6538                  HIP Experiment Report               March 2012
+
+
+   [thesis.karlsson]
+               Karlsson, N., "Enabling Multiple Host Identities on
+               Linux",  Master thesis, Helsinki University of
+               Technology, September 2005.
+
+   [thesis.takkinen]
+               Takkinen, L., "Host Identity Protocol Privacy
+               Management", Master thesis, March 2006,
+               <http://www.tml.tkk.fi/~anttiyj/Laura-Privacy.pdf>.
+
+Authors' Addresses
+
+   Thomas Henderson
+   The Boeing Company
+   P.O. Box 3707
+   Seattle, WA
+   USA
+
+   EMail: thomas.r.henderson@boeing.com
+
+
+   Andrei Gurtov
+   University of Oulu
+   Centre for Wireless Communications CWC
+   P.O. Box 4500
+   FI-90014 University of Oulu
+   Finland
+
+   EMail: gurtov@ee.oulu.fi
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Henderson & Gurtov            Informational                    [Page 35]
+