OpenBSD IPsec

  IPsec in the OpenBSD kernel is implemented as a pair of transport protocols [7,8]. Incoming IPsec packets are switched to the appropriate IPsec protocol for processing by ipv4_input(), following the usual packet processing path in the kernel (similar, for example, to TCP or UDP). Note that only packets destined for the local host are handled this way; IPsec packets that are passing through are simply forwarded if the host is configured to act as a router, otherwise they are dropped).

Outgoing packets are intercepted at ip_output(), where a check is made to see if IPsec processing is necessary. If so, the appropriate IPsec protocol output routines are called which encrypt/authenticate the packet, and then re-send it via ip_output() specifying that IPsec processing has already occurred (so as to avoid loops). Two methods are used to determine whether a packet needs to be IPsec-processed:

• If the packet originated from a local socket, it may have an attached Security Association (SA).
• If no such information is available, the source and destination addresses and ports from the packet are used to make a lookup in the kernel Security Policy Database (SPD). In OpenBSD, the SPD is implemented as a new protocol family in the radix tree, which is also used for routing entries. There are several benefits to using the radix tree:
  • Code reuse (and, thus, bug avoidance).
  • The radix tree internal representation is compact, allowing for large numbers of SPD entries without high memory requirements.
  • Lookup cost scales well with number of entries in the table.
  • Because a lookup returns the most specific result, it is easy to implement ``backup'' entries for packet classes (or, conversely, we can have special case handling of certain packet classes).

In both cases, the lookup provides enough information to locate the SA. Note that, on input, the packet itself contains enough information to locate the SA. The SA itself contains such information as the cryptographic algorithms and keys to be used, what optional features of the protocols are in use, various expiration timers, etc.

Both the SA and SPD tables may be populated either through manual keying utilities, or by some automated key management daemon (like IKE [5] or Photuris [6]). The interface to the kernel for either of these methods is via the PF_KEY socket [14], which is in many ways similar to the BSD routing socket.

Both in input or output, if the necessary cryptographic material has not been negotiated with the remote IPsec endpoint (for example, when doing on-demand or ``opportunistic'' IPsec), it is possible to notify a key management daemon which will then negotiate and install the proper SA and SPD entries in the kernel.

We have also implemented the enc pseudo-interface. Input packets that are IPsec-processed are made to appear as if they were received from the enc interface, by changing the interface pointer in the mbuf header. Thus, an administrator can easily filter non-IPsec protected packets using any packet filtering package. Furthermore, utilities like tcpdump [13] can be used to view the intermediate products of IPsec processing, for debugging purposes (this only works if IPsec processing takes place in the local host).

A more extensive (if somewhat dated) overview of the OpenBSD IPsec architecture is given in [10].

This is the standard IPsec processing that is more or less common across different implementations (and even operating systems). Use of IPsec in conjunction with the bridge, especially in the ``bump in the wire'' scenario, requires somewhat different processing. We shall describe these changes and requirements in the next two subsections.