The vast majority of traffic flowing across both the Internet and across private networks is in someway based on the TCP/IP protocol. The problem with TCP/IP is that it has been around for decades and was never designed to handle the demands being placed upon it. In order to make TCP/IP perform tasks that it was never intended to perform, dozens of protocols have been designed to piggyback on top of, or integrate with the TCP/IP protocol suite. For example, TCP/IP natively sends data in an unencrypted format. When people began to realize the need for encryption, protocols such as IPSec and HTTPS were invented.
Although many of TCP/IP’s shortcomings have been addressed through the creation of additional protocols, one of the most basic shortcomings is just now starting to take shape. The very nature of the TCP/IP protocol binds TCP/IP hosts to a physical location. The problem is that in the last couple of years, mobile computing has become a popular technology, and a protocol that is designed to bind a host to a physical location hardly seems appropriate for mobile computing. Let's look at how a new protocol can help overcome this limitation.
Mobile computing defined
When I mention mobile computing, I am not talking about picking up your laptop and working at the beach. Instead, I am talking about what’s known as end host mobility. In a nutshell, an end host is considered to be mobile if its IP address can change. As you are no doubt aware, there are lots of ways that a host’s IP address can change. For instance, it can be reassigned by a DHCP server; an address can be changed through an IPv6 prefix reassignment or through a NAT remapping, just to name a few methods. The point is that IP addresses change. It’s therefore important to have a protocol that can confirm a host’s identity by looking at something other than its IP address, since IP addresses can change at any time.
One of the proposed solutions to the end host mobility issue is the HIP protocol. Before you can really appreciate HIP though, you need to understand TCP/IP’s shortcomings in a mobile environment.
Two of the primary components of the TCP/IP protocol are the IP address and the Domain Name Server. When someone enters a URL, such as http://www.techrepublic.com/, TCP/IP does not natively understand how to take you to that Web site. Instead, the URL that you entered is passed to a DNS server. The DNS server then queries a database to find the IP address used by the requested Web site.
The IP address is made up of two parts: the network address and the host address. The network address is typically a class A, B, or C address that tells your computer on which network the Web server exists. The host address is the address of the server itself on that network. For example, if a DNS server returned the address, 18.104.22.168, then the 147.100 portion of the address would designate the network address. The computer could then use routing tables to determine how to get a packet from your computer to the network containing the Web server. Once the packet arrives at the network containing the Web server, the other half of the IP address is used to locate the Web server on the remote network.
This is what I mean when I say that an IP address is bound to a physical location. The network portion of the IP address forces packets to follow routing tables to a specific physical network in an effort to locate the requested host. If that host has moved to a different network, then the request will fail because the host can’t be located.
The creation of HIP
This is where the Host Identity Namespace comes into play. A Host Identity Namespace requires any device with an IP stack to have a Host Identifier (HI) that statistically should be globally unique. The host identifier is a 100 bit name that is assigned to the host.
Before I get into the particulars of how Host Identifiers work, I want to point out that a single host can have multiple Host Identifiers. For example, a host might have a well known identifier and an anonymous identifier. Additional identifiers can be self proclaimed or can be asserted through a third party authenticator, such as DNSSEC.
The reason why it is possible for a third-party authentication service to validate a host identity is because the host identity is based on public key cryptography. This means that not only can the host ID be validated by an authenticator; host IDs can also be used as a cryptography mechanism. For example, it would be possible for two hosts to communicate with each other using the IPSec protocol. In this instance, the host identifier is a public key and can therefore be used to authenticate IPSec packets.
The HIP protocol is made possible because it binds the TCP/IP transport layer protocols differently than what is currently done. In TCP/IP, TCP and UDP connections are bound to IP addresses. Once the HIP architecture is in place though, these connections are bound to the Host ID rather than to the IP address. This is possible because the HIP architecture breaks apart the internetworking and transport layers of the TCP/IP protocol stack.
As I explained earlier, IP addresses have two main components, and thus two separate roles. These roles could be defined as locators and end point identifiers. When the HIP architecture is put into place though, the IP address still functions as the locator. However, the host identifier takes over the role of endpoint identifier. This allows a host to be uniquely identified regardless of its IP address.
HIP rendezvous server
Endpoint identification aside, the question remains how do you go about identifying a host whose IP address is changing? If the hosts on your network don’t tend to change IP addresses very often, you could use Dynamic DNS to map host names to IP addresses. In a HIP architecture though, a DNS server is still a major component, but a new component called the HIP rendezvous server is also used.
A HIP rendezvous server is used as a go-between for the endpoint and the DNS server. The HIP rendezvous server works similarly to a proxy server. In a normal TCP/IP environment, the DNS server maintains a list of each host name and its corresponding IP address. In a HIP environment though, the DNS still contains records for each host. The difference is that these entries don’t contain the host’s IP address. Instead, they contain the IP address of the HIP rendezvous server. The rendezvous server in turn maintains its own database of host names and IP addresses. Each time that a host changes IP addresses, the rendezvous server’s tables are updated. This way, when an inbound request arrives for a mobile host, the request is sent to the rendezvous server. The rendezvous server then looks up the host’s current IP address and forwards the packet to the host.
Enhanced mobile security
A final benefit to HIP is the protocol is based on public keys, which makes it very easy to encrypt traffic from end point to end point. Furthermore, the protocol is also perfect for authenticating a host’s identity even though its IP address may change. These features make HIP perfect for environments that use wireless networking.
Most wireless access points use DHCP servers to assign IP addresses to wireless clients. Consequently, you never know what address a wireless client will be using. Protocols such as WEP and WAP are currently used to secure wireless communications, but these protocols only encrypt traffic flowing between wireless hosts or between a wireless host and an access point. The fact that HIP is public key-based means that communications could be encrypted from end point to end point regardless of whether the packet is flowing across a wireless or a wired connection.