ip(7)ip(7)NAMEipsec - Internet Protocol Security Architecture
DESCRIPTION
Internet Protocol Security (IPsec) is a security framework that is
designed to provide interoperable, high quality, cryptographically-
based security for Internet Protocol Version 4 (IPv4) and Internet Pro‐
tocol Version 6 (IPv6). The set of security services offered includes
the following: Only networks, systems, and applications you want are
authorized to access your host, the data stored in it, the network
behind a security gateway, or the bandwidth on that network. Any modi‐
fication of an individual IP packet is automatically detected, regard‐
less of the ordering of the IP packet in a stream of traffic. Messages
from a given source are verified to come from that source. Duplicate
datagrams that arrive within a given window are detected. Application-
level data is protected from unauthorized disclosure through encryp‐
tion. Data is protected from unauthorized disclosure by encrypting the
source and destination addresses, message length, and frequency of com‐
munication.
These services are provided at the Internet Protocol (IP) layer, offer‐
ing protection for both IP and upper layer protocols or applications.
For information on configuring IPsec, see the Network Administration:
Connections manual.
Secure Connections
The behavior of IPsec is determined by the secure connections defined
on the system. Each secure connection describes a bi-directional con‐
nection between two hosts or subnets. You define a secure connection
by providing a name and a rule for the connection. Each rule contains
the following: Identifies which IP packets match the rule. The selec‐
tor specifies values for the local IP address, remote IP address, upper
layer protocol, and upper layer ports of the matching packets, either
all or a specific value. You can also use subnets or ranges of IP
addresses for the local and remote values. Describes how IP packets
matching the selector are to be processed. The action may be to discard
(drop) the packet, to bypass IPsec processing (allow the packet in or
out with no security processing), or to apply IPsec processing. A
packet that does not match any policy rules is discarded. Lists the
set of IPsec protocols to be applied, the authentication and encryption
algorithms to be used, and associated parameters (the keys). With man‐
ual keying, only one proposal (one set of protocols) is allowed. You
use proposals for rules that apply IPsec processing only.
You use the SysMan IPsec utility to define secure connections that com‐
pose the overall IPsec configuration. The IPsec daemon (ipsecd) reads
the configuration information when it starts and places the rules into
the kernel.
For each incoming and outgoing packet, the kernel scans the Security
Policy Data base (SPD) sequentially to find a rule that matches. Thus,
connection rules are usually ordered from most specific to least spe‐
cific.
You can also use the SysMan IPsec utility to enable or disable IPsec
processing.
On a system in which no secure connections are defined, each transmit‐
ted packet is unprotected. Once transmitted, the IP header and payload
could be intercepted, changed, and sent to the destination; the desti‐
nation would not know that the data had been altered.
Security Protocols
When a secure connection is defined, it can be protected by the follow‐
ing traffic security protocols: Authentication Header (AH)
Provides data origin authentication, connectionless integrity,
and anti-replay protection services to a datagram. This enables
a receiver to verify both the identity of the sender and that
the data has not been altered. Encapsulating Security Payload
(ESP)
Provides all the protections of the AH protocol when you use
authentication, but also provides confidentiality through the
use of encryption.
The AH protocol can operate in either transport mode or tunnel mode.
In transport mode, the original packet's IP header is the IP header for
the resulting packet (AH header and payload). This is typically used
in in host-to-host communications. In tunnel mode, the packet is
appended to a new IP header (tunnel header) and AH header. This is
typically used in secure gateways and VPN configurations.
The ESP protocol can also operate in either transport mode or tunnel
mode.
In transport mode, the packet's IP header is the IP header for the
resulting encrypted packet (payload and ESP trailer). This is typi‐
cally used in in host-to-host communications. In tunnel mode, the
encrypted packet (original IP header, payload, and ESP trailer) is
appended to a new IP header (tunnel header). This is typically used in
secure gateways and VPN configurations.
The AH and ESP protocols support two Hashed Message Authentication
Codes (HMACs): Message Digest 5 (MD5-96) and Secure Hash Algorithm 1
(SHA1-96) authentication algorithms. The ESP protocol supports both
Data Encryption Standard (DES) and triple-DES (3DES) encryption algo‐
rithms.
Together with the use of cryptographic key management procedures and
protocols, you can employ these protocols in any context and manner.
How you employ them depends on the security and system requirements of
users, applications, and your particular organization or site.
Security Associations
When you define a secure connection, you provide information that is
used to create and establish an entity called a Security Association
(SA). An SA is an instantiation of the security policy, and contains
the following information: Security Parameter Index (SPI) Authentica‐
tion algorithm (AH or ESP) Encryption algorithm (ESP only) Encryption
and authentication keys Encryption context SA lifetime Exact selectors
that are being matched
This information is used to match and process packets that are to be
protected. A single secure connection that specifies one IPsec proto‐
col creates both an inbound and outbound SA.
The SPI, authentication algorithm, and destination IP address together
identify the SA. If the secure connection specifies both AH and ESP
protocols, an inbound and outbound SA is created for each protocol.
You can use the netstat command to display the SAs.
IPsec Daemon
The ipsecd daemon controls the operation of the IP security protocols
in the system. It combines the function of an IPsec policy manager and
Internet Key Exchange (IKE) daemon.
When started, ipsecd reads and parses the specified Security Policy
Database (SPD) file. The daemon transfers the information needed for
enforcing the policy into the IPsec kernel packet processing engine.
The daemon manages all requests to create security associations (SAs)
needed to communicate securely with other IPsec systems. It receives
Internet Key Exchange (IKE) requests from other systems, validates that
they match local policy, and generates the cryptographic keys needed
for the the SAs. The daemon initiates IKE exchanges with other systems
in response to requests from the kernel packet processing engine. The
kernel and the daemon communicate through the /dev/ipsec_engine pseudo-
device. By default, the daemon listens on UDP port 500 for IKE traffic
with other systems.
When IPsec is enabled on the system, the default action is to drop all
IP packets into and out of the system. The ipsecd daemon must be run‐
ning to instantiate a policy that allows packets to flow. If the dae‐
mon is not started or is killed, all network traffic will be blocked.
The daemon is started automatically at system boot time if IPsec is
enabled.
See ipsecd(8) for more information.
SEE ALSO
Commands: ipsec_certmake(8), ipsec_certview(8), ipsec_convert(8),
ipsec_keypaircheck(8), ipsec_keytool(8), ipsec_mgr(8), ipsecd(8)
Network Administration: Connections
Security Architecture for the Internet Protocol, RFC 2401 (November
1998)
IP Authentication Header, RFC 2402 (November 1998)
The Use of HMAC-MD5-96 within ESP and AH, RFC 2403 (November 1998)
The Use of HMAC-SHA-1-96 within ESP and AH, RFC 2404 (November 1998)
The ESP DES-CBC Cipher Algorithm With Explicit IV, RFC 2405 (November
1998)
IP Encapsulating Security Payload (ESP), RFC 2406 (November 1998)
The Internet IP Security Domain of Interpretation for ISAKMP, RFC 2407
(November 1998)
Internet Security Association and Key Management Protocol (ISAKMP), RFC
2408 (November 1998)
The Internet Key Exchange (IKE), RFC 2409 (November 1998)
The NULL Encryption Algorithm and Its Use With IPsec, RFC 2401RFC 2410
(November 1998)
IP Security Document Roadmap, RFC 2411 (November 1998)
The OAKLEY Key Determination Protocol, RFC 2412 (November 1998)
ip(7)