Internet.Security

252 INTERNET SECURITY

Security Parameters Index (SPI)

(32 bits)

Sequence number (32 bits)

Authentication data (variable)

Figure 7.4 IPsec AH format.

• Payload length (8 bits): This field specifies the length of the AH in 32-bit words, minus 2. The default length of the authentication data field is 96 bits, or three 32-bit words. With a three-word fixed header, there are a total of six words in the header, and the payload length field has a value of 4.

• Reserved (16 bits): This field is reserved for future use. It must be set to ‘zero’.

•SPI (32 bits): This field uniquely identifies the SA for this datagram, in combination with the destination IP address and security protocol (AH).

The set of SPI values in the range 1 – 255 is reserved by the IANA for future use. The SPI value of zero (0) is reserved for local, implementation-specific use. A key management implementation may use the zero SPI value to mean ‘No Security Association Exists’ during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established.

•Sequence number (32 bits): This field contains the monotonically increasing counter value which provides an anti-replay function. Even if the sender always transmits this field, the receiver need not act on it, i.e. processing of the sequence number field is at the discretion of the receiver. The sender’s counter and the receiver’s counter are initialised to zero when an SA is established. The first packet sent using a given SA will have a sequence number of 1. The sender increments the sequence number for this SA and inserts the new value into the sequence number field.

If anti-replay is enabled, the sender checks to ensure that the counter has not cycled before inserting the new value in the sequence number field. If the counter has cycled, the sender will set up a new SA and key. If the anti-replay is disabled, the sender does not need to monitor or reset the counter. However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over to zero.

•Authentication data (variable): This field is a variable-length field that contains the Integrity Check Value (ICV) or MAC for this packet. This field must be an integral

multiple of 32-bit words. It may include explicit padding. This padding is included to ensure that the length of AH is an integral multiple of 32 bits (IPv4) or 64 bits (IPv6).

7.2.2 AH Location

Either AH or ESP is employed in two ways: transport mode or tunnel mode. The transport mode is applicable only to host implementations and provides protection for upper-layer protocols. In the transport mode, AH is inserted after the IP header and before an upperlayer protocol (TCP, UDP or ICMP), or before any other IPsec header that may have already been inserted.

In the IPv4 context, AH is placed after the original IP header and before the upper-layer protocol TCP or UDP. Note that an ICMP message may be sent using either the transport mode or the tunnel mode. Authentication covers the entire packet, excluding mutable fields in the IPv4 header that are set to zero for MAC computation. The positioning of AH transport mode for an IPv4 packet is illustrated in Figure 7.5(a).

In the IPv6 context, AH should appear after hop-to-hop, routing and fragmentation extension headers. The destination options extension header(s) could appear either before or after AH, depending on the semantics desired. Authentication again covers the entire packet, excluding mutable fields that are set to zero for MAC computation. The positioning of AH transport mode for an IPv6 packet is illustrated in Figure 7.5(b).

Tunnel mode AH can be employed in either hosts or security gateways. When AH is implemented in a security gateway to protect transit traffic, tunnel mode must be used. In tunnel mode, the inner IP header carries the ultimate source and destination addresses, while an outer IP header may contain different IP addresses (i.e. addresses of firewalls or other security gateways). In tunnel mode, AH protects the entire inner IP packet, including the entire inner IP header. The position of AH in tunnel mode, relative to the outer IP header, is the same as for AH in transport mode. Figure 7.5(c) illustrates AH tunnel mode positioning for typical IPv4 and IPv6 packets.

7.3 IP ESP

The ESP header is designed to provide security services in IPv4 and IPv6. ESP can be applied alone, in combination with the IP AH or through the use of tunnel mode. Security services are provided between a pair of hosts, between a pair of security gateways or between a security gateway and a host.

The ESP header is inserted after the IP header and before the upper-layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode).

ESP is used to provide confidentiality (encryption), data authentication, integrity and anti-replay service, and limited traffic flow confidentiality. Confidentiality could be selected independent of all other services. However, use of confidentiality without integrity/ authentication may subject traffic to certain forms of active attacks that undermine the confidentiality service. Data authentication and integrity are joint services offered as an option with confidentiality. The anti-replay service is chosen only if data origin authentication

within a 32-bit word to ensure that the authentication data field is aligned on a 32-bit boundary.

The sender may add 0 – 255 bytes of padding. Inclusion of the padding field in an ESP packet is optional, but all implementations must support the generation and consumption of padding. For the purpose of ensuring that either the bits to be encrypted are a multiple of the algorithm’s blocksize or the authentication data is aligned on a 32-bit boundary, the padding is applied to the payload data exclusive of the IV, the pad length and next header fields.

The padding bytes are initialised with a series of integer values such that the first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes following a monotonically increasing sequence: 1, 2, 3, . . .. When this padding scheme is employed, the receiver should inspect the padding field. Any encryption algorithm requiring padding must define the padding contents, while any required receiver must process these padding bytes in specifying how the algorithm is used with ESP. In such circumstances, the encryption algorithm and mode selected will determine the content of the padding field. Subsequently, a receiver must inspect the padding field and inform senders of how the receiver will handle the padding field.

•Pad length: This field indicates the number of pad bytes immediately preceding it. The range of valid values is 0 – 255, where a value of 0 indicates that no padding bytes are present. This field is mandatory.

• Next header (8 bits): This field identifies the type of data contained in the payload data field, i.e. an extension header in IPv6 or an upper-layer protocol identifier. The value of this field is chosen from the set of IP numbers defined by the IANA. The next header field is mandatory.

•Authentication data (variable): This is a variable-length field containing an ICV computed over the ESP packet minus the authentication data. The length of this field is specified by the authentication function selected. The field is optional and is included only if the authentication service has been selected for the SA in question. The authentication algorithm must specify the length of the ICV and the comparison rules and processing steps for validation.

7.3.2 ESP Header Location

Like AH, ESP is also employed in the two transport or tunnel modes. The transport mode is applicable only to host implementations and provides protection for upper protocols, but not the IP header. In the transport mode, ESP is inserted after the IP header and before an upper-layer protocol (TCP, UDP or ICMP), or before any other IPsec headers that have already been inserted.

In the IPv4 context, ESP is placed after the IP header, but before the upper-layer protocol. Note that an ICMP message may be sent using either the transport mode or the tunnel mode. Figure 7.7(a) illustrates ESP transport mode positioning for a typical IPv4 packet, on a before and after basis. The ESP trailer encompasses any padding, plus the pad length, and next header fields.

After applying ESP

(a) ESP transport mode for an IPv4 packet

(c) ESP tunnel mode for typical IPv4 and IPv6 packets

Figure 7.7 Transport mode and tunnel mode for ESP authentication.

In the IPv6 context, the ESP appears after hop-by-hop, routing and fragmentation extension headers. The destination options extension header(s) could appear either before or after the ESP header depending on the semantics desired. However, since ESP protects only fields after the ESP header, it is generally desirable to place the destination options header(s) after the ESP header. Figure 7.7(b) illustrates ESP transport mode positioning for a typical IPv6 packet.

Tunnel mode ESP can be employed in either hosts or security gateways. When ESP is implemented in a security gateway to protect subscriber transit traffic, tunnel mode must be used. In tunnel mode, the inner IP header carries the ultimate source and destination

addresses, while an outer IP header may contain different IP addresses such as addresses of security gateways. In tunnel mode, ESP protects the entire inner IP packet, including the entire inner IP header. The position of ESP in tunnel mode, relative to the outer IP header, is the same as for ESP in transport mode. Figure 7.7(c) illustrates ESP tunnel mode positioning for typical IPv4 and IPv6 packets.

7.3.3 Encryption and Authentication Algorithms

ESP is applied to an outbound packet associated with an SA that calls for ESP processing. The encryption algorithm employed is specified by the SA, as is the authentication algorithm.

7.3.3.1Encryption

ESP is designed for use with symmetric algorithms like a triple DES in CBC mode. However, a number of other algorithms have been assigned identifiers in the DOI document. These algorithms for encryption are: RC5, IDEA, CAST and Blowfish.

For encryption to be applied, the sender encapsulates the ESP payload field, adds any necessary padding, and encrypts the result (i.e. payload data, padding, pad length and next header). The sender encrypts the fields (payload data, padding, pad length and next header) using the key, encryption algorithm, algorithm mode indicated by the SA and an IV (cryptographic synchronisation data). If the algorithm to be encrypted requires an IV, then this data is carried explicitly in the payload field. The payload data field is an integral number of bytes in length. Since ESP provides padding for the plaintext, encryption algorithms employed by ESP exhibit either block or stream mode characteristics.

The encryption is performed before the authentication and does not encompass the authentication data field. The order of this processing facilitates rapid detection and rejection of replayed or bogus packets by the receiver, prior to decrypting the packet. Therefore, it will reduce the impact of service attacks. At the receiver, parallel processing of packets is possible because decryption can take place in parallel with authentication. Since the authentication data is not protected by encryption, a keyed authentication algorithm must be employed to compute the ICV.

Referring to Figure 7.8, the 3DES – CBC mode requires an IV that is the same size as the block size. The IV is XORed with the first plaintext block before it is encrypted. For successive blocks, the previous ciphertext block is XORed with the current plaintext before it is encrypted. Triple DES, known as DES – EDE3, processes each block three times, each time with a different key. Therefore, the triple DES algorithm has 48 rounds. In DES – EDE3-CBC, an IV is XORed with the first 64-bit plaintext block (P1).

Some cipher algorithms allow for a variable-sized key (RC5), while others only allow a specific key size (DES, IDEA).

7.3.3.2Decryption

The receiver decrypts the ESP payload data, padding, pad length and next header using the key, encryption algorithm, algorithm mode and IV data. If explicit IV data is indicated, it