14.9. IPsecThe IETF has been developing an IP security protocol (IPsec) that is built directly on top of IP and provides end-to-end cryptographically based security for both IPv4 and IPv6. IPsec is a requirement for every IPv6 implementation and is an option for IPv4. Since IPv6 provides features that are not available in IPv4, the IPv6 and IPv4 versions of IPsec are implemented slightly differently. Although IPsec is still being standardized, it is sufficiently stable and standard that multiple interoperable implementations are now available and in use on IPv4. Possibly the best known of these is the IPsec implementation for Linux called FreeS/WAN.
Because IPsec is implemented at the IP layer, it can provide protection to any IP protocol including TCP and UDP. The security services that IPsec provides are:
IPsec is made up of three protocols, each of which is defined as a framework that defines packet layouts and field sizes and is suitable for use by multiple cryptographic algorithms. The protocols themselves do not define specific cryptographic algorithms to use, although every implementation is required to support a specified set of algorithms. The protocols that make up IPsec are:
The Encapsulating Security Payload (ESP) protocol provides confidentiality (encryption) and limited protection against traffic flow analysis. ESP also includes some of the services normally provided by AH. Both AH and ESP rely on the availability of shared keys, and neither one has a way to move them from one machine to another. Generating these keys is handled by the third IPsec protocol, the ISAKMP.
ISAKMP is also a framework protocol; it doesn't by itself define the algorithms that are used to generate the keys for AH and ESP. The Internet Key Exchange (IKE) protocol uses the ISAKMP framework with specific key exchange algorithms to set up cryptographic keys for AH and ESP. This layering may seem confusing and overly complicated, but the separation of ISAKMP from IKE means that the same basic IPsec framework can be used with multiple different key exchange algorithms (including plain old manual key exchange). The standardization of IKE allows different people to implement the same key exchange algorithms and be guaranteed interoperability. The Linux FreeS/WAN project has an implementation of IKE called Pluto.
In IPv6 the AH and ESP protocols can be used simultaneously, with an IPv6 feature called header chaining, to provide authentication modes that ESP alone cannot provide. When they are used in this way it is recommended that ESP be wrapped by the additional AH header. In IPv4, it's not possible to use them both at once (you can have only one header at a time).
IPsec provides two operating modes for AH and ESP, transport and tunnel. In transport mode, AH or ESP occur immediately after the IP header and encapsulate the remainder of the original IP packet. Transport mode works only between individual hosts; the packet must be interpreted by the host that receives it. Transport is used to protect host-to-host communications. Hosts can use it to protect all of their traffic to other cooperating hosts, or they can use it much the way TLS is used, as a protection layer around specific protocols.
In tunnel mode, the entire original packet is encapsulated in a new packet, and a new IP header is generated. IPsec uses the term security gateway for any device that can operate in tunnel mode. This term applies to all devices that can take IP packets and convert them to and from the IPsec protocols, whether they are hosts or dedicated routers. Because the whole IP packet is included, the recipient can forward packets to a final destination after processing. Tunnel mode is used when two security gateways or a gateway and a host communicate, and it is what allows you to build a virtual private network using IPsec.
The AH and ESP protocols each contain a 32-bit value that is called the Security Parameter Index (SPI). This is an identifier that is used to distinguish between different conversations going to the same destination. Every IPsec implementation is required to be able to independently track security parameters for the combination of SPI, destination IP address, and the security protocol that is being used (either AH or ESP). This combination of parameters is called a Security Association (SA). It is the responsibility of the specific ISAKMP key management protocol to negotiate and set the cryptographic parameters, including the SPI, for each Security Association.
An SA is effectively the collection of the cryptographic keys and parameters for use by either AH or ESP:
14.9.1. Packet Filtering Characteristics of IPsecThe AH and ESP protocols are implemented directly on top of the IP layer. AH is IP protocol 51, and ESP is IP protocol 50. The ISAKMP protocol uses UDP port 500 for both sending and receiving. In order to allow IPsec, you will need a packet filtering system that can filter on IP protocol type. Because IPsec provides end-to-end protections, a firewall will not be able to modify or even be able to inspect the contents of IPsec packets.
14.9.2. Proxying Characteristics of IPsecAH and ESP provide end-to-end message integrity protection that is calculated using data from the IP packet header. Using a proxy will change the header data, thereby causing a message integrity failure. In theory, it is possible for the IPsec architecture to allow the use of intermediary proxies in end-to-end communications if they can participate in the negotiation of integrity protection Security Association parameters. Unfortunately, the details for how this might work have not been defined so it is not currently possible to use IPsec through proxies.
It is, however, possible to use regular IP to the proxy system and have it speak IPsec to the destination. In addition, IPsec could be used with SOCKS. In this configuration, the client would set up communications with the SOCKS server via IPsec, and the SOCKS server would set up a separate IPsec communications channel to the final destination. However, this double use of IPsec may require significant CPU resources to implement.
14.9.3. Network Address Translation Characteristics of IPsecBoth AH and ESP include message integrity protections for the entire packet, including the headers. If you modify the packet at all, even to change the source or destination address, you will make the packet invalid. It is therefore impossible to do network address translation with AH or ESP. On the other hand, it's perfectly possible to do network address translation on packets that are then tunneled in AH or ESP; they don't care what happened to the packet while it was still a standard IP packet.
Therefore, you can combine network address translation and IPsec tunneling, as long as you do the network address translation first and then set up the IPsec tunnel. (Using IPsec parlance, it would be possible to implement network address translation behind or on a security gateway.)
14.9.4. Summary of Recommendations for IPsec
Copyright © 2002 O'Reilly & Associates. All rights reserved.