svn commit: r218794 - in head: . sys/netipsec
vanhu at FreeBSD.org
Mon Feb 21 08:58:39 UTC 2011
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.
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
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
Feel free to send me your benchmarks results if you do such an
But what will you do if you have to send the first packet in the
> 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
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.
More information about the svn-src-all