On the previous episode of As The IPsec Tunnel Churns, we discussed how IPsec configurations running in tunnel mode are established. This week, let’s get into the nitty gritty of why those parameters were chosen. So, why did we choose those particular parameters?
The answer is simple: speed and security. Certain options increase security, and certain options increase speed. Note that something that decreases security doesn’t necessarily increase speed — these are two separate and independent metrics.
Hash Algorithm: HMAC-SHA1
Hashing algorithms are for verifying data integrity, not encryption. This is important for secure communications. You want to make sure the packet you sent is the packet that arrived.
Without hashing, a nefarious party could throw a bunch of garbage into your packets and there’d be no way of knowing — even if your data is encrypted. On the public internet, “nefarious parties” could be anyone that could theoretically view the data stream. These days, that list could be endless; your transit providers, any state agencies with taps into transit networks, hackers who have secured access to routing and switching equipment, or even employees with or without ill intent.
A correctly implemented hash can negate this threat. A hash is simply a mathematical operation that runs on a dataset (in this case, a single IP packet) and generates a unique string. When it arrives at its destination, the hash is re-run. If the packet is changed in transit, the resulting hash will no longer match the computed value. Hashes are designed so that even tiny changes in a packet will radically alter the hash, and are extremely difficult (if not impossible) to reverse engineer.
The two common hashing options for IPsec are MD5 and SHA1.
IPsec tunnels use keyed-hash message authentication code (HMAC) versions of these algorithms. While vanilla MD5 has been proven broken, HMAC-MD5 is still considered secure. SHA1 is considered even more secure, at the cost of some computational overhead (i.e., it’s slower than MD5). Given phase 1 is focused more on security, we opt for the slower but more secure SHA1.
Note that you can set hashing to NONE. Never use this — it’s only included in the IPsec standard as a testing mechanism. This disables hashing (and at that point, you may as well not even bother with an IPsec tunnel).
Newer hashing options include SHA variations with larger bits, such as SHA-256, SHA-384, and SHA-512. They’re also a viable option.
Encryption Algorithm: AES256
There are a number of algorithms for encrypting traffic. Data Encryption Standard (DES) used to be the standard. While simple and fast, it was easily broken, and became obsolete in 1999. Triple DES (3DES) came in to replace it and is still in use today, but it’s terribly slow. Though these encryption algorithms can still can be used, they are highly discouraged. Instead, more modern algorithms should be used, particularly the Advanced Encryption Standard (AES) suite. Not only is AES far faster than 3DES, it’s also considered more secure. Another bonus: AES is hardware-accelerated on a wide variety of processors, making it even quicker while using less processing power.
Remember: using less processing per packet lets more packets be encrypted, which translates into increased throughput.
AES comes in a number of key size variants, starting at AES128. AES128 is considered to be secure today and for the foreseeable future.
Note: AES256 is even more secure, but the additional security afforded by jumping to 256 bits is similar to comparing the thickness of two pieces of paper: it’s there, but for all practical purposes there’s no difference. Also, AES256 is logically slower than AES128.
Key lifetime: 86400 seconds
Key lifetime is an interesting parameter. For one, you can forgo timing altogether and set it as a byte count — once x amount of bytes has been processed through the tunnel, it will renegotiate. However, most people use timing instead of byte counts.
When using a decent hashing and encryption method, any key life under 24 hours is more than adequate, as no one will be able to brute force your key in that amount of time.
You could even set it to as long as months (if your hardware supported it), but as we’re concerned with security and not performance in phase 1, 24 hours is acceptable.
Pre-shared key: k2;2.6TbYl+{/qa
Although certificates can be used and are more secure, no one ever wants to go through the hassle of setting up a key infrastructure dedicated to IPsec usage. Therefore, it’s important to pick a pre-shared key that’s relatively secure; this means no dictionary words, at least a few symbols, a few numbers, and a minimum of 15 characters.
The Diffie-Hellman key exchange may be secure, but it’s not going to matter if your pre-shared key is 12345.
Another note: don’t use the same pre-shared key across different phase 1 configurations. That’s just bad practice.
Pre-shared keys, no matter their length, have no effect on performance. It should be obvious that you should never share the PSK with anyone. When using certificates you can verify the remote side via a third party, but with PSKs, your only source of verification is the fact that no one else should know the key. If anyone else is aware of the PSK, you are vulnerable to a man-in-the-middle attack.
Mode: main
Phase 1 can operate in two modes: main or aggressive. In main mode, IKE negotiations occur in three sets of packet exchanges, with the last verification exchange occurring over an encrypted channel. Aggressive reduces the amount of cross-talk between endpoints by cramming all the parts of the phase 1 negotiation up until the final part of the DH key exchange into one packet. This will pass some normally encrypted parts in the clear; though these parts aren’t considered vital, we opt for main mode since we phase 1 is focused more on security rather than quick negotiations.
So there you have it – Alpha and Beta now have a phase 1 security association active and can move on to phase 2.
Phase 2
As mentioned before, phase 2 does the actual authentication and encryption of data across the tunnel. On modern hardware, certain options can shave off a few milliseconds per packet. While that may not sound like a lot, consider that a small to moderately used IPsec tunnel will be encrypting and decrypting 13,000 packets per second; tiny increases in hashing/encryption/decryption speed will have large effects on throughput. We therefore want the fastest IPsec algorithms we can implement without compromising security.
Hash Algorithm: HMAC-MD5
HMAC-MD5 is quite a bit speedier versus HMAC-SHA1 and still secure. NONE would be the fastest, but completely defeats the purpose of an IPsec tunnel.
Encryption Algorithm: AES128
AES is faster and more secure than DES, 3DES, and Blowfish (and its updated variant, Twofish). Neither is well supported in most vendor hardware. AES256 doesn’t add much in terms of security and comes with a speed penalty, so AES128 it is.
Key lifetime: 43200 seconds
This refers to the phase 2 security association key life, which is independent of the phase 1 security association key life. Given far more data is being encrypted using the phase 2 parameters, this can lead to a nefarious third party gathering a much larger data corpus of your encrypted packets for analysis. That said, MD5/AES128 is still impossible to brute force, so setting this depends on the data you’re securing and how secure you want it to be. If you don’t care about the transiting data after it arrives, you can set the key life to something quite long (though best practices state you should make it shorter than the phase 1 key life). If you care about someone pulling your packets offline and attempting to brute force them, you may way to set the key life to something quite short. They would still need a machine that is unfeasible to create now and in the future.
Keep in mind that every time the key life expires and phase 2 renegotiation starts, packets will be queued up and possibly dropped (if the renegotiation is slow) until it completes. Renegotiations are fairly quick (on the order of 1-2 seconds), but that’s still something to be aware of. Therefore, for performance reasons and to keep potential interruptions to a minimum, we keep the key life relatively long.
Perfect Forward Secrecy: disabled
Perfect Forward Secrecy (PFS) is a phase 2 specific configuration option. What this does is ensure that no phase 2 security association keys are derived from the same phase 1 security associations. While more secure for the very paranoid, this will cause phase 1 renegotiations whenever phase 2 keys expire. Not only are you subjected to phase 2 SA renegotiation delays, but those are compounded as the phase 1 SAs are also renegotiated. In certain other encryption situations such as TLS/SSL, PFS is very important. For IPsec, the benefit is minimal unless you’re using poor pre-shared keys combined with bad encryption methods.
Results
On our Juniper SRX 650s with optimal IPsec configurations, we can saturate a 1-gigabit port. Switching to SHA1/3DES with extremely short key lives and Perfect Forward Secrecy enabled (group 14) drops throughput to half that, as the tunnels are constantly renegotiating with inefficient hashing and encryption algorithms. Torturing the processors by sending a large number of tiny packets kills throughput to a quarter of what we can do.
So, when creating IPsec tunnels, don’t just accept the defaults, many of which are woefully bad choices.
Understand what the parameters are and make informed decisions to maximize your existing infrastructure’s performance.
Next up, the final part of our IPsec overview: why using IPsec configurations to handle your routing is a terrible idea, and the proper way to do it.
