How HIP Works

1 Introduction

The current Internet has two global name spaces, domain names and IP addresses. IP addresses are used as both topological locators and network interface identities. The dual role of IP addresses limits the flexibility of the Internet architecture and makes mobility and IP address renumbering difficult. In particular, transport protocols are bound to IP addresses and disconnect when an address changes.

The Host Identity Protocol (HIP) architecture RFC4423 (see Figure 1) defines a new global Internet name space. The Host Identity name space decouples the name and locator roles currently filled by IP addresses. With HIP, the transport layer operates on Host Identities instead of using IP addresses as endpoint names. At the same time, the network layer uses IP addresses as pure locators.

Figure 1 Figure 1

HIP provides end-to-end opportunistic security, resistance to CPU and memory exhausting denial-of-service (DoS) attacks, mobility and multi-address multihoming.

2 HIP in a nutshell

The Host Identity layer is added as a waist between the transport layer and network layer. Each HIP-enabled host has one or more host identifiers (HIs). The HI is a public key. A host identifier is represented by a 128-bit long identifier, the Host Identity Tag (HIT). A HIT is constructed by applying a cryptographic hash function over the public key. In HIP, sockets are bound to HIs rather than IP addresses. IP addresses are used to route packets just as today.

2.1 The Protocol Overview

The actual Host Identity Protocol (HIP) is composed of two-round-trip, end-to-end Diffie-Hellman key exchange protocol, a mobility exchange and some additional messages. The purpose of the HIP base exchange (see Figure 2) is to create assurance that the peers indeed possess private keys corresponding to their host identifiers (public keys). In consequence, the base exchange creates a pair of IPSec Encapsulated Security Payload (ESP) Security Associations (SAs), one in each direction.

Figure 2 Figure 2

We can describe this process in following steps:
I --> Directory: lookup R
I <-- Directory: return R's address and HI/HIT
I1    I --> R (Hi, Here is my I1, let's talk with HIP)
R1   R --> I (Ok, Here is my R1, handle this HIP cookie)
I2    I --> R (Computing, here is my counter I2)
R2   R --> I (OK. Let's finish HIP with my R2)
I --> R (ESP protected data)
I --> I (ESP protected data)

2.2 The Overall Picture

Figure 2 shows the process of base exchange. First the initiator looks up HI/HIT of the responder from DNS or RVS (Rendezvous Server). Figure 3 depicts the procedure for HIP with DNS. On the client side, the application sends DNS query to a DNS server. The DNS server replies with HI (FQDN->HI) instead of IP address. In a second step, another lookup is made in the Host Identity layer by the HIP daemon. This time, Host Identities are translated into IP addresses (HI->IP) for network layer delivery.

Figure 3 Figure 3

The transport protocol sends a packet containing server's HI. The Host Identity layer replaces the HI with corresponding IP address of the server. The network layer transmits this packet with an IP header. Accordingly, the 5-tuple socket becomes {protocol, source HI, source port, destination HI, destination port} from conventional {protocol, source IP, source port, destination IP, destination port}.

HIP uses a special IPsec ESP mode called Bound End-to-end Tunnel (BEET). The new mode provides limited tunnel mode semantics without the regular tunnel mode overhead.

3 Mobility

Since the SAs are not bound to IP addresses, the host is able to receive packets that are protected using a HIP-created ESP SA from any address. Thus, a host can change its IP address and continue to send packets to its peers. Figure 4 depicts the mobility process. In the beginning, the mobile host is at address 1 and it moves to the address 2 later. During the mobility process, the mobile host is disconnected from the peer host for a brief period of time while it switches from address 1 to address 2. Upon obtaining a new IP address, the mobile host sends a LOCATOR parameter to the peer host in an UPDATE message. The LOCATOR indicates the new IP address, the SPI associated with new IP address, the address lifetime and whether the new address is a preferred address. The peer host performs an address check and solicit a response from the mobile host. Depending on whether the mobile host has initiated a rekey, and on whether the peer host itself wants to rekey to verify the mobile host's new address, the process can be categorized into three cases:
(1) Readdress without rekeying, but with an address check, as in Figure 4;
(2) Readdress with a mobile-initiated rekey; and
(3) Readdress with a peer-initiated rekey.
Figure 4 Figure 4

4 Multihoming

A host can sometimes have more than one interface. The host may notify the peer host of the additional interfaces by using the LOCATOR parameter. In Figure 5 we assume that the multihoming host has two IP addresses, addr1 and addr2. Further, we assume that addr1 is the preferred address. The multihoming host sends an UPDATE packet including addr1 and addr2 to its peer host. The peer host sends UPDATE packets to each address and updates corresponding SPIs.
Figure 5 Figure 5

Valid XHTML 1.0 Strict