Chapter 12. Tunnels

The purpose of integrity checking is to ensure that the packets of data when received are identical to when transmitted - i.e. their contents have not been tampered with en route.

There are a number of algorithms that can be used. They all use a key which is known only to the two ends of the communication. The key is typically a sequence of random-looking bytes, usually expressed in hex notation.

Integrity checking on its own does not stop someone snooping on the contents of the packets, it just makes sure that they are not tampered with on the way (as only someone with knowledge of the key could change the data without invalidating it).

The purpose of encryption is to change the data when it is sent such that nobody snooping on the packet can make sense of it. There are different algorithms, offering different levels of security. Encryption similarly involves a key which is known only to the two ends of the communication.

IPsec provides two ways to encapsulate data - AH (Authentication Header) which integrity checks the packet data and also some of the header fields (IP addresses), and ESP - which both encrypts and integrity checks the payloads.

Authenticaion is a mechanism for ensuring that the two end users of a communication channel trust that they are who they think they are. Neither encryption nor integrity checking alone can do this. To ensure that you are talking to the correct person and not someone else masquerading as them, and to be sure nobody else can read your communications, you need to be sure that keys used for integrity checking and encryption are only known to the two (real) endpoints. Authentication can prevent a "Man-in-the-Middle" attack, where someone who knows the keys can set himself up between the two endpoints, and without their knowledge can masquerade as the other endpoint to each end. Note that a Man in the Middle can both read the data and modify it, without either of the endpoints being aware that this has happened.

It is worth noting that there is scope for confusion in the use of the term Authentication. It is sometimes also used to mean integrity checking, and indeed the "Authentication Header" (AH) should really be known as the Integrity Check Header!

IPsec can be used in what is known as manual-keying mode. When used this way, both endpoints need to trust each other, and choose and agree on the integrity and encryption keys to be used, using some private mechanism which they know to be secure, before the IPsec connection is configured. For example, the system administrators may already know each other, and may arrange to meet in private and exchange keying information (which they trust they will not divulge to anyone else), and then configure their FireBricks to use the agreed keys.

Choosing and configuring the algorithms and keys, as well as any other required connection parameters for a link is a complex business, and also has its own security implications, as you must install the same parameters, including the keys, at both ends of the link while at the same time ensuring the keys remain accessible only to the two ends. If you use any form of communication to do this and that communication channel is not itself secure, you have potentially lost your link security. For this reason there is a protocol known as IKE (Internet Key Exchange) which automatically negotiates and selects algorithms, keys and other parameters, and installs them at each end of the link, using a secure channel between the two systems. Public Key Cryptographic mechanisms are used to do this (using eg the Diffie-Hellman key exchange mechanism). This can be made secure by having the two ends of the link authenticate each other using for example X509 certificates, pre-shared secrets or other methods such as those supported by EAP (Extensible Authentication Protocol). It is still necessary to install these certificates, secrets or methods, obviously, but the configuration is simpler and more secure.

There are some global parameters affecting all connections which can be set on the main IKE entry. The logging options log, log-error, and log-debug can be used to steer IKE logging information which is not specific to a particular connection to a selected logging target.

The allow and trusted entries can be used to restrict IKE connections to particular IPs and/or IP ranges. An IKE connection setup request can potentially be received from any device, and setting up a connection involves some CPU-intensive calculations. The IKE implementation attempts to guard against the possibility of Denial-of-Service attacks from rogue devices requesting bogus connections by limiting the initial connection rate, but for added security the allow and trusted settings are provided. If either is set, only connections from the ranges listed are accepted, and connection requests from the trusted list are given higher priority.

There is also a Force-NAT option which will force the FireBrick to assume that remote devices on the list are behind NAT boxes. IKE has built-in NAT detetion so this option is rarely needed. See the separate section on NAT Traversal for more details.

When IKE connections are negotiated, a selection of compatible algorithms and keys for integrity checking and encryption are selected. The initiating end of the connection provides proposals of various combinations of algorithms it is willing to use, and the responding end picks a suitable set. The IKE implementation has built-in default proposal lists, which are suitable for normal use, but for tighter control further proposals can be configured. An IPsec IKE connection consists of two separate communication paths - the IKE control security association, and the IPsec data connection, and these have separate proposals, which are configured using the Proposal for IKE security association and Proposal for IPsec AH/ESP security association sections. See the later discussion on algorithms for further details.

To set up a new IKE connection, select "Add: New: IKE connections" in the IKE configuration page.

There are a large number of options available for configuring a connection, but the majority can usually be left at their default settings.

Select the required encapsulation type - either AH (providing just authentication) or ESP (providing authentication and/or encryption). Select the required algorithms and choose appropriate keys. The key lengths depend on the selected algorithm according to the following table:

Note that in the current implementation the same key is used for both incoming and outgoing traffic. The same keys and algorithms must be configured at the remote end of the link.

The above keys are examples only. To reduce the possibility that your link could be compromised by keys becoming known or guessed you should generate them using a source of random or pseudo-random data. On a Unix/Linux system the command xxd can be used in conjunction with the /dev/random file. For example to generate a 20-byte key the command would be:

        xxd -len 20 -p /dev/random

You also need to configure an SPI (Security Parameter Index) for both the incoming and outgoing traffic. The SPI value is an integer from 256 to 2³²-1. These are configured as local-spi for incoming traffic and remote-spi for outgoing traffic. The local-spi uniquely identifies this IPsec connection, so must be distinct for all IPsec connections on this FireBrick. The current FireBrick implementation requires that the local SPI for manual connections to be in the range 256 to 65535. The incoming SPI must match the outgoing SPI of the far end of the link, and vice-versa.

You must configure routing to specify which traffic the FireBrick should send out through the tunnel. The routing configuration uses the same style as used elsewhere in FireBrick configuration. A simple set of IPs and/or IP ranges can be specified in the routes attribute, or for more complex routing a number of separate route elements can be added to the tunnel config. Metrics and the routing tables to be used may also be specified.

A graph may be specified to monitor data through the tunnel. A speed may be set to rate-limit the traffic. the mode should be set to the default (tunnel) for normal applications. Transport-mode IPsec is used in certain situations when the traffic to be encapsulated does not have its own IP header. With the current implementation the only use of this is when it is required to provide both AH and ESP protection to encapsulated packets; AH authentication with ESP encryption can provide marginally better authentication but is rarely used. To configure this, set up an ESP tunnel with just encryption, and set up a separate AH IPsec entry in transport mode. Each must have their own separate SPIs, and the ESP entry should have the outer-spi field set to the local-spi of the AH entry. The AH entry should have no IPs, routing, graph or speed set.

The FireBrick IPsec implementation should be compatible with any IPsec implementation providing manual keying, provided a common set of algorithms can be chosen. As an example, the configuration for a Linux system using the ipsec-tools package will be described.

Consider a tunnel between a FireBrick and a Linux system with the following setup:

A suitable FireBrick xml config for this would be:

<ipsec
  local-ip="192.168.1.1" remote-ip="192.168.2.2"
  local-spi="1000" remote-spi="2000" type="ESP"
  auth-algorithm="HMAC-SHA1"
  auth-key="0123456789012345678901234567890123456789"
  crypt-algorithm="AES-CBC"
  crypt-key="00010203040506070809101112131415"
  routes="10.2.2.0/24" />

A corresponding ipsec-tools config file would be:

  flush;
  spdflush;

  add 192.168.2.2 192.168.1.1 esp 1000 -m tunnel
    -E rijndael-cbc 0x00010203040506070809101112131415
    -A hmac-sha1 0x0123456789012345678901234567890123456789;
  
  add 192.168.1.1 192.168.2.2 esp 2000 -m tunnel
    -E rijndael-cbc 0x00010203040506070809101112131415
    -A hmac-sha1 0x0123456789012345678901234567890123456789;

  spdadd 10.1.1.0/24 10.2.2.0/24 any
    -P in ipsec esp/tunnel/192.168.1.1-192.168.2.2/require;
  spdadd 10.2.2.0/24 10.1.1.0/24 any
    -P out ipsec esp/tunnel/192.168.2.2-192.168.1.1/require;
  

Note that rijndael is the name used by ipsec-tools for the AES algorithm.