|IPSEC(4)||Device Drivers Manual||IPSEC(4)|
ipsec — IP
ipsec is a security protocol in Internet
ipsec is defined for both IPv4 and
IPv6 (inet(4) and
consists of two sub-protocols, namely ESP (encapsulated security payload)
and AH (authentication header). ESP protects IP payload from wire-tapping by
encrypting it by secret key cryptography algorithms. AH guarantees integrity
of IP packet and protects it from intermediate alteration or impersonation,
by attaching cryptographic checksum computed by one-way hash functions.
ipsec has two operation modes: transport mode and
tunnel mode. Transport mode is for protecting peer-to-peer communication
between end nodes. Tunnel mode includes IP-in-IP encapsulation operation and
is designed for security gateways, like VPN configurations.
ipsec is controlled by key management
engine and policy engine, in the operating system kernel.
Key management engine can be accessed from the userland by using
PF_KEY sockets. The
socket API is defined in RFC2367.
Policy engine can be controlled by extended part of
setsockopt(2) operations, and
sysctl(3) interface. The kernel
implements extended version of
PF_KEY interface, and
allows you to define IPsec policy like per-packet filters.
setsockopt(2) interface is used to
define per-socket behavior, and
sysctl(3) interface is used to define
host-wide default behavior.
The kernel code does not implement dynamic encryption key exchange protocol like IKE (Internet Key Exchange). That should be implemented as userland programs (usually as daemons), by using the above described APIs.
The kernel implements experimental policy management code. You can
manage the IPsec policy in two ways. One is to configure per-socket policy
using setsockopt(2). The other is
to configure kernel packet filter-based policy using
PF_KEY interface, via
setkey(8). In both cases, IPsec policy
must be specified with syntax described in
With setsockopt(2), you can define IPsec policy in per-socket basis. You can enforce particular IPsec policy onto packets that go through particular socket.
In the latter case,
default” policy is allowed for use
with setkey(8). By configuring policy
default, you can refer system-wide
sysctl(8) variable for default
settings. The following variables are available.
require” in the syntax.
If kernel finds no matching policy system wide default value is
applied. System wide default is specified by the following
discard” which asks the kernel to
drop the packet.
The following variables are accessible via sysctl(8), for tweaking kernel IPsec behavior:
The variables are interpreted as follows:
draft-ietf-ipsec-ecn-02.txt. gif(4) talks more about the behavior.
net.inet6.ipsec6 tree has
similar meaning as the
ipsec protocol works like plug-in to
inet6(4) protocols. Therefore,
ipsec supports most of the protocols defined upon
those IP-layer protocols. Some of the protocols, like
icmp6(4), may behave differently with
ipsec. This is because
can prevent icmp(4) or
icmp6(4) routines from looking into IP
Daniel L. McDonald, Craig Metz, and Bao G. Phan, PF_KEY Key Management API, Version 2, RFC, 2367.
D. L. McDonald, A Simple IP Security API Extension to BSD Sockets, internet draft, draft-mcdonald-simple-ipsec-api-03.txt, work in progress material.
The implementation described herein appeared in WIDE/KAME IPv6/IPsec stack.
The IPsec support is subject to change as the IPsec protocols develop.
There is no single standard for policy engine API, so the policy engine API described herein is just for KAME implementation.
AH and tunnel mode encapsulation may not work as you might expect.
If you configure inbound “require” policy against AH tunnel or
any IPsec encapsulating policy with AH (like
ah/transport/A-B/require”), tunnelled packets will be
rejected. This is because we enforce policy check on inner packet on
reception, and AH authenticates encapsulating (outer) packet, not the
encapsulated (inner) packet (so for the receiving kernel there's no sign of
authenticity). The issue will be solved when we revamp our policy engine to
keep all the packet decapsulation history.
Under certain condition, truncated result may be raised from the
SADB_SPDDUMP operation on
PF_KEY socket. This occurs if there are too many
database entries in the kernel and socket buffer for the
PF_KEY socket is insufficient. If you manipulate
many IPsec key/policy database entries, increase the size of socket
|January 29, 1999||macOS 14.1|