You can configure other scenarios as nested combinations of the above configurations.
IPsec uses two different protocols, Authentication Header (AH) and Encapsulating Security Payload (ESP),
to ensure the authentication, integrity, and confidentiality of the communication.
To protect the integrity of the IP datagram, the IPsec protocols use hash message authentication codes
(HMAC). To derive this HMAC, the IPsec protocols use hash algorithms like MD5 and SHA to calculate a
hash based on a secret key and the contents of the IP datagram. This HMAC is then included in the IPsec
protocol header and the receiver of the packet can check the HMAC if it has access to the secret key.
To protect against denial of service attacks, the IPsec protocols use a sliding window. Each packet gets
assigned a sequence number and is accepted only if the packet's number is within the window or newer.
Older packets are immediately discarded. This protects against replay attacks where the attacker records
the original packets and replays them later.
A security association (SA) is the collection of security parameters and authenticated keys that are
negotiated between IPsec peers. For the peers to be able to encapsulate and de-encapsulate the IPsec
packets, they need a way to store the secret keys, algorithms, and IP addresses involved in the
communication. All these parameters needed for the protection of the IP datagram are stored in a security
association (SA). The security associations are in turn stored in a security association database (SADB).
An IPsec security association is a construct that specifies security properties that are recognized by
communicating hosts. The properties of the SA are the security protocol (AH or ESP), destination IP
address, and Security Parameter Index (SPI) number. SPI is an arbitrary 32-bit value contained in IPsec
protocol headers (AH or ESP) and an IPsec SA is unidirectional. Because most communication is
peer-to-peer or client-to-server, two SAs must be present to secure traffic in both directions. An SA specifies
the IPsec protocol (AH or ESP), the algorithms used for encryption and authentication, and the expiration
definitions used in security associations of the traffic. IKE uses these values in negotiations to create IPsec
SAs. You must create an SA prior to creating an SA-proposal. You cannot modify an SA once it is created.
Use the ipsecConfig --flush manual-sa command to remove all SA entries from the kernel SADB
and re-create the SA.
The IPsec sa-proposal defines an SA or an SA bundle. An SA is a set of parameters that define how the
traffic is protected using IPsec. These are the IPsec protocols to use for an SA, either AH or ESP, and the
encryption and authentication algorithms to use to protect the traffic. For SA bundles, [AH, ESP] is the
Authentication and Encryption Algorithms
IPsec uses different protocols to ensure the authentication, integrity, and confidentiality of the
communication. Encapsulating Security Payload (ESP) provides confidentiality, data integrity and data
source authentication of IP packets, and protection against replay attacks. Authentication Header (AH)
provides data integrity, data source authentication, and protection against replay attacks, but unlike ESP,
AH does not provide confidentiality.
In AH and ESP, hmac_md5 and hmac_sha1 are used as authentication algorithms. Only in ESP,
3des_cbc, blowfish_cbc, aes256_cbc and null_enc are used as encryption algorithms. Use
when configuring the authentication algorithm.
Algorithms and associated authentication policies
148 Configuring advanced security features
Encryption Level Policy