IP Security IPSec

IPSec provides security services at the IP layer by enabling a system to select required security protocols, determine the algorithm(s) to use for the service(s), and put in place any cryptographic keys required to provide the requested services. RFC 2401 for IP

IPSec is a defined encryption standard that encrypts the upper layers of the OSI model by adding a new predefined set of headers. A number of RFCs defined IPSec. IPSec is a mandatory requirement for IP version 6. (IPV6 is not covered in the examination.) IPSec ensures that the network layer of the OSI model is secured. In TCP/IP's case, this would be the IP network layer.

IPSec can be configured in two protection modes, which are commonly referred to as Security Association (SA). These modes provide security to a given IP connection. The modes are as follows:

• Transport mode—Protects payload of the original IP datagram; typically used for end-to-end sessions

• Tunnel mode—Protects the entire IP datagram by encapsulating the entire IP datagram in a new IP datagram

SA is required for inbound and outbound connection. In other words, IPSec is unidirectional. IKE, discussed in this chapter, allows for bidirectional SAs.

Figure 5-12 displays the extension to the current IP packet frame format for both transport and tunnel modes.

Figure 5-12 IPSec Protection Modes

Original IP Datagram

Transport Mode

Tunnel Mode

Original IP Datagram

IP Header

IP Data (Not Encrypted)

IP Header

IPSec Header

Data (Encrypted)

New IP Header





New IP Header

IPSec Header

Original Header

IP Data (Not Encrypted)

Original IP Datagram

The encapsulation security payload (labeled IPSec header in Figure 5-12) can be of two forms:

• Encapsulation Security Payload (ESP)

• Authentication Header (AH)

Each of these is discussed in the following sections.

Encapsulation Security Payload (ESP)

The ESP security service is defined in RFC 2406. ESP provides a service to the IP data (pay-load), including upper-layer protocols such as TCP. The destination IP port number is 50. The ESP header is located between the user data and original IP header, as displayed in Figure 5-13.

Figure 5-13 displays the ESP header. Figure 5-13 ESP Header


IP Data


ESP does not encrypt the original IP header, and encrypts only the IP data by placing a header in between the original IP header and data. ESP provides data confidentiality, data integrity, and data origin authentication. ESP also prevents replay attacks. Replay attacks can include intruders capturing a valid packet and replaying it over the network in an attempt to get a packet conversation between an illegal and legal host.

ESP does not protect the IP header and cannot ESP detect any alternations during packet delivery.

Figure 5-14 displays the frame formats when ESP is applied.

The Security Parameters Index (SPI) is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (ESP), uniquely identifies the Security Association for this datagram.

The sequence number, an unsigned 32-bit field, contains a monotonically increasing counter value. It is mandatory and is always present, even if the receiver does not elect to enable the antireplay service for a specific SA. Pad or padding is used when the frame needs to meet the minimum frame size formats. The pad length defines the length of padding used. Padding is used for a number of reasons. For example, padding can ensure that the minimum frame size is set so that packets are not discarded because they are too small. Padding is typically all binary ones (1111. . .) or zeros (0000. . .). The sequence number ensures that no intruder or intruders can replay data transactions by using any form of attack mechanisms.

Figure 5-14 ESP Frame Format

IP Header (Port 50)

Security Parameter Index (SPI)

Sequence Number

Payload Data (variable)

PAD (0-255 bytes)

PAD Length

Next Header

IP Data

Authentication Data

The Next Header is an 8-bit field that identifies the type of data contained in the Payload Data field. The IP data field contains the data to be sent. The Authentication Data field is a variable-length field containing an Integrity Check Value (ICV) computed over the ESP packet minus the Authentication Data.

Authentication Header (AH)

AH is described in RFC 2402. The IP protocol destination port is 51. Figure 5-15 highlights the fields in the IP datagram that are encrypted and authenticated. Note that not all fields, such as the Time to Live fields, are encrypted.

NOTE AH provides data origin authentication and optional replay-detection services. AH doesn't provide data confidentiality (or encryption). Authentication is done by applying one-way hash to create a message digest of the packet. Replay detection can be implemented using the sequence number in the IP packet header.

Figure 5-15 AH Header

AH Header

IP Header (Port 51)

AH Header

TCP/UDP Header


Fields protected by AH Unprotected (variable) Fields

Ver Le


Total Length


Flags, Fragment



Header Checksum

Source IP Address

Destination IP Address

Next Header

Payload Length


Security Parameter Index (SPI)

Security Parameter Index (SPI)

Sequence Number

Authentication Data d te c

Following is a description of an AH packet:

• Next Header, an 8-bit field, identifies the type of the next payload after the Authentication Header.

• The Payload Length field is an 8-bit field specifying AH's length in 32-bit words (4-byte units), minus 2.

• The Reserved field is a 16-bit field reserved for future use. It MUST be set to 0.

• The SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (AH), uniquely identifies the Security Association for this datagram.

AH can operate in transport or tunnel mode; however, contrary to ESP, AH also protects fields in the outer IP Header (in transport mode, this is the original IP header; in tunnel mode, this is the newly added IP header), which are normally considered nonvariable. AH ensures that if the original IP header has been altered, the packet is rejected.

Before you take a look at how IPSec is enabled on Cisco routers, you need to understand how keys are exchanged between secure devices to ensure that data is not comprised. IPSec ensures that once an IPSec tunnel is created, that the keys are modified so intruders cannot replicate the keys and create IPSec tunnels to insecure locations. A recent study showed that a network of computer hackers was able to decipher a DES-encrypted message in just a day.

In IPSec, this function is provided by Internet Key Exchange (IKE). IKE is discussed in the next section.

0 0

Post a comment