From owner-svn-src-head@FreeBSD.ORG Mon Feb 21 10:35:07 2011 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A195C1065674; Mon, 21 Feb 2011 10:35:07 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 46A9C8FC13; Mon, 21 Feb 2011 10:35:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id A480D41C7A6; Mon, 21 Feb 2011 11:35:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id xxD9WA2w8VfQ; Mon, 21 Feb 2011 11:35:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id BF4DB41C7B7; Mon, 21 Feb 2011 11:35:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 54B694448F3; Mon, 21 Feb 2011 10:30:26 +0000 (UTC) Date: Mon, 21 Feb 2011 10:30:26 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Pawel Jakub Dawidek In-Reply-To: <20110221092143.GA1766@garage.freebsd.pl> Message-ID: <20110221100635.F13400@maildrop.int.zabbadoz.net> References: <201102180940.p1I9eD29050530@svn.freebsd.org> <20110219073412.GC2016@garage.freebsd.pl> <20110221084025.GA14934@zeninc.net> <20110221092143.GA1766@garage.freebsd.pl> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@freebsd.org, VANHULLEBUS Yvan , src-committers@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r218794 - in head: . sys/netipsec X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 10:35:07 -0000 On Mon, 21 Feb 2011, Pawel Jakub Dawidek wrote: Hi, > 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. So let me hijack this one. I am not sure about merging it either but frankly it doesn't matter much if you go from 8.2->8.3 with your custom kernels (you have to build them anyway as IPSEC is not in GENERIC) and the UPDATING note is in place so you have the heads up, or eventually going from 7.x or 8.x to 9.x and hit the same problem. The fact that we still need to do it now rather than doing years ago is the real problem and we have lots of similar issues in other areas where we have excellent state of the art draft code but not final or updated RFC updates and we'll see these kinds of situations a lot more in the future also for GENERIC features. That said doing the full hash and if it fails checking the truncated is what I consider (by design) bad magic in security and as Yvan had pointed out doesn't help if you are the initiator but only if you are the responder (not even thinking about possible security implications yet). I think the counter is actually the right thing rather than spitting log() messages per packet on the console for those kinds of things. netstat -s is un underutilized debugging tool unfortunately. Educating users is what needs to be done (in addition to fixing more counters). The longer we are going to stay on the earlier version though the more likely we will run into interop problems with other stacks no matter what. Having been through this pros and cons before during the review I convinced myself that we'll eventually have to bite the bullet -- so rather now than later. That said if you can come up with a clean solution that will work in all cases I am happy to hear that. Adding a single global sysctl or compile time option to avoid POLA problems for the MFC is probably the thing I could be talked into with clear mentioning in NOTES/man page that it'll be gone from 9. That said a sysctl is probably the most user friendly given that they can update all kernels and then switch the sysctls with all peers, flush and be done w/o reboot or anything. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family.