Virtual private network (VPN) technology has changed immensely since the publication of the original Guide to IPsec VPNs (SP 800-77) in 2005. The guide was recently reworked and modernized, and Red Hat engineers lent a hand to updating this important document. The updated document takes into consideration the evolution of cryptography, software and hardware capabilities, as well as virtualization and containerization in today’s complex and cloud-based network infrastructure, and presents solid guidance for a modern environment.
Red Hatters are a longtime contributors and developers of IPsec standards and open source IPsec software. Through this collaboration with the National Institute of Standards and Technology (NIST), we go beyond delivering products that are open, interoperable, and compliant to modern security standards, but also help to improve the security of the internet for everyone.
This work is published as NIST Special Publication SP 800-77 R1: Guide to IPsec.
Special Publications Series 800 publications
The NIST Special Publication (SP) 800 series is a set of documents that describe the guidelines, recommendations, and technical specifications for use in the U.S. government with respect to internet security. Whereas the Federal Information Processing Standards (FIPS) standards tell you what cryptography to use, the SP 800 series tells you how to use security technologies.
15 years of “Guide to IPsec”
In the late 90s, VPN technologies were standardized at the Internet Engineering Task Force (IETF) and made their way into the FIPS publications. In 2005, NIST released SP 800-77 Guide to IPsec to advise the government and its contractors on how best to deploy IPsec VPNs.
This is the same year that Red Hat released Red Hat Enterprise Linux (RHEL) 4. The world has changed a lot since then. CPU power and network bandwidth have increased dramatically, encryption is built into CPUs (such as the Intel AES-NI instruction set), and network cards offload the encryption from the main CPU. Encryption algorithms have also changed. The virtualization of computers and services has changed how networks are designed and deployed.
Traditionally, administrators were concerned about which other computers were co-located in the same facility. Now, with the increased use of cloud technologies, they have to be concerned with datacenters literally outside their control and other tenants that are using the same CPU and network cards.
Compute nodes and entire networks are now ephemeral and are spun up and down, or are moved, based on user demand and operating cost, but also the reliance on one’s physical infrastructure as a high barrier for eavesdropping is gone. Cloud computing further abstracts computing resources literally out of the hands of administrators and into datacenters out of their control and with co-tenants that could be adversarial. This increased the need to encrypt all data in motion.
Using IPsec, network traffic can be protected by encryption. IPsec VPNs are also able to “extend” IP networks from one datacenter to another datacenter without requiring any IP address renumbering. As networks need to span the physical, virtual, public, and private clouds, IPsec helps to securely connect these environments into the hybrid or multi-cloud strategy.
The updated “Guide to IPsec VPNs”
The update guide’s intended audience is network administrators and architects. Those who are fairly familiar with the IPsec (and IKE) protocol can find a quick overview of the changed FIPS requirements and operational recommendations in the Executive Summary. The guide can also be used as extensive documentation of the IKE and IPsec subsystem when RHEL is placed into FIPS mode via the system-wide crypto policies setting.
An in-depth tutorial describes the IPsec packet format (eg ESP), the Internet Key Exchange version 2 (IKEv2) protocol that is used to configure IPsec and explains in detail how the two protocols interact to create VPN solutions.
Hands-on examples with typical IPsec deployments are shown via case studies. The examples show different IPsec implementations and their configurations, such as Cisco, Linux using libreswan (RHEL’s IPsec application), OpenBSD using iked, and FreeBSD using strongSwan. These examples can be used to help the conversation when connecting RHEL to third party VPN implementations.
Red Hat Enterprise Linux, of course, already implements the IPsec recommendations and requirements from the NIST publication. Strict compliance with this guide can be enforced by placing the System Wide Crypto policies in FIPS mode.
Outside of FIPS mode, RHEL still attempts to follow recommendations of the document, but allows for flexibility in configuring VPN connections. For example, it supports the non-FIPS approved algorithm ChaCha20-Poly1305, and can also be configured to allow legacy cryptographic algorithms such as 3DES and SHA-1 on specific VPN connections so that it can still interoperate with legacy equipment. When RHEL needs to connect to third party VPN servers which lack the latest recommended crypto policies, the guide can be used to determine the next best crypto policies.
NIST and Red Hat prefer IPsec VPNs over other VPN technologies. The guide discusses the differences between IPsec and other VPN technologies, such as SSL-based VPNs like OpenVPN, or WireGuard. This can be used as reference to convey to other VPN administrators why IPsec VPNs are the preferred technology.
We are excited about the results of our work with NIST. We believe the “Guide to IPsec VPNs” is a very useful document that can help everyone, including our customers, to encrypt more of their data in motion.
