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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide