Introducing VPN Technologies
Date: Dec 6, 2011
One of the single largest growing tools used by businesses today is Virtual Private Networks (VPN). Everyday, thousands of individuals use the internet to connect to remote offices for work related tasks. These connections have to be made in as secure a fashion as humanly possible, and the single largest tool in our arsenal to make this happen is IP Security (IPsec). In fact, it would not be unrealistic to say that IPsec is the most commonly used security implementation found in VPN deployments.
IP Security (IPsec)
IPsec is a suite of protocols that allows us to encrypt and authenticate each IP packet found in a given communications session. IPsec provides the mechanism for mutual authentication to take place as a communications session is built, as well as allow us to negotiate the cryptographic keys that will be used during the life of the session once it is established. The beautiful part about IPsec is that it is an end-to-end security scheme that operates within the Internet Protocol Suite. This means that we can use it to protect data in all three of the primary models used for VPN architectures:
- Network-to-Network—this model protects communications between two specific networks, such as an organization's headquarters network and a branch office network.
- Network-to-Host—this model protects communications between one or more individual hosts and a specific network belonging to an organization. The host-to-gateway model is most often used to allow hosts on unsecured networks, such as traveling employees and telecommuters, to gain access to internal organizational services, such as the organization's e-mail and Intranets.
- Host-to-Host—A host-to-host architecture protects communication between two specific computers. It is most often used when a small number of users need to use or administer a remote system that requires the use of inherently insecure protocols.
IPsec can protect any application traffic crossing an IP network and does not require applications to be built to leverage its capabilities. There are other internet security systems that do require an application to be designed to support them; a few of these include Transport Layer Security (TLS), Secure Sockets Layer (SSL) and Secure Shell (SSH). These tools can only protect application protocols that have been built to be compatible with them, and they work at the upper layers of the TCP/IP OSI Model.
IPsec, however, was created by the Internet Engineering Task Force (IETF) to operate at the Network Layer of the OSI model. This open standard protocol suite combines these three protocols to protect network traffic:
- Authentication Headers (AH)—defines a method for authenticating and securing data
- Encapsulating Security Payloads (ESP)—defines a method for authenticating, securing and encrypting data
- Security Associations (SA)—negotiates any security parameters and authentication keys
Authentication Headers (AH)
Authentication headers are defined in RFC 2402, and they provide data origin authentication as well as offering optional anti-replay protection. The drawback with AH is that the authentication it provides for the IP Header is not complete. That is because some of the IP fields cannot be correctly predicted by the receiver. These fields are known as “mutable fields” and they may and often do change during transmission. AH will, however, successfully protect the IP packet's payload, and the payload is actually what we are interested in protecting.
In a nutshell, Authentication Headers will authenticate data origin; it will protect data integrity, and has the optional capability of playback protection. The one drawback to AH, is that it does not offer data confidentiality.
What is a replay attack? A replay attack is when a valid data transmission is repeated or delayed on a network. The purpose for doing this is to apply an IP substitution during the data retransmission so that a cyber criminal can masquerade as a legitimate user or program by falsifying data.
Encapsulating Security Payloads (ESP)
This is one of those protocols where the name says it all. If we looked at an illustration of an IPsec packet we would see that there is an ESP header and an ESP Trailer surrounding, or encapsulating the payload. This header and trailer allow us to authenticate the data's origin, protect ourselves from possible replay attacks, and it does provide data confidentiality. That seems like it would be the security trifecta. Three out of three is much better than what AH offered us. Or is it?
ESP provides more capabilities than AH, but as with all things in networking, this comes at a cost. ESP is substantially more processor intensive than AH. So if data confidentiality isn't a concern, AH may be a better fit based on network resources. The other issue is that ESP requires some pretty solid cryptography, which might not be allowed or even possible in some environments. So there will be situations where you may have to use Authentication Headers rather than ESP.
ESP and AH Modes of Operation
No matter which protocol you chose—Authentication Headers (AH) or Encapsulation Security Payload (ESP)—we quickly discover that they both operate in one of two modes:
- Tunnel Mode
- The entire IPsec process is transparent to the end hosts
- Requires specialized gateway devices to handle the IPsec workload
- Encrypts the entire IP packet, and then encapsulates that into another IP Packet that is used for routing
- Used in Network-to-Network and Host-to-Network VPN's
- Transport Mode
- Encrypts only the IP Payload, but inserts the IPsec Header directly after the IP header in the packet
- Provides no protection for the original IP Address
- Uses the original IP Address for routing
- Only protects data from the Transport Layer of the OSI model and up
- Used in Host-to-Host VPN's
Security Associations (SA)
A Security Association (SA) is a combination of shared security attributes used between two end points to support a secure communication session. In Cisco IOS there is a well-defined framework used to establish these security associations:
- Internet Security Association and Key Management Protocol (ISAKMP)—only provides a framework for authentication and key exchange and is designed to be key exchange independent, thus relying on authenticated keying materials from:
- Internet Key Exchange (IKE)—a Stateful command/response protocol that uses UDP packets, usually on port 500 to create an SA on both sides of a link. The negotiated key material is then given to the IPsec stack.
- Kerberized Internet Negotiation of Keys (KINK)—a Stateless command/response protocol that can create, delete, and maintain IPsec SAs. Each command or response contains a common header along with a set of type-length-value (TLV) payloads.
If it wasn't for the bundle of algorithms and data that provide the parameters necessary to maintain AH and/or ESP operations that are provided by Security Associations, there would be no IPsec protocol in the first place.
Conclusion
We have looked closely at one of the most commonly used protocol suites employed in networking today. Whether it is a 'road warrior' in a hotel room in the middle of nowhere or branch offices connected via site-to-site VPN's, we have seen what technologies protect our data, and how they operate to create a secure framework that eliminates distance as an impediment to exchanging data and accessing network resources. It is amazing how much this simple suite of protocols can do for us.