 |
Index for
Section 7 |
|
 |
Alphabetical
listing for I |
|
 |
Bottom of
page |
|
ip(7)
NAME
ipsec - 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 Protocol Version 6
(IPv6). The set of security services offered includes the following:
Access control
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.
Connectionless integrity
Any modification of an individual IP packet is automatically detected,
regardless of the ordering of the IP packet in a stream of traffic.
Data origin authentication
Messages from a given source are verified to come from that source.
Protection against replays (a form of partial sequence integrity)
Duplicate datagrams that arrive within a given window are detected.
Confidentiality
Application-level data is protected from unauthorized disclosure
through encryption.
Limited traffic flow confidentiality
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
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:
Selector
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.
Action
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.
Proposal
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
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
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
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.
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)
|
Index for
Section 7 |
|
|
Alphabetical
listing for I |
|
 |
Top of
page |
|