↓ Skip to main content
Le Site de François
  1. Index/

IPsec (Internet Protocol Security)

Security Networking Cryptography Vpn Encryption Layer3

IPsec (Internet Protocol Security) is a suite of IETF standards (core specification RFC 4301) that adds cryptographic security to IP packets at the network layer, transparently to applications running above it. Where TLS secures a specific connection between two application endpoints, IPsec secures all IP traffic between two hosts or networks — including traffic from applications that have no TLS support, protocols that predate encryption (routing protocols, SNMP, ICMP), and layer-3 metadata that TLS cannot protect. IPsec provides two protocol headers: AH (Authentication Header, IP protocol 51) signs the IP packet including immutable header fields, providing integrity and source authentication without confidentiality — rarely used in modern deployments because NAT rewrites fields that AH covers. ESP (Encapsulating Security Payload, IP protocol 50) encrypts the payload and provides authenticated encryption with AES-GCM or ChaCha20-Poly1305, optionally protecting the inner IP header as well; ESP is the universally deployed choice. Both operate in two modes: transport mode protects only the payload of an existing IP packet (used for host-to-host encryption between endpoints that share routing), and tunnel mode encapsulates the entire original IP packet inside a new one with new source and destination addresses — the basis of VPN gateways where traffic from one network is tunnelled to another through the public internet.

The session management layer is IKEv2 (Internet Key Exchange version 2, RFC 7296), which runs over UDP port 500 (and 4500 for NAT traversal with UDP encapsulation of ESP). IKEv2 negotiates the cipher suite, performs mutual authentication (via X.509 certificates, raw public keys, or pre-shared keys), and establishes Security Associations (SAs): unidirectional agreements that specify the cryptographic parameters — algorithm, key, lifetime, and SPI (Security Parameter Index) — for a single direction of traffic. The two parties maintain a Security Association Database (SAD), which maps incoming SPI values to their decryption parameters, and a Security Policy Database (SPD), which maps traffic selectors (source/destination IP prefixes, port ranges, protocols) to the action to take — encrypt (and which SA to use), bypass (send cleartext), or discard. On Linux, both databases live in the kernel’s XFRM subsystem (inspectable and configurable via ip xfrm state and ip xfrm policy), and IKEv2 is managed by a user-space daemon — strongSwan and libreswan are the two most common — which communicates with the kernel via the NETLINK_XFRM socket. Hardware offload of IPsec crypto is available on NICs that support xfrm offload, enabling line-rate encryption without CPU overhead.

IPsec occupies a distinct position relative to the other security layers in this glossary. It operates below the transport layer, so it protects all traffic including mTLS handshakes and the application layer on top — the two can be layered. MACsec operates one layer below IPsec, at layer 2, and can protect the Ethernet frames that carry IPsec packets; the two are complementary. In Kubernetes, IPsec is the transparency-preserving pod-to-pod encryption choice: Cilium supports an IPsec mode where it installs XFRM policies on every node so that all pod traffic crossing node boundaries is ESP-encrypted without any application or container change, using PSK or certificate-based keys rotated automatically. This makes IPsec-based pod encryption a practical alternative to mTLS service mesh overlay encryption for environments where mTLS sidecar injection is undesirable or where the workload is not able to participate in a SPIFFE identity scheme. The PQC transition affects IPsec at the IKEv2 layer: RFC 9370 specifies ML-KEM for use in IKEv2 key exchange, and RFC 9242 defines the ML-DSA signature algorithms for IKEv2 authentication, with strongSwan and libreswan adding support as the standards finalise.

Related

WireGuard

Networking Security Vpn Cryptography Linux Kernel
WireGuard is a VPN protocol and implementation designed by Jason Donenfeld, merged into the Linux kernel in 5.6 (2020) and subsequently ported to Windows, macOS, iOS, Android, and BSD. Its defining characteristic is radical simplicity: the reference Linux kernel implementation is approximately 4,000 lines of code, compared to tens of thousands for IPsec’s XFRM subsystem and hundreds of thousands for OpenVPN. This simplicity is a deliberate security property — a smaller codebase has a smaller attack surface, is easier to audit, and is less likely to contain implementation vulnerabilities. WireGuard achieves this by making every design decision that allows optionality to be eliminated: there is no algorithm negotiation, no handshake negotiation, no cipher suite selection. The cryptographic suite is fixed: X25519 for key exchange, ChaCha20-Poly1305 for authenticated encryption, BLAKE2s for hashing and key derivation (via a custom HKDF-like construction), and Curve25519 for the static key pairs that identify peers. Peers are identified exclusively by their 32-byte Curve25519 public key, making WireGuard a public-key routed VPN: there are no usernames, passwords, certificates, or CAs; access control is entirely a function of which public keys are listed in each peer’s configuration.

AES (Advanced Encryption Standard)

Cryptography Symmetric Encryption Nist Security Primitives
AES (Advanced Encryption Standard), standardised as NIST FIPS 197 in 2001, is the symmetric block cipher that underlies virtually all data encryption in modern infrastructure. It was selected through a five-year open competition that evaluated 15 candidate algorithms; the winner, Rijndael (designed by Joan Daemen and Vincent Rijmen), became AES. A block cipher takes a fixed-size block of plaintext and a key and produces a fixed-size block of ciphertext — AES always operates on 128-bit (16-byte) blocks, regardless of key size. Three key lengths are standardised: AES-128 (128-bit key, 10 rounds), AES-192 (192-bit key, 12 rounds), and AES-256 (256-bit key, 14 rounds), providing 128, 192, and 256 bits of security respectively against classical attacks. AES-256 is the conservative choice for data with long confidentiality requirements and is mandated by CNSA 2.0 for national security systems; AES-128 is widely deployed in TLS and provides adequate security for most workloads. The internal structure — SubBytes, ShiftRows, MixColumns, AddRoundKey — is fully public and has withstood over two decades of cryptanalysis; the best known attacks against full-round AES are theoretical and computationally infeasible, requiring work far beyond brute force but not threatening practical security.

MACsec (IEEE 802.1AE)

Security Networking Layer2 Ethernet Ieee Encryption
MACsec (MAC Security, IEEE 802.1AE) is an IEEE standard, first published in 2006 and supported in the Linux kernel since 4.6 (2016), that encrypts and authenticates Ethernet frames at layer 2 — hop by hop between directly connected devices. Its operating layer is what distinguishes it from IPsec (layer 3) and TLS (layer 4): MACsec wraps Ethernet frames, not IP packets or TCP streams, so it can protect every byte that traverses a link segment regardless of what protocol it carries. ARP replies, DHCP offers, LLDP frames, routing protocol adjacencies, and layer-2 broadcast traffic are all encrypted and authenticated alongside application data — something neither IPsec nor TLS can accomplish because both require an IP header to already be present and unenforced. The topology implication of this is that MACsec is link-local and hop-by-hop: it encrypts between two directly adjacent Ethernet peers (a host and a switch, or two switches), decrypts at each hop for forwarding decisions, and re-encrypts toward the next hop. It cannot stretch across a routed boundary; for that, IPsec is the right tool.