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:
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:
The following algorithms are considered suitable for IPsec:
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:
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
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.
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.