N Squared Problem
Here's how the math for the n squared problem works: assume you have two parties connecting to one another. The formula for the n squared problem says that for each party n, the number of connections needed can be determined by the formula n * (n 1). So, for two parties, you need two connections (one in each direction). If you only want to know how many bidirectional connections you need, just divide your result by 2. So, for a 100-peer fully meshed VPN connection using preshared keys, you have the following:
• 100 routers
• 9900 unidirectional IPsec SAs
• 4950 unique preshared key combinations Not scalable, indeed!
Even assuming hub-and-spoke, which makes up the majority of IPsec deployments today, that is still too many keys. Many organizations get around this by using something called a group preshared key (sometimes called a wildcard preshared key). A group preshared key is a key that is used on a device for multiple peers rather than being unique to a specific peer. This method eases the initial configuration requirements but is much less secure. Consider if one router is compromised and the preshared key is determinedall the peer routers must be immediately reconfigured with a new key. Not fun.
Digital Signatures
As an alternative, digital signatures allow each device to assert its identity in a verifiable way to other parties. The most common method is using a CA as described in the "Basic PKI" section of Chapter 4.
From a design standpoint, digital certificates should be used whenever possible for large site-to-site deployments. Although the definition of "large varies" from organization to organization, anything over about 25 peers is a good justification for PKI, even fewer if you are deploying a full mesh (discussed later). Because of the difficulty getting and managing digital certificates on your users' workstations, most organizations choose to use wildcard preshared keys with Xauth and OTP (discussion to follow for remote user VPNs).
This PKI should be a "closed" PKI and need not interact with any other identity systems in your network. Whether you choose to source the CA yourself or work through a service, the end result is the same.
NOTE
One essential element of your PKI not already discussed is the concept of certificate revocation lists (CRLs). From time to time, an IPsec peer may compromise its trust with the rest of the network. This could be caused by a device compromise or theft. It is essential that the rest of your network be told of this event; otherwise, users will continue to trust the device. CRLs are the means to distribute this information. Housed at the CA, a CRL is like a list at a store identifying people who have tried to pass bad checks. Before accepting an IPsec peer as trusted, the CRL is checked in advance by the IPsec device. Although many devices list CRLs as an optional feature, they should always be implemented when using digital certificates.
When using CRLs and a PKI, it is important for each device to have the accurate time because devices need to know when to retrieve a new CRL list as well as when to check the validity dates on a certificate.
Mode Config and Extended Authentication (Xauth)
Mode Config is a method for provisioning an "internal" IP address for the IPsec ESP tunnel. It is implemented in some IPsec gear now, though the standard for this will not be released until IKEv2. When a remote user VPN is established from a client, it is useful to provision that client with an internal (perhaps RFC 1918) address by which policy decisions can be made for the client. Without Mode Config, the inner address of the tunnel would be the dynamic IP address assigned to the client, which is not generally suitable for access control decisions within an organization's network.
Xauth defines a method of extended authentication that occurs between IKE phase 1 and phase 2. It allows for a username and password to be required before IKE establishes the IPsec SAs. In this way, remote user VPNs can take advantage of group preshared keys for IKE phase 1 but can require more extensive, user-specific authentication before phase 2 (often an OTP). This addresses some of the limitations of preshared keys, but it is still not as secure as digital certificates. But because an organization can take advantage of its existing AAA infrastructure, Xauth is considerably easier to manage.
Xauth and Mode Config as currently implemented, will need to be updated after IKEv2 is released to be standards compliant. IKEv2, for example, mandates EAP as the Xauth method.
Diffie-Hellman Group
As mentioned previously, Oakley (a part of IKE) is used to derive a session key that enables encryption for the IKE information. Diffie-Hellman (DH) is the algorithm used for this negotiation. The coolest part about DH (if indeed crypto is ever cool) is that this shared session key is derived with no secrets shared between the parties in advance and without the secret key being transmitted between the parties. This was quite an achievement when it was introduced in 1976. DH is vulnerable to man-
in-the-middle (MITM) attacks, which is why SKEME is used to authenticate each peer in the DH exchange. DH as part of Oakley can operate in several different groups. For example, group 1 is 768bit, group 2 is 1024-bit, and group 5 is 1536-bit. As with most algorithms in cryptography, if all other things are equal, more bits means more secure. It also means more computation. As you go through the pilot phase of your VPN, you might wish to try different DH group values and determine whether there is a noticeable difference in IPsec gateway CPU utilization. If not, higher groups are more secure.
Perfect Forward Secrecy
As discussed earlier, the DH algorithm is used by IPsec to derive the session key used in an SA. This occurs for both IKE and IPsec SAs. Perfect forward secrecy (PFS) is the idea that the compromise of any one of these session keys should not allow the attacker any useful additional data to aid in compromising the others. Without PFS, for example, if an attacker were able to compromise the IKE SA session key, the attacker could perhaps use it to increase the chances of compromising the IPsec SAs session keys. PFS ensures that this can't happen by requiring that unique DH exchanges occur for each of the needed session keys. From a design standpoint, it is very unlikely that someone will be able to compromise any of these keys. However, it doesn't take much work to enable PFS on your devices. The only design impact (besides the security difference) is the potential performance impact the additional DH exchanges take. Ask your hardware vendor if enabling PFS will have a significant impact on the crypto chips the vendor uses. Like DH group selection, you should experiment with this feature in the pilot stage to determine impact.
Encryption Protocol Selection
After examining many of the supporting design choices you can make, one of the biggest decisions you have to make is which encryption mechanism you use for the transport of the data. This section very briefly describes the three main protocols you can select to encrypt your SAs.
• Data Encryption Standard (DES)
• Advanced Encryption Standard (AES)
First standardized in 1977, DES should no longer be used. In a 1999 decryption challenge, 56-bit DES ciphertext was cracked in just over 22 hours by using an exhaustive key search. See the following URL for more details: http://www.rsasecurity.com/rsalabs/challenges/des3/.
Triple DES
Triple DES (3DES) essentially encrypts the data three times using DES and three different 56-bit keys. This is considered secure by most and comprises the majority of IPsec VPN deployments today. Although it depends on the type of VPN hardware you are using, 3DES has additional performance requirements for your VPN hardware compared to DES.
AES was ratified by the U.S. National Institute of Standards and Technology after a 4-year study to determine a suitable replacement to DES. It supports key sizes of 128, 192, and 256 bits as opposed to 56 bits for DES. It is defined in Federal Information Processing Standards (FIPS) publication 197. If your vendor is still using 3DES, you should make sure it has a short-term road map to AES support. AES is the new standard for data encryption and should be used instead of 3DES whenever possible.
Authentication/Integrity Protocol Selection
When using IKE/IPsec, you have a choice of two different hash mechanisms for authentication and integrity checks: the Secure Hash Algorithm (SHA) and message digest 5 (MD5). This is a simple choice: SHA-1 is 160-bit and MD5 is 128-bit. But because they operate in different ways, you can't just examine the number of bits to determine the security level. That being said, SHA-1 is considered more secure but more computationally intensive. Just like any other crypto function on an IPsec gateway, consider the performance penalty, if any, before opting for the more secure choice.
4 PREV
NEXT t
Continue reading here: Fragmentation and Path Maximum Transmission Unit Discovery
Was this article helpful?