IPSec protocol framework

This is not an exhaustive list of IPSec-related RFCs, but you can find these RFCs and others at the Internet Engineering Task Force (IETF) website:

www.ietf.org/rfc.html

Specific RFCs that relate to IPSec can be found at the following website:

www.ietf.org/html.charters/ipsec-charter.html

Notice that just three years after IPSec was introduced, a veritable army of IPSec tools was developed and quickly accepted by the networking industry.

Some things to remember when you are planning an IPSec deployment are as follows:

• IPSec supports High-Level Data-Link Control (HDLC), ATM, Point -to-Point Protocol (PPP), and Frame Relay serial encapsulation.

• IPSec also works with Generic Routing Encapsulation (GRE) and IP-in-IP (IPinIP) Encapsulation Layer 3 tunneling protocols. IPSec does not support the data-link switching (DLSw) standard, source-route bridging (SRB), or other Layer 3 tunneling protocols.

• IPSec does not support multipoint tunnels.

• IPSec works strictly with unicast IP datagrams only. It does not work with multicast or broadcast IP datagrams.

• IPSec is slower than Cisco Encryption Technology (CET) because IPSec provides perpacket data authentication.

• IPSec provides packet expansion that can cause fragmentation and reassembly of IPSec packets, creating another reason that IPSec is slower than CET.

• When using NAT, be sure that NAT occurs before IPSec encapsulation so that IPSec has global addresses to work with.

Table 2-7 shows the major protocols that you can encounter when working with IPSec. The following is a quick review of these standard protocols:

• IP Security Protocol (IPSec)

— Authentication Header (AH)

— Encapsulating Security Payload (ESP)

• Message Encryption

— Data Encryption Standard (DES)

• Message Integrity (Hash) Functions

— Hash-based Message Authentication Code (HMAC)

— Secure Hash Algorithm-1 (SHA-1)

• Peer Authentication

— Rivest, Shamir, and Adelman (RSA) Digital Signatures

— RSA Encrypted Nonces

• Key Management

— Certificate Authority (CA)

• Security Association

— Internet Key Exchange (IKE)

— Internet Security Association and Key Management Protocol (ISAKMP)

NOTE IKE and ISAKMP are interchangeable in Cisco implementations.

These protocols are examined in more detail in the following sections.

The IPSec Protocols

The protocols that IPSec uses to provide traffic security are Authentication Header (AH) and Encapsulating Security Payload (ESP). These two protocols are considered purely IPSec protocols and were developed strictly for IPSec. Each protocol is described in its own RFC, which was identified in Table 2-7. You can use AH and ESP independently on an IPSec connection, or you can combine their use.

IKE and IPSec negotiate encryption and authentication services between pairs. This negotiation process culminates in establishing Security Associations (SAs) between security pairs. IKE SAs are bidirectional, but IPSec SAs are unidirectional and must be established by each member of the VPN pair to establish bidirectional traffic. There must be an identical SA on each pair to establish secure communications between pairs. The information associated with each SA is stored in a Security Association Database, and each SA is assigned a Security Parameters Index (SPI) number that, when combined with the destination IP address and the security protocol (AH or ESP), uniquely identifies the SA.

The key to IPSec is the establishment of these SAs. SAs are negotiated once at the beginning of an IPSec session and periodically throughout a session when certain conditions are met. To avoid having to negotiate security for each packet, there had to be a way to communicate the use of an already agreed upon SA between security pairs.

That is where the AH and ESP protocols come into use. These two protocols are simply a means of identifying which prenegotiated security features to use for a packet going from one peer to another. Both of these protocols add an extra header to the IP datagram between the Layer 3

(IP) and Layer 4 (usually TCP or UDP) protocol headers. A key element contained in each protocol's header is the SPI, giving the destination peer the information it needs to authenticate and decrypt the packet.

Authentication Header

The Authentication Header (AH) protocol is defined in RFCs 1826 and 2402 and provides for data integrity, data origin authentication, and an optional antireplay service. AH does not provide encryption, which means that the packets are sent as clear text. AH is slightly quicker than ESP, so you might choose to use AH when you need to be certain of the source and integrity of the packet but confidentiality is not a concern.

Devices configured to use AH insert an extra header into the IP datagrams of "interesting traffic," between the IP header and the Layer 4 header. Because a processing cost is associated with IPSec, VPNs can be configured to choose which traffic to secure, and IPSec and non-IPSec traffic can coexist between security pairs. You might choose to secure e-mail traffic but not web traffic, for example. The process of inserting the AH header is shown in Figure 2-5.

Figure 2-5 AH Header in IPSec Datagram