IRTF HIP Research Group                                     T. Henderson
Internet-Draft                                        The Boeing Company
Intended status: Informational                                 A. Gurtov
Expires: September 9, 2009                                          HIIT
                                                           March 8, 2009


                         HIP Experiment Report
                      draft-irtf-hip-experiment-05

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 9, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Henderson & Gurtov      Expires September 9, 2009               [Page 1]


Internet-Draft            HIP Experiment Report               March 2009


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.














































Henderson & Gurtov      Expires September 9, 2009               [Page 2]


Internet-Draft            HIP Experiment Report               March 2009


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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1.  What is HIP? . . . . . . . . . . . . . . . . . . . . . . .  5
     1.2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.3.  Related Work on ID/Locator Split . . . . . . . . . . . . .  6
   2.  Host Stack Implications  . . . . . . . . . . . . . . . . . . .  8
     2.1.  Modifications to TCP/IP stack implementations  . . . . . .  8
       2.1.1.  ESP implementation extensions  . . . . . . . . . . . . 10
     2.2.  User-space implementations . . . . . . . . . . . . . . . . 11
     2.3.  Issues common to both implementation approaches  . . . . . 11
       2.3.1.  Resolver issues  . . . . . . . . . . . . . . . . . . . 11
       2.3.2.  IPsec management API extensions  . . . . . . . . . . . 12
       2.3.3.  Transport protocol issues  . . . . . . . . . . . . . . 12
       2.3.4.  Legacy NAT traversal . . . . . . . . . . . . . . . . . 14
       2.3.5.  Local management of host identity namespace  . . . . . 14
       2.3.6.  Interactions with host firewalls . . . . . . . . . . . 15
     2.4.  Relation to shim6 protocols  . . . . . . . . . . . . . . . 15
     2.5.  IPv4 vs. IPv6 issues . . . . . . . . . . . . . . . . . . . 15
     2.6.  What have early adopters learned from experience?  . . . . 16
   3.  Infrastructure Implications  . . . . . . . . . . . . . . . . . 18
     3.1.  Impact on DNS  . . . . . . . . . . . . . . . . . . . . . . 18
     3.2.  HIP aware middleboxes  . . . . . . . . . . . . . . . . . . 18
     3.3.  HIT resolution infrastructure  . . . . . . . . . . . . . . 18
     3.4.  Rendezvous servers . . . . . . . . . . . . . . . . . . . . 19
   4.  Application Implications . . . . . . . . . . . . . . . . . . . 20
     4.1.  Static vs. dynamic linking of resolver library . . . . . . 20
     4.2.  Using a native HIP API . . . . . . . . . . . . . . . . . . 20
   5.  Network Operator's Perspective . . . . . . . . . . . . . . . . 21
     5.1.  Management of the host identity namespace  . . . . . . . . 21
     5.2.  Use of ESP encryption  . . . . . . . . . . . . . . . . . . 21
     5.3.  User privacy issues  . . . . . . . . . . . . . . . . . . . 22
     5.4.  Access control lists based on HITs . . . . . . . . . . . . 23
     5.5.  Firewall issues  . . . . . . . . . . . . . . . . . . . . . 23
   6.  Experimental Basis of this Report  . . . . . . . . . . . . . . 25
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 27
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 28



Henderson & Gurtov      Expires September 9, 2009               [Page 3]


Internet-Draft            HIP Experiment Report               March 2009


   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31


















































Henderson & Gurtov      Expires September 9, 2009               [Page 4]


Internet-Draft            HIP Experiment Report               March 2009


1.  Introduction

   This document summarizes the work and experiences of the Host
   Identity Protocol IRTF Research Group (HIP-RG).  The HIP-RG was
   chartered to explore the possible benefits and consequences of
   deploying the Host Identity Protocol architecture [RFC4423] in the
   Internet.

1.1.  What is HIP?

   The Host Identity Protocol architecture introduces a new name space,
   the "host identity" name space, to the Internet architecture.  The
   express purpose of this new name space is to allow for the decoupling
   of identifiers (host identities) and locators (IP addresses) at the
   internetworking layer of the architecture.  The contributors to HIP
   have expected that HIP will enable alternative solutions for several
   of the Internet's challenging technical problems, including
   potentially host mobility, host multihoming, site multihoming, IPv6
   transition, and network-level security.  Although there have been
   many architectural proposals to decouple identifiers and locators
   over the past 20 years, HIP is currently the most actively developed
   proposal in this area.

   The Host Identity Protocol itself provides a rapid exchange of host
   identities (public keys) between hosts and uses a Sigma-compliant
   Diffie-Hellman key exchange to establish shared secrets between such
   endpoints [RFC5201].  The protocol is designed to be resistant to
   Denial-of-Service (DoS) and Man-in-the-middle (MitM) attacks, and
   when used together with another suitable security protocol, such as
   Encapsulated Security Payload (ESP) [RFC4303], it provides encryption
   and/or authentication protection for upper layer protocols such as
   TCP and UDP, while enabling continuity of communications across
   network layer address changes.

   A number of experimental RFC specifications were published by the
   IETF's HIP Working Group, including the HIP base protocol [RFC5201],
   ESP encapsulation [RFC5202], registration extensions [RFC5203], HIP
   rendezvous servers [RFC5204], DNS resource records [RFC5205], and
   mobility management [RFC5206].  Host identities are represented as
   ORCHIDs [RFC4853] in Internet protocols.  Additionally, the research
   group published one RFC on requirements for traversing NATs and
   firewalls [RFC5207].

1.2.  Scope

   The research group is tasked with producing an "experiment report"
   documenting the collective experiences and lessons learned from other
   studies, related experimentation, and designs completed by the



Henderson & Gurtov      Expires September 9, 2009               [Page 5]


Internet-Draft            HIP Experiment Report               March 2009


   research group.  The question of whether the basic identifier/locator
   split assumption is valid falls beyond the scope of this research
   group.  When indicated by its studies, the HIP RG can suggest
   extensions and modifications to the protocol and architecture.  It is
   also in scope for the RG to study, in a wider sense, the consequences
   and effects that wide-scale adoption of any type of separation of the
   identifier and locator roles of IP addresses is likely to have.

   In this report, we summarize the collective experience of early
   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.

   o  Whereas the two previous sections focus on the implementation and
      deployment of the network plumbing to make HIP work, the next two
      focus on the impact to users and operators of the network.
      Section 4 examines how the support of HIP in the host and network
      infrastructure affects applications; whether and how HIP provides
      benefits or drawbacks to HIP-enabled and legacy applications.

   o  Section 5 provides an operator's perspective on HIP deployment.

   o  In Section 6, we list the experimental activities and research
      that have contributed to this report.

1.3.  Related Work on ID/Locator Split

   The topic of whether a new name space is needed for the Internet is
   controversial.  The Name Space Research Group (NSRG) at the IRTF was
   not able to reach consensus on the issue, nor even to publish a final
   report.  The IRTF HIP research group is tasked to evaluate the impact
   of deployment of a HIP or related name space in the Internet.  Yet,
   there seems to be little disagreement that, for many scenarios, some
   level of indirection from network name to network location is
   essential or highly desirable to provide adequate service.  Mobile IP
   [RFC3775] is one example (the first such Standards Track proposal),
   with particular deployment and security properties, that reuses an
   existing name space for host naming.  Since Mobile IP was finalized
   many new variants to providing this indirection have been suggested.
   Even prior to Mobile IP, the IETF has published informational
   documents describing architectures separating network name and
   location, including the work of Jerome Saltzer [RFC1498], and Nimrod



Henderson & Gurtov      Expires September 9, 2009               [Page 6]


Internet-Draft            HIP Experiment Report               March 2009


   [RFC1992].

   Most recently, there has been standardization and development efforts
   in the IETF and IRTF on shim6 protocols and HIP, and consideration of
   ID/Locator solutions within the IRTF Routing Research Group (RRG).
   In the academic research community, several related proposals have
   been explored, such as the Internet Indirection Infrastructure (i3)
   [paper.i3], IPNL [paper.layered], DataRouter [paper.datarouter],
   Network Pointers [paper.netpointers], FARA [paper.fara], and TRIAD
   [paper.triad].









































Henderson & Gurtov      Expires September 9, 2009               [Page 7]


Internet-Draft            HIP Experiment Report               March 2009


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, and
   servers.  There are two primary ways to support HIP on such an end
   host.  The first is to make changes to the kernel implementation to
   directly support the decoupling of identifier and locator.  Although
   this type of modification has data throughput performance benefits,
   it is also the more challenging to deploy.  The second approach is to
   implement all HIP processing in user-space, and configure the kernel
   to pass packets through user-space for HIP processing.

   The following public HIP implementations are known:

   o  HIP4BSD (http://www.hip4inter.net)-- FreeBSD kernel modifications
      and user-space keying daemon;

   o  HIPL (http://infrahip.hiit.fi)-- Linux kernel and user-=space
      implementation;

   o  OpenHIP (http://www.openhip.org)-- User-space keying daemon and
      packet processing for Linux, Windows XP, and Macintosh OS X, plus
      a Linux kernel packet processing variant based on an extended
      kernel IPsec implementation;

   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 September 9, 2009               [Page 8]


Internet-Draft            HIP Experiment Report               March 2009


    +--------------------+                       +--------------------+
    |                    |                       |                    |
    |   +------------+   |                       |   +------------+   |
    |   |    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 September 9, 2009               [Page 9]


Internet-Draft            HIP Experiment Report               March 2009


                  |-----------------------|
    --------      |   ----------     ----------
    | HIP  |--    ----|  App v6 |    |  App v4 |
    -------- |    |   ----------     ----------
      |      |    |       | HIT           | LSI
      |    ------------   | AF_INET6      | AF_INET
      |    | resolver |   |               |
      |    ------------   |  sockets API  |        user-space
    --|-------------------|-------------------------------
      | sockets and       |               |        kernel
      | PF_KEY API    ---------           |
      |-------------> |TCP/UDP|<-----------
      |               ---------
      |                   |
    ----------        ---------
    | SAD/SPD|<-----> | ESP   |  {HIT_s, HIT_d} <-> SPI
    ----------        ---------  {HIT_s, HIT_d, SPI} <-> {IP_s, IP_d, SPI}
                          |
                      ---------
                      |  IP   |
                      ---------

    Figure 2: Overview of typical implementation changes to support HIP

   Legacy applications can continue to use the standard AF_INET6 (for
   IPv6) and AF_INET (for IPv4) socket API.  IPv6 applications bind
   directly to HIT, which is a part of IPv6 address space reserved for
   ORCHIDs.  IPv4 applications bind to Local Scope Identifier (LSI) that
   has significance only within a host.  The HIP layer translates
   between LSIs and HITs that are still used underneath for HIP base
   exchange.

2.1.1.  ESP implementation extensions

   HIP requires a Bound End-to-End Tunnel (BEET) mode of ESP operation,
   which mixes tunnel-mode semantics with transport-mode syntax.  BEET
   is not supported by all operating system distributions at present, so
   kernel modifications might be needed to obtain true kernel support
   using existing IPsec code.  At the time of writing, the BEET mode has
   been integrated to Linux and FreeBSD kernels.

   The current strategy that implementers have adopted is to develop a
   common IPsec BEET patch for the Linux kernel.  The patch could
   potentially allow all implementations of HIP to run in the userspace
   and use a common clean interface towards the kernel.  Still, the BEET
   patch introduces problems for the opportunistic HIP mode when HIP
   identifiers alone are used at the socket API, because there is no way
   to name the responder host at the onset of socket and Security



Henderson & Gurtov      Expires September 9, 2009              [Page 10]


Internet-Draft            HIP Experiment Report               March 2009


   Association creation.

   Another inconvenience experienced in current Linux implementations
   (due to the native IPsec implementation, not HIP specifically) is a
   loss of the first data packet that triggers the HIP association
   establishment.  Instead, this packet should be cached and transmitted
   after the association is established.

2.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 other locally scoped HIP identifiers to such a virtual device,
   where the ESP header is applied and an outer IP address replaces the
   HIT.  On the receive side, a raw socket bound to ESP 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.

2.3.  Issues common to both implementation approaches

2.3.1.  Resolver issues

   Much initial experimentation with HIP has involved using HITs
   directly in IPv6 socket calls, without any resolution infrastructure.
   To do so requires some type of a priori HIT exchange, in the absence
   of a resolution service.  Manual exchange of HITs has been a major
   inconvenience for experimentation.  It can be overcome via 1)
   opportunistic HIP mode, 2) storing HITs in DNS AAAA entries, 3) name
   resolution service such as OpenDHT, 4) a HIT exchange service, or 5)
   link local broadcast.  Opportunistic mode involves a "leap of faith"



Henderson & Gurtov      Expires September 9, 2009              [Page 11]


Internet-Draft            HIP Experiment Report               March 2009


   to accept and learn of the peer's identity, in much the same way that
   ssh works today.

   At the time of writing, 1) is only supported by OpenHIP, and 2) is
   only supported by HIP4BSD.  Implementing the first approach in a
   clean way is challenging, as HITs need to be known when an
   application binds or connects to a socket.  Approach 2) has been
   difficult in practice due to resistance of sysadmins to include AAAA
   entries in the DNS server.  However, using a widely available third-
   party DNS service has a low cost.  Approach 3) is being progressed
   with two independent implementations of HIP-OpenDHT interface.  At
   the moment, the easiest way for enabling experimentation appears to
   be the approach 4) when a shell script based on SSH and SCP can
   connect to a peer machine and copy HITs to the local configuration
   files.  However, this approach is not scalable or secure for the long
   run.

   For option 5), HIP 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.

2.3.2.  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.3.  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



Henderson & Gurtov      Expires September 9, 2009              [Page 12]


Internet-Draft            HIP Experiment Report               March 2009


   packet, when it is a TCP SYN packet, results into TCP timeout of 1
   second [RFC2988] that unnecessarily delays the application.  A loss
   of a UDP packet can cause even longer timeouts in application.
   Therefore, it was found to be important for HIP implementations to
   support the buffering of the packet.  On the other hand, if the HIP
   base exchange takes longer than 1 second, which is the case on
   lightweight devices, a spurious timeout can occur at the transport
   layer.  The HIP implementation could prevent this scenario by
   manipulating timeouts values at the transport layer or,
   alternatively, drop the original or retransmitted duplicate packet

   The multihoming support in [RFC5206] is stated for the purpose of
   failover, when a host starts using a spare locator when a current
   locator fails.  A host deploying multihoming for load balancing can
   simultaneously transmit data from several locators to utilize
   bandwidth over parallel network paths or to reduce the latency.  Such
   a scenario creates several issues at the transport layer, related to
   congestion control and error recovery.  In particular, if packets
   from a single TCP connection are sent over different paths, they can
   experience different propagation delays.

   When packets take different paths to reach the destination, they can
   arrive in a different order than transmitted, an effect known as
   packet reordering.  Packet reordering easily confuses reliable
   transport protocols, such as TCP and SCTP, or the application if
   unreliable UDP transport protocol is used [RFC4653] [RFC3522].

   The use of paths with different characteristics can also impact the
   estimate of a retransmission timer at the sender's transport layer.
   TCP uses a smoothed average of the path's Round Trip Time and its
   variation as the estimate for a retransmission timeout.  After the
   retransmission timeout expires, the sender retransmits all
   outstanding packets in go-back-N fashion.

   When multihoming is used for simultaneous data transmission from
   several locators, there can easily be scenarios when the
   retransmission timeout does not correspond to the actual value.  When
   packets simply experience different RTT, its variation is high, which
   sets the retransmission timeout value unnecessary high.  When packets
   are lost, the sender waits excessively long before retransmitting.
   Fortunately, modern TCP implementations deploying Selective
   Acknowledgments (SACK) and Limited Transmit are not relying on
   retransmission timeouts except when most outstanding packets are
   lost.

   Load balancing among several paths requires some estimate of each
   path's capacity.  The TCP congestion control algorithm assumes that
   all packets flow along the same path.  To perform load balancing, the



Henderson & Gurtov      Expires September 9, 2009              [Page 13]


Internet-Draft            HIP Experiment Report               March 2009


   HIP layer can attempt to estimate parameters such as delay,
   bandwidth, and loss rate of each path.  A HIP scheduler can then
   distribute packets among the paths according to their capacity and
   delay, to maximize overall utilization and minimize reordering.  The
   design of the scheduler is a topic of current research work.
   Different network paths can have different Maximum Transmission Unit
   (MTU) sizes.  Transport protocols perform MTU size discovery
   typically only in the beginning of a connection.  As HIP hides
   mobility from the transport layer, it can happen that packets on the
   new path get fragmented without knowledge of the transport protocol.
   To solve this problem, the HIP layer could inform the transport layer
   of mobility events.  This method, known as transport triggers, is
   still under research although initial specification attempts have
   been made in the IETF.

2.3.4.  Legacy NAT traversal

   Legacy NAT traversal has been implemented for two HIP implementations
   (HIPL and HIP4BSD) according to the NAT traversal draft under
   development in the HIP WG [cite draft].  Finding an IPv6 NAT
   implementation for experiments has been difficult.  NAT traversal is
   expected to be a major mode of HIP operation in the future.

2.3.5.  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 passkey in memory (like in SSL
   certificates on servers, that ask for a password when booting Linux).





Henderson & Gurtov      Expires September 9, 2009              [Page 14]


Internet-Draft            HIP Experiment Report               March 2009


2.3.6.  Interactions with host firewalls

   HIP is presently an experimental protocol, and some default firewall
   configuration scripts on popular Linux distributions do not permit
   such traffic.  Determining which rules to modify without compromising
   other performance can be tricky; the default rule set on one popular
   distribution has over one hundred rules.  Moreover, it may be the
   case that the end user has no control over the firewall settings, if
   administered by an enterprise IT department.

2.4.  Relation to shim6 protocols

   The Site Multihoming in IPv6 (multi6) WG documented the ways that
   multihoming is currently implemented in IPv4 networks and evaluated
   several approaches for advanced multihoming.  The security threats
   and impact on transport protocols were covered during the evaluation.
   The work continued in another WG, Site Multihoming by IPv6
   Intermediation (shim6), which focusing on specifications of one
   selected approach.  This WG uses the approach of inserting a shim
   layer between the IP and the transport layers that hides effects of
   changes in the set of available addresses.  The applications are
   using one active address that enables referrals.  Shim6 relies on
   cryptographically generated IPv6 addresses to solve the address
   ownership problem.

   HIP and shim6 use a common format for control packets.  HIP
   specifications define only simple multihoming scenarios leaving such
   important issues as interface selection untouched.  Shim6 offers
   complementary functionality that can be be reused in HIP.  The
   OpenHIP implementation integrates HIP and shim6 protocols in the same
   framework, with the goal of allowing HIP to reuse the shim6 failure
   detection protocol.

2.5.  IPv4 vs. IPv6 issues

   HIP has been oriented towards IPv6 deployment, but many
   implementations have added support also for IPv4.  HIP supports IPv6
   applications well, as the HITs are used from the general IPv6 address
   space using the ORCHID prefix.  HITs are statistically unique,
   although are not routable on the IP layer.  Therefore a mapping
   between HITs and routable IP addresses is necessary at the HIP layer,
   unless an overlay network is 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
   may be used as an LSI if it is configured to refer to a particular



Henderson & Gurtov      Expires September 9, 2009              [Page 15]


Internet-Draft            HIP Experiment Report               March 2009


   host identity on a given host, or LSIs may be drawn from an
   unallocated IPv4 address range.

   HIP makes it possible to use IPv6 applications over IPv4 network and
   vice versa.  Interfamily part of BEET patch in the Linux kernel was
   found more difficult to complete compared with the single-family
   processing.

   TODO: Interfamily handovers

2.6.  What have early 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.

   The experience with attempting to integrate the HIPL kernel-based
   implementation to the official Linux kernel has been unsuccessful.
   Although counter-examples exist, e.g.  SCTP is a large unit in the
   kernel, the Linux community resisted incorporating the HIP code.  The
   kernel developers felt that since MIP and IKE are implemented as
   user-space signaling daemon in Linux, that should be an approach for
   HIP too.  Furthermore, the kernel-patch was somewhat big, affecting
   the kernel in many places and having several databases.

   Opportunities for misconfiguration of the Linux kernel have been a
   side effect of the need to patch the kernel.  Mistakenly disabling a
   configuration option or compiling a feature as a module instead of
   statically caused many installation problems.  Some scripts that
   could verify that the configuration is appropriate could help to
   solve this problem, as could fully user-space test implementations.

   Installing several HIP implementations onto a single machine creates
   some complications.  All implementations store some files in /etc/hip
   directory and use /proc system to report the status.  While direct
   conflicts in filenames were luckily avoided, it might have been
   better to coordinate from the beginning so that different
   implementations, for example, use different subdirectories.  However,
   we expect this issue to be of significance only to HIP developers but
   not for an average user.  Some users have been explicitly asking
   about co-existence of HIP with other VPN and Mobile IP software.
   E.g., on Windows those tend to install own versions of TAP drivers



Henderson & Gurtov      Expires September 9, 2009              [Page 16]


Internet-Draft            HIP Experiment Report               March 2009


   which might conflict with the driver used by OpenHIP implementation.


















































Henderson & Gurtov      Expires September 9, 2009              [Page 17]


Internet-Draft            HIP Experiment Report               March 2009


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.

   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.  Performance measurement
   results with a prototype are available, but experimentation on a wide
   scale is still missing.  [RFC5207].

   As argued by Aura et al. [paper.hipanalysis], the encryption of the
   Responder HI prevents policy-based NAT and firewall support for HIP.
   The catch is that when the HI is encrypted, middle boxes in the
   network cannot verify the signature on I2 and, thus, cannot safely
   create a state for the HIP association.  On the other hand, if the HI
   is not encrypted, a stateful middle box like a NAT can process I2 and
   create a protocol state for the session.  It may be possible to push
   the I1/R1 exchange into the firewall and to filter false puzzle
   solutions at the firewall.  The encryption of HI-I prevents such
   middle-box implementations.

3.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.

   The main idea is to transmit HIP control packets using the i3 system



Henderson & Gurtov      Expires September 9, 2009              [Page 18]


Internet-Draft            HIP Experiment Report               March 2009


   as a lookup and rendezvous service, while transmitting data packets
   efficiently end-to-end using IPsec.  Performance measurements are
   being executed, comparing the association setup latency, throughout
   and RTT of Hi3 with plain IP, HIP and i3.

   One difficulty has been with debugging the i3 system.  In some cases
   the messages did not traverse i3 correctly; due to its distributed
   nature and lack of tracing tools, making the system work has been
   challenging.  Fortunately, these shortcomings are being addressed.

   NATs and firewalls were a major disturbing factor in execution of
   experiments.  Many networks did not allow incoming UDP packets to go
   through, therefore, preventing messages from i3 servers to reach the
   client.

   So far the Hi3 system has been evaluated on a larger scale only
   analytically.  The problem is that running a larger number of clients
   to create a sufficient load for the server is difficult.  A cluster
   on the order of a hundred Linux servers is needed for this purpose.
   Contacts to a State Supercomputer Centre in Finland have not been
   successful so far.  A possible opportunity is to use one of existing
   Emulab installations, e.g. in Utah for these tests.

3.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.

   Following advanced concepts need further study.

   o  Multiple RVS per host for fault tolerance (e.g. one rendezvous
      node crashes).  An algorithm for selecting the best RVS.

   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 September 9, 2009              [Page 19]


Internet-Draft            HIP Experiment Report               March 2009


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

   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].




























Henderson & Gurtov      Expires September 9, 2009              [Page 20]


Internet-Draft            HIP Experiment Report               March 2009


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 [cite
   Dietz draft].

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
   own AAA databases and network firewalls.  Finally, the users would
   not need to be concerned with technical details of host identity
   management.

   The operator may use Public Key Infrastructure (PKI) to certify host
   identities of its customers.  Then, it uses the private key of
   operator's Certificate Authority to sign the public key of its
   customers.  This way, third parties 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.  Signaling
   of SIP protocol could be used to deliver host identities if it is
   secured by existing mechanisms in operator's network. [reference SIP/
   HIP draft]

5.2.  Use of ESP encryption

   (Reference the Dietz draft here) Discussion regarding whether
   operators can provide "value-added" services and priority, and comply
   with wiretapping laws, if all sessions are encrypted.  This is not so
   much a HIP issue as a general IPsec issue.  One study evaluated the
   use of HIP and ESP on lightweight devices (Nokia N770 Internet
   Tablets having 200 MHz processors) [paper.mobiarch].  The overhead of
   using ESP on such platform was found to be tolerable, about 30% in
   terms of throughput.  With a bulk TCP transfer over WiFi without HIP
   was producing 4.86 Mbps, while over ESP security associations set up



Henderson & Gurtov      Expires September 9, 2009              [Page 21]


Internet-Draft            HIP Experiment Report               March 2009


   by HIP it was 3.27 Mbps.

5.3.  User privacy issues

   Using public keys for identifying hosts creates a privacy problem as
   third parties can determine the source host even if attached to a
   different location in the network.  Various transactions of the host
   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-



Henderson & Gurtov      Expires September 9, 2009              [Page 22]


Internet-Draft            HIP Experiment Report               March 2009


   round-trip Diffie Hellman key exchange protocol.  If the host avoids
   storing its public keys in the reverse DNS or DHT repository, the
   framework achieves full location and identity privacy.

   A natural approach to reducing privacy threats of persistent
   identifiers is to replace them with short-lived identifiers that are
   changed regularly to prevent user tracking.  Furthermore, identifiers
   must be changed simultaneously at all protocol layers, otherwise an
   adversary could still link the new identifier through looking at the
   identifier at another protocol layer that remained the same after the
   change.  The HIP privacy architecture that simultaneously changes
   identifiers on MAC, IP, and HIP/IPsec layers was developed in TKK
   [thesis.takkinen].  The default frequency of changes is every 6 to 10
   minutes.  Unfortunately, each change causes a delay of 3 seconds, and
   possibly loss of data packets, which might be unacceptable for real-
   time applications.

5.4.  Access control lists based on HITs

   A firewall typically separates an organization's network from the
   rest of the Internet.  An Access Control List (ACL) specifies packet
   forwarding policies in the firewall.  Current firewalls can filter
   out packets based on IP addresses, transport protocol, and port
   values.  These values are often unprotected in data packets and can
   be spoofed by an attacker.  By trying out common well-known ports and
   a range of IP addresses, an attacker can often penetrate the firewall
   defenses.  Furthermore, legacy firewalls often disallow IPsec traffic
   and drop HIP control packets.  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.

   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 example.com regardless of their current locators.  It is
   difficult without no forward confirmed reverse DNS to use for
   reputation purposes.

5.5.  Firewall issues

   HIIT has implemented a HIP firewall based on Linux iptables
   [thesis.vehmersalo].  Firewalls can be stateless, filtering packets
   based only on the ACL, and stateful, which can follow and remember
   packet flows.  Stateless firewalls are simple to implement but



Henderson & Gurtov      Expires September 9, 2009              [Page 23]


Internet-Draft            HIP Experiment Report               March 2009


   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 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 September 9, 2009              [Page 24]


Internet-Draft            HIP Experiment Report               March 2009


6.  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 following is a possibly incomplete list of current research
   activities related to HIP.

   o  Boeing (T. Henderson, J. Ahrenholz, J. Meegan.  OpenHIP
      implementation, Secure Mobile Architecture)

   o  NomadicLab, Ericsson (P. Jokela, P. Nikander, J. Melen.  BSD HIP
      implementation)

   o  HIIT (A. Gurtov, M. Komu, A. Pathak, D. Beltrami.  HIPL, legacy
      NAT traversal, firewall, i3, native API)

   o  UCB (D. Joseph, HIP proxy implementation)

   o  Laboratory of Computer Architecture and Networks, Polytechnic
      School of University of Sao Paulo, Brazil (T. Carvalho, HIP
      measurements, Hi3)

   o  Telecom Italia (M. Morelli, comparing existing HIP
      implementations)

   o  NEC Heidelberg (L. Eggert, M. Esteban, V. Schmitt working on RVS
      implementation, DNS, NAT traversal)

   o  U. of Hamburg-Harburg (M. Shanmugam, A. Nagarajan, HIP
      registration protocol)

   o  U. of Tuebingen (K. Wehrle, T. Lebenslauf to work on Hi3 or HIP-
      OpenDHT)

   o  University of Parma (UNIPR), Department of Information Engineering
      Parma, Italy.  N. Fedotova (HIP for P2P)

   o  Siemens (H. Tschofenig, HIP middleboxes)




Henderson & Gurtov      Expires September 9, 2009              [Page 25]


Internet-Draft            HIP Experiment Report               March 2009


   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 September 9, 2009              [Page 26]


Internet-Draft            HIP Experiment Report               March 2009


7.  Acknowledgments

   Miika Komu has provided helpful comments on earlier versions of this
   draft.















































Henderson & Gurtov      Expires September 9, 2009              [Page 27]


Internet-Draft            HIP Experiment Report               March 2009


8.  References

   [RFC2988]  Paxson, V. and M. Allman, "Computing TCP's Retransmission
              Timer", RFC 2988, November 2000.

   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
              (HIP) Architecture", RFC 4423, May 2006.

   [RFC5201]  Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
              "Host Identity Protocol", RFC 5201, April 2008.

   [RFC5202]  Jokela, P., Moskowitz, R., and P. Nikander, "Using the
              Encapsulating Security Payload (ESP) Transport Format with
              the Host Identity Protocol (HIP)", RFC 5202, April 2008.

   [RFC5203]  Laganier, J., Koponen, T., and L. Eggert, "Host Identity
              Protocol (HIP) Registration Extension", RFC 5203,
              April 2008.

   [RFC5204]  Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
              Rendezvous Extension", RFC 5204, April 2008.

   [RFC5205]  Nikander, P. and J. Laganier, "Host Identity Protocol
              (HIP) Domain Name System (DNS) Extensions", RFC 5205,
              April 2008.

   [RFC5206]  Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
              Host Mobility and Multihoming with the Host Identity
              Protocol", RFC 5206, April 2008.

   [RFC5207]  Stiemerling, M., Quittek, J., and L. Eggert, "NAT and
              Firewall Traversal Issues of Host Identity Protocol (HIP)
              Communication", RFC 5207, April 2008.

   [RFC4853]  Housley, R., "Cryptographic Message Syntax (CMS) Multiple
              Signer Clarification", RFC 4853, April 2007.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC1498]  Saltzer, J., "On the Naming and Binding of Network
              Destinations", RFC 1498, August 1993.

   [RFC1992]  Castineyra, I., Chiappa, N., and M. Steenstrup, "The
              Nimrod Routing Architecture", RFC 1992, August 1996.



Henderson & Gurtov      Expires September 9, 2009              [Page 28]


Internet-Draft            HIP Experiment Report               March 2009


   [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 September 9, 2009              [Page 29]


Internet-Draft            HIP Experiment Report               March 2009


              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.

   [book.hip]
              Gurtov, A., "Host Identity Protocol (HIP): Towards the
              Secure Mobile Internet",  Wiley and Sons, June 2008.

   [thesis.takkinen]
              Takkinen, L., "Host Identity Protocol Privacy Management",
               Master thesis, TKK, March 2006.

   [thesis.vehmersalo]
              Vehmersalo, E., "Host Identity Protocol Enabled Firewall:
              A Prototype Implementation and Analysis",  Master thesis,
              TKK, September 2005.

   [I-D.nikander-esp-beet-mode]
              Melen, J. and P. Nikander, "A Bound End-to-End Tunnel
              (BEET) mode for ESP", draft-nikander-esp-beet-mode-09
              (work in progress), August 2008.















Henderson & Gurtov      Expires September 9, 2009              [Page 30]


Internet-Draft            HIP Experiment Report               March 2009


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 September 9, 2009              [Page 31]