Encapsulating Security Payload (ESP)
ESP is the IPSec protocol that provides confidentiality, data integrity, and data source authentication of IP packets, and also provides protection against replay attacks. It does so by inserting a new header an ESP header after an IP header (and any IP options) and before the data to be protected, either an upper-layer protocol or an entire IP datagram, and appending an ESP trailer. The location of the ESP header and trailer in an ESP-protected packet are shown in figure 3.4. ESP is a new IP protocol and an ESP packet is identified by the protocol field of an IPv4 header and the "Next Header" field of an IPv6 header. If the value is 50 it's an ESP packet and immediately following the IP header is an ESP header. RFC2406 defines ESP.
Figure 3.4. An ESP-protected IP packet
An older version of ESP from RFC1827 did not provide data integrity and is considered deprecated by the IPSec Working Group. There were several implementations of RFC1827, but they have all been replaced by the current definition of ESP.
Since ESP provides both confidentiality and authentication, it has multiple algorithms defined in its SA one for confidentiality called a cipher; and the other for authentication called the authenticator. Each ESP SA will have at most one cipher and one authenticator. It is possible to define NULL ciphers or NULL authenticators and do ESP without encryption or ESP without authentication respectively, but it is illegal to have both a NULL cipher and a NULL authenticator within a single ESP SA. This is illegal because not only is it a pointless burden on the system, but because it provides no security. One thing that cannot be mentioned enough is that doing something insecure with a security protocol is worse than not doing the security protocol in the first place because of the false sense of security provided. ESP provides security and it should not be used in a patently insecure manner.
The ESP header is not encrypted but a portion of the ESP trailer is. Enough is in clear text, though, to allow for a recipient to process the packet. Since the SPI is used, along with the destination IP address of the IP header of this packet, to identify an SA it must be in the clear. In addition, the sequence number and authentication data are also in the clear (this is explained further in chapter 5). This is due to the specified order of processing of ESP packets: First verify the sequence number, then verify the integrity of the data, then decrypt the data. Since decryption is last, the sequence number and authentication data must be in the clear.
All encryption algorithms used with ESP must operate in cipher block chaining (CBC) mode. CBC requires that the amount of data to encrypt be a multiple of the block size of the cipher. This requirement is met by adding padding to the end of the data when necessary to encrypt. The pad becomes part of the cipher text of the packet and is stripped off by the recipient after IPSec processing. If the data is already a multiple of the block size of the cipher, padding need not be added. Compliant implementations are required to support the Data Encryption Standard (DES).
Ciphers in CBC mode also require an initialization vector (IV) to jump-start the encryption process. This IV is contained in the payload field generally as the first bytes, although it is up to a specific algorithm specification to define where it obtains its IV, and a size of the IV. For instance, when using 3DES-CBC the IV is the first 8 bytes of the protected data field.
As mentioned, ESP is both a header and a trailer it encapsulates the data it protects. The header portion contains the SPI and sequence number, the trailer contains the padding (if any), an indicator regarding the length of the pad, the next protocol of the data after ESP, and the authentication data. The size of the authentication data is dependent on the authenticator used. Compliant implementations are required to support both HMAC-MD5 and HMAC-SHA as authenticators with an output of 96 bits. You'll note that these two MACs produce different-sized digests though. HMAC-MD5 produces a 128-bit digest while HMAC-SHA produces a 160-bit digest. This is alright because the high-order 96 bits of the digest are used as ESP's authentication data. Ninety-six bits was chosen because it ensured alignment for IPv6.
There was some discussion about the security of truncating the output of a MAC. It has generally been agreed that such a practice is not inherently insecure and may, in fact, increase security. Regardless of the practice of the two required authenticators, new authenticators may be any length and padding is used to enforce alignment.
The ESP specification defines the format of the ESP header, where that header is placed when doing transport mode or tunnel mode, output data processing, input data processing, and other information such as fragmentation and reassembly. The ESP specification imposes requirements on transforms used with ESP but does not specify what those transforms are. That is left to individual transform specifications. Currently there is one document that describes using AES-CBC as the cipher for ESP, and two documents that describe using the truncated output of HMAC-MD5 and HMAC-SHA as the authenticators for ESP. Other cipher documents include Blowfish-CBC, CAST-CBC, 3DES-CBC, and the depricated DES-CBC (all optional to implement).
Top IPSec (2nd Edition) ISBN: 013046189X
EAN: 2147483647 Year: 2004
Pages: 76 Authors: Naganand Doraswamy, Dan Harkins
flylib.com © 2008-2017. If you may any questions please contact us: flylib@qtcs.net |