IPsec provides authentication and integrity of packets, and also confidentiality of communication. To this avail, it uses a number of cryptographic primitives, such as:

• HMAC (Hash-MAC) -- used for creating digests of messages;
• digital signatures (RSA-based);
• encryption algorithms (DES, 3DES, IDEA, AES);
• key transfer mechanisms (DH, IKE, Kerberos).

The use of particular implementations of algorithms is driven by their provable security and performance -- since operations are applied for each IP packet at origin and destination, these must be quick so as to not create bottlenecks in transmission. Contemporary IPsec relies mostly on AES due to its better performance and longer keys than that of DES, which, in connection with efficient implementations in hardware allows for high-security and throughtput solutions.

IPsec suite allows selection of security protocols and provision of required keys between two communicating parties. As such, then, it can be used to create private, closed to public transmission lines between the parties. Referring to one of the first figures in this series, you will find immediate use of IPsec for alleviating problems of data transmission over internet. Recall use cases for the following aspects of communication:

1. access control -- restricting access to priviledged users only;
2. integrity of connection -- assuring that the stream of data (IP packets, etc.) has not been modified on the fly by a third party;
3. data authentication -- assuring that originator of the data is the one who the recepient believes it is;
4. data confidentiality -- even though data is sent over a public medium, it cannot be eavesdropped and information it contains remains secret.

In general, IPsec contains three mechanisms, which we will describe in detail below. They can be combined or used stand-alone, and in general, IPsec provides two modes of operation:

The modes can be mixed to serve different network settings, such as, eg. client connecting to a network via VPN channel.

1. AH - Authenticated Headers

Detailed in RFC 4302, 4305. Provides sender authentication and data integrity and, optionally, replay detection. This is obtained by inserting into an exisiting IP datagram the Authentication Header, that is dependant on the IP packet's headers. It takes the following form: (see Fig.4.4.3/1)

Fig.4.4.3/1

This is the significance of the fields:

• Next Header contains next header after AH header;
• Length length of AH header -- number of 32-bit words;
• Reserved for further use, now 32 zeros;
• SPI 32-bit number for security association for this IP packet;
• Sequence Number a counter value, used as countermeasure against replay attack; transmitter has to observe it, receiver does not and every new SA (see below) established resets this counter;
• Authentication Data data authenticating original IP header (except for those that change as the packet travels trhough network (i.e. TTL, checksum, ToS) and all content of the packet after the AH header; the mechanism used for calculating this part is negotiated at set-up by both parties.

Since Authentication Data is calculated using a key shared by transmitter and receiver and is based on IP packet contents - the payload of such packet cannot be changed by a third party, nor can be modified the header fields.

2. ESP - Encapsulating Security Payload

Detailed by RFC 4303, 4305. Provides data confidentiality (unlike AH!), sender authentication and data integrity. This is achieved by inserting additional information after original IP packet header, that contains EPS-specific information and encapsulates the original payload. An IP packet with ESP has the following form: (see Fig.4.4.3/2)

Fig.4.4.3/2

The fields in this datagram represent as follows:

• IP - original IP header;
• ESP header - contains Security Parameters Indes (SPI) and sequence number, which role is the same as that in AH;
• [L4, data] - correspond to original packet's Layer 4 headers and payload (remember, IPsec works on L3); they consititute Payload Data Field of ESP. They can be padded to suit the chosen cipher.
• ESP trailer - contains padding length and Next Headerfield identifying datatype contained in payload;
• ESP auth - this can be a HMAC over the entire packet.

As can be seen in the picture, L4, data and ESP trailer fields are encrypted, so that data in payload is kept hidden.

3. SA - Security Associations

These are collections of connection-specific information that each sender/receiver maintains in order to apply adequate security measures for each received packet. Specifically, the foloowing triple uniquely identifies an SA:

• sender IP address;
• type of IPsec Protocol (ESP or AH);
• Security Parameters Index (SPI).

Note that all this information is contained in an incomming IP datagram. An SA is, then, a combination of the following information:

• corresponding host: who to apply the rules to;
• traffic type: on what kind of connections (what services, etc.);
• algorithm set: what algorithms to use for authentication, encryption;
• keys set: which keys to use for these algorithms.

Note that SA are unidirectional, i.e. for a two-way communication two SA are required -- one for each communicating party. Also, each type of IPsec maintains its own set of SA, so typically many SA are maintained for each communication, they are stored in SAD (SA Database).