From owner-freebsd-net@FreeBSD.ORG Sun Jun 29 20:06:46 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5C8D106567A for ; Sun, 29 Jun 2008 20:06:46 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outf.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id AC0938FC0C for ; Sun, 29 Jun 2008 20:06:46 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id B244423F1; Sun, 29 Jun 2008 13:06:53 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id E5F9B2D6004; Sun, 29 Jun 2008 13:06:45 -0700 (PDT) Message-ID: <4867EB67.1020900@elischer.org> Date: Sun, 29 Jun 2008 13:07:03 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Kevin Oberman References: <20080629005756.4BA1B4500E@ptavv.es.net> In-Reply-To: <20080629005756.4BA1B4500E@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, VANHULLEBUS Yvan Subject: Re: FreeBSD NAT-T patch integration X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2008 20:06:46 -0000 Kevin Oberman wrote: >> Date: Sat, 28 Jun 2008 23:13:00 +0200 >> From: VANHULLEBUS Yvan >> Sender: owner-freebsd-net@freebsd.org >> >> On Fri, Jun 27, 2008 at 11:06:19AM -0400, George V. Neville-Neil wrote: >>> At Thu, 26 Jun 2008 12:56:41 -0700, >>> julian wrote: >>>> I'm planning on committing it unless someone can provide a reason not >>>> to, as I've seen it working, needed it, and have not seen any bad >>>> byproducts. >>>> >>> I'd be interested to know how you tested it. >> I can answer that question: >> >> - We do have "non regression tests", which test every night that "it >> works" in a "good scenario", with a peers who runs quite the same >> kernel, with the same patch and the same userland. >> >> We do also some "bad scenarios" tests, but not as much as I would like >> actually (it's much more complex to test). >> >> >> - We do have THOUSANDS of customers who use it for years now. And >> customers are really not well nown to always generate "good >> scenarios".... >> >> Customers can do some mistakes, can use some very strange stacks for >> peers, can use a lots of other IPSec stacks for peers, can have *a >> lot* of peers (of course with various implementations, configurations, >> NAT or not, etc...) for the same gate, etc... >> >> And how do I know that it works ? >> Well, when it doesn't work, I do know it, quite quickly most of the >> time ! >> >> As Bjoern said in another mail, we're talking about security. >> Security is my job, security is what we provide to our customers, and >> even if some of our customers just don't understant what they do, some >> others do *really* understand things, and do *really* test devices, >> check if it works, and quickly reports us problems (and ask for quick >> solutions). >> >> >> >>> NAT-T and IPsec are >>> non-trivial protocols/subsystems that can have far reaching impacts on >>> the network stack. >> Yes. >> >> >>> Also, are you planning to maintain it after >>> committing it? >> I plan to do that. >> >> >>> The biggest problem with NAT-T hasn't been the code, >>> it's been that the author, >> Really ? >> >> >>> who is doing a great job on the code, >> Thank you.... >> >> >>> has >>> been too busy to maintain it anywhere but at work. >> That is not exact, and I'm really sorry if you understood that after >> our discussion at the last EuroBSDCon. >> >> First, you can check that I'm sending this mail on saturday evening, >> which is out of my work hours :-) >> >> Then I can for example confirm that I did the whole migration from >> RELENG6 to RELENG7 on my free time, just because I needed a working >> FreeBSD7 + NAT-T patch at home before I've been asked to do it at >> work. >> >> Yes, I'm doing most of IPSec / NAT-T stuff at work, but it is mainly >> because I'm *paid* for that !!! >> Let me tell this again: working on FreeBSD's IPSec stack (and on >> NAT-T, of course, adn also on ipsec-tools) is a part of my job. >> >> What I told you some months ago is that there are some things that I >> cannot really do at work, because it takes lot of time and because >> those things are more "code cleanups" than "new features" (we were >> talking about PFKey V2 cleanups related to NAT-T ports). >> >> >> And if I did not spend that time to do that cleanup, that's not >> because I don't have such time, that's because I was starting to >> fear that the patch may be never commited, so I wasn't sure to want to >> continue spending lots of time on a patch "for nothing". >> >> If Bjoern or you told me some months ago "do that cleanup and we'll >> commit the patch", it would already have been done, and we would have >> *all* saved some time ! >> >> >> And yes, I do also spend some parts of my free time on things that are >> not related to FreeBSD's IPSec (and, to be completely honest, on >> things which are not related at all to computers....). >> >> >> >>> That is not a slam >>> on the person or the code, I have the highest respect for both, but it >>> reflects and important reality of the situation. >> I feel that "the reality of the situation" is that FreeBSD's IPSec >> stack needs more people *working on it*, not more people wasting their >> time about why some work should or shouldn't be reported. >> >> That is not a slam on the persons who are still working on the IPsec >> stack, I have the highest respect for them, but it reflects an >> important reality of the situation... >> >> >> >>> Unless you're >>> stepping up to maintain it as well as commit it I think it should not >>> be committed. I know the Bjoern has been working hard to pick up the >>> IPsec stuff in his free time, and I value his input on this subject >>> quite a bit. >> You said it yourself: actually, FreeBSD's IPSec stack is just >> maintained by one person, which worked hard on it, which does a great >> job on it, but which can spend only some parts of his free time on it. >> >> That is a problem. >> Of course, the solution can NOT be to ask Bjoern to spend more time on >> it (well, Bjoern, do that if you want :-). >> >> The only other solution I see is to find a way to help people who want >> to help you.... > > Thanks so much to folks like Bjorn and Yvan who spend the time to do > some tough jobs like dealing with IPsec and being stubborn about > committing things to security tools without very careful audit. > > In case you missed it, IPsec is about security, not features. And, in > case you have never been involved in real security or crypto, security > is really, really hard. > > No, no, it's much harder than that! > > While I'd love to see NAT-T, until someone who knows EXACTLY what the > IPsec and NAT-T code is doing and what it is required to do can do the > line by line review, it should NOT be committed. so, you don't think that this is rather a slap in teh face of the person who wrote this, and who's job is to do security related work in a proffesional context? "This requires a someone who knows what they are doing, and despite the fact that you do this for a living, I arbitrarlily exclude you from that category"?