An IPsec security association (SA) specifies security properties that are recognized by communicating hosts. These hosts typically require two SAs to communicate securely. A single SA protects data in one direction. The protection is either to a single host or a group (multicast) address. Because most communication is peer-to-peer or client-to-server, two SAs must be present to secure traffic in both directions.
The security protocol (AH or ESP), destination IP address, and security parameter index (SPI) identify an IPsec SA. The SPI, an arbitrary 32-bit value, is transmitted with an AH or ESP packet. The ipsecah(7P) and ipsecesp(7P) man pages explain the extent of protection that is provided by AH and ESP. An integrity checksum value is used to authenticate a packet. If the authentication fails, the packet is dropped.
Security associations are stored in a security associations database. A socket-based administration engine, the pf_key interface, enables privileged applications to manage the database. The in.iked daemon provides automatic key management. See the pf_key(7P) and in.iked(1M) man pages.
A security association contains the following information:
Material for keys for encryption and authentication
The algorithms that can be used
The identities of the endpoints
Other parameters that are used by the system
SAs require keying material for authentication and encryption. The managing of keying material that SAs require is called key management. The Internet Key Exchange (IKE) protocol handles key management automatically. You can also manage keys manually with the ipseckey command. SAs on IPv4 and IPv6 packets can use automatic key management.
See IKE Overview, for how IKE manages cryptographic keys automatically. See Keying Utilities, for how you can manually manage the cryptographic keys by using the ipseckey command. The ipseckey(1M) man page provides a detailed description of the command options.