From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: IPsec: Default to rekey=no Date: Tue, 19 May 2015 18:06:01 +0200 Message-ID: <1432051561.16602.65.camel@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6665408587267996392==" List-Id: --===============6665408587267996392== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-05-19 at 17:56 +0200, Larsen wrote: > If I understand it corretly, adding "rekey=3Dno" only disables the server = > trying to rekey, so this is left to the client and should not be a =20 > security problem therefore. Yes, the client may still trigger creating a new child sa. I just wouldn't trust the client to do that. > If this is not added, clients behind a NAT will experience an interruption = =20 > in their vpn connection. I think this depends on the lifetime of something = =20 > (ikelifetime? keylifetime?). Anyhow, as long as the server tries to rekey, = =20 > the connection will be disturbed. > In the end, the user might not use IPsec anymore because of that. Of course the usability would be worse. But I am sure that security is coming first. IPsec has always had these woes. That is the main reason why those awful SSL VPN solutions exist. > Lars >=20 >=20 >=20 > On Tue, 19 May 2015 17:45:52 +0200, Michael Tremer =20 > wrote: >=20 > > Hi, > > > > obviously we cannot make this as a default option for anything. The > > rekeying is a very important process in the security of a VPN. Without > > that brute-force attacks are getting much more feasible and if they > > succeed all the data that has been transferred in this session can be > > decrypted afterwards. > > > > The link that you provided does at no point say that disabling rekeying > > is a recommended strategy to do that. It just points out some issues and > > incompatibilities with the Windows client. > > > > I CCed Wolfgang Apolinarski who recently worked on this whole matter. He > > seems to use the rekey=3Dno option, too. Maybe he can contribute some > > insight why this is needed from his point of view. > > > > Best, > > -Michael > > > > On Tue, 2015-05-19 at 17:19 +0200, Larsen wrote: > >> Hi, > >> > >> we noticed interruptions with our IPsec roadwarrriors. The problem =20 > >> turned > >> out to be caused by the server trying to rekey with the client that is > >> sitting behind a NAT (Windows 7 client at colleague's home). See > >> https://wiki.strongswan.org/projects/strongswan/wiki/Windows7#Rekeying-b= ehavior > >> > >> This was solved by adding "rekey=3Dno" to "/etc/ipsec.user.conf" for each > >> connection. > >> I wonder if this should be added by IPFire by default as I guess that =20 > >> all > >> roadwarriors behind a NAT (probably the majority) might have this =20 > >> problem. > >> > >> So, adding > >> print CONF "\trekey=3Dno\n"; > >> to > >> /srv/web/ipfire/cgi-bin/vpnmain.cgi > >> > >> > >> Lars > >> _______________________________________________ > >> Development mailing list > >> Development(a)lists.ipfire.org > >> http://lists.ipfire.org/mailman/listinfo/development --===============6665408587267996392== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjIKCmlRSWNCQUFC Q2dBR0JRSlZXMTlyQUFvSkVJQjU4UDl2a0FrSGd6a1AvMnh1QUtNSEY4RGg5L3RicHpndm5UY1YK Ui9GajZYNFZQbk9rU1FkYzZpU1draUtZcFdWWDRIUTI3eFFPdC8yY1ZVeXRXc09Ibk53bDFhc3ZS dnBuTyt3QQpXNllqVnZnc09pRXhBSjlhTE1ZcnA3aU9tUEtwNnNHVGZZd21MOGZxOEcvdTlmT2F6 Mll1blUvcWRKdXZVMCtKCmxhcys2cnZkYnFORFVmcTRHdWY5WXlNVlpKamFzY2k4eTZjL3czZVpY NWVzVW1VMEJGSEVTZ1FyU0Y2K1pzNmoKRjc4djRLYUhBNTBqMmJ2bVlhUjJXU3d1VUw0WHMzRU9L NklDQjdDY2dIWVdvM1N3dmpPR1NqaVJta3FsUUd1VwpTakYzd2haRlNhN1FoYTdRVWkxZXVCczcx NStZcDNOTUI5MnhaY0swelhBci96YlVpSDJKOVNhTHZvRzZTeGRFClBkUU1PdlRCOElmZ2FNeEpP c1dWNE96dEV1Rm9VaU83UG1HKzdWUmZvaVcwZWUvMGpVVkJvRTI2ZGpEQnhYU0oKYXFSU1hESCsz cEtsL04yYmYySElraHZKeUZyQldrSHB1TGJnNFEvSjh5RFVYcENMSTg4MEVSbHUwd0xYMHNtVQo1 TTk5cEx3VUlRRFg3dDhTYnRDWklnZFhOck9sS2hxUlhESzJKS3NldmxzZDUrZWpRcGRaa01ZNTJY enRsWTZ2CkFpbXBzd3IyREJWMGFnNERlK0xkWFlVa08wTm1xRVV2eGFOMnhuNDV0NkhOamR6Z2FH dUZDWElxOGtabm1CcjcKaFB4MWVTL1JRL2tJTkxjVE8ra2M2ZFNGbWxrTWtXN1I0SCtXUmJIUiti Y2x5alM1TldFRFNVQkhMazFxU1kzRApEUVk4c3hjK21pdUhMNjNKNjVTQgo9Qys1aQotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0K --===============6665408587267996392==--