Neutron includes an advanced service known as Virtual Private Network as a Service, or VPNaaS, which enables users to send and receive data between instances or remote hosts and across secure tunnels. A virtual private network enables users to segment data from other traffic so that only the intended recipient has access. VPNs commonly describe secure connections over a public network, such as the Internet, and can be created by establishing a connection between two endpoints, or peers, through the use of dedicated connections, virtual tunneling protocols, or traffic encryption.
The VPNaaS extension introduces the following network resources that allow users to build IPSec-based virtual private networks:
- IKE policies: These define the parameters used for phase 1 of an IPSec connection
- IPSec policies: These define the parameters used for phase 2 of an IPSec connection
- VPN services: These define the local encryption domain
- IPSec site connections: These define IKE and IPSec policies, a VPN service, the peer address, and the remote encryption domain
In this chapter, I will discuss the basics of IPSec and the workflow to create site-to-site connections, including:
- Enabling VPNaaS in Neutron
- Managing IKE and IPSec policies
- Managing VPN services
- Managing IPSec site connections
- Demonstrating how VPNs are built by Neutron
IPSec is a standard suite of protocols that provides security at layer 3, or the IP layer, and was designed to provide the following security features when transferring packets across a network:
IPSec contains many elements, which will be discussed in the following sections.
Encapsulating Security Payload (ESP) provides authentication, integrity, and confidentiality, which help protect against data tampering and provide message content protection. IPSec implements industry standard algorithms, such as SHA and MD5, to produce a unique identifier for each packet that cannot be forged. These "fingerprints" allow the receiver to determine whether a packet has been tampered with. Packets that are not authenticated are discarded and not delivered.
ESP provides encryption services in IPSec and translates readable messages into unreadable formats to hide message content. When the encrypted packet is received, the data is then decrypted from the unreadable format back to a readable message. The use of encryption and decryption allows only the sender and authorized receiver to read the data.
An ESP header is inserted into each packet between the IP header and the rest of the packet, as demonstrated in the following diagram:
Figure 12.1
Authentication Header (AH) provides authentication and integrity using the same algorithms as ESP. In addition to protecting against data tampering, an AH can provide anti-replay protection, which protects against the unauthorized retransmission of packets. The authentication header is inserted into each packet between the IP header and the rest of the packet. The payload, however, is not encrypted. The AH allows the receiver to verify that the message is intact and unaltered, but the message is potentially vulnerable to snooping.
The following diagram shows the insertion of the authentication header between the IP header and the rest of the packet:
Figure 12.2
AH and ESP can be used separately or in conjunction with one another. Details about when to use one or the other as well as examples of use cases for AH over ESP or vice versa are outside the scope of this book.
A security association, or SA, is a logical connection between two endpoints transferring data and provides data protection for unidirectional traffic using defined IPSec protocols. An IPSec tunnel usually consists of two unidirectional SAs, one for each direction of traffic, which together provide a protected, full duplex channel to transfer data.
A security policy, or SP, defines the traffic to which a security association is applied, resulting in its encryption or another action that an SA may prescribe.
A mode is a method in which the IPSec protocol is applied to a packet. IPSec can be used in tunnel or transport mode.
In tunnel mode, IPSec encapsulates the entire IP packet, including the original headers. Once encapsulated, the original packet becomes the payload of a new packet with its own set of headers. The new IP header contains two IPSec gateway addresses and hides the internal addresses. The following diagram demonstrates a packet in tunnel mode:
Figure 12.3
Tunnel mode is commonly used for site-to-site and remote access VPN tunnels.
In transport mode, IPSec encapsulates only the packet payload; the IP header is not changed or concealed. As a result, an attacker can learn where the packet is coming from and where it is headed. The following diagram demonstrates a packet in transport mode:
Figure 12.4
Transport mode is used for end-to-end tunnels, such as between a client and server, and is often used when another tunneling protocol, such as GRE, is first used to encapsulate a packet; then, IPSec is used to protect the GRE tunnel.
Internet Security Association and Key Management Protocol (ISAKMP) is a protocol to establish security associations and cryptographic keys. The use of keys ensures that only the sender and receiver of a message can access it. ISAKMP only provides a framework for authentication and key exchange and uses the Internet Key Exchange (IKE) protocol and others to facilitate the setup of security associations and the exchange of keys between parties that are sending messages. IPSec requires that keys be recreated or refreshed frequently so that parties can continue to communicate securely with one another and uses IKE to manage the process of refreshing keys.
An IPSec tunnel establishment can be summarized in the following steps: initiation, IKE phase 1, IKE phase 2, data transfer, and termination.
As network traffic is matched for protection according to the IPSec security policy configured on an IPSec peer, an IPSec tunnel is initiated.
In IKE phase 1, the security parameters and keys required to establish an ISAKMP SA are negotiated. The ISAKMP SA is then used to set up a secure channel to negotiating the IKE phase 2 parameters.
In IKE phase 2, the security parameters and keys required to establish unidirectional IPSec SAs for each direction of traffic are negotiated. The IPSec SAs are used to protect network traffic while it is transferred across the network.
When data is transferred through the tunnel, it is encapsulated according to the security algorithms and parameters provided by the security association.
A tunnel is closed when its IPSec SAs are deleted or have timed-out. An IPSec SA may time out as a result of being idle for a specified period of time or once a specified amount of traffic has passed through the tunnel.
Neutron provides users with the ability to define many of the IKE, IPSec, and key management parameters through the use of profiles and connection definitions. These profiles and their use in creating secure site-to-site tunnels will be covered later in the following sections.