Virtual Private Networks (VPNs) provides a secure tunnel across a public (and thus, insecure) network. This provides a mechanism for organizations to connect users and offices together, without the high costs of dedicated leased lines. VPNs are most often used across the Internet, the world’s largest public network, providing users with access to email, documents, printers, and systems as if they were actually at their central office. VPNs are generally used for two purposes:
• Client VPNs – connect home or “roaming” users to an office.
• Site-to-Site VPNs – connect remote offices to a main office.
What is IPSEC?
IPSEC, short for IP Security, is a suite of protocols, standards, and algorithms to secure traffic over an untrusted network, such as the Internet. IPSEC is supported on both Cisco IOS devices and PIX Firewalls. IPSEC provides three core services:
• Confidentiality – prevents the theft of data, using encryption.
• Integrity – ensures that data is not tampered or altered, using a hashing algorithm. • Authentication – confirms the identity of the host sending data, using pre-shared keys or a Certificate Authority (CA).
• Anti-replay – prevents duplication of encrypted packets, by assigning a unique sequencing number.
The IPSEC Protocols:
IPSEC uses one of two protocol headers for securing data:
• Authentication Header (AH)
• Encapsulation Security Payload (ESP)
Authentication Header (AH), or IP protocol 51, provides no confidentiality of data. It does not encrypt any data at all. However, AH provides both authentication and integrity services. Because AH does not perform encryption, it is a quicker standard than ESP.
- AH uses a hash algorithm to compute a hash value on both the payload and header of a packet, ensuring integrity of the packet. However, this causes a very specific problem. AH will not work through a NATed device.
NAT changes the IP header of a packet during translation, but the hash value is not changed. Thus, the receiving device will believe the packet has been altered in transit, and reject the packet.
Encapsulation Security Payload (ESP), or IP protocol 50, performs confidentiality, authentication, and integrity services. Thus, ESP does perform encryption, and is inherently more secure than AH. ESP introduces both an additional header and trailer to a packet. ESP also uses a hash algorithm for data integrity. However, the hash does not include the IP header of the packet, and thus ESP will (usually) work through a NATed device. ESP and AH can be used separately, or used in conjunction with each other.
Consider what happens when you run IPSec with GRE. The end station sends a data packet, the GRE adds additional header information (as it encapsulates the original data packet into the GRE packet) and IPSec adds additional header information. So if the end station sends a large packet (say for example 1500 which is the max size for Ethernet) and you add the header information for GRE and the header information for IPSec, there is now a packet much larger than 1500 and it must be fragmented by routers along the path. Also consider that some applications send the TCP packet with the Do Not Fragment bit set so that the router can not fragment the packet but the packet is too large to go accross the link. So the application does not work.
Transport vs. Tunnel Modes
Each IPSEC protocol (AH or ESP) can operate in one of two modes:
• Transport mode – Original IP headers are left intact. Used when securing communication from one device to another single device.
– IPsec header is inserted into the IP packet
– No new packet is created
– Works well in networks where increasing a packet’s size could cause an issue
– Frequently used for remote-access VPNs
• Tunnel mode – the entire original packet is hashed and/or encrypted, including both the payload and any original headers. A temporary IP header is applied to the packet during transit. Used to tunnel traffic from one site to another.
– Entire IP packet is encrypted and becomes the data component of a new (and larger) IP packet.
– Frequently used in an IPsec site-to-site VPN
Security Associations (SA)
IPSEC VPN peers establish a Security Association (SA), a “connection” or “policy” between the two endpoints of the VPN tunnel. An SA is a one-way virtual tunnel between the VPN peers. Thus, for full communication to occur, two SA’s must be established, one for each direction
Before the SA can be established, several parameters must be negotiated between VPN peers, and keys must be both created and exchanged. The Internet Key Exchange (IKE) protocol controls this negotiation process, on UDP port 500. IKE Policy Sets are created to negotiate several parameters, including:
• The encryption algorithm (such as DES, 3DES, or AES)
• The hashing algorithm (such as MD5 or SHA-1)
• The authentication method (such as shared keys or RSA signatures)
• The Diffie-Hellman (D-H) group for creating and sharing keys
• The SA Lifetime, measured in seconds or in kilobytes sen
How to Set Up an SA:
– Sometimes referred to as “manual keying”
– You configure on each node:
• Participating nodes (I.e. traffic selectors)
• AH and/or ESP [tunnel or transport]
• Cryptographic algorithm and key
• Automatically – Using IKE (Internet Key Exchange)
There are two phases to this negotiation process:
IKE Phase 1 establishes the initial tunnel (referred to as the IKE or ISAKMP SA). Peers are authenticated, encryption and hashing algorithms are negotiated, and keys are exchanged based on the IKE Policy Sets. Two modes can be used for Phase 1 negotiation:
• Main Mode – slower, but more secure
• Aggressive Mode – faster, but less secure
IKE Phase 2 establishes the IPSEC tunnel (IPSEC SA), which details the AH or ESP parameters for securing data. These parameters are contained in an IPSEC Transform Set. IKE Phase 1 negotiates parameters for the tunnel (key exchange) itself, while IKE Phase 2 negotiates parameters for the data traversing that tunnel.