IPsec, a Tutorial--Part V

IPsec Transforms
As discussed above, IPsec delivers data confidentiality services by executing a transform on plain text data. Common ciphers used in the IPsec transform are DES, 3DES, and AES. All of these transforms conform to specifications for IPsec's symmetric-key cryptographic requirements per RFC 2401. Another item that all of these transforms have in common is that they can all be deployed in using ESP, authentication headers (AH), or a combination of the two.

ESP
ESP provides a combination of security services for IPsec-processed IP packets. Examples of the services offered by ESP include data confidentiality, data origin, data integrity assurance mechanisms, and data flow confidentiality. The services offered by ESP depend on which services are negotiated during IPsec security association establishment. As such, any service, or combination of services, can be selected by the administrator before SA negotiation takes place. ESP can be deployed in transport or tunnel mode. Additionally, it can be deployed alone, or in conjunction with authentication headers.

Encryption--Message and Traffic-Flow Confidentiality
ESP provides confidentiality services by allowing the use of popular symmetric key encryption ciphers such as DES, 3DES, and AES. Assuming that a user selects DES as their transform cipher, the encrypting device would take the input data at 64-bit blocks nd encrypt them using a key 56 bits in length. ESP would then "wrap," or encapsulate, the ciphered payload with an ESP header (IP protocol number 50), the 64-bit blocks of the original message can be chained together using cipher block chaining (CBC) or CFB, yielding greater antireplay and data integrity protection.

The format of an ESP-processed IP packet varies based on which IPsec transform mode is selected. In transport mode, the header is placed before the ciphered payload, and after the IP header. As such, ESP in transport mode offers only confidentiality protection for Layer 4-7 protocol information--it is effective at providing confidentiality to the IP-encapsulated payload of the original message. To increase the protective boundary of ESP on a per-packet basis, administrators can select tunnel mode when defining their IPsec transforms. ESP in tunnel mode includes the original IP header in the ciphered payload. The ESP header is placed before the ciphered inner IP header, and after the cleartext outer IP header. As such, IPsec in tunnel mode protects the source and destination of the IP traffic flows themselves, in addition to Layer 4-7 protocol information protected in transport mode.

Note:
3DES and AES are considered to be stronger encryption ciphers than DES, as they use longer encryption keys (128-bit key for 3DES and 256-bit key for AES). However, they are also more computationally expensive and administrators should therefore carefully balance the need for confidentiality with the cost of their VPN infrastructure.

Each ESP packet is marked with a security parameter index (SPI). The SPI enables encrypting and decrypting devices to understand which SA the ESP packet belongs to. SPIs are a 32-bit arbitrarily derived by the destination IPsec peer during IKE. Using SPIs to identify the packet's appropriate SA is critical, as each SA may be processed under a variety of different parameters, such as selected encryption transforms and Diffie-Hellman keys. In addition to the SPI, a sequence number is created for each ESP packet. Sequence numbers increase incrementally, per packet, offering built-in antireplay protection for ESP-processed traffic in both tunnel (Figure 14) and transport mode (Figure 12).