Section 5.3. IPsec Basics

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:

A general description of security requirements and mechanisms at the network layer
A protocol for encryption (Encapsulating Security Payload, ESP)
A protocol for authentication (Authentication Header, AH)
A definition for the use of cryptographic algorithms for encryption and authentication
A definition of security policies and security associations between communication peers
Key management

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:

Transport mode: The SA is made between two end nodes and defines the encryption or authentication for the payload of all IP packets for that connection. The IP header is not encrypted.
Tunnel mode: The SA is usually made between two security gateways. The whole packet including the original IP header is encrypted or authenticated by encapsulating it in a new header. This is the foundation for a virtual private network (VPN).

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.

5.3.2.1. IKEv1

IKEv1 is specified in RFC 2409 and updated in RFC 4109. It consists of selected functions from three different protocols:

ISAKMP (Internet Security Association and Key Management Protocol): ISAKMP specifies a framework for the management of SAs and key exchange without describing the process in detail. It therefore supports different key exchange mechanisms. It is specified in RFC 2408, which was obsoleted by RFC 4206.
Oakley Key Determination Protocol: The Oakley Key Determination protocol is used for the exchange of keys and is specified in RFC 2412. It is an extension of the Diffie/Hellman algorithm. It uses only a subset of the functions of the Oakley protocol.
SKEME (Versatile Secure Key Exchange Mechanism for the Internet): SKEME is a fast key exchange technique described in "SKEME: A Versatile Secure Key Exchange Mechanism for Internet," from IEEE Proceedings of the 1996 Symposium on Network and Distributed Systems Security by H. Krawczyk. IKE uses only a subset of the functions defined for the SKEME protocol.

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.

Table 5-1. Changes in RFC 4109
Algorithm	RFC 2409	RFC 4109
DES for encryption	MUST	MAY (crypto weakness)
TripleDES for encryption	SHOULD	MUST
AES-128 for encryption	N/A	SHOULD
MD5 for hashing and HMAC	MUST	MAY (crypto weakness)
SHA1 for hashing and HMAC	MUST	MUST
Tiger for hashing	SHOULD	MAY (lack of deployment)
AES-XCBC-MAC-96 for PRF	N/A	SHOULD
Preshared secrets	MUST	MUST
RSA with signatures	SHOULD	SHOULD
DSA with signatures	SHOULD	MAY (lack of deployment)
RSA with encryption	SHOULD	MAY (lack of deployment)
D-H Group 1 (768)	MUST	MAY (crypto weakness)
D-H Group 2 (1024)	SHOULD	MUST
D-H Group 14 (2048)	N/A	SHOULD
D-H elliptic curves	SHOULD	MAY (lack of deployment)

All algorithms with a "should" or "must" level in the new recommendation are seen to be secure and robust at the time of writing.

You can find all IKEv1 relevant and updated numbers and codes at http://www.iana.org/assignments/ipsec-registry.

5.3.2.2. IKEv2

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.

You can find all relevant and updated IKEv2 numbers and codes at http://www.iana.org/assignments/ikev2-parameters.

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):

To define the entire IKE protocol in a single document, replacing RFCs 2407, 2408, and 2409, and incorporating subsequent changes to support NAT Traversal, Extensible Authentication, and Remote Address acquisition.
To simplify IKE by replacing the eight different initial exchanges with a single four-message exchange.
To decrease IKE's latency in the common case by making the initial exchange two round trips (four messages) and allowing the ability to piggyback setup of a CHILD_SA on that exchange.
To reduce the number of possible error states by making the protocol reliable. This is done by requiring all messages to be acknowledged and sequenced. This allows shortening CREATE_CHILD_SA exchanges from three messages to two.
To maintain existing syntax and magic numbers to the extent possible to make it likely that implementations of IKEv1 can be enhanced to support IKEv2 with minimum effort.

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:

Security Policy Database (SPD): Specifies the policies that determine the disposition of all IP traffic (inbound or outbound) from a host or security gateway. There are three possible processing rules after application of the SPD policies: discard, bypass, or protect.
Security Association Database (SAD): Contains an entry for each SA and the parameters associated with it.
Peer Authorization Database (PAD): Provides a link between an SA management protocol (such as IKE) and the SPD.

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.

For a good overview of the relevant security RFCs and drafts, go to the IETF Security working group at http://www.ietf.org/html.charters/wg-dir.html and at http://sec.ietf.org.

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.