IPsec

IPsec

IP-IP tunnelling type.
Suite of protocols for securing network communication.
Uses orthogonal concepts

Concept: AH vs ESP

Main L3 protocols, IP packet's proto field point to either AH (51) or ESP(50)

AH (51)

Authentication only, doesn't provide encryption. Auth (hash-based) is computed using all IP header fields (but TTL and header checksum)

Notable headers:

• Security Parameter Index: 32bit identifier, used by recipient to fetch the security context associated with the packet
• Authentication Data: calculated hash value, mismatched hash value means the packet is discarded

Incompatible with NATs since IP addresses are used to compute the hash, intermediate parties doing NAT don't know the secret key to recompute the hash. Thus the receiving site drops the packets.

ESP (50)

Provides encryption and flow identifier (Security Parameter Index - SPI)

Concept: Tunnel vs Transport

The modes differ in policy application. Distinguished only by next header field in AH or ESP header.

next header (symbolic name)	mode
ip	tunnel mode
AH or ESP	transport mode

Transport

Provides encryption and authentication (or both). The IP header is not encrypted. The IP header determines the policy to be used for the packet

Example for AH mode | IP header | AH header | TCP |

Typically used to secure communication between hosts

Tunnel

The entire IP packet is encapsulated. Implication of that is following: the encapsulated source/destination addresses may be different than these in IP header (routing information is changed).

| IP header | AH header | IP header | TCP |

Typically used to secure communication between networks

Concept: IKE vs manual

Mechanism of negotiating keys

IKE

In Linux typically implemented via pluto or charon

Manual

Concept: main mode vs aggressive

Processing

Description of the IPsec processing on the Linux OS

Security Policy Database (SPD)

What to encrypt, e.g, "all packets from 10.0.0.0/13 IPsec encrypt"
ip xfrm policy dumps all policies

SADP

How to encrypt, or rather how to apply the security transformations
ip xfrm state dumps all security associations, dumps the master key as well

Packet flow

Sender side (simplified): 0. Send packet

1. ip_route_output_flow() check the routing information ip route get <dst>
2. xfrm_lookup_route() find IPsec SPDs (finds IPsec policy)
3. if no policy found: just send
4. if policy found, get xfrm_state. If the state is not yet established, drop UDP packet (TCP is not dropped) and establish the xfrm_state

Received side (simplified): 0. Incoming packet

1. Decide if packet is for local process or not, if not then forward
2. if local and ESP packet then go into XFRM
3. find SA using SPI, validate keys, decrypt
4. submit decrypted IP packet back to IP stack

References

1. One of the best IPsec descriptions
2. IPsec in Linux kernel
3. https://www.youtube.com/watch?v=7oldcYljp4U