Day 22. IPsec Technologies
CCNA Security 210-260 IINS Exam Topics
3.1.a Describe IPsec protocols and delivery modes (IKE, ESP, AH, tunnel mode, transport mode)
Key Topics
Today we will focus on the fundamentals of virtual private network (VPN) technologies, as well as look in detail at the building blocks behind Internet Protocol security (IPsec).
VPNs
A VPN provides security services to traffic traversing a relatively less trustworthy network between two relatively more trusted systems or networks. Most commonly, the less trusted network is the public Internet. A VPN is virtual in that it carries information within a private network, but that information is actually transported over a public network. A VPN is also private in that the traffic is encrypted to keep the data confidential while it is transported across the public network. There are four main benefits to using VPNs:
Cost savings: Organizations can use VPNs to reduce their connectivity costs.
Security: Advanced encryption and authentication protocols protect data.
Scalability: Organizations can use the Internet to easily interconnect new offices.
Compatibility: VPNs can be implemented across a wide variety of WAN link options.
There are many different types of VPN technologies, some of which offer privacy through isolation, and some of which offer both privacy and security by implementing cryptographic protocols. Table 22-1 summarizes some of these VPN options.
The CCNA Security exam focuses on three of these types of VPN:
Site-to-site IPsec VPN
Remote-access IPsec VPN
Remote-access SSL VPN
A site-to-site IPsec VPN is an extension of a classic WAN network. Site-to-site VPNs connect entire networks to each other. For example, site-to-site VPNs can connect a branch office network to a company headquarters network. Transport across a site-to-site VPN is transparent to the communicating hosts. The hosts send and receive normal TCP/IP traffic between each other. VPN gateways provide security services at the borders between the trusted and non-trusted networks. Figure 22-1 shows how site-to-site VPNs can be used to securely connect branch offices to a company headquarters network using an insecure Internet connection.
Remote-access VPN technology is an evolution of dialup connections. Remote-access VPNs can support the needs of telecommuters, mobile users, and extranet consumer-to-business traffic, as shown in Figure 22-2. Remote-access VPNs connect individual hosts that must access their company network securely over the Internet. In a remote-access VPN, each host typically has VPN client software. Whenever the host tries to send any traffic, the VPN client software encapsulates and encrypts that traffic before sending it over the Internet to the VPN gateway at the edge of the target network.
On the other hand, SSL VPNs provide a suite of security services that are similar to the security services provided by IPsec. SSL VPN technology has become popular for the implementation of remote-access VPNs with or without the use of client software. SSL-based VPNs leverage the SSL protocol. SSL was initially developed by Netscape in the 1990s. The Internet Engineering Task Force (IETF) later produced a standards-based more secure alternative called TLS. There are slight differences between SSL and TLS, but the protocols remain similar. The terms are sometimes used interchangeably, but interestingly, the protocols are not interoperable. Cisco SSL VPNs are really using TLS behind the scenes, so both SSL and TLS are mentioned in this chapter.
One of the most popular features of a clientless SSL VPN is the capability to launch a browser and simply connect to the address of the VPN device, as opposed to running a separate VPN client program to establish an IPsec VPN connection.
The most successful application running on top of SSL is HTTP because of the huge popularity of the World Wide Web. All the most popular web browsers in use today support HTTPS (HTTP over SSL/TLS). Figure 22-3 shows two types of SSL VPN connections across the Internet: the noncorporate user connects using a clientless SSL VPN through a web browser, while the employee connects using a client-based SSL VPN. Both clients are authenticated using the AAA server in order to access the internal protected resources.
We will cover the concepts, the terminology, and the configuration of these three types of VPN deployments in upcoming review days.
IPsec Framework
IPsec is an open standard that defines how a VPN can be secured across IP networks. IPsec protects and authenticates IP packets between source and destination. IPsec provides these essential security functions:
Confidentiality: IPsec ensures confidentiality by using encryption.
Data integrity: IPsec ensures that data arrives unchanged at the destination, meaning that the data has not been manipulated at any point along the communication path.
Origin authentication: Authentication ensures that the connection is made with the desired communication partner. IPsec uses Internet Key Exchange (IKE) to authenticate users and devices that can carry out communication independently. IKE can use the following methods to authenticate the peer system:
Pre-shared keys (PSK)
Digital certificates
RSA-encrypted nonces
Anti-replay protection: Anti-replay protection verifies that each packet is unique and is not duplicated.
Key management: Allows for an initial safe exchange of dynamically generated keys across a non-trusted network and a periodic rekeying process, limiting the maximum amount of time and data that are protected with any one key.
These security functions define the IPsec framework and spell out the rules for secure communications. IPsec relies on existing algorithms to implement encryption, authentication, and key exchange. Figure 22-4 illustrates some of the standard algorithms that IPsec uses. The framework allows technologies to be replaced over time. When cryptographic technologies become obsolete, it doesn’t make the IPsec framework obsolete. Instead, obsolete technologies are replaced with more current versions, keeping the framework in place.
The following subsections will look at each individual line of the IPsec framework in detail.
IPsec Protocols
There are two main IPsec framework protocols: Authentication Header (AH) and Encapsulating Security Payload (ESP).
AH
AH, which is IP protocol 51, is the appropriate protocol to use when confidentiality is not required. In other words, AH does not provide data encryption. AH does, however, provide origin authentication, data integrity, and anti-replay protection for IP packets that are passed between two systems. AH achieves data integrity and origin authentication by applying a keyed one-way hash function to the packet to create a hash, or message digest. The hash is combined with the text and is transmitted. The receiver detects changes in any part of the packet that occur during transit by performing the same one-way hash function on the received packet and comparing the result to the value of the message digest that the sender has supplied. AH supports the HMAC-MD5 and HMAC-SHA-1 algorithms.
ESP
Like AH, ESP provides origin authentication, data integrity, and anti-replay protection; however, unlike AH, it also provides confidentiality. ESP, which is IP protocol 50, provides confidentiality by encrypting IP packets. ESP supports various symmetric encryption algorithms, including DES, 3DES, and AES. The original data is well protected by ESP, because the entire original IP packet is encrypted. When ESP authentication is also used, the encrypted IP packet and the ESP header and trailer are included in the hashing process. When both authentication and encryption are used, encryption is performed first. Authentication is then performed by sending the encrypted payload through a hash algorithm. The hash provides data integrity and data origin authentication. Last, a new IP header is prepended to the authenticated payload. The new IP address is used to route the packet. ESP does not attempt to provide data integrity for this new external IP header. Figure 22-5 illustrates the ESP encryption and authentication process on an IP packet using tunnel mode.
In modern IPsec VPN implementations, the use of ESP is more common than AH.
IPsec Modes of Operations
ESP and AH can be used in two different ways, or modes. The encapsulation can be done in tunnel mode or in transport mode.
ESP transport mode does not protect the original packet’s IP header. Only the original packet’s payload is protected. An ESP header is inserted between the original IP header and the protected payload.
ESP tunnel mode protects the entire original IP packet. The entire original IP packet, including its IP header, is encrypted and becomes the payload for the new packet. An ESP header is applied for the transport layer header, and this is encapsulated in a new packet with a new IP header. The new IP header specifies the VPN peers as the source and destination IP addresses. The IP addresses specified in the original IP packet are not visible.
The encapsulation performed on an ESP packet with each mode is illustrated in Figure 22-6.
AH can also be implemented in either tunnel mode or transport mode. AH transport mode provides authentication and integrity for the entire packet. It does not encrypt the data, but it is protected from modification. AH tunnel mode encapsulates the IP packet with an AH and a new IP header, and signs the entire packet for integrity and authentication.
Confidentiality
Day 29 provided an in-depth review of the different encryption technologies. The following are some of the encryption algorithms and key lengths that IPsec can use:
DES algorithm: DES uses a 56-bit symmetric key.
3DES algorithm: 3DES is a variant of the 56-bit DES. It uses three independent 56-bit encryption keys per 64-bit block, which provides significantly stronger encryption strength over DES.
AES: AES provides stronger security than DES and is computationally more efficient than 3DES. AES offers three different key lengths: 128 bits, 192 bits, and 256 bits.
SEAL: As a stream cipher, SEAL encrypts data continuously rather than encrypting blocks of data. SEAL uses a 160-bit key.
Data Integrity
VPN data is typically transported over the public Internet. Potentially, this data could be intercepted and modified. To guard against this problem, you can use one of the data-integrity algorithms, which were discussed in our review on Day 29. Remember that a data-integrity algorithm adds a hash to the message, which guarantees the integrity of the original message. If the transmitted hash matches the received hash, the message has not been tampered with. However, if there is no match, the message was altered. A Hashed Message Authentication Code (HMAC) is a data-integrity algorithm that guarantees the integrity of the message. IPsec currently supports three common HMAC algorithms:
HMAC-Message Digest 5 (HMAC-MD5): HMAC-MD5 uses a 128-bit shared-secret key of any size but the output is a 128-bit hash.
HMAC-Secure Hash Algorithm 1 (HMAC-SHA-1): HMAC-SHA-1 uses a secret key of any size but the output is a 160-bit hash.
HMAC-Secure Hash Algorithm 2 (HMAC-SHA-2): The SHA-2 family of HMACs is based on the same base algorithm as SHA-1. The SHA-2 family (the second generation of SHA algorithms) includes the 256-, 384-, and 512-bit hash algorithms, referred to as SHA-256, SHA-384, and SHA-512 respectively.
Origin Authentication
When you are conducting business long distance, it is necessary to know who is at the other end of the phone, email, or fax. The same is true of VPN networks. The device on the other end of the VPN tunnel must be authenticated before the communication path is considered secure. Four peer-authentication methods exist:
Pre-shared keys (PSK): A secret key value is entered into each peer manually and is used to authenticate the peer. This is a shared secret that both parties must exchange ahead of time.
RSA signatures: The exchange of digital certificates authenticates the peers. The local device derives a hash and encrypts it with its private key. The encrypted hash is attached to the message and is forwarded to the remote end, and it acts like a signature. At the remote end, the encrypted hash is decrypted using the public key of the local end. If the decrypted hash matches the recomputed hash, the signature is genuine. (RSA is named after its inventors, Rivest, Shamir, and Adleman.)
RSA encrypted nonces: A nonce is a random number that is generated by the peer. RSA-encrypted nonces use RSA to encrypt the nonce value and other values. This method requires that each peer is aware of the public key of the other peer before negotiation starts.
ECDSA signatures: The ECDSA is the elliptic curve analog of the Digital Signature Algorithm (DSA) signature method. ECDSA signatures are smaller than RSA signatures of similar cryptographic strength. ECDSA operations can be computed more quickly than similar-strength RSA operations.
Key Management
Encryption algorithms require a symmetric, shared secret key to perform encryption and decryption. How do the encrypting and decrypting devices get the shared secret key? The easiest key exchange method is to use a public key exchange method. Public key exchange methods allow shared keys to be dynamically generated between the encrypting and decrypting devices. The method has two variants:
The Diffie-Hellman (DH) key agreement, mentioned on Day 29, is a public key exchange method. This method provides a way for two peers to establish a shared-secret key, which only they know, even though they are communicating over an insecure channel.
ECDH is a variant of the DH protocol using elliptic curve cryptography (ECC).
These algorithms are used to establish session keys. They support different prime sizes that are identified by different DH or ECDH groups. DH groups vary in the computational expense that is required for key agreement and the strength against cryptographic attacks. Larger prime sizes provide stronger security, but require additional time to compute. The following is a quick listing of the different DH groups:
DH1: 768-bit
DH2: 1024-bit
DH5: 1536-bit
DH14: 2048-bit
DH15: 3072-bit
DH16: 4096-bit
DH19: 256-bit ECDH
DH20: 384-bit ECDH
DH24: 2048-bit ECDH
Suite B Cryptographic Standard
RFC 4869 defines a set of cryptographic algorithms to adhere to National Security Agency (NSA) standards for classified information. Called Suite B, it includes these specified algorithms:
Encryption that is based on AES using 128- or 256-bit keys
Hashing (digital fingerprinting) based on SHA-2
Digital signatures with the ECDSA using curves with 256- and 384-bit prime moduli
Key exchange, either pre-shared or dynamic, using the ECDH method
Note
For an excellent article on Cisco-recommended cryptographic algorithms and best practices, see http://www.cisco.com/web/about/security/intelligence/nextgen_crypto.html.
IKE
IPsec uses the IKE protocol to negotiate and establish secured site-to-site or remote-access VPN tunnels. IKE is a framework provided by the Internet Security Association and Key Management Protocol (ISAKMP) and parts of two other key management protocols, namely Oakley and Secure Key Exchange Mechanism (SKEME). An IPsec peer accepting incoming IKE requests listens on UDP port 500.
IKE uses ISAKMP for Phase 1 and Phase 2 of key negotiation. Phase 1 negotiates a security association (a key) between two IKE peers. The key negotiated in Phase 1 enables IKE peers to communicate securely in Phase 2. During Phase 2 negotiation, IKE establishes keys (security associations) for other applications, such as IPsec.
There are two versions of the IKE protocol: IKE version 1 (IKEv1) and IKE version 2 (IKEv2). IKEv2 was created to overcome some of the limitations of IKEv1. IKEv2 enhances the function of performing dynamic key exchange and peer authentication. It also simplifies the key exchange flows and introduces measures to fix vulnerabilities present in IKEv1. Both IKEv1 and IKEv2 protocols operate in two phases. IKEv2 provides a simpler and more efficient exchange. Both IKEv1 and IKEv2 are reviewed in the following sections.
IKEv1 Phase 1
IKEv1 Phase 1 occurs in one of two modes: main mode and aggressive mode. Main mode has three two-way exchanges between the initiator and receiver. These exchanges define what encryption and authentication protocols are acceptable, how long keys should remain active, and whether Perfect Forward Secrecy (PFS) should be enforced. Figure 22-7 summarizes these three two-way exchanges.
The first step in IKEv1 main mode is to negotiate the security policy that will be used for the ISAKMP SA. There are five parameters, which require agreement from both sides:
Encryption algorithm
Hash algorithm
Diffie-Hellman group number
Peer authentication method
SA lifetime
The second exchange in IKEv1 main mode negotiations facilitates Diffie-Hellman key agreement. The Diffie-Hellman method allows two parties to share information over an untrusted network and mutually compute an identical shared secret that cannot be computed by eavesdroppers who intercept the shared information.
After the DH key exchange is complete, shared cryptographic keys are provisioned, but the peer is not yet authenticated. The device on the other end of the VPN tunnel must be authenticated before the communications path is considered secure. The last exchange of IKE Phase 1 authenticates the remote peer.
Aggressive mode, on the other hand, compresses the IKE SA negotiation phases that are described thus far into two exchanges and a total of three messages. In aggressive mode, the initiator passes all data that is required for the SA. The responder sends the proposal, key material, and ID and authenticates the session in the next packet. The initiator replies by authenticating the session. Negotiation is quicker, and the initiator and responder IDs pass in plaintext.
IKEv1 Phase 2
The purpose of IKE Phase 2 is to negotiate the IPsec security parameters that define the IPsec SA that protects the network data traversing the VPN. IKE Phase 2 only offers one mode, called quick mode, to negotiate the IPsec SAs. In Phase 2, IKE negotiates the IPsec transform set and the shared keying material that is used by the transforms. In this phase, the SAs that IPsec uses are unidirectional; therefore, a separate key exchange is required for each data flow. Optionally, Phase 2 can include its own Diffie-Hellman key exchange, using PFS. Figure 22-8 illustrates the IKE Phase 2 exchange.
Video: IKEv1 Phase 1 and IKEv1 Phase 2
Refer to the Digital Study Guide to view this video.
IKEv2
IKE Version 2, a next-generation key management protocol that is based on RFC 7296, is an enhancement of the IKE protocol. IKEv2 offers less overhead, has support for NAT Traversal, has less delay when creating SAs, has faster rekeying times, is less susceptible to DoS attacks, and offers support for EAP between VPN peers. IKEv2, illustrated in Figure 22-9, uses fewer messages to accomplish the same (and more) objectives as IKEv1.
Activity: Identify the IPsec Terminology
Refer to the Digital Study Guide to complete this activity.
Study Resources
For today’s exam topics, refer to the following resources for more study.
Check Your Understanding
Refer to the Digital Study Guide to take a ten-question quiz covering the content of this day.