Host Identity Protocol for Linux

An IP address determines the name and network location of a computer on the Internet. The network stack reuses this IP address at all layers, including the application layer. As a consequence, existing network connections break when an IP address changes. For example, suppose you are streaming a video from your favorite Web site and you switch from a WLAN to LAN connection. Then, your host's IP address changes and breaks the stream. This happens because the video-streaming application and the host use different IP addresses. Even though the host uses the new IP address, the application still uses the old address.

What creates this problem in the current Internet architecture? The IP address specifies both the name and the topological location of a host on the Internet. Here's an analogy: a person named Abhinav Pathak who lives in New Delhi should still be called Abhinav Pathak when he is visiting London. As simple as it may seem, this analogy currently does not work on today's Internet.

Host Identity Protocol (HIP) assigns a permanent, location-independent name to a host. HIP names a host essentially using a public key, which is referred to as Host Identity in HIP literature. As public keys are quite long, usually it is more convenient to use a 128-bit fingerprint of the HI, which is called the Host Identity Tag (HIT). The HIT resembles an IPv6 address, and it gives the host a permanent name. The Internet Assigned Numbers Authority (IANA) allocated an IPv6 address prefix for HITs (2001:0010::/28).

The HIT is similar to an SSH fingerprint, but unlike SSH, it can be used by all applications. HIP also supports IPv4-compatible names called Local Scope Identifiers (LSIs). HITs in HIP are statistically unique and inherently secure because they are derived from public keys and, therefore, are difficult to forge.

In HIP, sockets in transport protocols, such as TCP, are bound to HITs rather than IP addresses. The networking stack translates the HITs to IP addresses before packet transmission on the wire. The reverse occurs on the host receiving HIP packets. When the host changes the network, the networking stack changes the IP address for the translation. The application doesn't notice the change because it is using the constant HIT. This is how HIP solves the problem of host mobility.

HIIT has developed an implementation of HIP for Linux (HIPL), which is available from the InfraHIP II Web pages. In this article, we describe how you can benefit from HIP and explain how to install and run HIP on your Linux system.

Linux is ported to many platforms and devices, such as laptops, smartphones and PDAs. These devices are mobile but usually lack mobility support from the networking stack. Many networking applications on Linux don't provide communications privacy either. HIP solves both of these problems and also provides support for multihomed hosts. Here, we describe four practical problems that HIP solves.

Access to host services usually is constrained using IP addresses. For example, consider the access control files for Linux. The hosts.allow and hosts.deny files contain the service names and hostnames (or IP addresses) of the hosts that are allowed to access certain services.

Suppose a server grants permission to a particular client to access its remote services, such as SSH, FTP and so on. It specifies its hosts files as follows:

$ cat /etc/hosts.deny
ALL: ALL

$ cat /etc/hosts.allow
ALL: 10.0.0.10

This states that only a client with an IP address of 10.0.0.10 is allowed to access services running on this host. All other IPs are blocked.

Now, what happens when the client with IP 10.0.0.10 moves to a new network and its IP address changes? Or, what happens if its DHCP lease time expires and it is granted another IP address? In such cases, the client would no longer be able to access the server. Either it has to regain its IP address or the server has to update its hosts.allow and hosts.deny files.

HIP easily solves this problem. The server's /etc/hosts.allow file contains the HIT of the client instead of the IP address. The client has the same HIT independent of its IP address and, hence, its network location. The entry in the /etc/hosts.allow file looks like this with HIP:

$ cat /etc/hosts.allow
ALL: [2001:15:e156:8a78:3226:dbaa:f2ff:ed06]

This shows that the client with the HIT (that is, name) 2001:15:e156:8a78:3226:dbaa:f2ff:ed06 is allowed to access the services on the server.

The HIP software running on the server uses public keys to authenticate the client before the client can use a particular service. A crucial part of the authentication is for the server to check that the client's HIT (fingerprint) matches the public key. This way, the server can cryptographically verify that the client is the one it claims to be.