|IPSEC(4)||Device Drivers Manual||IPSEC(4)|
Both protocols may be enabled or disabled using the following sysctl(3) variables in /etc/sysctl.conf. By default, both protocols are enabled:
There are four main security properties provided by IPsec:
ESP can provide the properties authentication, integrity, replay protection, and confidentiality of the data (it secures everything in the packet that follows the IP header). Replay protection requires authentication and integrity (these two always go together). Confidentiality (encryption) can be used with or without authentication/integrity. Similarly, one could use authentication/integrity with or without confidentiality.
AH provides authentication, integrity, and replay protection (but not confidentiality). The main difference between the authentication features of AH and ESP is that AH also authenticates portions of the IP header of the packet (such as the source/destination addresses). ESP authenticates only the packet payload.
[IP header] [TCP header] [data...]
If we apply ESP in transport mode to the above packet, we will get:
[IP header] [ESP header] [TCP header] [data...]
Everything after the ESP header is protected by whatever services of ESP we are using (authentication/integrity, replay protection, confidentiality). This means the IP header itself is not protected.
If we apply ESP in tunnel mode to the original packet, we would get:
[IP header] [ESP header] [IP header] [TCP header] [data...]
Again, everything after the ESP header is cryptographically protected. Notice the insertion of an IP header between the ESP and TCP header. This mode of operation allows us to hide who the true source and destination addresses of a packet are (since the protected and the unprotected IP headers don't have to be exactly the same). A typical application of this is in Virtual Private Networks (or VPNs), where two firewalls use IPsec to secure the traffic of all the hosts behind them. For example:
Net A <----> Firewall 1 <--- Internet ---> Firewall 2 <----> Net B
Firewall 1 and Firewall 2 can protect all communications between Net A and Net B by using IPsec in tunnel mode, as illustrated above.
This implementation makes use of a virtual interface,
enc0, which can be used in packet filters to specify
those packets that have been or will be processed by IPsec.
NAT can also be applied to
interfaces, but special care should be taken because of the interactions
between NAT and the IPsec flow matching, especially on the packet output
path. Inside the TCP/IP stack, packets go through the following stages:
UL/R -> [X] -> PF/NAT(enc0) -> IPsec -> PF/NAT(IF) -> IF UL/R <-------- PF/NAT(enc0) <- IPsec <- PF/NAT(IF) <- IF
With IF being the real interface and UL/R the Upper Layer or Routing code. The [X] stage on the output path represents the point where the packet is matched against the IPsec flow database (SPD) to determine if and how the packet has to be IPsec-processed. If, at this point, it is determined that the packet should be IPsec-processed, it is processed by the PF/NAT code. Unless PF drops the packet, it will then be IPsec-processed, even if the packet has been modified by NAT.
ipsec. These are generally net.inet.ah.*, net.inet.esp.*, net.inet.ip.forwarding, net.inet6.ip6.forwarding, and net.inet.ip.ipsec-*. Full explanations can be found in sysctl(3), and variables can be set using the sysctl(8) interface.
A number of kernel options are also relevant to
options(4) for further
ipsec. A socket can specify security levels for three different categories:
For each of the categories there are five possible levels which specify the security policy to use in that category:
When a new socket is created, it is assigned the default system security level in each category. These levels can be queried with getsockopt(2). Only a privileged process can lower the security level with a setsockopt(2) call.
For example, a server process might want to accept only authenticated connections to prevent session hijacking. It would issue the following setsockopt(2) call:
int level = IPSEC_LEVEL_REQUIRE; error = setsockopt(s, IPPROTO_IP, IP_AUTH_LEVEL, &level, sizeof(int));
The system does guarantee that it will succeed at establishing the required security associations. In any case a properly configured key management daemon is required which listens to messages from the kernel.
A list of all security associations in the kernel tables can be obtained using the ipsecctl(8) command.
information about memory use by IPsec with the
flag (look for “tdb” and “xform”
The IPsec protocol design process was started in 1992 by John Ioannidis, Phil Karn, and William Allen Simpson. In 1995, the former wrote an implementation for BSD/OS. Angelos D. Keromytis ported it to OpenBSD and NetBSD. The latest transforms and new features were implemented by Angelos D. Keromytis and Niels Provos.
Niklas Hallqvist and Niels Provos are the authors of isakmpd(8).
Eric Young's libdeslite was used in this implementation for the DES algorithm.
Steve Reid's SHA-1 code was also used.
|March 18, 2016||OpenBSD-6.1|