Re: AW: IPsec: Default to rekey=no

Re: AW: IPsec: Default to rekey=no

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 3532 bytes --]

Hi,

On Tue, 2015-05-19 at 20:08 +0200, Wolfgang Apolinarski wrote:
> Hi!
> 
> I first want to say that I do not like the standard configuration of ipsec in 
> ipfire, because I am mainly using Windows and Android clients (phone/PC) and 
> the standard configs just do not work with that. This is why I added some 
> configuration templates to the ipfire wiki (which are mostly taken from the 
> Strongswan docu with some added information specific to ipfire).

Indeed is it quite complicated to have one generic configuration for
both, the net-to-net connections and all roadwarrior connections. We
will get in inter-operability hell. Luckily this has become much better
with strongswan.

> When rekey is set to no, the server does not initiate any rekey, which is 
> mandatory for Windows, because Windows does not like the server to take the 
> initiative. Windows clients are initiating the rekey every 58-59 minutes 
> (according to the strongswan docu, I did not check that in the logs).
> 
> There is (at least one) other alternatives than rekey=no:
> Set the lifetime of the child SA to something like 90 minutes. Then Windows 
> clients initiate the rekey after 58-59 minutes and rekey can be set to yes.
> 
> One could also set rekey=no, but fix the lifetime of the CHILD_SA. The 
> CHILD_SA is then thrown away and the client needs to rekey (and apparently 
> does so). If I understand the strongswan docu [1] correctly, the default is 
> set to 1h (attention to the margin!) and should also be used when rekey=no. So 
> rekey=no is a safe setting, security wise (someone should test this behavior, 
> though).

I can live with either of those two options. If we find a way that we
can kill the connection when the client does not rekey in a certain time
that we get rid of the need to rely on the client to rekey. We cannot
trust that the client will do this.

There is also a related bug over here:
  https://wiki.strongswan.org/issues/945

This one points out that rekey=no is different for IKEv1 and IKEv2.

> If connecting two ipfire devices via ipsec is one of the user scenarios that 
> should be supported, a default setting of rekey=no might not make sense since 
> both ipfire devices would not rekey, i.e., the connection would be dropped. A 
> longer CHILD_SA lifetime could be an alternative.

There is no need to have rekey=no for the net-to-net connections.

> What is on my whish list:
> An option menu when creating a new ipsec vpn connection that offers specific 
> configurations (Windows 7 (X.509 Machine Auth), Windows Phone (X.509 User Auth 
> over EAP-TLS), Android (IKEV1, X.509, xauth)).
> I did not add this, because of a) time and b) my weird configuration that uses 
> the ipfire DHCP and ends the tunnel directly in the green network (which - 
> from what I understood while reading the old documentation - is not the normal 
> configuration).

I too have a very long wishlist with IPsec features. More authentication
methods to enhance compatibility with more mobile devices is definitely
on the list, but also tough to realise if you do not have a central user
management system.

> > On Tue, 19 May 2015 18:06:06 +0200, Michael Tremer
> > <michael.tremer(a)ipfire.org> wrote:
> (...)
> > IPsec has always had these woes. That is the main reason why those awful
> > SSL VPN solutions exist.
> 
> Yes! :-)
> 
> Cheers,
> Wolfgang
> 
> [1] https://wiki.strongswan.org/projects/strongswan/wiki/ExpiryRekey

-Michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]