svn commit: r218794 - in head: . sys/netipsec
Pawel Jakub Dawidek
pjd at FreeBSD.org
Mon Feb 21 09:22:11 UTC 2011
On Mon, Feb 21, 2011 at 09:40:25AM +0100, VANHULLEBUS Yvan wrote:
> > 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....
You can't talk to two such peers with sysctl or without anyway. I assume
that if someone already has tunnels configured and they work, they work,
because the other end uses 96 bits hashes. Once he upgrades there is no
way to get old behaviour back quickly.
You are changing on-the-wire protocol in the middle of stable branch. Am
I alone in thinking that this is bad idea?
I'm not saying using larger hash is wrong. Quite the opposite.
I actually implemented this for a customer, but never got around merging
it to FreeBSD, because of the on-the-wire protocol change.
Imagine a situation where someone does upgrade from 8.2 to 8.3 one of
his IPsec machines. Tunnels stop to work. How can he tell what went
wrong? We don't even log hash mismatches, we only bump some counter.
This is not user-friendly. Situations like that make people angry and
make them want to use FreeBSD a little bit less.
> Feel free to send me your benchmarks results if you do such an
I'm sorry, but is really lame way to deal with criticism.
> > 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....
Well, checking two hashes isn't really so time consuming. The hash is
only truncated, so if you calculate a larger one you also have smaller
one to compare. Even better, in common case the larger one will simply
match and you have no additional overhead whatsoever. Having said that,
I don't think this is the right solution. We want larger hash to be more
secure and falling back to smaller hash defeats this goal and there is
also the problem when we are initiator.
Hmm, although on hash mismatch we could try comparing smaller hash and
if it matches discard the packet, but log a warning that the other end
is using unsupported, 96 bits hash.
> > 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....
Small patchset in what sense? In terms of diff size, yes, but because
you change on-the-wire protocol I think the impact is not small at all.
> 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.
The "multiple peers issue" is no a valid argument, as I said, because we
can't handle those anyway in any case. I'm happy that we tell users to
switch to HMAC/SHA1, but we currently don't do that. No warning is
logged, for example.
All in all, I don't really feel convinced. If nobody supports my
concerns, I'll let go sysctl addition, but I'd still strongly recommend
not to MFC this change to stable/8.
Pawel Jakub Dawidek http://www.wheelsystems.com
pjd at FreeBSD.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-all/attachments/20110221/2088a401/attachment.pgp
More information about the svn-src-all