IPsec-related Tags

  This category includes tags that are used internally by the IPsec stack [6] to detect processing loops and propagate information to high-level protocols.

• IPSEC_IN_DONE records the fact that the packet was received under a particular IPsec Security Association (SA). If the packet has been encrypted under several SAs, there will be one such tag for each SA, with the most recently processed SA located closer to the head of the list. The tag contains enough information to locate the SA data structure in the relevant kernel database. This is used for two purposes:

  1.

  Determine whether a packet has been processed by an SA that satisfied the IPsec policy requirements, e.g., ``all TCP packets from host A must arrive encrypted''. There are various locations in the network stack where such checks are performed.

  2.

  Propagate the information to the socket layer, whereby it is made available to applications via the getsockopt() call. Thus, applications can determine whether a connection is protected, the relevant parameters, the peer's identity (e.g., public-key certificate), etc.

  This is one of the few tags that is used both inside and outside the kernel component where it is created (IPsec stack). The fact that tag processing (in particular freeing) is integrated with mbuf processing (freeing) helped in limiting the amount of supporting code that needed to be added throughout the stack.

• IPSEC_OUT_DONE records IPsec SAs that have been applied to an outgoing packet. This is primarily used to catch processing loops in the network stack, which could cause repeated processing (encryption) of a packet under the same set of SAs. This is necessary because the IPsec standards [5] require support for nested SA processing. Consider the following legitimate policy: ``all packets to subnet 10.1.2.0/24 must be encrypted to the security gateway 10.1.2.1''. Notice that the security gateway's address lies within the destination subnet's address space. A packet that matched this rule once would thus repeatedly match it every time it was re-evaluated by the IPsec policy database, causing a loop. Using the IPSEC_OUT_DONE tag, we can detect this cycle (or any cycle, of arbitrary length) and transmit the packet without further IPsec processing.
• IPSEC_IN_CRYPTO_DONE is issued by device drivers to indicate that an incoming IPsec packet has been successfully processed by a network card that has integrated support for IPsec, indicating the SA(s) processed. Incoming packets undergo regular IPsec processing; just prior to decryption/verification, the kernel checks for the presence of this tag for the specific SA. If this is present, decryption is skipped and processing continues as if it were successful. This allowed us to integrate IPsec-offloading support with less than 10 lines of kernel code.
• IPSEC_OUT_CRYPTO_NEEDED is used for the outgoing case of using a network card with integrated cryptographic processing. If the kernel is aware that the outgoing network interface offers such capabilities it simply attaches this tag to the packet, again indicating which SA it should be processed under. The device driver is then responsible for loading the SA parameters to the network card (if necessary), and for indicating to the hardware that IPsec processing under that SA is needed.
• IPSEC_IN_COULD_DO_CRYPTO is issued by device drivers that detect incoming IPsec packets for which they do not have the SA. The IPsec stack can use this tag as a signal that cryptographic processing can be off-loaded to the network interface. Although the device driver could silently load the relevant SA for end-systems, the situation is more complicated for gateways and firewalls that allow IPsec traffic to traverse them: in that case, the driver may not know which SAs are ``local'' and which refer to hosts behind the firewall. Since such knowledge is implicitly available to the network stack (different code will be executed), we made that code responsible for SA loading.

  Furthermore, the IPsec stack is (or can be) more aware about usage patterns across multiple SAs and can make better-informed decisions as to how best to use the limited resources available in the network card (such cards can typically support a limited number of SAs in their internal RAM).

• IPSEC_PENDING_TDB is used by the network stack to indicate that IPsec processing should occur to the packet before it is transmitted to the network. One tag for each SA that needs to be applied to the packet is attached, in the order in which they must be applied. This tag is necessary because of the requirement for SA-bundle processing (i.e., policy may require that a packet be processed by a series, or ``bundle'', or SAs -- not just one SA) and the fact that in OpenBSD cryptographic processing uses continuations [8].