Host Identity Protocol - State-of-the-Art Multihoming Protocols and Support for Android

src ULID(A)=L1(A) dst ULID(B)=L1(B) ULP src L2(A) dst L3(B) Multihoming shim IP Receiver B src ULID(A)=L1(A) dst ULID(B)=L1(B) ULP src L2(A) dst L3(B) Multihoming shim IP

Figure 2.2: SHIM6Mapping with Changed Locators

In order to enable that, an Application Programming Interface (API) has been defined to enable greater control and information exchange for those applications that need it [40].

2.2 Host Identity Protocol

The Host Identity Protocol (HIP) allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IPaddresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Sigma-compliant Diffie-

Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to Denial-of-Service (DoS) and Man-in-the-Middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCPand UDP [37].

2.2.1

HIP

Architecture

The Internet has two important global namespaces: IP addresses and DNS names. These two namespaces have a set of features and abstractions that have powered the Internet to what it is today. They also have a number of weaknesses. Moreover, semantic overloading and functionality extensions have greatly complicated these namespaces.

The Host Identity namespace fills an important gap between the IP and DNS namespaces: it consists of Host Identifiers. A Host Identifier (HI) is cryptographic in its nature—it is the public key of an asymmetric key-pair. Each host will have at least one Host Identity, but it will typically have more than one. Each Host Identity uniquely identifies a single host (e.g. two hosts cannot have the same Host Identity). The Host Identity, and the corresponding Host Identifier, can be either public (e.g. published in the DNS) or unpublished. Client systems will tend to have both public and unpublished Identities.

There is a subtle but important difference between Host Identities and Host Identifiers. An Identity refers to the abstract entity that is identified. An Identifier, on the other hand, refers to the concrete bit pattern that is used in the identification process.

When HIP is used, the actual payload traffic between two HIP hosts is typically, but not necessarily, protected with IP Security (IPSec). The Host Identities are used to create the needed IPSec Security Associations and to authenticate the hosts. WhenIPSecis used, the actual payloadIPpackets do not differ in any way from standardIPSec-protected IP packets [36].

2.2 Host Identity Protocol 21 FQDN or IP Address IP Address, Port IP Address Application Transport Network IP FQDN or Host ID Host ID, Port

Host ID IP Address

HIP

MAC Address

Physical MAC Address

Host Identity

Figure 2.3: HIP Architecture

the Host Identity Tag (HIT). As said, the HI is a public key and directly represents the Identity. Since there are different public key algorithms that can be used with different key lengths, theHIis not good for use as a packet identifier, or as an index into the various operational tables needed to support HIP. Consequently, a hash of the HI, the HIT, becomes the operational representation. It is 128b long and is used in the HIPpayloads and to index the corresponding state in the end hosts. The HIThas an important security property in that it is self-certifying [37].

2.2.2

HIP

Base Exchange

The HIP base exchange is a two-party cryptographic protocol used to establish communications context between hosts. The base exchange is a Sigma- compliant four-packet exchange. The first party is called the Initiator and the second party the Responder. The four-packet design helps to make HIP DoS resilient. The protocol exchanges Diffie-Hellman keys in the 2nd _and

3rd _{packets, and authenticates the parties in the 3}rd _{and 4}th _{packets. Ad-}

the Initiator completing it in the 3rd _{packet before the Responder stores any}

state from the exchange.

Initatior

Responder

I1 < HIT(I), HIT(R) or NULL >

< HIT(I), HIT(R), challenge >

I2 < HIT(I), HIT(R), response, authentication >

< HIT(I), HIT(R), authentication >

R2 Security Context established

ESP protected message

Figure 2.4: HIPfour-way handshaking

The exchange can use the Diffie-Hellman output to encrypt the Host Identity of the Initiator in the 3rd _{packet or the Host Identity may instead be}

sent unencrypted. The Responder’s Host Identity is not protected. It should be noted, however, that both the Initiator’s and the Responder’s HITs are transported as such (in cleartext) in the packets, allowing an eavesdropper with a priori knowledge about the parties to verify their identities. Data packets start to flow after the 4th _{packet. The 3}rd _{and 4}th _HIP _{packets may}

carry a data payload in the future. However, the details of this are to be defined later as more implementation experience is gained.

Finally,HIPis designed as an end-to-end authentication and key establish- ment protocol, to be used withESP and other end-to-end security protocols,

2.2 Host Identity Protocol 23 but the base protocol does not cover all the fine-grained policy control found in Internet Key Exchange (IKE) (that, for example, allows IKE to support complex gateway policies). Thus, HIPis not a replacement for IKE [37].

2.2.3 End-host Mobility and Multihoming

Architecturally, HIP provides for a different binding of transport-layer protocols. That is, the transport-layer associations (e.g. TCP connections and UDPassociations) are no longer bound toIPaddresses but to Host Identities. It is possible that a single physical computer hosts several logical end- points. With HIP, each of these end-points would have a distinct Host Iden- tity. Furthermore, since the transport associations are bound to Host Iden- tities, HIP provides for process migration and clustered servers. That is, if a Host Identity is moved from one physical computer to another, it is also possible to simultaneously move all the transport associations without break- ing them. Similarly, if it is possible to distribute the processing of a single Host Identity over several physical computers,HIPprovides for cluster-based services without any changes at the client end-point.

As said, HIPdecouples the transport from the internetworking layer, and binds the transport associations to the Host Identities. Consequently, HIP can provide for a degree of internetworking mobility and multihoming at a low infrastructure cost. HIP mobility includes IP address changes (via any method) to either party. Thus, a system is considered mobile if itsIPaddress can change dynamically for any reason like Point-to-Point Protocol (PPP), Dynamic Host Configuration Protocol (DHCP),IPv6prefix reassignments, or a NAT device remapping its translation. Likewise, a system is considered multihomed if it has more than one globally routable IPaddress at the same time. HIPlinksIPaddresses together, when multipleIPaddresses correspond to the same Host Identity, and if one address becomes unusable, or a more preferred address becomes available, existing transport associations can easily be moved to another address.

When a node moves while communication is already ongoing, address changes are rather straightforward. The peer of the mobile node can just

accept a HIP or an integrity protected IPSec packet from any address and ignore the source address. However, a mobile node must send aHIPreaddress packet to inform the peer of the new address(es), and the peer must verify that the mobile node is reachable through these addresses [36].

More lately, Pierrel et al. introduced a policy system for simultaneous multiaccess based on HIPcalled HIPSImultaneous Multi-Access (SIMA) [43]. The proposal extends HIP by allowing flows to use different paths indepen- dently of each other, since HIP does not support load sharing. To enable flow distribution, flows are identified by source and destination ports and by the HIT. The RendezVous Server is also extended to be able to store flow policies. Whilst these policies define the usage rules of the available inter- faces, the proposal does not detail the policy specification (e.g. rules actions, interface priority, and cost) [50].

In document State-of-the-Art Multihoming Protocols and Support for Android (Page 31-36)