5.3. IPsec Basics
IPsec, originally defined in RFC 2401 and updated in RFC 4301, describes a security architecture for both versions of IP for IPv4 and IPv6.
The following elements are part of the IPsec framework:
The configuration of IPsec creates a boundary between a protected and an unprotected area. The boundary can be around a single host or a network. The access control rules specified by the administrator determine what happens to packets traversing the boundary. The security requirements are defined by a Security Policy Database (SPD). Generally, each packet is either protected using IPsec security services, discarded, or allowed to bypass IPsec protection, based on the applicable SPD policies identified by the selectors. The selectors are the specific traffic match criteria defined by an administratorfor example, a specific application being transmitted from a subnet to a specific end-host.
RFC 4301 contains a section listing all the changes since RFC 2401. The basic IPsec concepts remain the same. Changes have been made to address new IPsec scenarios, improve performance, and simplify implementation. A new database, the Peer Authorization Database (PAD), has been added and is described later in this chapter.
5.3.1. Security Associations
Security Associations (SA) are agreements between communication peers. Three elements are part of the agreement: a key, an encryption or authentication mechanism, and additional parameters for the algorithm. SAs are unidirectional, and each separate security service requires an SA. This means that two communication peers who want to encrypt and authenticate a two-way communication need four SAs (one pair for encryption and one pair for authentication). Bidirectional application trafficfor example, a bidirectional Telnet connectionalso requires four SAs at each communication peer. Peer A must protect the traffic it initiates and the return traffic from Peer B. It also requires two additional SAs to ensure that if Peer B initiates a Telnet session, both it and the return traffic for this scenario are protected.
IPsec differentiates two modes of transport:
5.3.2. Key Management
Most of the security mechanisms provided by IPsec require the use of cryptographic keys. A separate set of mechanisms has been defined for putting the keys in place. Support for both manual and automated distribution of keys is a requirement. RFC 4301 specifies IKEv2 (described later in this section) as an automated key distribution mechanism. Other mechanisms may be used.
In order to establish a Security Association (SA), the communication peers have to agree on a cryptographic algorithm and negotiate keys. The negotiation of an SA often happens over insecure paths. Internet Key Exchange (IKE) specifies a protocol that allows for the exchange and negotiation of parameters for an SA.
IKEv1 is specified in RFC 2409 and updated in RFC 4109. It consists of selected functions from three different protocols:
IKEv1 uses UDP on port 500 and goes through two phases:
In phase one, the ISAKMP communication peers negotiate a secure, authenticated communication channel called ISAKMP Security Association. Note that some implementations use the term "IKE SA," which is synonymous with the ISAKMP SA. The phase one exchange is based on the Diffie/Hellman algorithm and encrypted identification tokens. The authentication can be secured by either preshared keys, an RSA checksum encrypted with the private key of the sender, or the public key of the receiver.
In phase two, the cryptographic algorithms and the keys for other protocols (e.g., ESP and/or AH) can be exchanged over the secure communication channel established in phase one. The outcome of IKE phase two results in an IPsec SA. These IPsec SAs define the security services to be used for protecting the traffic in transit. Multiple IPsec SAs can be negotiated via the secure channel set up in phase one. This allows for more granular and more flexible security services to be negotiated. Both the IPsec SAs and ISAKMP SAs generate new cryptographic keys on a periodic basis to provide greater security. Typically, the IPsec SAs are rekeyed at a faster rate than the ISAKMP SAs.
RFC 4109 updates the original specification. The changes are made to ensure that the suggested and required algorithms reflect the current market situation. The changes are intended to be deployed for all IKEv1 implementations.
Table 5-1 lists the changes as presented in the RFC.
All algorithms with a "should" or "must" level in the new recommendation are seen to be secure and robust at the time of writing.
IKEv2 is specified in RFC 4306, which combines and therefore obsoletes RFC 2407, "The Internet IP Security Domain of Interpretation for ISAKMP," RFC 2408, "Internet Security Association and Key Management Protocol (ISAKMP)," and RFC 2409, "The Internet Key Exchange (IKE)." IKEv2 brings, among other things, enhancements for the use of IPsec in combination with NAT traversal, for Extensible Authentication, and for Remote Address acquisition.
IKEv2 runs over UDP ports 500 and 4500, and must accept packets from any ports and respond to those same ports.
The initial exchange (called phase one in IKEv1 terminology) normally consists of two pairs of messages. The first message pair negotiates cryptographic algorithms, exchanges nonces, and does a Diffie-Hellman exchange. The second message pair authenticates the previous messages, exchanges identities and certificates, and establishes the first CHILD_SA.
In IKEv1, SA lifetimes were negotiated. In IKEv2, each end of the SA is responsible for enforcing its own lifetime policy on the SA and rekeying the SA when necessary. The end with the shorter lifetime will have to request the rekeying if the lifetime policies are different. Another difference between the two IKE versions is that IKEv2 allows parallel SAs with the same traffic selectors between common endpoints. This difference, among other things, supports traffic with different Quality of Service (QoS) requirements among the SAs. Hence, unlike IKEv1, the combination of the endpoints and the traffic selectors may not uniquely identify an SA between those endpoints. Therefore, with IKEv2, SAs can no longer be deleted based on duplicate traffic selectors.
Opening an IPsec connection through a NAT creates some special problems. The changing of IP addresses changes the checksums, so they will fail and cannot be corrected by the NAT, because they are cryptographically protected. IKEv2 has improved support for such situations by negotiating UDP encapsulation of IKE and ESP packets. Port 4500 is reserved for UDP-encapsulated ESP and IKE. Because NATs often translate TCP and UDP port numbers, IPsec packets must be accepted from any port and sent back to that same port.
A summary of the changes and goals for RFC 4306 can be taken from the RFC. Here are some of the main points (refer to the RFC for the whole list):
A list of algorithms to be used with IKEv2 is specified as mandatory to implement in RFC 4307 "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)." This is in order to ensure interoperability between different implementations.
5.3.3. IPsec Databases
There are three important databases in the IPsec model:
The Peer Authorization Database is new with the specification in RFC 4301. Its main functions are to identify the peers or groups of peers authorized to communicate with the IPsec entity, to specify the protocol and method used to authenticate each peer, and to contain the authentication data for each peer.
5.3.4. IPsec Performance
There is work in progress to ensure that IPsec performance concerns are addressed so that vendors can create sound implementations. This work is part of the Benchmarking Methodology Working Group (BMWG). If you are interested in this work, go to the BMWG at http://www.ietf.org/html.charters/bmwg-charter.html or refer to the drafts: draft-ietf-bmwg-ipsec-term-08.txt and draft-ietf-bmwg-ipsec-meth-01.txt.