IPsec Parameter Choice Rationales

转载 2016年08月30日 14:48:28


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, though many vendors don’t yet support them.

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: utilizing less processing per packet allows for more packets to 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. To be honest, when utilizing 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.


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.


1,首先增加Jenkisn插件 https://wiki.jenkins-ci.org/display/JENKINS/Extended+Choice+Parameter+plugin  需要安装...
  • e295166319
  • e295166319
  • 2017年01月04日 11:29
  • 5667

Jenkis 增加参数构建

1,首先增加Jenkisn插件https://wiki.jenkins-ci.org/display/JENKINS/Extended Choice Parameter plugin 直接在管理界面...
  • freewebsys
  • freewebsys
  • 2015年02月12日 08:34
  • 8137


IPSec(网络层):          IPSec在数据包三层头部(IP头部)和四层头部之间插入一个预定义的IPSec头部,对OSI上层协议数据提供保护。IPSec没有定义具体加密算法和散列函数,仅...
  • u010726042
  • u010726042
  • 2016年10月09日 18:23
  • 930


1.安装IPsec apt-get install openswan  ※安装过程中选择“不使用证明书” 2.编辑 /etc/ipsec.conf 文件,修改   (a). protos...
  • dotuian
  • dotuian
  • 2013年04月18日 12:31
  • 1519


认证方式就是采用AH头,加密方式就是采用ESP头 AH头结构 AH协议为IP通信提供数据源认证、数据完整性和反重播保证,它能保护通信免受篡改,但不能防止窃听,适合用于传输非机密数据。AH的工...
  • tantexian
  • tantexian
  • 2015年02月03日 13:13
  • 5076


本文出自 “见证成长” 博客,请务必保留此出处http://nanjingfm.blog.51cto.com/2121842/847244 NAT和ipsec本身是一对矛盾体,但是现...
  • dbcxxf
  • dbcxxf
  • 2017年05月25日 10:48
  • 381


本文档的Copyleft归yfydz所有,使用GPL发布,可以自由拷贝,转载,转载时请保持文档的完整性,严禁用于任何商业用途。 msn: yfydz_no1@hotmail.com 来源:http...
  • funtasty
  • funtasty
  • 2014年11月02日 17:19
  • 1344

Ubuntu12.04: 下载,编译Android2.6.29内核goldfish,将新编译的内核和镜像安装至模拟器

下载android goldfish内核源码,然后编译生成zImg,用新生成的内核和编译android4.0.1源码时产生的镜像加载至模拟器,并查看模拟器的内核版本验证是否加载成功。...
  • yanzi1225627
  • yanzi1225627
  • 2013年07月12日 20:01
  • 4666


IPSec数据流处理   数据流输入处理:   1)模块接收一个IP包;   2)如果IP包下一下协议proto=UDP&&port=500,绕过不处理,传给上层协议;   3)判断下一个协议prot...
  • dolphin98629
  • dolphin98629
  • 2014年02月20日 10:44
  • 794


场景1[+S=C]...[+S=C]=== [plain] view plaincopy ...
  • lanmolei814
  • lanmolei814
  • 2014年07月24日 10:16
  • 2053
您举报文章:IPsec Parameter Choice Rationales