NAME | DESCRIPTION | SECURITY CONSIDERATIONS | ATTRIBUTES | SEE ALSO
The IP Security Architecture (IPsec) provides protection for IP datagrams. The protection can include confidentiality, strong integrity of the data, partial sequence integrity (replay protection), and data authentication. IPsec is performed inside the IP processing, and it can be applied with or without the knowledge of an Internet application.
IPsec provides two mechanisms for protecting data. The Authentication Header ("AH") provides strong integrity, replay protection, and data authentication. AH protects as much of the IP datagram as it can. AH cannot protect fields that change nondeterministically between sender and receiver.
The Encapsulating Security Payload ("ESP") provides confidentiality over what it encapsulates, as well as the services that AH provides, but only over that which it encapsulates. ESP's authentication services are optional, which allow ESP and AH to be used together on the same datagram without redundancy.
Two types of algorithms are used for IPsec, authentication and encryption algorithms.. Authentication algorithms produce an integrity checksum value or "digest" based on the data and a key. The size of both the digest and the key are described in authentication algorithm pages. See, for example, authmd5h(7M) and authsha1(7M). Encryption algorithms encrypt data with a key. Encryption algorithms operate on data in units of a "block size". The size of both the block size and the key size are described in the encryption algorithm pages. See, for example, encrdes(7M) and encr3des(7M).
Both AH and ESP use Security Associations (SAs), which are entities that specify security properties from one host to another. Two communicating machines need at least two SAs to communicate securely, unless they are using multicast, and then they can use the same multicast SA. SAs are managed through the pf_key(7P) interface. Automatic SA management is not yet available, but a command-line front-end is available by means of ipseckey(1M). An IPsec SA is identified by a tuple of <AH or ESP, destination IP address, and SPI>. The Security Parameters Index ("SPI") is an arbitrary 32-bit value that is transmitted on the wire with an AH or ESP packet. See ipsecah(7P) or ipsecesp(7P) for an explanation about where the SPI falls in a protected packet.
Mechanism and policy are separate. The policy for applying IPsec can be enforced in two places: on a system-wide level, or on a per-socket level.Configuring systemwide policy is done by the command ipsecconf(1M). Configuring per-socket policy will be discussed later in this section.
Systemwide IPsec policy is applied to incoming and outgoing datagrams. Some additional rules can be applied to outgoing datagrams because of the additional data known by the system. Inbound datagrams can either be accepted or dropped. The decision to drop or accept an inbound datagram is based on several criteria, which sometimes overlap or conflict. Conflict resolution is resolved by which rule is parsed first, with one exception. If a policy entry states that traffic should bypass all other policy, it will automaticaly be accepted. Outbound datagrams will either be sent with protection or without. If protection is applied, it can be either specific algorithms, or not. If policy normally would protect a datagram, it can be bypassed in either by an exception in systemwide policy, or by requesting a bypass in per-socket policy.
For intra-machine traffic, policies will be enforced, but actual security mechanisms will not be applied; rather, the outbound policy on an intra-machine packet will translate into an inbound packet that has had those mechanisms applied.
typedef struct ipsec_req { uint_t ipsr_ah_req; /* AH request */ uint_t ipsr_esp_req; /* ESP request */ uint_t ipsr_self_encap_req; /* Self-Encap request */ uint8_t ipsr_auth_alg; /* Auth algs for AH */ uint8_t ipsr_esp_alg; /* Encr algs for ESP */ uint8_t ipsr_esp_auth_alg; /* Auth algs for ESP */ } ipsec_req_t;
Bypass all policy. Only the superuser may request this service.
Regardless of other policy, require the use of the IPsec service.
Regardless of other policy, enforce a unique SA for traffic originating from this socket.
The ipsec_self_encap_req is used to add an additional IP header outside the original one. This is in case IP options not normally encapsulated by ESP need to be. Algorithm values from <net/pfkeyv2.h> are as follows:
This uses the MD5-HMAC (RFC 2403) algorithm for authentication. See authmd5h(7M).
This uses the SHA1-HMAC (RFC 2404) algorithm for authentication. See authsha1(7M).
This uses the DES (RFC 2405) algorithm for encryption. See encrdes(7M).
This uses the Triple DES (RFC 2451) algorithm for encryption. See encr3des(7M).
#include <sys/socket.h> #include <netinet/in.h> #include <net/pfkeyv2.h> /* For SADB_*ALG_* */ /* .... socket setup skipped */ rc = setsockopt(s, IPPROTO_IP, IP_SEC_OPT, (const char *)&ipsec_req, sizeof (ipsec_req_t));
While IPsec is an effective tool in securing network traffic, it will not make security problems disappear. Security issues beyond the mechanisms that IPsec offers may be discussed in a similar "Security Consideration" section within individual reference manual pages.
See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPE | ATTRIBUTE VALUE |
---|---|
Interface Stability | Evolving |
ipsecconf(1M),ipseckey(1M),getsockopt(3SOCKET),setsockopt(3SOCKET),attributes(5),authmd5h(7M),authsha1(7M),encrdes(7M), encr3des(7M),inet(7P)ip(7P),ipsec(7P),ipsecah(7P),ipsecesp(7P),pf_key(7P)
Kent, S., and Atkinson, R., RFC 2401, Security Architecture for the Internet Protocol, The Internet Society, 1998.
Kent, S. and Atkinson, R.,RFC 2406, IP Encapsulating Security Payload (ESP), The Internet Society, 1998.
Madson, C., and Doraswamy, N, RFC 2405, The ESP DES-CBC Cipher Algorithm with Explicit IV, The Internet Society, 1998.
Madsen, C. and Glenn, R., RFC 2403, The Use of HMAC-MD5-96 within ESP and AH, The Internet Society, 1998.
Madsen, C. and Glenn, R., RFC 2404, The Use of HMAC-SHA-1-96 within ESP and AH, The Internet Society, 1998.
Pereira, R. and Adams, R., RFC 2451, The ESP CBC-Mode Cipher Algorithms, The Internet Society, 1998.
NAME | DESCRIPTION | SECURITY CONSIDERATIONS | ATTRIBUTES | SEE ALSO