From owner-freebsd-net@FreeBSD.ORG Sun Jun 29 20:32:39 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 6622F106566C for ; Sun, 29 Jun 2008 20:32:39 +0000 (UTC) (envelope-from oberman@es.net) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.freebsd.org (Postfix) with ESMTP id 487688FC0A for ; Sun, 29 Jun 2008 20:32:39 +0000 (UTC) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id JAJ06637; Sun, 29 Jun 2008 13:32:37 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 78F6245047; Sun, 29 Jun 2008 13:32:36 -0700 (PDT) To: Julian Elischer In-Reply-To: Your message of "Sun, 29 Jun 2008 13:07:03 PDT." <4867EB67.1020900@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1214771556_77486P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sun, 29 Jun 2008 13:32:36 -0700 From: "Kevin Oberman" Message-Id: <20080629203236.78F6245047@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; ; ; X-Sender: X-To_Name: Julian Elischer X-To_Domain: elischer.org X-To: Julian Elischer X-To_Email: julian@elischer.org X-To_Alias: julian 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:32:39 -0000 --==_Exmh_1214771556_77486P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Sun, 29 Jun 2008 13:07:03 -0700 > From: Julian Elischer > Sender: owner-freebsd-net@freebsd.org > > 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"? Not at all. No one should both write and vet security code. It takes two pairs of eyes connected to two brains to write and check code. I don't care how competent the programmer. This is a good rule for all code, but is too "expensive" for most code. Can you imagine how few updates would ever be checked in if every one needed a line-by-line vetting before a commit was allowed? Security code really an exception. It simply has to be right and I heartily approve of the care being taken by both Bjorn and Yvan. I feel both are doing exactly the right thing, much as I'd with they could do it faster. This is how you avoid potential disasters like the recent Debian openssh screw-up. (Just a small change that looked fine, but broke security done by a single programmer and never vetted). -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1214771556_77486P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFIZ/Fkkn3rs5h7N1ERAjS2AKCPhIDpbHgm75abb+mnPSJgm8TBAACghovp pizJSf/Tmn+Ez2t3Ly62r7w= =sPsb -----END PGP SIGNATURE----- --==_Exmh_1214771556_77486P--