Packet Level Authentication (PLA) Extensions for Host Identity Protocol (HIP)

Packet Level Authentication (PLA) is a novel security solution that aims to provide availability and integrity protection on the network layer. PLA offers hop-by-hop authentication: any intermediate node has the ability to independently verify authenticity and integrity of the traffic, without pre-established trust relationships with the sender or other nodes that handled the traffic. The good analogy to PLA is a paper currency: anyone can verify validity of the paper bill using built-in security measures such as watermark and hologram, there is no need to contact the bank that has issued the bill. Similarly, PLA allows intermediate nodes to detect modified, delayed, and duplicated packets simply by looking at the packet's contents. This protects the recipient from denial-of-service attacks, since such packets can be dropped immediately before they can reach the destination, and cause a load to the recipient or the recipient's network. Furthermore, strong security mechanisms offered by PLA have additional uses. They can be used to implement simple and secure user authentication, since there is often no need for puzzle mechanisms or to contact external authentication servers. PLA achieves it goals by adding a cryptographic signature and other fields to the packet's header. PLA utilizes elliptic curve cryptography (ECC) due to its compact key and signature sizes, but can also work with other cryptographic solutions. While the public key signature verification is resource intensive operation, it can be performed at wire-speed with a dedicated hardware acceleration . We feel that combining PLA with HIP is advantageous, since both technologies are based on cryptographic operations and provide different sets of features. PLA offers hop-by-hop authentication and integrity protection, and depending on local policies it can make the HIP base exchange unnecessary in some cases. While HIP provides end-to-end confidentiality and security.

Packet Level Authentication (PLA) Extensions for Host Identity Protocol (HIP) basically add PLA's features, such as a hop-by-hop integrity protection, to HIP using a new HIP parameter (PLA_HIP).

Following PLA's security mechanisms are included in the PLA-HIP extensions, and MUST be added to the PLA_HIP parameter by the sender: 1. The sender's cryptographic identity (public key) and the signature over the packet. The signature protects packet's integrity and should be calculated over the whole packet ignoring the fields that may change during the lifetime of the packet. If the signature verification fails, the packet MUST be dropped. While PLA-HIP can utilize any public key algorithms including RSA and DSA, using Elliptic Curve Digital Signature Algorithm (ECDSA) is recommended due to its low key and signature sizes. 2. Timestamp. The aim of the timestamp is provide protection against replay attacks that use delayed packets. Efficient usage of the timestamp field requires loosely synchronized clocks in the network. Network's policy decides how strictly the timestamp is enforced. For example, in a public network differences of several seconds can be tolerated. 3. The sequence number is a monotonically increasing number that allow intermediate nodes to detect duplicated packets, and packets that are significantly out-of-order. It is important to note that performing signature and other above mentioned checks is optional. The recipient and intermediate nodes can decide which checks to perform. For example, some nodes may opt to verify only the timestamp and sequence number fields, ignoring the signature field. Therefore PLA-HIP can also be supported by devices with a limited computing power. PLA also offers additional security mechanisms, such as trusted third parties that act as certificate authorities (CAs) and authorize nodes in the network. For simplicity, they have been omitted from this version of the draft.

The functionality provided by PLA-HIP is somehow related to HICCUPS, SAVAH, and HIP certificates. The biggest difference is that PLA-HIP is a path independent solution that does not use acknowledgment messages, and does not require state for the integrity protection in verifying nodes. Since each packet can be verified independently, PLA-HIP is suitable for multihoming and dynamic network environments.

The following diagram in , shows an example how the PLA-HIP packet is processed in a node. The order of verification steps is not strict, and can be decided by the verifier. PLA-HIP packets are considered to be fully valid if they pass all checks, however, in some cases nodes may forward packets even though they have failed timestamp or sequence number checks.

|Verify timestamp| ----------------------+ +----------------+ | | | | Fail | | | v v /-----------\ Fail +----------------------+ |Drop packet| <------------ |Verify sequence number| \-----------/ +----------------------+ ^ | | | OK | Fail | | | OK +----------------+ | <------------- |Verify signature|-----------------------+ (Out) +----------------+ ]]>

In addition to the basic HIP headers, the PLA-HIP packet contains sender's public key, signature, and timestamp and sequnce number fields provided by the PLA_HIP parameter. Basically the PLA-HIP packet can be expressed as: IP ( HIP ( HOST_ID, PLA_HIP, HIP_SIGNATURE) PAYLOAD ) Where HOST_ID and HIP_SIGNATURE parameters are defined in Sections 5.2.8 and 5.2.11 of . And the PLA_HIP parameter is defined in .

The following is the definition of the PLA_HIP parameter:

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Both the timestamp and sequence number fields are 32 bits long.

No IANA considerations.

No security considerations.

Thanks to Miika Komu for his helpful comments and suggestions.