Introduction

  The IP Security architecture [14], as specified by the IETF (Internet Engineering Task Force), is comprised of a set of protocols that provide data integrity, confidentiality, replay protection, and authentication at the network layer. This positioning in the network stack offers considerable flexibility in transparently employing IPsec in different roles (e.g., in building Virtual Private Networks, end-to-end security, remote access, etc.). Such flexibility is not possible in higher or lower levels of abstraction.

The overall IPsec architecture is very similar to previous work [12] and is composed of three modules:

• The data encryption/authentication protocols [1,2]. These are the ``wire protocols,'' used for encapsulating IP packets to be protected. Outgoing packets are authenticated, encrypted, and encapsulated just before being sent to the network, and incoming packets are decapsulated, verified, and decrypted immediately upon receipt. These protocols are typically implemented inside the kernel, for performance and security reasons. A brief overview of the OpenBSD kernel IPsec architecture is given in Section 2.
• The key exchange protocol (IKE) [11] is used to dynamically establish and maintain Security Associations (SAs). An SA is the set of parameters necessary for one-way secure communication between two hosts (e.g., cryptographic keys, algorithm choice, ordering of transforms, etc.). Although the wire protocols can be used on their own using manual key management, wide deployment and use of IPsec in the Internet requires automated, on-demand SA establishment.

  Due to the large number and variety of configurations and options an IKE implementation must support, this part of the IPsec architecture tends to dominate the other two in terms of code size and complexity. The first part of this paper discusses the OpenBSD implementation of IKE.

• The policy module governs the handling of packets on their way into or out of an IPsec-compliant host. Even though the security protocols protect the data from tampering, they do not address the issue of which host is allowed to exchange what kind of traffic with what other host. While traditional packet filtering mechanisms, such as employed in modern firewalls, can be used (with minor modifications) in enforcing traffic policies, a higher-level mechanism for validating and configuring such filters is needed. The second part of this paper discusses the implementation of a security policy mechanism based on trust management [6] in the OpenBSD IPsec.