|Skip Navigation Links|
|Exit Print View|
|Oracle Solaris Administration: IP Services Oracle Solaris 10 1/13 Information Library|
Authentication Header (AH)
Encapsulating Security Payload (ESP)
AH protects data with an authentication algorithm. An ESP protects data with an encryption algorithm. ESP can and should be used with an authentication mechanism. If you are not traversing a NAT, you can combine ESP with AH. Otherwise, you can use an authentication algorithm and an encryption mechanism with ESP.
The authentication header provides data authentication, strong integrity, and replay protection to IP datagrams. AH protects the greater part of the IP datagram. As the following illustration shows, AH is inserted between the IP header and the transport header.
The transport header can be TCP, UDP, SCTP, or ICMP. If a tunnel is being used, the transport header can be another IP header.
The encapsulating security payload (ESP) module provides confidentiality over what the ESP encapsulates. ESP also provides the services that AH provides. However, ESP only provides its protections over the part of the datagram that ESP encapsulates. ESP provides optional authentication services to ensure the integrity of the protected packet. Because ESP uses encryption-enabling technology, a system that provides ESP can be subject to import and export control laws.
In a TCP packet, ESP encapsulates only the TCP header and its data. If the packet is an IP-in-IP datagram, ESP protects the inner IP datagram. Per-socket policy allows self-encapsulation, so ESP can encapsulate IP options when ESP needs to.
If self-encapsulation is set, a copy of the IP header is made to construct an IP-in-IP datagram. For example, when self-encapsulation is not set on a TCP socket, the datagram is sent in the following format:
[ IP(a -> b) options + TCP + data ]
When self-encapsulation is set on that TCP socket, the datagram is sent in the following format:
[ IP(a -> b) + ESP [ IP(a -> b) options + TCP + data ] ]
For further discussion, see Transport and Tunnel Modes in IPsec.
Table 19-2 Protections Provided by AH and ESP in IPsec
IPsec security protocols use two types of algorithms, authentication and encryption. The AH module uses authentication algorithms. The ESP module can use encryption as well as authentication algorithms. You can obtain a list of the algorithms on your system and their properties by using the ipsecalgs command. For more information, see the ipsecalgs(1M) man page. You can also use the functions that are described in the getipsecalgbyname(3NSL) man page to retrieve the properties of algorithms.
IPsec uses the Cryptographic Framework to access the algorithms. The Cryptographic Framework provides a central repository for algorithms, in addition to other services. The framework enables IPsec to take advantage of high performance cryptographic hardware accelerators.
For more information, see the following:
Authentication algorithms produce an integrity checksum value or digest that is based on the data and a key. The AH module uses authentication algorithms. The ESP module can use authentication algorithms as well.
Different releases of Oracle Solaris provide different default encryption algorithms.
Starting in the Solaris 10 7/07 release, the contents of the Solaris Encryption Kit are installed by the Solaris installation media. This release adds the SHA2 authentication algorithms: sha256, sha384, and sha512. The SHA2 implementations conform to the RFC 4868 specification. This release also adds larger Diffie-Hellman groups: 2048-bit (group 14), 3072-bit (group 15), and 4096-bit (group 16). Note that Oracle Sun systems with CoolThreads technology accelerate the 2048-bit groups only.
Caution - Starting in the Solaris 10 7/07 release, do not add the Solaris Encryption Kit to your system. The kit downgrades the patch level for encryption on your system. The kit is incompatible with the encryption on your system.