Practical Overview of the IPsec Protocol

You can have multiple IPsec SAs between two endpoint hosts, since you can have different policies. For example, one IPsec SA could describe an IPsec connection using ESP and tunnel mode between the two hosts, while a second IPsec SA could describe an IPsec ESP tunnel mode connection between machines on the subnets behind the IPsec hosts. You could even limit the range of ports allowed on such a connection if you wanted to. These IPsec SAs are stored in the

Security Association Database (SAD).

The SPD and SAD work together almost like a firewall. An IPsec packet that is received has to match an SPI in the SAD, or the packet is dropped (as dictated by an SPD entry). If a matching SPI is found for an authenticated packet, once the IPsec packet is successfully decrypted using ESP, the source and destination address and ports are checked with the policy that belong to this IPsec SA. If the packet matches the policy, it is allowed to enter the normal networking path of the kernel. But if the decrypted packet has an unexpected source address, for example 127.0.0.1, the packet does not match the IPsec SA policies and will be dropped.

Encryption Details

Apart from the policies, the IPsec SA also contains the agreed stream cipher to use. There is a wide variety of stream ciphers that can be used, but the most common ones are AES and 3DES. Single DES (or 1DES) is sometimes still used but is really far too weak for modern use and it is very strongly discouraged.

Currently SHA1 and MD5 are used as secure hashing algorithms. Which ciphers and hash functions are available depends on the specific kernel implementations. MD5's lifespan is limited at this point, as it is showing some cracks, but HMAC usage of MD5 has not yet been attacked. It was designed to work despite this possible form of attack, which involves finding 'collisions'.

Manual Keying

So far we have seen what happens when two trusted parties want to exchange authenticated and encrypted data. But how do they establish this trust relationship when they are on the other side of the world?

One could send an encrypted email, or talk over a (presumably) secure telephone to exchange a secret key, known as manual keying, and then enter this key into the kernel manually where it can be used for the cryptographic functions of that IPsec SA.

Manual keying is not recommended. Not only is it hard to set up, it is invariably never touched again by the system administrator, and the key-life becomes indefinite, making it more susceptible to a brute force attack. Also, once the secret key is compromised, all past intercepted communication can be decrypted using it. Manual keying has no replay protection.

Manual keying is strongly discouraged, so much that the authors will not explain how to set it up in this book. Those who, against better judgment, want to use manual keying should read the relevant parts of the manual that comes with Openswan.

36