What is an IPsec protocol that authenticates that packets received were sent from the source?

Authentication header (AH)

AH, one of the IPSec security protocols, provides integrity protection for packet headers and data, as well as user authentication. It can optionally provide replay protection and access protection. AH cannot encrypt any portion of packets.

AH modes

AH has two modes: transport and tunnel. In tunnel mode, AH creates a new IP header for each packet; in transport mode, AH does not create a new IP header. In IPSec architectures that use a gateway, the true source or destination IP address for packets must be altered to be the gateway's IP address. Because transport mode cannot alter the original IP header or create a new IP header, transport mode is generally used in host-to-host architectures.

Encapsulating security payload (ESP)

ESP is the second core IPSec security protocol. In the initial version of IPSec, ESP provided only encryption for packet payload data. Integrity protection was provided by the AH protocol if needed. In the second version of IPSec, ESP became more flexible. It can perform authentication to provide integrity protection, although not for the outermost IP header. Also, ESP's encryption can be disabled through the Null ESP Encryption Algorithm. Therefore, in all but the oldest IPSec implementations, ESP can be used to provide only encryption; encryption and integrity protection; or only integrity protection.

ESP has two modes: transport and tunnel. In tunnel mode, ESP creates a new IP header for each packet. The new IP header lists the endpoints of the ESP tunnel (such as two IPSec gateways) as the source and destination of the packet. Because of this, tunnel mode can be used with all three VPN architecture models.

Internet Key Exchange (IKE)

The purpose of the Internet Key Exchange (IKE) protocol is to negotiate, create, and manage security associations. Security association (SA) is a generic term for a set of values that define the IPSec features and protections applied to a connection. SAs can also be manually created, using values agreed upon in advance by both parties, but these SAs cannot be updated; this method does not scale for real-life large-scale VPNs. IKE uses five different types of exchanges to create security associations, transfer status and error information, and define new Diffie–Hellman groups. In IPSec, IKE is used to provide a secure mechanism for establishing IPsec-protected connections.

IP Payload Compression Protocol (IPComp)

In communications, it is often desirable to perform lossless compression on data—to repackage information in a smaller format without losing any of its meaning. The IP Payload Compression Protocol (IPComp) is often used with IPSec. By applying IPComp to a payload first, then encrypting the packet through ESP, effective compression can be achieved.

IPComp can be configured to provide compression for IPSec traffic going in one direction only (e.g., compress packets from endpoint A to endpoint B, but not from endpoint B to endpoint A) or in both directions. Also, IPComp allows administrators to choose from multiple compression algorithms, including DEFLATE and LZS.49 IPComp provides a simple yet flexible solution for compressing IPSec payloads.

IPComp can provide lossless compression for IPSec payloads. Because applying compression algorithms to certain types of payloads may actually make them larger, IPComp only compresses the payload if it will actually make the packet smaller.

IPSec uses IKE to create security associations, which are sets of values that define the security of IPsec-protected connections. IKE phase 1 creates an IKE SA; IKE phase 2 creates an IPSec SA through a channel protected by the IKE SA. IKE phase 1 has two modes: main mode and aggressive mode. Main mode negotiates the establishment of the bidirectional IKE SA through three pairs of messages, while aggressive mode uses only three messages. Although aggressive mode is faster, it is also less flexible and secure. IKE phase 2 has one mode: quick mode. Quick mode uses three messages to establish a pair of unidirectional IPSec SAs. Quick mode communications are encrypted by the method specified in the IKE SA created by phase 1.

ESP

ESP provides confidentiality (in addition to authentication, integrity, and anti-replay protection) for the IP payload. ESP in transport mode does not sign the entire packet. Only the IP payload (not the IP header) is protected. ESP can be used alone or in combination with AH (in order to provide for signing of the entire packet).

NOTE

IPSec is based on machine certificates, thus authentication pertains to only the computer from which the message was sent. IPSec cannot verify that data was sent from a particular user (although there are other mechanisms for doing so).

The ESP header is placed before the IP payload, and an ESP trailer and ESP authentication trailer are placed after the IP payload. The ESP header contains the following fields:

Security Parameters Index (SPI) Used to identify which SA is used in conjunction with the security protocol and destination address. This value is used by the receiver to determine the packet identification.

Sequence Number Provides anti-replay protection for the packet. The sequence number starts at 1 and increases in 32-bit increments. It is used to indicate the packet number sent over the quick mode SA for the communication. This number cannot be repeated. If a recipient gets a number that has been repeated, it will not accept the packet.

The ESP trailer contains the following fields:

Padding Validates that byte boundaries are present on encrypted payloads. This process is required by the encryption algorithm.

Padding Length Used to show the length, in bytes, of the Padding field.

Next Header Used to identify whether the payload data is TCP or UDP.

The ESP authentication trailer contains the Authentication Data field, which holds the message authentication code, also known as the integrity check value (ICV). The ICV is used for message verification and authenticity. The ICV is calculated by the packet receiver and checked against the sender’s value for integrity verification.

Figure 10.3 illustrates how ESP affects the data. You can see that the IPSec AH header has been placed after the IP header and before the TCP header.

AH

AH does not provide confidentiality, which means that the data is not encrypted. Without data encryption, unauthorized people could use a sniffer-type program on your network to capture and read the packets, but they could not modify the data. AH works by using keyed hash algorithms, which are used to sign the packet for integrity verification.

Here is the process by which AH works:

Computer A sends data to Computer B.

The IP header, the AH header, and the data are signed to provide integrity.

The recipient at Computer B can be assured that the data was sent from Computer A and that the data arrived at the destination unmodified.

The AH header is placed between the IP header and IP payload to ensure integrity and authentication. AH can be used alone or combined with ESP. The AH header contains the following fields:

Next Header Used to identify the IP payload via the IP protocol ID. The value here indicates the protocol (for example, TCP is represented by a value of 6).

Length Used to indicate the length of the AH header.

SPI A combination field that contains the destination address and the security protocol. This field is used to identify the correct SA for communication.

Sequence Number Used to provide the packet with anti-replay protection. The sequence number starts at 1 and then increases in increments. The value in this field is a 32-bit number. For the life of the quick mode SA, the sequence number cannot repeat itself. If the receiver does a check on this field and finds that an SA with this number has been received in the past, the packet is denied.

Authentication Data Used to verify message integrity and authentication using the ICV. The ICV value is checked and calculated by the receiver over the IP header, the AH header, and the IP payload.

Packet Signature with the AH Header Used by AH to sign the entire packet. The packet is checked for integrity. The AH header will be inserted before any additional IPSec headers if other IPSec headers are present.

Packet Signature and Encryption Used to protect IP payloads, as shown in Figure 10.4. The signed portion of the packet indicates the packet has been signed for integrity and authentication, and the encrypted portion of the packet indicates that the information itself is confidential.

The AH packet signature is shown in Figure 10.4.

If you need both data integrity and authentication for the IP header, use ESP and AH in combination, as illustrated in Figure 10.5.

EXAM DAY WARNING

Be able to differentiate between the AH and ESP IPSec protocols, and know how each of these protocols operate to make the data secure.