Overview

From OpenHIP
Jump to: navigation, search

Main Page - Overview - Installation - Configuration - Usage - Contributing - Doxygen - Links

Implementation architecture

Note: as of OpenHIP 0.9, the kernel mode is no longer supported.

There are two ways to run this HIP software, depending on your operating system and whether or not you want to patch your kernel:

  1. entirely in userspace, for Linux (user-mode HIP, or UMH) and Windows XP (HIP for Windows service or console app) and Mac OS X
  2. with kernel support, for Linux only

Recently, the userspace implementations have received most development attention and have more features.

Both architectures consist of a user-space HIP daemon (hip) that implements the control plane protocol. The main difference is in the data plane; the userspace version does all ESP encryption of data packets in userspace, while the Linux kernel version uses patches to IPsec tools and a kernel patch to extend/reuse the Linux ESP implementation.

The HIP daemon requires the following libraries (the most recently tested version are listed in parenthesis, but these exact versions are not required):

  • openssl (0.9.8g) cryptographic libraries
  • libxml2 (2.6.32) XML libraries
  • (kernel mode only) libipsec from ipsec-tools 0.6.6 patched with ipsec-tools-0.6.6-hip.patch

The XML library is used for generating and parsing all of hipd's configuration files. The cryptographic library provides hashing (SHA, MD5, HMAC), encryption (3DES, BLOWFISH, AES), and public key signing/verification (RSA, DSA). Libipsec is used to send PFKEY messages to the Linux kernel that manage the IPsec security associations.

Userspace implementation

The userspace implementation does not require any changes to the kernel, because all of the IPsec processing is done in a user process. A virtual device, the TAP driver, is used to pick packets destined to LSIs and send them to the HIP process. While this makes installation easier, the drawback is reduced performance as each user packet in a HIP association needs to be copied from user memory to the kernel, processed and sent back to the kernel to the real network interface.

Hipumh-arch.gif

Unlike the Linux version with kernel support, applications must connect using 32-bit LSIs or 128-bit HITs to use HIP. The LSIs are of the form 1.x.x.x, where the last 24-bits are either the lower 24-bits of the HIT or some value specified in the identities file. A 1.0.0.0/8 route directs packets to the TUN/TAP driver (Linux) or the TAP-Win32 driver (Windows), where they are sent to a listening socket in the HIP process. The HIP process features multiple threads for handling traffic input and output, and PFKEY and netlink functions that are normally services provided by the Linux kernel. This was designed in a manner such that the HIP daemon code (hipd) can be completely reused, running as a single thread in this HIP userspace process.

The TAP driver is already included in the latest Linux kernels. For Windows, you may need to download and install the TAP-Win32 driver.

  • TAP-Win32 (9.0.0.4 1/22/2008) virtual device driver from OpenVPN (newer TAP-Win32 v9 adapters should also work)

Linux kernel support

Note: as of OpenHIP 0.9, the kernel mode is no longer supported.

If you are running Linux and patch your kernel to support HIP, you will benefit from higher performance. Kernel support adds the requirement:

  • Linux kernel 2.6.13.5 patched with linux-2.6.13.5-hip.patch
Hip-arch.gif

In this release, Linux applications connect to IP addresses and IPsec (SPD) policies control whether or not HIP is used. The ipsec-tools setkey utility is used to set up a policy requiring a HIP ESP tunnel for traffic destined for a specified peer. When packets are sent to that peer and match the policy entry, the kernel notifies hipd, hipd performs the HIP protocol handshake with the peer and sets up the Security Association using the native IPsec support from the 2.6 kernel. (The kernel should hold these first trigger packets, but the IPsec developers have not implemented this yet.) The resulting pair of SAs (incoming and outgoing) is associated with the HIT, so the underlying IP addresses may change without re-establishing the SAs.

Conformance

See the Release Notes for information on the conformance of specific OpenHIP releases. Some of the HIP specifications are still evolving, so the state of software conformance may change over time. Generally this software implements the following RFCs:

  • RFC 5201 Host Identity Protocol
  • RFC 5202 Using the ESP Transport Format with HIP
  • RFC 5203 Registration Extensions
  • RFC 5204 HIP Rendezvous Extension
  • RFC 5206 End-Host Mobility and Multihoming with HIP
  • RFC 5770 Basic HIP Extensions for NAT Traversal (without STUN integration)

These Internet Drafts have been implemented (note that some of these drafts are outdated):

  • draft-melen-hip-mr-02.txt
  • draft-irtf-hiprg-dht-04.txt
  • draft-nikander-hiprg-hi3-00.txt

Interoperability

This software has been tested with three other implementations in the past, see the Interoperability page.

To verify the operation of your HIP installation, you can visit the Boeing HIP test server at:

http://hipserver.mct.phantomworks.org/

The test server was established to check interoperability among the other implementations. For more information on using the server, please visit the URL shown above.

Files

The hip-n.n.tgz source distribution contains these directories:

  • docs - Doxygen support files.
  • conf - default configuration files.
  • src - all of the source code.
    • src/include - header files.
    • src/linux - Linux-specific code and packaging.
    • src/mac - OS X-specific code.
    • src/protocol - HIP protocol code.
    • src/usermode - User-mode threads that implement ESP, PFKEY, and Netlink functionality.
    • src/util - Utility code, hitgen, scripts.
    • src/win32 - Windows-specific code and installer.