Bug 10396

Essentially, this is working fine over here:

> Conn1[1972]: ESTABLISHED 10 seconds ago, 1.2.3.4[...]...5.6.7.8[...]
> Conn1[1972]: IKEv2 SPIs: fb735b3dbc49891e_i* e361b5741d611eae_r, public key reauthentication in 2 hours
> Conn1[1972]: IKE proposal: AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_8192
> Conn1{11120}:  INSTALLED, TUNNEL, ESP SPIs: cf3f153f_i cf81292a_o, IPCOMP CPIs: c24d_i b3ab_o
> Conn1{11120}:  AES_CBC_256/HMAC_SHA2_512_256, 361 bytes_i (4 pkts, 6s ago), 649 bytes_o (5 pkts, 3s ago), rekeying in 42 minutes
> Conn1{11120}:   192.168.180.0/24 === 192.168.160.0/22 

The problem with that long primes is that it is very costly to find a prime number of that size. Getting enough random data for the key exchange takes a while and therefore, establishing the connection looks like this:

> initiating IKE_SA Conn1[1972] to 5.6.7.8
> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
> sending packet: from 1.2.3.4[500] to 5.6.7.8[500] (1244 bytes)
> retransmit 1 of request with message ID 0
> sending packet: from 1.2.3.4[500] to 5.6.7.8[500] (1244 bytes)
> retransmit 2 of request with message ID 0
> sending packet: from 1.2.3.4[500] to 5.6.7.8[500] (1244 bytes)
> received packet: from 5.6.7.8[500] to 1.2.3.4[500] (1313 bytes)
> parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ]

The host that established the connection itself takes a while to generate the random "key". It then sends a packet and the other host starts generating the key, which takes a while. During that time, the first host retransmits the packet several times until it gets the reply.
It is well possible that this process times out on hosts where it is very hard to get random data at all.

A suitable workaround is to use smaller keys with which the negotiation will be a lot faster.

We'll ship support for Elliptic Curve DH (ECP) for IPsec in Core Update 72, which uses much smaller keys, but with the same level of security as MODP with longer keys.

http://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=26dfc86a7be473138c60e1a869e51b30db346a0f

Thanks for that clarification, Michael. Would it still make sense to change the GUI defaults to not use the long keys by default? I am presuming that they will need to be retained for compatibility.

Yeah, we should consider reverting the defaults. Using ECC would be the best regarding the key lengths, but I don't know how many endpoints support that already.

Thanks for your sharing your experience on this.

That's exactly my concern. I am still in the process of converting our existing Endian Community Edition Firewalls with IPFire installs, and EFW does not support ECC. 

Perhaps a default selection similar to the current one, minus 8192, plus a usage note on the advanced page that explains which options are "best" for different scenarios (security/performance/compatibility)?

http://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=aea35c5aca126e10d6aeb803b5c929b136ca9f97

I, for one, heartily approve. Thank you for all of the work on this, Michael.

Now to read up on all of these settings to figure out if I am using the right combination for my needs...

As long as the VPN connection is working everything's fine.

We do not have any broken or easy to crack encryption or hashing algorithms on there, so almost any option is "safe". Try to avoid 3DES and MD5 though.

The higher an algorithm in a list, the better the security.

Michael: Thanks for the inclusion of ECP, it is up and seems to be working fine on 20 tunnels!

I thought I might post a link here that I found, which seems to indicate which key sizes should be used. Specifically, note the first table, which indicates the recommended MODP/ECP key sizes based on a given DES/AES symmetric key size. I was surprised to see that the recommended MODP key size is 7680 if you are using AES-192, and this might indicate that AES-256 and AES-192 should be excluded from the defaults until ECP is common enough to use in the default settings?

Anyhow, I thought this information might be helpful in the future if you ever need to revisit the GUI defaults again.

http://www.nsa.gov/business/programs/elliptic_curve.shtml

You cannot compare those two that easy. They are encrypting data over here, which is not the same as exchanging a key.

If you use AES with your IPsec connection, the actual data is encrypted with a symmetric key. Both parties need to have that key, so there is need to generate is on one host and "transfer" it to the other. Obviously, this cannot be done in cleartext, because someone could intercept that and replace the key or just use it to decrypt the encrypted data.
Therefore we have IKE, which does the key-transfer job. It will connect to the other peer and establish a secure channel over which the symmetric (ESP) key is transferred. For that, asymmetric cryptography is used. This is either using the Diffie-Hellman key exchange or using ECC. Over this channel, only management information is exchanged, but no data.

Why is it this complicated? Using asymmetric cryptography sounds like a viable technique to communicate. It is, but at the same time, it is computationally costly. You can see in one of the tables of the linked post, that you need 64 times more time to encrypt/decrypt a single chunk of data compared to symmetric algorithms. So back in the days, when we didn't have so much power in our routers, this was not feasible doing. Hence the symmetric cryptography.

As a conclusion, those two don't depend too much on each other. Of course it doesn't make sense to use AES-256 and then exchange that key over a connection that is weakly secured. So if you can, pick the best algorithms you can possibly use.

I don't think that we will see many IPsec appliances supporting ECP very soon, so it may take a long time until ECP becomes the default setting in IPFire. But if you are creating VPN connections between two IPFire systems, you are ready to use it and you should do so!

Thanks for the details, Michael. Hopefully other firewall distributions can be brought along to support ECP. 

I have indeed switched over to Core 72 and ECP on all but one of our tunnels (that device is still running Endian, for now). It is refreshing to see the active development that goes on with IPFire (a major reason we chose it, in fact), so keep up the good work!