RFC 6538

The Host Identity Protocol (HIP) Experiment Report

📅 published March 2012, from ietf

Hiii, Let's Get Into RFC 6538 🦋✨

okay bestie, this one is the IRTF (Internet Research Task Force) being cute about the Host Identity Protocol (HIP) 💅 It's an Informational RFC, so it's a report and not a spec you have to implement. Written by T. Henderson (The Boeing Company) and A. Gurtov (University of Oulu), it came out in March 2012 🌸 It's published under ISSN 2070-1721. It doesn't obsolete or update any other RFCs, so it's giving independent main character energy 👑

Sooo here's the vibe of the whole thing: the research group basically looked back at what they learned from studying and experimenting with HIP between 2004 and 2009 🧚 It covers what happens when HIP shows up in host stacks, the internet infrastructure, and apps, plus the view from a network operator's side, and a list of HIP experiments. It's not just for HIP either, other overlay-based architectures can learn from it too 🫶

Status of This Memo ✨

okay so this doc is NOT an Internet Standards Track spec 🙈 It's published for info only. It's a product of the IRTF, which shares research results that might not be ready for deployment yet 💀 It represents the consensus of the IRTF HIP Research Group, but anything approved by the IRSG can't become any level of Internet Standard (see Section 2 of RFC 5741). For the current status, errata, and feedback, check http://www.rfc-editor.org/info/rfc6538 💜

Copyright (c) 2012 IETF Trust and the document authors, all rights reserved 🎀 This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as of the publication date, so read those carefully because they spell out your rights and restrictions 📜

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

1. Introduction 🌈

1.1. What is HIP? 🔥

okay so the Host Identity Protocol architecture adds a brand new namespace to the Internet, called the "host identity" namespace 🧚 The whole point is to split identifiers (host identities) from locators (IP addresses) at the internetworking layer, which is so iconic. HIP is expected to help with host mobility, host multihoming, site multihoming, IPv6 transition, NAT traversal, and network-level security, and it's one of the most actively developed ideas for this over the last 20 years [book.gurtov] 💖

The protocol gives hosts a fast exchange of host identities (public keys) and uses a Diffie-Hellman exchange that's Sigma compliant ("SIGn-and-MAc") to set up shared secrets [RFC5201] ✨ It's built to resist Denial-of-Service (DoS) and Man-in-the-Middle (MitM) attacks, and paired with something like Encapsulated Security Payload (ESP) [RFC4303], it gives encryption and/or authentication for upper-layer protocols like TCP and UDP, while keeping connections going even when network-layer addresses change 🦋

The HIP working group published a bunch of Experimental RFCs: 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 show up in Internet protocols as Overlay Routable Cryptographic Hash Identifiers (ORCHIDs) [RFC4843] 💜 The research group also published one RFC on requirements for traversing NATs and firewalls [RFC5207], and the working group later published legacy NAT traversal text [RFC5770] 🌸 As of writing, the specs were starting to move toward Standards Track status ⭐

1.2. Terminology 🍓

The terms in this doc are defined elsewhere, so go check Section 3 of [RFC4423] for the HIP-specific terminology 📖

1.3. Scope 🧁

The research group was tasked with writing an "experiment report" about what they learned from other studies, experiments, and designs they finished 🌷 Whether the identifier-locator split assumption is valid is outside this group's scope 🙅 When their studies show it's needed, the HIP-RG can suggest extensions and changes to the protocol and architecture. They also looked at the wider effects of wide-scale adoption of any kind of identifier and locator separation for IP addresses 🦋

During 2004 to 2009, when most of this report was drafted, research projects and open source projects formed to study HIP 💅 They built software that's interoperable with the Experimental RFCs and also supports extensions that don't have RFCs yet ✨

The research group was most active in two areas 💖 First, they studied HIP extensions that went beyond the IETF HIP working group's charter and the RFCs (RFC 5201-5206) first published in April 2008. Some of that work (NAT traversal, certificate formats for HIP, legacy application support, and a native sockets API for HIP) ended up in the IETF HIP working group when it was rechartered in 2008 🎀 Other extensions (like HIP in the Internet Indirection Infrastructure (i3) overlay, using distributed hash tables for HIT-based (Host Identity Tag) lookups, mobile router extensions, and so on) are either still in progress in the research group or were abandoned 🥀 Most of the group's energy went into studying HIP extensions or applying HIP to new problem areas, like the Internet of Things 🌈 Second, they talked about the progress and results of implementations and experiments so far, plus perspectives from end users, operators, and enterprises on deploying HIP 💜 This second area is what this report focuses on, not the extensions 🫶

Last but not least, the group was chartered to study these things but didn't study them rigorously, because they didn't get enough input 🙈

Heads up, bestie: the list below is the stuff they were chartered to look at but didn't dig into properly.
  • 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).
  • Large scale deployments (thousands of hosts or greater).
  • Exploration of whether introducing an identity-locator mechanism would be architecturally sound, deployed at wide scale.
  • Changes to the HIP baseline architecture and protocol or other identity-locator separation architectures.

Part 1 of 8. More parts are coming, so stay tuned for Section 1.4 and beyond 💖🧚

1.4. Organization 🗂️

okay so in this report we're basically spilling the tea on what early implementers and adopters of HIP have learned, and it's laid out like this 💅

  • Section 2 is all about what supporting HIP does to an end host. 💻
  • Section 3 covers deploying HIP and how it plays with network infrastructure: middlebox traversal, name resolution, Access Control Lists (ACLs), and HIP infrastructure like rendezvous servers. 🚧

Sections 2 and 3 are the plumbing. The next three are about the people who actually use the network and the people who run it, so the vibe shifts a little. ✨

  • Section 4 looks at how HIP support in the host and in the network affects applications, and whether HIP helps or hurts both HIP-enabled and legacy apps. 📱
  • Section 5 gives us an operator's perspective on HIP deployment. 🛠️
  • Section 6 talks about user privacy. 🙈

And to wrap up, Section 7 lists the experimental activities and research that fed into this report, and Section 8 gives a quick recap of related work. 🎀

2. Host Stack Implications 💻

HIP is mainly an extension to the TCP/IP stack of Internet hosts, so in this section we're sharing some experiences that several implementation groups ran into while building it. 🧠 Our notes come from implementers who added HIP to general-purpose computing platforms like laptops, desktops, servers, and PDAs. 📲 There are two main ways to get HIP running on an end host:

  • The first is to change the kernel implementation so it directly supports decoupling the identifier from the locator. Honestly, this one has real data throughput performance benefits, but it's also the harder of the two to deploy. 😤
  • The second is to do all HIP processing in user-space and configure the kernel to route packets through user-space for that processing. 🧚

Here are the public HIP implementations that are known and actively maintained, bestie:

Next up, we'll go over issues specific to how HIP gets added to a stack, and then talk about general issues that apply to both implementation approaches. 💖

2.1. Modifications to TCP/IP Stack Implementations 🧩

In this section we're focusing on supporting HIP with these assumptions in mind:

  • HIP is implemented by directly changing the TCP/IP stack implementation. 🔧
  • Applications (using the sockets API) are unaware of HIP. 🫣

A HIP implementation usually has a key management process that works with an IPsec-extended stack, as Figure 1 shows. In practice, HIP has been built entirely in 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 gives the big-picture summary of what it takes to support HIP natively in an implementation, and we dig into it more in the later sections. ✨ To enable HIP natively, you need extensions to the key management interface (shown here as the PF_KEY API [RFC2367]) along with the security association database (SAD) and security policy database (SPD). 🗝️ You also need changes to the ESP implementation 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 so they respond correctly to mobility and multihoming events [TCP-RLCI]. 🌈

                  |-----------------------|
    --------      |   ----------     ----------
    | 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 keep using the standard AF_INET6 (for IPv6) and AF_INET (for IPv4) sockets API, no drama. 🙌 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 only has significance within a host. The HIP layer translates between LSIs and HITs and the IP addresses that still get used underneath for HIP base exchange. It's giving middleman energy, honestly. 🫶

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 isn't supported by all operating system distributions at the moment, so kernel modifications might be needed to get true kernel support using existing IPsec code. 🙃 At the time of writing, the BEET mode has been adopted into vanilla Linux and FreeBSD kernels. 🎉

The HIPL project has contributed an IPsec BEET patch for the Linux kernel. 🐧 Kernel-level support could potentially let all Linux implementations of HIP run in user-space while using a common interface toward the kernel. 🌸

One annoying thing in the current Linux IPsec implementation (this comes from the native IPsec implementation, not HIP specifically) is that the first data packet that triggers HIP association establishment gets lost. 😭 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, which is essential for supporting HIP on hosts where operating system modifications aren't possible. 💅 Even on operating systems you can modify, there's often a big deployment advantage to 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) that look like typical application deployment on the target systems. 📦

When HIP runs in user-space, you need some technique to identify packets that require HIP processing, divert them to user-space for that processing, and then re-inject them into the stack for further transport protocol processing. 🔁 A commonly used technique is to deploy a virtual device in the kernel, like a network tap (TAP) device, although operating systems may offer other ways to divert 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 sends all packets with destination addresses matching 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 by a UDP port when UDP encapsulation is used. 🛎️

2.3. Issues Common to Both Implementation Approaches 🤝

2.3.1. User-Space Handling of HITs

Lots of early HIP experimentation involved using HITs directly in IPv6 socket calls, with no resolution infrastructure to learn the HIT from, for example, a domain name, or to resolve the IP address. 🥲 To experiment with HIP using HITs, you need an a priori HIT exchange when there's no resolution service. Manually exchanging HITs has been a major inconvenience for experimenting, ngl. 😩 It can be overcome via 1) opportunistic HIP mode (RFC 5201, Section 4.1.6), 2) storing HITs in DNS AAAA entries and looking them up by domain name, 3) a 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, because HITs need to be known when an application binds or connects to a socket. 😵‍💫 Approach 2 has been difficult in practice because sysadmins resisted including AAAA entries for HITs in the DNS server, and it's a non-standards-compliant use of the resource record. 💀 Approach 3 is being progressed with two independent implementations of a HIP-OpenDHT interface. ⭐ Right now, the easiest way to enable experimentation seems to be approach 4, where a shell script based on Secure SHell (SSH) and Secure Copy (SCP) connects to a peer machine and copies HITs into the local configuration files. Still, this approach is not scalable or secure for the long run, so be warned. 🚨 HIPL developers have had positive experiences with alternative 5. 👑

2.3.2. Opportunistic Mode ✨

okay so in opportunistic mode, the Initiator starts a base exchange without knowing the Responder's HIT 🫣 the big perk is that you don't need any extra lookup infrastructure for HIs [RFC5205] [RFC6537]. no directory, no drama 💅

BUT it has a few downsides, bestie 😭 First, the Initiator might not be able to identify the Responder uniquely just from the IP address when private address realms are involved [RFC5770]. Second, the Initiator has to take a "leap of faith" 🙈 which means assuming there is no man-in-the-middle attack. it can be partially mitigated by using certificates on the Responder side [RFC6253] or by popping up a graphical prompt so the user can explicitly accept the connection [paper.usable-security]. ngl the user getting a say is very iconic 👑

the opportunistic mode needs only minor state machine changes for the Responder and small changes for the Initiator [paper.leap-of-faith] 🌸 The Responder can just pick a suitable HIT when it gets the very first HIP base exchange packet (called an "I1") even without a predefined HIT for itself. The Initiator should be more careful, though, when it processes the first packet coming back from the Responder, called the "R1" 👀 For example, the Initiator should make sure it can tell apart simultaneously initiated opportunistic base exchanges from each other. main character energy, but make it organized 💖

In the HIPL project, opportunistic mode was successfully applied at the HIP layer for service registration [RFC5203] ✨ HIP4BSD implemented opportunistic mode successfully with small modifications to the FreeBSD socket layer 🦋 The Linux implementation was more of a challenge, though, as described below.

The HIPL project tried opportunistic mode by slotting a shim in at two different layers 🧚 In the first approach, an API-based shim captured socket calls from the application. this was kinda complicated to build, and each individual application (or group of applications) had to be explicitly enabled to use opportunistic mode 😩 In the second approach [paper.leap-of-faith], the shim sat between the network and transport layers. After a successful base exchange, the shim turned IP-based packet flows into HIT-based packet flows by re-injecting the translated packets back into the networking stack. the glow-up is real 🌈

Unless it was bypassed for DNS, both of the HIPL opportunistic approaches made the application(s) go through opportunistic mode procedures for DNS requests too 💀 Both approaches also implemented an optional "fall back" to non-HIP base connectivity if the peer didn't support HIP. The detection of peer HIP support was based on timeouts. To avoid timeouts completely and cut the delay down to a single Round-Trip Time (RTT) for TCP, the project also experimented with TCP-specific extensions [thesis.bishaj] 🎀

The OpenHIP project played with opportunistic mode through an opportunistic (-o) option 🍓 On the Responder side, this option decides whether HIP accepts I1s that come in with a zeroed receiver's HIT. On the Initiator's side, the option lets you configure a name and an 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. Normally the LSI is based on the bottom 24 bits of the HIT, but in opportunistic mode the HIT is unknown, so the LSI may differ from the HIT 🧐

the tea on the opportunistic mode experiments: it's possibly best suited for HIP-aware applications 💜 It can either be used by HIP itself in registration extensions or by native HIP applications [RFC6317]. this way, the inherent security trade-offs of opportunistic mode are explicitly visible to the user through the HIP-aware application 🫶

2.3.3. Resolving HITs to Addresses 🗺️

so when HIP is used in opportunistic mode, the Initiator doesn't know the Responder's HIT, but it does know its IP address 🥹 In most other cases, though, the kernel or applications may know the HITs and not the IP addresses. in those cases, an IP address resolution step for HITs has to happen 🔥

a few techniques have been tried out 🌷 First, OpenDHT can also use HITs as keys for IP address records. Second, work by Ponomarev has shown that the reverse DNS tree can be used for reverse lookups of the ORCHID space [HIT2IP] 🦋 Third, the need for resolution may trigger some kind of HIP bootstrap message, kinda like an Address Resolution Protocol (ARP) message (to resolve the HIT) 🧚 The bootstrap (BOS) packet used to exist in the early revisions of the HIP base specifications, but it got 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. this has triggered warnings on some Windows hosts running antivirus software, because those products classified broadcasts with an 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 the PF_KEY API [RFC2367] 🎀 PK_KEY is a socket protocol family that trusted applications can use to access the IPsec key engine in the operating system. users of this interface typically need sysadmin privileges 👑

the HIP-related extensions to the PF_KEY interface define a new protocol, IPPROTO_HIP 🍓 Their main job 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 don't 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 get lost unless the HIP and IPsec implementation can buffer the packet until the base exchange completes and the IPsec SAs are set up 😬 Losing that data packet when it's a TCP SYN packet results in a TCP timeout [RFC6298], which unnecessarily delays the application. a lost UDP packet can cause even longer timeouts in applications 💀 So it was found to be important for HIP implementations to support buffering the packet. on the flip side, if the HIP base exchange or UPDATE takes longer than 1 second (which is the case on lightweight devices), a spurious timeout can happen at the transport layer 🙃 The HIP implementation could prevent this by manipulating timeout values at the transport layer or, alternatively, by dropping the original or retransmitted duplicate packet 🧠

The multihoming support in [RFC5206] is meant for failover, when a host starts using an alternative locator because the current locator fails 🔁 A host could use this multihoming support for load balancing across different locators, though 👀 Multihoming like that could potentially cause issues with transport protocol congestion control and loss detection mechanisms. However, no experimental results from using HIP multihoming in this way have been reported 🫠

the use of paths with different characteristics can also throw off 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 where the retransmission timeout doesn't match the actual value 😵‍💫 When packets simply experience different RTTs, the variation is high, which sets the retransmission timeout unnecessarily high. When packets get lost, the sender waits excessively long before retransmitting. Fortunately, modern TCP implementations that deploy Selective Acknowledgments (SACKs) and Limited Transmit don't rely on retransmission timeouts except when most outstanding packets are lost 🙌

load balancing across several paths needs some estimate of each path's capacity. The TCP congestion control algorithm assumes that all packets flow along the same path 🛣️ To do load balancing, the HIP layer can try 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, and none are reported to exist 🔬 Different network paths can also have different Maximum Transmission Unit (MTU) sizes. Transport protocols perform MTU discovery typically only at the beginning of a connection. Since HIP hides mobility from the transport layer, packets on the new path can end up fragmented without the transport protocol knowing 😱 To solve this, the HIP layer could inform the transport layer of mobility events. Protocols that 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 of them (HIPL and HIP4BSD) implement Interactive Connectivity Establishment (ICE) techniques [RFC5770] for inbound NAT traversal. It's also been reported that using Teredo [RFC4380] over HIP was simpler than the modifications ICE techniques required, because Teredo effectively shows up 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 NAT traversal implementations for HIP based on ICE techniques proved complicated to implement or integrate, so 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 ✨

Okay so, one thing some experimental implementations aren't handling yet is how to pick a source HIT when you might have several host identities (and some of them might be unpublished) 🫣. It's basically the same vibe as source address selection for transport sockets. How much HIP policy you expose to users is a UI question, and default or automatic configuration guesses could have undesirable privacy implications for the user. Not it 🙅‍♀️

Helsinki University of Technology (TKK, now Aalto) built an extension of the native HIP API to control multiple host identities [thesis.karlsson] 💅. The HIPL development group also found a problem with Linux routing and multiple identities 👀. Linux routing is based on longest prefix match, so having multiple HITs on virtual devices is a problem for access control, because the stack picks the source HIT based on the destination HIT. A coarse-grained fix is to terminate the longest prefix match for ORCHIDs in the Linux networking stack. A more fine-grained solution tries to return a source HIT that matches the algorithm used to generate the destination HIT, which helps stay compatible with new algorithms standardized in the future 🧠.

There are security and privacy issues with storing private keys securely on a host 😬. Current implementations just store private keys in a file that's readable only by applications with root privileges. That might not be enough protection, since keys could be read straight off the disk or by 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 that setup. In a Boeing pilot project, temporary certificates were generated from a key on a USB SIM chip and used in the HIP base exchange. Using certificates in HIP requires extensions to the HIP specifications [RFC6253]. Another option is encrypting keys on disks and keeping a passkey in memory, like Secure Socket Layer (SSL) certificates on servers that ask for a password when Linux boots 🔐.

2.3.8. Interactions with Host Firewalls 🧱

HIP is presently an experimental protocol, and some default firewall configuration scripts on popular Linux distributions don't permit the HIP number 🙃. Figuring out which rules to modify without compromising other policies can be tricky. The default rule set on a previous SuSE Linux distribution was found to contain over one hundred rules, ngl 💀. It may also be the case that the end user has no control over firewall settings, if an enterprise IT department administers them. However, HIP over UDP has eased 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, since the HITs are drawn from the general IPv6 address space using the ORCHID prefix. HITs are statistically unique, but they aren't routable at the IP layer. That means 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. An IPv4 address may be used as an LSI if it's configured to refer to a particular host identity on a given host. Alternatively, LSIs may be drawn from an unallocated IPv4 address range, but a lack of coordination on the LSI space may hinder implementation portability.

HIP makes it possible to use IPv6 applications over the IPv4 network and vice versa 🔁. This is called "interfamily operation" (flexibility between different address families), and it's enabled by the fact that the transport pseudoheader is always based on HITs, 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 turned out to be harder to complete than the single-family processing 😤.

HIP also has the potential to perform cross-family support, where one side of a transport session is IPv6 based and the other 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 implementation in terms of performance and DoS resilience would be useful 🧪. If the kernel implementation is shown to perform significantly better than the user-space one, that may be a sufficient justification to incorporate HIP within the kernel. However, experiences on general purpose laptops and servers suggest 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, it 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. The kernel patch was also 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 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 don't 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, which means 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 (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 🧚

okay so a rendezvous server (RVS) [RFC5204] was implemented by HIIT for HIPL, and there's an OpenHIP implementation too 💅 the idea got extended into a relay server in [RFC5770]. bestie, the early experiments with the HIPL version gave us a few lowkey iconic observations:

  • an RVS may be better than dynamic DNS updates for hosts that change their address rapidly 🦋
  • registering a HIP host with an RVS costs a base exchange 🎀
  • sending UPDATE and CLOSE packets through rendezvous servers is advised, and RVS handling of UPDATE messages can typically solve the double jump [MULTI-HOMED] mobility problem 🫶

there are also some advanced concepts that still need further study, no cap 👀

  • multiple RVSs per host for fault tolerance (e.g., one rendezvous node crashes) and an algorithm for selecting the best RVS 🌸
  • load balancing. an RVS server could distribute I1s to different Responders if the Responder's identity is shared or opportunistic HIP is used 💜
  • offering a rendezvous service in a P2P fashion by HIP hosts 🌈

3.5. Hybrid DNS-DHT Resolution ✨

so we already had pure DNS and pure DHT HIP name resolution, but then someone was like "what if we mix them??" 😭 the hybrid approach keeps the standard DNS interface for clients and adds last-hop DHT resolution underneath. the vibe is that you get the best of both worlds: DNS brings wide deployment and support for legacy applications, and the DHT brings fault tolerance and efficiency when handling flat data keys 🍓

the DHT is typically run internally by the organization that manages the last-hop DNS zone and the DNS server. that means the HITs belonging to that organization can be stored locally by that same organization, which improves deployability of the resolution system 🏠 organizations could also share a DHT between themselves, or connect their DNS servers to a publicly available DHT such as OpenDHT, if they want 🌐 the perk of running a DHT on a local server cluster instead of a geographically spread one is higher performance, because the internal DHT latencies are lower ⚡

the system was prototyped by modifying the BIND DNS server so it redirects queries for HITs to a DHT server 🔥 the interface was implemented in XML according to the specifications in [RFC6537]. and it's completely backward compatible with legacy applications, since the standard DNS resolver interface is used 🫶

performance got tested by running 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. at a low request rate, the average latency of one query request was less than 50 ms, and the secured update latency was less than 100 ms 🦋 but the delay increased exponentially with the request rate, hitting 1 second at 200 requests per second (update rate 0) and almost 2 seconds (update rate 0.5) 💀 the maximum delay also exceeded the mean by several times, which is a lot, bestie 😭

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 the DHT implementation that was used (Bamboo), and it could definitely be 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 let HIP support unmodified applications, so go check that out. here are some extra application considerations 👇

4.1. Non-Intrusive HIP Insertion 🌸

one way to support legacy applications that use dynamic linking is to dynamically interpose a modified resolver library 🪄 using HIPL, several legacy applications were shown to work without any changes, just by dynamically re-linking the resolver library. for example, the Firefox web browser successfully worked with an Apache web server 🦊 the re-linking only requires configuring an LD_PRELOAD system variable, which can be done in a user shell profile file or as a start-up wrapper for an application. this gives the user fine-grained policy control over which applications use HIP 🎛️ that could be 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 that case, the order of linking dynamic libraries must be coded carefully ⚠️

aside: the double LD_PRELOAD thing is the kind of bug that makes you question your whole life, so code the library order carefully, bestie 😭

another method for transparently using HIP has no reported implementation experience yet. it's 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 🦋

there was a concern that FTP would not work due to the problem of application referrals, meaning passing the IP address within application messages. but it was discovered not to be a problem for FTP in practice 🎉 it's shown to work well in both passive and active modes [paper.namespace]. it's still an open question how big of a problem referrals really are in practice 🤔 at least they don't seem to be used on the client side, because clients are behind NATs, so client addresses are unsuitable as referrals 🙃

4.3. Latency ⏱️

some applications may be sensitive to additional RTTs or processing caused by 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 want 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 yet 🤷‍♀️ however, a network provider has brought some HIP issues to the HIP research group. those 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 come up 😬 the operator may prefer to generate the host identity itself, rather than letting each host create its own identities. there are a few reasons for this. public-private key generation is a demanding operation that can take tens of seconds on a lightweight device, like a mobile phone 📱 after generating a host identity, the operator can immediately insert it into its own AAA databases and network firewalls 🔐 this way, users don't have to worry about the technical details of host identity management 🫶

the operator may use a Public Key Infrastructure (PKI) to certify host identities of its customers 🏅 it then uses the private key of an operator's Certificate Authority (CA) to sign the public key of its customers. this way, third parties who possess the public key of the CA can verify the customer's host identity and use that information, e.g., for admission control to infrastructure 🚪 this kind of 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 is still there 😵 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 👀

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 still comply with wiretapping laws, if all sessions are encrypted 🤔 this isn't so much a HIP issue as a general end-to-end encryption issue, bestie 💜

the processing power of mobile devices also has to 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, the transfer without HIP produced 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's also possible to use HIP in a NULL encryption configuration if either SHA1 or MD5 authentication is 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 🔍 those 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 get past 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. that means HIT-based ACLs may be longer (because you can't group hosts with a single entry) and harder for human users to deal with (because of the length of the HIT compared with an IPv4 or IPv6 prefix) 🥴

additionally, operators would like to grant access to 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 🫠

5.4. Firewall Issues ✨

okay so Helsinki University of Technology (TKK, now Aalto) built a HIP firewall on Linux iptables [paper.firewall], and it runs in user-space 🔥

firewalls come in two flavours, bestie. Stateless ones only filter packets based on the ACL, which makes them simple to build and coarse-grained in what they protect. The upside is that they're super efficient, since they barely need any memory or CPU 💅 Stateful firewalls are the main character 👑 They figure out whether a packet belongs to an existing flow or kicks off a new one. A flow identifier mixes info from several protocol headers to sort packets into the right bucket. The firewall drops the state once the flow ends (like when a TCP connection closes) or after a timeout. It can also toss out suspicious packets that fail a checksum or have sequence numbers outside the current sliding window 🫶

A transparent firewall doesn't need the hosts inside the protected network to register with it, or even to know it exists 🦋 An explicit firewall does need hosts to register and authenticate 🎀

Now the HIP-aware firewall that sits in the middle is giving detective 🕵️‍♀️ It identifies flows using the HITs of the communicating hosts, plus SPI values and IP addresses. It has to link the HIP base exchange together with the IPsec ESP data packets that follow. During the base exchange, the firewall learns the SPI values from the I2 and R2 packets. After that, it only lets through ESP packets that carry a known SPI value and arrive from the same IP address the base exchange used. If the host changes its location and its IP address, the firewall (assuming it's still on the path) picks up on the change by following the mobility update packets 🧚

It's also possible to build a stateless, end-host-based firewall that reuses the higher-layer mechanisms already in the system, like access control lists 💜 In this setup, HITs go into the access control lists. The base exchange might fully complete, but ESP doesn't get passed up to the transport layer unless the HITs are allowed in the ACL. so the vibe is "you can say hi, but you're not getting in" 🙈

A HIP host can register with an explicit firewall using the usual procedure [RFC5203] 🌸 The registration lets the host and the firewall authenticate each other. In the common case, where the Initiator and Responder are behind different firewalls, the Initiator may need to register with its own firewall first, and then with the Responder's firewall afterward. two firewalls, one bestie, very layered 🍓

Some researchers have suggested that a firewall guarding security-critical environments should get involved in the base exchange and UPDATE procedures, using middlebox-injected echo requests. Otherwise, the firewall can be circumvented with replay attacks if there's a compromised node inside the network that the firewall is trying to protect [HIP-MIDDLE]. this is a whole security moment 😭🔥

6. User Privacy Issues

okay privacy time, and it's a lot 💜

using public keys to identify hosts creates a privacy problem, because third parties can determine the source host even when it's attached to a different location in the network. Various transactions of the host could get linked together if the host keeps using the same public key. Using a static IP address also lets people link the host's transactions together 🙈 Multiplexing multiple hosts behind a single NAT, or using short address leases from DHCP, can reduce the user-tracking problem. However, IPv6 addresses could reduce how often NAT translation happens, and they can cause extra privacy issues tied to the use of Media Access Control (MAC) addresses in IPv6 address autoconfiguration. HIP does provide for anonymous (unpublished) HITs, for when the Initiator wants to stay anonymous. The catch is that 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 it encrypts its host identity with the Diffie-Hellman-generated keying material and sends it in the I2 packet. Authenticating the R1 stops the active attacker (the impersonator of the Responder), and encrypting the identity stops the passive adversary 🎀 Here's the tea though: the Responder sends its public key unencrypted in the first reply message (R1) to the Initiator, so third-party on-path eavesdroppers can see the Responder's identity. But if the Responder authenticates the Initiator and performs access controls before sending the R1, it can avoid disclosing its public key to an active attacker 🫶

DNS records can provide information that combines host identity and location info, the host public key, and the host IP address. So identity and location privacy are related, and they should be handled in an integrated way 💅 The goal of the BLIND is to provide a framework for identity and location privacy [paper.blind] [HIP-PRIVACY]. Identity protection comes from hiding the actual public keys from third parties, so only the trusted hosts can recognize the keys. Location privacy comes from integrating traffic forwarding with NAT translation and decoupling host identities from locators. Using random IP and MAC addresses also helps with location privacy, which shifts the focus to protecting host identifiers from third parties. This approach is, by its very nature, incompatible with middlebox authentication. (yes, that's a real tradeoff, babe 💀)

To keep the identity hidden, the host public key and its hash (HIT) can be encrypted with a secret key that both Initiator and Responder know beforehand. However, this is a requirement that can't be easily implemented in practice 😭 The BLIND framework protects against both active and passive attackers by 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 ✨

Another way to cut down on the privacy threats of persistent identifiers is to swap them for short-lived identifiers that change regularly, so nobody can track the user 🌈 Identifiers must be changed simultaneously at all protocol layers, though. Otherwise, an adversary could still link the new identifier by looking at an identifier on another protocol layer that stayed the same after the change. The HIP privacy architecture that changes identifiers on the MAC, IP, and HIP/IPsec layers all at once was developed at Helsinki University of Technology (TKK, now Aalto) [thesis.takkinen] 🧚 HIP could be extended in the future to let active sessions migrate identities 💖

7. Experimental Basis of This Report

this report is based on experiences and research results from early adopters, implementers, and research activities 🔥 A bunch of implementations have been in development since 2002 (Section 2), so the research is seriously established 👑

One production-level deployment of HIP has been reported. Boeing described how it uses HIP to build Layer 2 VPNs over untrusted wireless networks [HIPLS] 🦋 This isn't the traditional end-host-based use of HIP. Instead, it uses HIP-aware middleboxes to create ESP tunnels on demand between provider-edge (PE) devices, which is a whole different energy 💅

The InfraHIP II project is deploying HIP infrastructure in the public Internet, including test servers and rendezvous and relay servers 🌸

Here's a possibly incomplete list of past and current research activities related to HIP. Don't worry if it's not 100% complete, the squad is huge 🫶

  • Boeing Research & Technology (J. Ahrenholz, O. Brewer, J. Fang, T. Henderson, D. Mattes, J. Meegan, R. Paine, S. Venema, OpenHIP implementation, Secure Mobile Architecture)
  • NomadicLab, Ericsson (P. Jokela, P. Nikander, J. Melen. BSD HIP implementation)
  • Helsinki Institute for Information Technology (HIIT) (A. Gurtov, M. Komu, A. Pathak, D. Beltrami. HIPL, legacy NAT traversal, firewall, i3, native API)
  • 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) 💜
  • University of California, Berkeley (A. Joseph, HIP proxy implementation)
  • Laboratory of Computer Architecture and Networks, Polytechnic School of University of Sao Paulo, Brazil (T. Carvalho, HIP measurements, Hi3) 🌈
  • Telecom Italia (M. Morelli, comparing existing HIP implementations)
  • NEC Heidelberg (L. Eggert, M. Esteban, V. Schmitt working on RVS implementation, DNS, NAT traversal) ✨
  • University of Hamburg-Harburg (M. Shanmugam, A. Nagarajan, HIP registration protocol)
  • University of Tuebingen (K. Wehrle, T. Lebenslauf to work on Hi3 or HIP-OpenDHT)
  • University of Parma (UNIPR), Department of Information Engineering Parma, Italy. (N. Fedotova, HIP for P2P) 🧚
  • Siemens (H. Tschofenig, HIP middleboxes)
  • Denmark (Aalborg University, Lars Roost, Gustav Haraldsson, Per Toft, HIP evaluation project, OpenDHT-HIP interface) 🍓
  • Microsoft Research, Cambridge (T. Aura, HIP analysis)
  • MIT (H. Balakrishnan. Delegation-Oriented Architecture)
  • Huawei (D. Zhang, X. Xu, hierarchical HIP architecture, HIP proxy, key revocation) 🔥

okay so this section is the "who else is doing this??" tea 🫖 It briefly rounds up related work on the ID-locator split, with extra focus on recent IETF and IRTF activity. Before the research group even existed, academics were already poking at this in proposals like 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 whole namespace question is super controversial 💀 The Namespace Research Group (NSRG) at the IRTF couldn't reach consensus on it, and couldn't even publish a final report. still, almost everyone agrees that for lots of scenarios you need some level of indirection from network name to network location to get decent service 🙌 Mobile IP [RFC6275] reuses an existing namespace for host naming, and since it got finalized, a bunch of new ways to do this indirection have popped up. Even before Mobile IP, the IETF published informational documents describing architectures that separate network name and location, including Jerome Saltzer's work [RFC1498] and Nimrod [RFC1992] 🦋

Now for the recent efforts in the IETF and IRTF:

  • The Site Multihoming in IPv6 (multi6) WG wrote down how multihoming was being done in IPv4 networks and evaluated several approaches for advanced multihoming 🌸 They looked at security threats and the impact on transport protocols along the way. The work carried on in another WG, Site Multihoming by IPv6 Intermediation (shim6), which zoomed in on specifying one chosen approach [RFC5533]. Shim6 puts a shim layer between IP and the transport layers, hiding the effects of changes in the set of available addresses. Applications use 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 specs only define simple multihoming scenarios and leave big stuff like interface selection untouched. Shim6 offers complementary functionality that HIP could reuse [REAP4HIP]. The OpenHIP implementation puts HIP and shim6 in the same framework, with the goal of letting HIP reuse the shim6 failure detection protocol. And HIP and shim6 socket APIs were designed together [RFC6317] [RFC6316] ✨
  • The IRTF Routing Research Group (RRG) has explored a class of solutions to the global routing scalability problem 🗺️ Some split the existing IP address space into identifiers and locators, like LISP [LISP] and Six/One Router [SIX-ONE]. Others push for a fuller separation of those roles, including ILNP [ILNP] and RANGI [RANGI].
  • The End-Middle-End research group looked at 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 talked about whether EME could help HIP get through middleboxes.
  • The IETF Multipath TCP working group is building ways to use multiple paths at once in a regular TCP session 🛣️ MPTCP tries to solve the multihoming problem HIP also addresses, but it only does it for TCP, specifically.
  • The Unmanaged Internet Protocol has a bunch of similarities to the HIP architecture 👀 It focuses on identifiers that aren't centrally managed, and they're also based on a cryptographic hash of a node's public key [thesis.ford].
  • Apple Back To My Mac service gives secure connections between hosts using IPsec between a pair of host identifiers 🍎 Apparently though, 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 never formally set out to compare HIP with other ID-locator split approaches, those conversations happened on other lists, like the Routing research group mailing list 💬 A comparison of HIP's mobility management solution with other approaches was also published in [MOBILITY-COMPARISON].

9. Security Considerations 🔒

Okay, this part is serious bestie, so listen up 🫶 This document is an informational survey of HIP-related research and experience. Space doesn't allow a full accounting of every security issue tied to the approaches covered here 😭 The individually referenced documents may discuss security considerations for their own protocol components. For the base HIP protocol security considerations, go to Section 8 of [RFC5201].

Don't skip the referenced docs, because they're where the real security details live. 🚨

10. Acknowledgments 💜

Big thank-you energy going out to Miika Komu, Pekka Nikander, Ari Keranen, and Jeff Ahrenholz, who gave 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 clarifying Diffie-Hellman privacy properties 🌈 ily all 🫶

11. Informative References 📚

Here's the full reading list, every single reference with all its details, bestie 🧚

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

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

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

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

Okay, the sources! 📚 Every paper, thesis, and book below is part of the proof, so I'm keeping each one exactly as it was written. 💖

  • [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 Protocols, April 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), 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. 🍓
  • [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. 🎓✨
  • [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 ✨

Last but not least, the people who wrote this! 🫶 Here's where you can find them, exactly as listed:

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
📦 where this page comes from