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