The ESP Header

   

When ESP is used to protect an IP packet the ESP header (figure 5.1) immediately follows an IP header. In the case of IPv4, the ESP header immediately follows the IP header (including any options). The protocol field of that IP header will be 50 to indicate that following the IP header is an ESP header. In case of IPv6, the placement of the ESP header depends on the presence of extension headers. The ESP header is always inserted after the extension headers, which can change en route to the destination. This includes the hop-by-hop, routing, and the fragment headers. The ESP header should be inserted before the destination options header because it is desirable to protect the destination options. If extension headers are present, the next header field of the extension header immediately preceding the ESP header is set to 50. In the absence of any extension header, the next header field in the IPv6 header is set to 50.

Figure 5.1. The ESP Header (and trailer)

graphics/05fig01.gif

ESP provides both confidentiality and integrity to the packet it is protecting. The scope of these two services on the ESP packet are not identical. This is due to a desire to authenticate as much information in the packet as possible but also allowing for efficient processing.

Being an IPSec header, the ESP header contains an SPI field. This value, combined with the destination address and protocol in the preceding IP header, identifies the appropriate security association to use in processing the packet. The SPI itself is an arbitrary number and is selected by the destination, usually during an IKE exchange (more on this in Chapter 7). Note that the SPI is authenticated but not encrypted. This is a necessity because the SPI is used to identify the state encryption algorithm and key used to decrypt the packet. If the SPI were encrypted we'd have a serious chicken-and-egg problem!

The sequence number provides antireplay services to ESP. As described in Chapter 3, this value is a unique and monotonically increasing number inserted into the header by the sender. The sequence number is authenticated but not encrypted. This is because we want to determine whether a packet is a duplicate, and hence that we will drop this packet, without expending resources to decrypt it. Since the sequence number does not really require confidentiality it does not expose any secrets in cleartext form a safety check can be accomplished by doing the antireplay check prior to decryption.

The actual data being protected by ESP is contained in the payload data field. The length of this field therefore depends on the length of the data. The protected data field is also used to contain any initialization vector that an encryption algorithm may require. The specific transform document that describes how to use ESP with a particular algorithm must define the location of the IV and address any alignment issues that may arise due to the addition of the IV in the payload data field. For all of the encryption algorithms defined for use with ESP, the IV is the first 8 octets of data in the protected data field. Note, though, that this is not encrypted.

Padding is used in ESP to maintain boundaries. Certain modes of encryption algorithms require that the input to the cipher be a multiple of its block size. Padding accomplishes this. Also, if confidentiality is not employed by the SA, padding is still used to right-justify the pad length and next header fields of the ESP header. Certain payloads may not require padding if the payload data already provides the necessary alignment, but up to 255 bytes of padding can still be added. This technique can be used to hide the actual length of the payload data. The contents of the padding is dependent on the encryption algorithm used to provide confidentiality. If the algorithm defines a certain value in its pad that value must be used. If the algorithm does not specify any required pad value, ESP dictates that the first byte of the pad be the value 1 and that all subsequent bytes have a monotonically increasing value. The value of the pad should be checked by the receiver as an additional check for proper decryption and also as an additional protection against certain cut-and-paste attacks if authentication is not employed.

The pad length field simply defines how much pad has been added so that the recipient can restore the actual length of the payload data. The pad length field is mandatory, so even if there is no pad, the pad length field will indicate that. In this case its value should be self-evident.

The authentication data field is used to hold the result of the data integrity check usually a keyed hash function done on the ESP packet (note the coverage of the integrity check from Figure 3.1). The length of this field depends on the authentication algorithm employed by the SA used to process this packet. If an authenticator is not specified in the SA used to process an ESP packet there is no authentication data field.


   
Top


IPSec(c) The New Security Standard for the Internet, Intranets, and Virtual Private Networks
IPSec (2nd Edition)
ISBN: 013046189X
EAN: 2147483647
Year: 2004
Pages: 76

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net