Stronger IPsec VPN Configurations Needed

Should you be using IPsec with IKEv2, SHA-2 and AES?

The use of IPsec is pervasive throughout the networking industry. However, many organizations are using IPsec in sub-optimal configurations that result in weaker connection security. Many organizations use IPsec with pre-shared keys and weak encryption algorithms and no form of authentication. Organizations should reconsider how they are using IPsec to ensure it provides maximum security for their organization's private communications.

Virtually all network professionals are familiar with the Internet Protocol Security (IPsec) standard. The Internet Engineering Task Force (IETF) created IPsec as a method to secure end-to-end IP communications by providing confidentiality, authenticity and integrity of the data. Originally, IPsec was a method of authenticating and encrypting IPv6 packets. However, it was such a great idea that it was also applied to IPv4.

Many organizations rely on IPsec to secure external communications to prevent against eavesdropping of the embedded application data. IPsec can provide data origin authentication, replay protection, confidentiality, connectionless integrity and access control. IPsec helps prevent against eavesdropping, replay and spoofed packet attacks, Man-in-the-Middle (MITM) attacks and Denial of Service (DoS) attacks. IPsec can perform all of these functions provided IPsec has been implemented correctly by the manufacturer and the administrator has configured in properly on their equipment and in their software. However, the unfortunately truth is that many organizations have not established their IPsec deployments using the industry best practices.

Several years ago Mark Lewis also wrote a great article on the "Top 10 reasons why IPsec VPNs fail" that covers these same concepts about IPsec configuration options.

Issues with Pre-Shared Secrets

One of the first things to mention about encryption is that the security is in the secrecy of the key and not the secrecy of the algorithm. Encryption algorithms are made public so that the industry can vet the mathematics to ensure that the algorithm is secure. In public/private key encryption the security is guaranteed by keeping the private key safe.

IPsec deployments operate in much the same way. However, many organizations insist on configuring pre-shared secrets that are identical on both ends of the connection. Rather than take the time to set up a Certificate Authority (CA) and issue individual keys to each IPsec endpoint, administrators take the easy way out and use the same key on each IPsec endpoint. Therefore, if one endpoint is compromised or physically stolen, all the other IPsec links are vulnerable.

Many tunnel-mode IPsec connections can stay operational for years with the same keys. As IT staff come and go the secrecy of that pre-shared key erodes over time. Certificates are much stronger, but take a little bit of extra configuration work. However, if your organization insists on using pre-shared key then you should have a process of changing them out every few months and using different keys on different connections.

Issues with NAT

The other significant issue that plagues IPsec deployments is that many organizations make extensive use of Network Address Translation (NAT) (or rather Port Address Translation (PAT)). NATs are pervasive in enterprise organizations due to their address-hiding properties and their perceived security benefits. This affects IPsec when the source IP address in the outer header changes as the packet is transmitted from the data source, through the NAT, and received at the destination. This causes difficulties for the Authentication Header (AH) because it preserves the original IP header inside the authenticated header. If the outer header is changed in any way then the inner packet validation fails because the inner packet's source address no longer matches the outer packet's source address and the packet is discarded.

This is why many organizations turn to using NAT Traversal to solve this problem. The NAT Traversal technique encapsulates the IPsec packets in UDP port number 4500 (although other ports can be chosen) and encapsulates IKE messages in UDP port 500. Then as the packet is sent from the source to the destination the inner IPsec packets remain in tack and only the outer IP header is modified with NAT. The issues is that even with NAT Traversal many organization's still can't or don't use AH so their implementations only use Encapsulating Security Payload (ESP) and ESP-HMAC.

As IPv6 is deployed, organizations will use Aggregatable Global Unicast addresses. These public addresses will not require the use of any NAT function at their Internet perimeters. Therefore, is all nodes start to use Global Unicast IPv6 addresses then there will not be a need for NAT. Without NAT then we can be certain that the IPv6 addresses of the inner and outer packets will match and we can use AH in combination with ESP for higher-integrity IPsec connections.

In IPv6 networks there is no need for NAT to provide for additional IP addresses. The IETF RFC 4864 provides great coverage of the issues surrounding "Local Network Protection for IPv6" and describing why NAT is not needed in IPv6.

However, no sooner than I write this, we now have a new IETF RFC 6296 "IPv6-to-IPv6 Network Prefix Translation" has been published. The difference here is that this method provides a 1:1 mapping of IPv6 addresses and there is no need for PAT-type functions to handle an IPv6 address shortage problems as we have with IPv4.

There is a misconception that IPv6 is more secure than IPv4 because IPv6 mandates the use of IPsec. IETF RFC 2460 states that to have "a full implementation of IPv6" then nodes must support AH and ESP extension headers. IETF RFC 4294 states in section 8 that IPv6 nodes must support AH and ESP. However, this is in fact false, because we know that in the "real world", not all IPv6 devices have the CPU resources required to perform the encryption mathematics. IPv6 networks could have small sensors that have limited CPU and battery resources so they want to minimize the packets they send and they will not use IPsec.

If you haven't seen it yet, there is an extremely funny You Tube video on the use of IPv6 and NAT. The sad thing is that we have all met "I like my NATs, they make me feel safe" people during our careers.

Issues with Weak Encryption and Hashing Algorithms

As time goes on and processors become more advanced so do the capabilities of attackers to brute-force decrypt encrypted data. Year-after-year the encryption algorithms we are using get weaker and weaker because of the advances in the capabilities of the cryptanalysts. For example, years ago the Electronic Frontier Foundation (EFF) and was able to use their DES cracker "Deep Crack" to crack a 56-bit key in 22 hours. Today it can be cracked even faster on modern computers or distributed systems.

To this point, the IETF release the RFC 4722, "Security Implications of Using the DES" recommending not using DES in favor of Advanced Encryption Standard (AES).

Message Digest 5 (MD5) and Secure Hash Algorithm 1 (SHA-1) are Hashed Message Authentication Codes (HMAC) techniques that produce a checksum of the contents of the packet to ensure that the packet hasn't been tampered with in transit. SHA-1 is generally considered cryptographically stronger than MD5 but SHA-1 requires more computing cycles to calculate so SHA-1 is used in environments that require superior overall security.

It is commonly accepted that 40-bit and 56-bit symmetric-key encryption are easy to break with a modest amount of computing power. Even 128-bit MD4 (equivalent to 64-bit) has been broken and research has been taking place on the reality of breaking 128-bit MD5. Because of these weaknesses, the IETF has published RFC 6151 "MD5 and HMAC-MD5 Security Considerations" which recommends not using MD5 in favor of SHA-1 and AES-CMAC (RFC 4493). For comparison, SHA-1 has a power of 2^80 and RSA-1024 also has a strength of 2^80.

In IPsec there are several different types of encryption techniques used in various parts of the protocol. IPsec uses encryption algorithms, digital signatures, key exchange algorithms, and hashing functions. Therefore, you must consider each one of these algorithms being used in your implementation of IPsec and see if you can do any better with how you have things configured today. Recently I have seen many organizations using weaker encryption algorithms and I do not want you making the same mistakes.

Suite B Cryptographic Algorithms

The IETF published an RFC 4308 that gives the industry guidance on the recommended "Cryptographic Suites for IPsec". The IETF also recommends the use of "Suite B Cryptographic Suites for IPsec" in RFC 4869. The National Security Agency (NSA) also recommends the use of "Suite B" cryptographic algorithms as part of its Cryptographic Modernization Program. A few years ago Bill Lattin wrote a Network World article titled "Upgrade to Suite B security algorithms" which reinforces the need to use better cryptographic algorithms. Therefore, you should take the advice of these experts and favor the use of Suite B algorithms in your IPsec configurations.

U.S. Government Encryption Standards

Government organizations have specific mandates on the types of encryption that can be used. NIST has recommended phasing out these older encryption techniques in favor of new ones with increased key-size. If your organization has the need to transmit Sensitive But Unclassified (SBU) data over the Internet and you are using IPsec then you must adhere to the guidance from the NSA and NIST to use stronger cryptographic algorithms. In fact, there is a variety of standards that U.S. federal organizations must follow regarding IPsec algorithms.

The Federal Information Processing Standards (FIPS) standards are published by the National Institute of Standards and Technology (NIST) and are part of the Information Technology Reform Act of 1996 and the Federal Information Security Management Act of 2002. FIPS 197 provides information on the use of AES with keys sizes of 128 and 256 bits. FIPS 186-3 provides information on Digital Signature Standard (DSS) and recommends using Elliptic Curve Digital Signature Algorithm with curves that have 256 and 384-bit prime moduli. FIPS 180-4 provides information on the Secure Hash Standard (SHS) recommending using SHA-256 and SHA-384. FIPS-140-2 provides guidelines for the Security Requirements for Cryptographic Modules and the security of the products providing these functions. This standard is being revised into FIPS 140-3. NIST SP 800-77 is a good "Guide to IPsec VPNs". The NIST SP 800-56B (soon to be SP 800-56C) provides recommendations on key agreement and negotiation recommending Elliptic Curve Diffie-Hellman (DH) with curves that have 256 and 384-bit prime moduli. The National Security Agency (NSA) also publishes information on the use of Suite B algorithms.

Internet Key Exchange (IKE)

The other problem that organizations run into and end up configuring weaker IPsec deployments involves the methods used to perform the exchange of the keys. The Internet Key Exchange (IKE) protocols is used to facilitate the process of systems exchanging their keys in a secure way. The Internet Key Exchange (IKE) was originally defined in IETF RFC 2409.

IKE is used to create Security Associations (SAs) between the IPsec endpoints. There are two options administrators can choose: Phase 1 with Main Mode or Aggressive Mode and Phase 2 with Quick Mode. The Phase 1 process is to establish a secure channel that the second phase can use to negotiate IPsec parameters using the shared secret negotiated in Phase 1. Some organizations use Phase 1 with Aggressive Mode which is a 3-packet exchange rather than the 6-packet exchange of Main Mode. However, there are significant vulnerabilities when Aggressive Mode is used and we recommend using Phase 1 with Main Mode.

Even though IKE is widely used there were improvements that could be made to the protocol. In December of 2005, the IETF published RFC 4306 "Internet Key Exchange (IKEv2) Protocol". Both the ISAKMP RFC and the IKE RFC are now obsoleted by IETF RFC 4306. The IETF also published RFC 4718 "IKEv2 Clarifications and Implementation Guidelines" Many products are now starting to support IKEv2 so if you have the ability to configure IKEv2 then you should chose the stronger option.

Vendor Updates

Although the IPsec standards have been stable for many years there are still improvements being made by vendors in their implementations of the IPsec protocol. For example, newer Microsoft operating systems like Vista Service Pack 1, in Windows Server 2008, and in Windows 7 now have support for Suite B algorithms. Cisco released a 64-bit version of their IPsec client software last year. Therefore, if you are using older versions of the Cisco IPsec client then you will want to upgrade to the newest versions so your organization can stay up to date.

Cisco and other vendors haven't supported IKEv2 for many years but now they are starting to support it. Cisco IOS 15.1(1)T has support for IKEv2 SHA-2 and Suite B algorithms. The newest ASA firmware release 8.4 supports IKEv2 and now SHA-2. Be sure to check with your vendor and see what options are available in their latest versions. Upgrade your software and configure the stronger IPsec methods.

Export Control

1 2 Page 1
Page 1 of 2
SD-WAN buyers guide: Key questions to ask vendors (and yourself)