Protection Mechanisms

IPsec provides two mechanisms for protecting data. The Authentication Header (AH) provides strong integrity, replay protection, and data authentication. AH protects as much of the IP datagram as it can. AH cannot protect fields that change nondeterministically between sender and receiver.

The Encapsulating Security Payload (ESP) provides confidentiality over what it encapsulates, as well as the services that AH provides, but only over that which it encapsulates. ESP's authentication services are optional, which allow ESP and AH to be used together on the same datagram without redundancy.

Authentication and encryption algorithms are used for IPsec. Authentication algorithms produce an integrity checksum value or "digest"based on the data and a key. Encryption algorithms operate on data in units of a "block size".

NAT Traversal

IPsec's ESP can also encapsulate itself in UDP if IKE (see in.iked(8)) discovers a Network Address Translator (NAT) between two communicating endpoints.

A UDP socket can be specified as a NAT-Traversal endpoint. See udp(4P) for details.

Security Associations

AH and ESP use Security Associations (SA). SA's are entities that specify security properties from one host to another. Two communicating machines require two SAs (at a minimum) to communicate securely. However, communicating machines that use multicast can share the same multicast SA. SAs are managed through the pf_key(4P) interface. For IPv4, automatic SA management is available through the Internet Key Exchange (IKE), as implemented by in.iked(8). A command-line front-end is available by means of ipseckey(8). An IPsec SA is identified by a tuple of <AH or ESP, destination IP address, and SPI>. The Security Parameters Index (SPI) is an arbitrary 32-bit value that is transmitted on the wire with an AH or ESP packet. See ipsecah(4P) or ipsecesp(4P) for an explanation about where the SPI falls in a protected packet.

Protection Policy and Enforcement Mechanisms

Mechanism and policy are separate. The policy for applying IPsec is enforced on a system-wide or per-socket level. Configuring system-wide policy and per-tunnel policy (see Transport Mode and Tunnel Mode sections) is done via the ipsecconf(8) command. Configuring per-socket policy is discussed later in this section.

System-wide IPsec policy is applied to incoming and outgoing datagrams. Some additional rules can be applied to outgoing datagrams because of the additional data known by the system. Inbound datagrams can be accepted or dropped. The decision to drop or accept an inbound datagram is based on several criteria which sometimes overlap or conflict. Conflict resolution is resolved by which rule is parsed first, with one exception: if a policy entry states that traffic should bypass all other policy, it is automatically be accepted. Outbound datagrams are sent with or without protection. Protection may (or may not) indicate specific algorithms. If policy normally would protect a datagram, it can be bypassed either by an exception in system-wide policy or by requesting a bypass in per-socket policy.

Intra-machine traffic policies are enforced, but actual security mechanisms are not applied. Instead, the outbound policy on an intra-machine packet translates into an inbound packet with those mechanisms applied.

IPsec policy is enforced in the ip(4P) driver. Several ndd tunables for /dev/ip affect policy enforcement, including:

icmp_accept_clear_messages

igmp_accept_clear_messages

pim_accept_clear_messages

ipsec_policy_log_interval

Transport Mode and Tunnel Mode

If IPsec is used on a tunnel, Tunnel Mode IPsec can be used to protect distinct flows within a tunnel or to cause packets that do not match per-tunnel policy to drop. System-wide policy is always Transport Mode. A tunnel can use Transport Mode IPsec or Tunnel Mode IPsec.

Per-Socket Policy

The IP_SEC_OPT or IPV6_SEC_OPT socket option is used to set per-socket IPsec policy. The structure used for an IP_SEC_OPT request is:

typedef struct ipsec_req {


    uint_t      ipsr_ah_req;           /* AH request */


    uint_t      ipsr_esp_req;          /* ESP request */


    uint_t      ipsr_self_encap_req;   /* Self-Encap request */


    uint8_t     ipsr_auth_alg;         /* Auth algs for AH */


    uint8_t     ipsr_esp_alg;          /* Encr algs for ESP */


    uint8_t     ipsr_esp_auth_alg;     /* Auth algs for ESP */
} ipsec_req_t;

The IPsec request has fields for both AH and ESP. Algorithms may or may not be specified. The actual request for AH or ESP services can take one of the following values:

IPSEC_PREF_NEVER

IPSEC_PREF_REQUIRED

The following value can be logically ORed to an IPSEC_PREF_REQUIRED value:

IPSEC_PREF_UNIQUE

In the event IP options not normally encapsulated by ESP need to be, the ipsec_self_encap_req is used to add an additional IP header outside the original one. Algorithm values from <net/pfkeyv2.h> are as follows:

SADB_AALG_MD5HMAC

SADB_AALG_SHA1HMAC

SADB_EALG_DESCBC

SADB_EALG_3DESCBC

SADB_EALG_BLOWFISH

SADB_EALG_AES

SADB_AALG_SHA256HMAC
SADB_AALG_SHA384HMAC
SADB_AALG_SHA512HMAC

An application should use either the getsockopt(3SOCKET) or the setsockopt(3SOCKET) call to manipulate IPsec requests. For example:

#include <sys/socket.h>
#include <netinet/in.h>
#include <net/pfkeyv2.h>   /* For SADB_*ALG_* */
/* .... socket setup skipped */
rc = setsockopt(s, IPPROTO_IP, IP_SEC_OPT,


   (const char *)&ipsec_req, sizeof (ipsec_req_t));