IPsec is a network security protocol used to provide security at the network layer of the OSI Model, where IP packets reside. IPsec processes data both inbound (traffic coming into the network) and outbound (traffic going outside of the network). It is quite comprehensive and as a result needs to be covered in quite a lot of detail, but overall it is just adding security to the network layer.


  • IP security policy
    • SA - Security Association
      • SAD - Security Association Database
      • SPD - Security Policy Database
  • AH - Authentication Header
  • Encapsulating Security Payload
    • ESP in Tunnel and Transport Modes

IP security policy

An IP security policy is the policy that an IP packet follows in order for it to be secure. This policy is determined by the attributes of the packets which the sender and receiver are attempting to exchange over the network using something called a Security Association.

SA - Security Association

A security association is simply the associations that are shared between the IP packets being sent by both sender and receiver. A few examples of such associations are things such as the encryption and authentication algorithms that the two hosts will use, as well as the protocol mode (tunnel or transport).

SA's are determined by an SPI (Security Parameters Index) which is simply a string that is added to the header of the packet. In addition the 'Security Architecture for the Internet Protocol' [1] standard describes a SA as: "a triple consisting of a Security Parameter Index (SPI), an IP Destination Address, and a security protocol (AH or ESP) identifier". Therefore an SA comprises of an SPI, the address of the packet and an identifier establishing the security protocol which is used to handle the security of the packet; both AH and ESP will be covered at a later stage.

SAD - Security Association Database

You'll be glad to know that there is nothing SAD about a Security Association Database. Jokes aside, an SAD is simply a database containing indexes of security policies (SPI's). This database is used by the SPD in order to establish policies.

SPD - Security Policy Database

As mentioned, a SPD is essentially an index, or several indexes from an Security association Database. An example of this could be a policy which contains several security associations, which is stored in the SPD as a policy which the sender and receiver in the network will adhere to.

AH - Authentication Header

AH is a header that is added to the IP packet. It allows stateless integrity and data origin authenticaion of packets. An additional, but optional security feature of AH is the prevention of replay attacks, which is actuated when the receiver's Security Association allows it to increment the checksum, of course, this means that the receiver will be able to read this value, which is the optional mechanism that must be selected in order for replay attacks to be avoided using AH.

This value (which is sent and incremented) is the Sequence Number Field of the packet. It is not recommended to share this value amongst multiple senders as AH has no way of synchronising this data and thus cannot prevent replay attacks in this case. Below is the format of the Authentication Header, as extracted from the AH RFC documentation [2].

| Next Header   |  Payload Len  |          RESERVED             |
|                 Security Parameters Index (SPI)               |
|                    Sequence Number Field                      |
|                                                               |
+                Integrity Check Value-ICV (variable)           |
|                                                               |

ESP - Encapsulating Security Payload

Firstly, the term payload immediately indicates that ESP is related to the payload of a packet. Again, as the name suggests, the payload of the packet is encapsulated with security features which provide "data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and (limited) traffic flow confidentiality"[3].

ESP in Tunnel and Transport Modes

It is important to note, in that ESP encapsulates (encrypts) data differently depending on which mode it is being ran in. There are two modes, transport and tunnel. In tunnel mode, ESP is applied to the whole packet which is placed inside of a new header that is used for routing purposes; this is of course because the encapsulated ESP packet is encrypted and therefore cannot be read by other routers (hopping). Therefore encapsulating it in this way allows the ESP packet to be transmitted and read by routers, because the new IP address can be read.

ESP in transport mode encrypts the payload of the packet instead of encapsulating the encrypted packet in a new packet (as done in tunnel mode). A drawback is that this allows traffic analysis, because the IP address of the packet is visible to the network, although the payload is encrypted.

See the specification for ESP here[3].


  • [1] https://tools.ietf.org/html/rfc4301
  • [2] https://tools.ietf.org/html/rfc4302
  • [3] https://tools.ietf.org/html/rfc4303