IP Security (IPSec) Authentication Header (AH)

Dr Milan Markovi

Introduction
This presentation examines the IPsec framework and its three main components:
Authentication Header (AH), Encapsulating Security Payload (ESP), and Internet Key Exchange (IKE).

IPsec adds integrity checking, authentication, encryption and replay protection to IP packets. It is used for end-to-end security and also for creating secure tunnels between gateways. IPsec was designed for interoperability. When correctly implemented, it does not affect networks and hosts that do not support it. IPsec is independent of the current cryptographic algorithms; it can accommodate new ones as they become available.

Introduction

It works both with IPv4 and IPv6. In fact, IPsec is a mandatory component of IPv6. IPsec uses state-of-the-art cryptographic algorithms. The specific implementation of an algorithm for use by an IPsec protocol is often called a transform. For example, the DES algorithm used by ESP is called the ESP DES-CBC transform. The transforms, like the protocols, are published in the RFCs. Two major IPsec concepts should be clarified: Security Associations and tunneling.

Security Associations (SA)

An SA is a unidirectional (simplex) logical connection between two IPsec systems, uniquely identified by the following triple:
<Security Parameter Index, IP destination address, security protocol>

The definition of the members is as follows:

Security parameter index (SPI) This is a 32-bit value used to identify different SAs with the same destination address and security protocol. The SPI is carried in the header of the security protocol (AH or ESP). The SPI has only local significance, as defined by the creator of the SA. SPI values in the range 1 to 255 are reserved by the Internet Assigned Numbers Authority (IANA). Generally, the SPI is selected by the destination system during SA establishment. IP destination address This address can be a unicast, broadcast, or multicast IP address. However, currently SA management mechanisms are defined only for unicast addresses. Security protocol This can be either AH or ESP.

Security Associations (SA)

An SA can be in either of two modes, transport or tunnel, depending on the mode of the protocol in that SA. SAs are simplex, hence, for bidirectional communication between two IPsec systems, there must be two SAs defined, one in each direction. A single SA gives security services to the traffic carried by it either by using AH or ESP, but not both. In other words, for a connection that should be protected by both AH and ESP, two SAs must be defined for each direction. In this case, the set of SAs that define the connection is referred to as an SA bundle. The SAs in the bundle do not have to terminate at the same endpoint. For example, a mobile host could use an AH SA between itself and a firewall and a nested ESP SA that extends to a host behind the firewall.

Security Associations (SA)

An IPsec implementation maintains two databases related to SAs: Security Policy Database (SPD) The Security Policy Database specifies what security services are to be offered to the IP traffic, depending on factors such as source, destination, whether it is inbound, outbound, etc. It contains an ordered list of policy entries, separate for inbound and outbound traffic. These entries might specify that some traffic must bypass the IPsec processing, some must be discarded, and the rest must be processed by the IPsec module. Entries in this database are similar to firewall rules or packet filters. Security Association Database (SAD) The Security Association Database contains parameter information about each SA, such as AH or ESP algorithms and keys, sequence numbers, protocol mode and SA lifetime. For outbound processing, an SPD entry points to an entry in the SAD. That is, the SPD determines which SA is to be used for a given packet. For inbound processing, the SAD is consulted to determine how the packet must be processed. The user interface of an IPsec implementation usually hides or presents these databases in a more friendly way.

Tunneling

Tunneling or encapsulation is a common technique in packet-switched networks. It consists of wrapping a packet in a new one. That is, a new header is attached to the original packet. The entire original packet becomes the payload of the new one.

Tunneling
In general, tunneling is used to carry traffic of one protocol over a network that does not support that protocol directly. For example, NetBIOS or IPX can be encapsulated in IP to carry it over a TCP/IP WAN link. In the case of IPsec, IP is tunneled through IP for a slightly different purpose: To provide total protection, including the header of the encapsulated packet. If the encapsulated packet is encrypted, an intruder cannot figure out, for example, the destination address of that packet. (Without tunneling, he or she could.) The internal structure of a private network can be concealed in this way. Tunneling requires intermediate processing of the original packet while en-route. The destination specified in the outer header, usually an IPsec firewall or router, receives the tunneled packet, extracts the original packet, and sends it to the ultimate destination. The processing overhead is compensated by the extra security.

Tunneling
A notable advantage of IP tunneling is the possibility to exchange packets with private IP addresses between two intranets over the public Internet, which requires globally unique addresses. Since the encapsulated header is not processed by the Internet routers, only the endpoints of the tunnel (the gateways) need to have globally assigned addresses; the hosts in the intranets behind them can be assigned private addresses (for example, 10.x.x.x). As globally unique IP addresses are becoming a scarce resource, this interconnection method gains importance.

Authentication Header (AH)

AH is used to provide integrity and authentication to IP datagrams. Replay protection is also possible. Although its usage is optional, the replay protection service must be implemented by any IPseccompliant system. The services are connectionless, that is they work on a per-packet basis. AH is used in two modes, transport mode and tunnel mode. AH authenticates as much of the IP datagram as possible. In transport mode some fields in the IP header change en-route and their value cannot be predicted by the receiver. These fields are called mutable and are not protected by AH.
The mutable IPv4 fields are: Type of service (TOS) Flags Fragment offset Time to live (TTL) Header checksum

When protection of these fields is required, tunneling should be used.

Authentication Header (AH)

The payload of the IP packet is considered immutable and is always protected by AH. AH is identified by protocol number 51, assigned by the IANA. AH processing is applied only to non-fragmented IP packets. However, an IP packet with AH applied can be fragmented by intermediate routers. In this case, the destination first reassembles the packet and then applies AH processing to it. If an IP packet that appears to be a fragment (offset field is nonzero, or the More Fragments bit is set) is input to AH processing, it is discarded. This prevents the so-called overlapping fragment attack, which misuses the fragment reassembly algorithm in order to create forged packets and force them through a firewall. Packets that fail authentication are discarded and never delivered to upper layers. This mode of operation greatly reduces the chances of successful denial of service attacks, which aim to block the communication of a host or gateway by flooding it with bogus packets.

AH Header format

AH Header format
The fields are as follows:
Next header The next header t is an 8-bit field that identifies the type of what follows. The value of this field is chosen from the set of IP protocol numbers defined in the most recent Assigned Numbers RFC from the IANA. In other words, the IP header protocol field is set to 51, and the value which would have gone in the protocol field goes in the AH next header field. Payload length This field is 8 bits long and contains the length of the AH header expressed in 32-bit words, minus 2. It does not relate to the actual payload length of the IP packet as a whole. If default options are used, the value is 4 (three 32-bit fixed words plus three 32-bit words of authentication data minus two). Reserved This field is reserved for future use. Its length is 16 bits and it is set to zero.

AH Header format
Security parameter index (SPI) This field is 32 bits in length. See Security parameter index (SPI) This is a 32-bitvalue used to identify different SAs with the same destination address and security protocol. The SPI is carried in the header of the security protocol (AH or ESP). Generally, the SPI is selected by the destination system during SA establishment. Sequence number This 32-bit field is a monotonically increasing counter, which is used for replay protection. Replay protection is optional; however, this field is mandatory. The sender always includes this field and it is at the discretion of the receiver to process it or not. At the establishment of an SA, the sequence number is initialized to zero. The first packet transmitted using the SA has a sequence number of 1. Sequence numbers are not allowed to repeat. Thus the maximum number of IP packets that can be transmitted on any given SA is 232-1. After the highest sequence number is used, a new SA and consequently a new key is established. Anti-replay is enabled at the sender by default. If upon SA establishment the receiver chooses not to use it, the sender need not be concerned with the value in this field anymore. Typically, the anti-replay mechanism is not used with manual key management.

AH Header format
Authentication data This is a variable-length field containing the Integrity Check Value (ICV), and is padded to 32 bits for IPv4 or 64 bits for IPv6. The ICV for each packet is calculated with the algorithm selected at SA initialization. As its name implies, it is used by the receiver to verify the integrity of the incoming packet. In theory, any MAC algorithm can be used to calculate the ICV. The specification requires that HMACMD5-96 and HMAC-SHA-1-96 must be supported. The old RFC 1826 requires Keyed MD5. In practice, Keyed SHA-1 is also used. Implementations usually support two to four algorithms. When doing the ICV calculation, the mutable fields are considered to be filled with zero.

Keyed MD5 and Keyed SHA-1

HMAC-MD5-96 and HMAC-SHA1-96

AH in Transport Mode

AH in Tunnel Mode

AH in Transport and Tunnel Modes

AH in transport mode In this mode, the authentication header is inserted immediately after the IP header. If the datagram already has IPsec header(s), then the AH is inserted before them Transport mode is used by hosts, not by gateways. Gateways are not required to support transport mode. The advantage of transport mode is less processing overhead. The disadvantage is that mutable fields are not authenticated. AH in tunnel mode With this mode, the tunneling concept is applied, a new IP datagram is constructed and the original IP datagram is made the payload of it. AH in transport mode is applied to the resulting datagram. Tunnel mode is used whenever either end of a security association is a gateway. Thus, between two firewalls, tunnel mode is always used. Gateways often also support transport mode.

AH in Tunnel Modes
This mode is allowed when the gateway acts as a host, that is, in cases when traffic is destined to the gateway itself. For example, SNMP commands could be sent to the gateway using transport mode. In tunnel mode the outer headers' IP addresses do not need to be the same as the inner headers addresses. For example, two security gateways can operate an AH tunnel which is used to authenticate all traffic between the networks they connect together. This is a very typical mode of operation. The advantages of tunnel mode include total protection of the encapsulated IP datagram and the possibility of using private addresses. However, there is extra processing overhead associated with this mode.

HVALA NA PANJI