Date: Mon, 21 Feb 2011 09:40:25 +0100 From: VANHULLEBUS Yvan <vanhu@FreeBSD.org> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r218794 - in head: . sys/netipsec Message-ID: <20110221084025.GA14934@zeninc.net> In-Reply-To: <20110219073412.GC2016@garage.freebsd.pl> References: <201102180940.p1I9eD29050530@svn.freebsd.org> <20110219073412.GC2016@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi. On Sat, Feb 19, 2011 at 08:34:12AM +0100, Pawel Jakub Dawidek wrote: > On Fri, Feb 18, 2011 at 09:40:13AM +0000, VANHULLEBUS Yvan wrote: > > Author: vanhu > > Date: Fri Feb 18 09:40:13 2011 > > New Revision: 218794 > > URL: http://svn.freebsd.org/changeset/base/218794 > > > > Log: > > Fixed IPsec's HMAC_SHA256-512 support to be RFC4868 compliant. > > This will break interoperability with all older versions of > > FreeBSD for those algorithms. > > > > Reviewed by: bz, gnn > > Obtained from: NETASQ > > MFC after: 1w > > First of all, I can't see such a change being merged to stable, where > going from 8.2 to 8.3 will break IPsec tunnels. No. It will break IPsec tunnels *which use HMAC_SHA2 for hash in phase2*. In the real world, we are still at the level where we're trying to make people understand that using an hash algorithm in phase2 is important. I just don't know if some people use actually HMAC_SHA2 for phase2, those who does really care about security and do really want HMAC_SHA2 will upgrade both peers, the others (including people that do know that HMAC_SHA1 is *not* as weak as SHA1 starts to be) will just have to switch back to HMAC_SHA1 until peer does support RFC4868. > Second of all I really think that an UPDATING entry is not enough. > We should at least provide sysctl to change it back I sent a mail on freebsd-net@ at the beginning of january, to ask some feedback from users, and got NO response at all. So I considered implementing such a sysctl would be just time waste. And it is also a quite bad solution, as it does not solves situations where you want to do IPsec using HMAC_SHA2 with two peers, one which is RFC4868 compliant, and the other which uses the old round-96 bits draft for it's implementation.... > and if we can detect > this based on packet size, Afaik, you can't. Well, of course, you can still try both RFC4868 and round96 bits hashs, and consider that the packet is valid if one of the checks is good.... Feel free to send me your benchmarks results if you do such an implementation... But what will you do if you have to send the first packet in the tunnel ? > it would be best to log a warning that the > other side is using old implementation and it (the other side) should be > either upgraded or this sysctl should be changed locally to enable old > behaviour. As said upper, afaik, you just can't detect such things without wasting LOTS of CPU cycles.... > I'm happy to remove such sysctl after one full major release, > so we won't support tunnels between FreeBSD 8 and FreeBSD 10, but we > should IMHO definitely support tunnels between both 8-9 and 9-10. The only thing you may do is to include again the old code and put some #ifdef RFC4868_SUPPORT / #else / #endif in kernel code, or set up a global sysctl (which will be quite intrusive for such a small patchset) so people will be able to decide if they want their whole IPsec stack to be RFC4868 or draft-round96 compliant.... But once again, this will NOT solve issues with multiple peers, and once again, the "simple" solution when you can't upgrade both peers is to switch back to HMAC_SHA1, which is actually really strong enough, and which is NOT affected by this patch. Yvan.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110221084025.GA14934>