Section 5.4. IPv6 Security Elements

5.4. IPv6 Security Elements

IPsec describes general security mechanisms that can be used with both protocols, IPv6 and IPv4. This means that IPv6 is not more secure than IPv4. The difference in security is that IPsec may be installed separately for IPv4, whereas it is a mandatory and integral part of the IPv6 stack, and therefore available with any implementation.

The IPsec specification defines protocols for the Authentication header (AH) and the Encapsulating Security Payload header (ESP). With IPv6, these headers are included as Extension headers. An IPsec implementation must support ESP and may support AH. With the older specification, support for both protocols was required. The requirement for AH support has been removed because ESP can be used to provide integrity, which in most cases has proven to be sufficient.

5.4.1. Authentication Header

The Authentication Header (AH) provides integrity and authentication (no confidentiality) for all end-to-end data transported in an IP packet. It supports different authentication mechanisms. It is specified in RFC 4302 (which obsoletes RFC 2402) and is indicated by the protocol value 51 in the preceding header.

The AH is located between the IPv6 header and upper-layer headers (e.g., TCP, UDP, ICMP). If extension headers are present, it has to be placed after the Hop-by-Hop, Routing, and Fragment Extension headers.

The format of the AH is shown in Figure 5-1.

Figure 5-1. The format of the Authentication Header

Each field is discussed in the following list:

Next Header (1 byte): The Next Header field identifies the type of header that follows the Authentication header. It uses the values listed in Table 2-1.
Payload Length (1 byte): Describes the length of the header in four-byte units, not including the first eight bytes in the calculation. This length indication is necessary because the authentication data in the AH may differ in length depending on the algorithm used.
Reserved (2 bytes): Not used; set to 0.
Security Parameter Index (SPI) (4 bytes): Arbitrary 32-bit value. Used by the receiver to identify the SA to which an incoming packet belongs. The SPI field is mandatory, and this mechanism for mapping inbound traffic to unicast SAs must be supported by all AH implementations. If an IPsec implementation supports multicast, it must additionally support multicast SAs using the de-multiplex algorithm specified for this purpose for mapping inbound IPsec datagrams to SAs. SPI values in the range of 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use. The SPI value of 0 is reserved for local, implementation-specific use and must not be sent on the wire.
Sequence Number (4 bytes): This 32-bit sequence number is a monotonically increasing counter value. It has to be set by the sender, but it is the choice of the receiver whether to act on it. It ensures that packets with identical data are not resent repeatedly. This prevents replay attacks in a unicast or single-sender SA. For a multi-sender SA, the anti-reply features of AH are not available, because the AH does not have a means to synchronize packet counters among multiple senders. On establishment of an SA, the value is set to 0 at the sender and at the receiver. The first packet always has the value 1, which is increased by one for every consecutive packet. When the value 232 is reached, the counter is reinitialized to 0.
Integrity Check Value (variable length): This field contains the checksum (Integrity Check Value, ICV) for the packet. The length depends on the algorithm chosen on establishing the SA. It is always a multiple of four bytes.

The AH Specification in RFC 4302 defines a new Extended (64-bit) Sequence Number (ESN). It cannot be seen in Figure 5-1 because only the low-order 32 bits of the Extended Sequence Number are transmitted. The high-order 32 bits are maintained as part of the sequence number counter by both transmitter and receiver, and are included in the computation of the ICV. The 64-bit sequence number is a new option designed to support high-speed IPsec implementations. The use of an Extended Sequence Number is negotiated on setup of the SA. The default with IKEv2 is ESN, unless 32-bit is explicitly negotiated.

The checksum is calculated over the following fields:

All fields of the IP header or Extension header fields before the AH that do not change in transit or whose value when arriving at the destination can be predicted. For example, if a Routing Extension header is present, the last address in the Routing Extension header is used for the calculation. The Class field, the Flow Label, and the Hop Limit are not included in the calculation.
All fields of the Authentication header.
Other Extension headers present and the payload.
The high-order bits of the ESN (if employed) and any implicit padding required by the integrity algorithm.

The following algorithms are considered suitable for IPsec:

Keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms
One-way hash functions (e.g., MD5, SHA-1, SHA-256, etc.)

Other algorithms can be negotiated. RFC 4305, "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)," lists the following implementation rules for AH:

MUST, HMAC-SHA1-96 (RFC 2404)
SHOULD, AES-XCBC-MAC-96 (RFC 3566)
MAY, HMAC-MD5-96 (RFC 2403)

Weaknesses have become apparent in MD5; however, they should not affect the use of MD5 with HMAC.

The Authentication header can be used in both transport and tunnel modes, as shown in Figure 5-2.

Figure 5-2. Authentication header in transport and tunnel mode

In transport mode, the whole payload, including the fields of the IPv6 header, which do not change in transit, is secured. In tunnel mode, the inner packet contains the IP address of sender and receiver. The outer IP header contains the IP address of the tunnel endpoints. In this case, the complete original packet, including the fields of the outer header that do not change in transit, is secured.

5.4.2. Encapsulating Security Payload Header

The Encapsulating Security Payload Header (ESP) provides Integrity, Confidentiality, Data Origin Authentication, Anti-Replay Service, and limited Traffic Flow Confidentiality for all end-to-end data transported in an IP packet. The set of services provided is negotiated on establishment of the SA. The ESP is defined in RFC 4303 (which obsoletes RFC 2406) and indicated by a protocol value of 50 in the preceding header.

The ESP is located in front of the transport (e.g., UDP or TCP), network control (e.g, ICMP), or routing (e.g., OSPF) protocol header.

The format of the ESP is shown in Figure 5-3.

Figure 5-3. Format of the Encapsulating Security Payload header

Security Parameter Index (SPI, 4 bytes): Arbitrary 32-bit value. Used by the receiver to identify the SA to which an incoming packet belongs. The SPI field is mandatory, and this mechanism for mapping inbound traffic to unicast SAs must be supported by all ESP implementations. If an IPsec implementation supports multicast, it must additionally support multicast SAs using the de-multiplex algorithm specified for this purpose for mapping inbound IPsec datagrams to SAs. SPI values in the range of 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use. The SPI value of 0 is reserved for local, implementation-specific use and must not be sent on the wire.
Sequence Number (4 bytes): This 32-bit sequence number is a monotonically increasing counter value. It has to be set by the sender, but it is the choice of the receiver whether to act on it. It ensures that packets with identical data are not resent repeatedly. This prevents replay attacks in a unicast or single-sender SA. For a multi-sender SA, the anti-reply features of ESP are not available, because the ESP does not have a means to synchronize packet counters among multiple senders. On establishment of an SA, the value is set to 0 at the sender and at the receiver. The first packet always has the value 1, which is increased by one for every consecutive packet. When the value 232 is reached, the counter is reinitialized to 0.
Payload Data (variable length): Contains the encrypted data as well as the encryption initialization vector (IV) if required by the encryption mechanism.
Padding (0 to 255 bytes): Used to align the packet to a multiple of 4 bytes and to reach a minimum packet size if the encryption mechanism requires one.
Pad Length (1 byte): Indicates the number of preceding padding bytes.
Next Header (1 byte): Identifies the type of header that follows the ESP header. It uses the values listed in Table 2-1. To facilitate the rapid generation and discarding of the padding traffic in support of traffic flow confidentiality, the protocol value 59 (no next header) designates a "dummy" packet. The receiver of a dummy packet must discard it without creating an error message.
Integrity Check Value (variable length): The Integrity Check Value (ICV) is a variable-length field containing a checksum computed over the ESP header, Payload, and ESP trailer fields. The ICV field is optional. It is present only if the integrity service is selected, and it is provided by either a separate integrity algorithm or a combined mode algorithm that uses an ICV. The length of the field is specified by the integrity algorithm selected and associated with the SA.

The Padding, Pad Length, and Next Header fields are part of the ESP Trailer. The encryption algorithm is either specified manually and included in the SA for the packet stream or negotiated dynamically by the key exchange protocol.

The new ESP Specification in RFC 4303 defines a new Extended (64-bit) Sequence Number (ESN). It cannot be seen in Figure 5-3, because only the low order 32 bits of the Extended Sequence Number are transmitted. The high-order 32 bits are maintained as part of the sequence number counter by both transmitter and receiver and are included in the computation of the ICV. The 64-bit sequence number is a new option designed to support high-speed IPsec implementations. The use of an Extended Sequence Number is negotiated on setup of the SA. The default with IKEv2 is ESN unless 32-bit is explicitly negotiated.

RFC 4305, "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)," lists the implementation rules for ESP, shown in Tables 5-2 and 5-3.

Table 5-2. Encryption algorithms
Rule	Algorithm
MUST	NULL (1)
MUST-	TripleDES-CBC (RFC 2451)
SHOULD+	AES-CBC with 128-bit keys (RFC 3602)
SHOULD	AES-CTR (RFC 3686)
SHOULD NOT	DES-CBC (RFC 2405)

Table 5-3. Authentication algorithms
Rule	Algorithm
MUST	HMAC-SHA1-96 (RFC 2404)
MUST	NULL (1)
SHOULD+	AES-XCBC-MAC-96 (RFC 3566)
MAY	HMAC-MD5-96 (RFC 2403)

Combined Mode algorithms provide both confidentiality and authentication services. They are expected to provide significant throughput and efficiency advantages. However, at the time of this book's writing, there are no such mechanisms available. AES-CCM, which has been adopted as the preferred mode for security in IEEE 802.11i, is expected to be of interest in the near future. Stay tuned.

Since ESP authentication and encryption are both optional, support for NULL algorithms must be given for both. Note that only one of them can be set to NULL at a time.

The ESP can be used in both transport and tunnel modes, as shown in Figure 5-4.

Figure 5-4. Encapsulating Security Payload Header in transport and tunnel mode

In transport mode, the IP header and the Extension headers that follow are not encrypted; otherwise the packet could not be forwarded. If the complete packet has to be encrypted, tunnel mode is the way to go. Just as with the AH in tunnel mode, the inner packet contains the IP address of sender and receiver, whereas the outer IP header contains the IP address of the tunnel endpoints.

The ESP can be used with a NULL encryption option, which is defined in RFC 2410. With NULL encryption, only the authentication option of the ESP is used, and the packet is not encrypted.

5.4.3. Combination of AH and ESP

The two headers can be used in combination as well. In that case, the AH header has to precede the ESP header to verify authenticity and integrity before the packet is decrypted. The authentication option has been included in the ESP header to allow for authentication of encrypted packets with only one header.

If the AH header is used in tunnel mode, the first IP header is included in the authentication. If the ESP header is used, only the part of the packet following the ESP header is authenticated. If encryption and integrity of the IP addresses are required, both headers must be combined. If both headers are used, it is obviously not necessary to use the authentication in the ESP header. On the other hand, an ESP header with NULL encryption can be used if the given authentication is sufficient.