Host Identity Protocol for Linux
HIP authenticates and secures communication between two hosts. HIP authenticates hosts and establishes a symmetric key between them to secure the data communication. The data flow between the end hosts is encrypted by IPsec Encapsulating Security Payload (ESP) with the symmetric key set up by HIP. HIP introduces mechanisms, such as cryptographic puzzles, that protect HIP responders (servers) against DoS attacks. Applications simply need to use HITs instead of IP addresses. Application source code does not need to be modified.
HIP provides transparent mobility support for existing network applications. TCP connections are bound to HITs instead of IP addresses. HITs do not change for a given host. HITs are further mapped to IP addresses. When an IP address changes, new mappings between the HIT and the new IP address are formed. When a host moves to a new network and obtains a new IP address, the host informs its peers about its new IP address, and TCP connections are sustained.
WLAN access points and broadband modems employ NATs due to the lack of IPv4 addresses. However, you have to configure your NAT settings manually if you want to use P2P software or connect to your computer behind a NAT. It may even be impossible if your ISP employs a second NAT.
With HIP, hosts can address each other with HITs across private address realms of NATs. HIP makes use of two alternative NAT traversal technologies, ICE and Teredo, to traverse the NATs. Setting up a server behind a NAT using HIP does not require manual configuration of the NAT. The HIPL on-line manual infrahip.hiit.fi/hipl/manual/ch21.html describes the details.
The InfraHIP site offers free services for the HIP community. For example, you can register your HIT to the DNS or Distributed Hash Table (DHT). The site also offers free HIP forwarding services to assist in NAT traversal and locating mobile nodes.
The Host Identity Protocol architecture (Figure 1) defines a new namespace, the Host Identity namespace, which decouples the name and locator roles of IP addresses. With HIP, the transport layer operates on host identities instead of IP addresses as endpoint names. The host identity layer is between the transport layer and the network layer. The responsibility of the new layer is to translate identities to routable locators before a host transmits the packet. The reverse applies to incoming packets.

Figure 1. The Host Identity layer is located between the transport and network layers.
The actual Host Identity Protocol (HIP) is composed of a two round-trip, end-to-end Diffie-Hellman key-exchange protocol, called base exchange, mobility updates and some additional messages. The networking stack triggers the base exchange automatically when an application tries to connect to an HIT.

Figure 2. HIP Base Exchange
During a base exchange, a client (initiator) and a server (responder) authenticate each other with their public keys and create symmetric encryption keys for IPsec to encrypt the application's traffic. In addition, the initiator must solve a computational puzzle. The responder selects the difficulty of the puzzle according to its load. When the responder is busy or under DoS attack, the responder can increase the puzzle difficulty level to delay new connections.
We can describe this process as follows:
I --> DNS: lookup R I <-- DNS: return R's address and HI/HIT
The initiator application connects to an HIT:
I1 I --> R (Hi, Here is my I1, let's talk with HIP) R1 R --> I (OK, Here is my R1, solve this HIP puzzle) I2 I --> R (Computing, here is my counter I2) R2 R --> I (OK. Let's finish base exchange with my R2) I --> R (ESP protected data) R --> I (ESP protected data)
HIP provides a mechanism similar to base exchange to handle IP address changes. When a host detects a new IP address, it informs all its peers of the address change. The hosts adjust their IPsec security associations accordingly, and the applications running on the hosts continue sending data to each other as if nothing happened.
When two hosts are connected to each other using HIP and one of them moves, the mobile host tells its current location to the other. If both hosts move at the same time, they can lose contact with each other. In this case, an HIP rendezvous server assists the hosts. The rendezvous server has a fixed IP address and, therefore, it offers a stable contact point for mobile hosts. The rendezvous server relays only the first packet, and after the contact, the hosts can communicate with each other directly. HIP includes another similar service, called HIP Relay, that forwards all HIP packets to support NAT traversal.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Designing Electronics with Linux | May 22, 2013 |
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
- Linux Systems Administrator
- New Products
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Web & UI Developer (JavaScript & j Query)
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Featured Jobs
| Linux Systems Administrator | Houston and Austin, Texas | Host Gator |
| Senior Perl Developer | Austin, Texas | Host Gator |
| Technical Support Rep | Houston and Austin, Texas | Host Gator |
| UX Designer | Austin, Texas | Host Gator |
| Web & UI Developer (JavaScript & j Query) | Austin, Texas | Host Gator |
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?





4 hours 18 min ago
8 hours 49 min ago
8 hours 50 min ago
10 hours 50 min ago
19 hours 35 min ago
20 hours 9 min ago
21 hours 8 min ago
21 hours 58 min ago
1 day 2 hours ago
1 day 5 hours ago