Date: Mon, 21 Feb 2011 10:21:43 +0100 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: VANHULLEBUS Yvan <vanhu@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: <20110221092143.GA1766@garage.freebsd.pl> In-Reply-To: <20110221084025.GA14934@zeninc.net> References: <201102180940.p1I9eD29050530@svn.freebsd.org> <20110219073412.GC2016@garage.freebsd.pl> <20110221084025.GA14934@zeninc.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 >=20 > 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 > implementation... 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. >=20 > 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. >=20 > 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. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk1iLqcACgkQForvXbEpPzSbhQCgiVSd5DnMhjByrVMuh4cAYAfK VkQAnjk5E8n05GduiKG8Ij7xO4tmPzkd =65VV -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110221092143.GA1766>