ipsec - Internet Protocol Security Architecture
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 Protocol 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 modification of an individual IP packet
is automatically detected, regardless 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 encryption. Data is protected
from unauthorized disclosure by encrypting the source and
destination addresses, message length, and frequency of
communication.
These services are provided at the Internet Protocol (IP)
layer, offering protection for both IP and upper layer
protocols or applications.
For information on configuring IPsec, see the Network
Administration: Connections manual.
Secure Connections [Toc] [Back]
The behavior of IPsec is determined by the secure connections
defined on the system. Each secure connection
describes a bi-directional connection 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 selector 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 manual 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 compose 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 specific.
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 transmitted packet is unprotected. Once transmitted,
the IP header and payload could be intercepted, changed,
and sent to the destination; the destination would not
know that the data had been altered.
Security Protocols [Toc] [Back]
When a secure connection is defined, it can be protected
by the following 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 typically 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 algorithms.
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 [Toc] [Back]
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) Authentication 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 protocol 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 [Toc] [Back]
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 running to instantiate a policy that
allows packets to flow. If the daemon 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.
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)
[ Back ] |
