An IPsec security association SA defines the security properties that will be applied to an IP packet that matches the IP parameters that are also stored in the SA. Each SA is unidirectional. Because most communications are bidirectional, two SAs are required for a single connection.
Together, the following three elements uniquely identify an IPsec SA:
The security protocol (AH or ESP)
The destination IP address
The security parameter index (SPI)
The SPI of the SA provides additional protection and is transmitted in the AH or ESP header of an IPsec-protected 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 (SADB). A socket-based administrative interface, PF_KEY enables privileged applications to manage the database programmatically. For example, the IKE daemon and the ipseckey command use the PF_KEY socket interface.
For a more complete description of the IPsec SADB, see Security Associations Database for IPsec.
For more information about how to manage the SADB, see the pf_key(7P) and ipseckey(1M) man pages.
Security associations (SAs) require keying material for authentication and for encryption. The managing of this keying material is called key management. Oracle Solaris provides two methods for managing the keys for IPsec SAs: IKE and manual key management.
The Internet Key Exchange (IKE) protocol handles key management automatically. This Oracle Solaris release supports IKE version 2 (IKEv2) and IKE version 1 (IKEv1) of the IKE protocol.
The use of IKE to manage IPsec SAs is encouraged. These key management protocols offer the following advantages:
Simple configuration
Provide strong peer authentication
Automatically generate SAs with a high quality random key source
Do not require administrative intervention to generate new SAs
For more information, see How IKE Works.
To configure IKE, see Configuring IKEv2. If you are communicating with a system that does not support the IKEv2 protocol, follow the instructions in Configuring IKEv1.
The use of manual keys is more complicated than IKE and is potentially risky. A system file, /etc/inet/secret/ipseckeys, contains the encryption keys. If these keys are compromised, they can be used to decrypt recorded network traffic. Because IKE frequently changes the keys, the window of exposure to such a compromise is much smaller. Using the ipseckeys file or its command interface, ipseckey, is appropriate only for systems that do not support IKE.
While the ipseckey command has only a limited number of general options, the command supports a rich command language. You can specify that requests be delivered by means of a programmatic interface specific for manual keying. For additional information, see the ipseckey(1M) and pf_key(7P) man pages.
Typically, manual SA generation is used when IKE is unavailable for some reason. However, if the SPI values are unique, manual SA generation and IKE can be used at the same time.