Date: Sat, 28 Jun 2008 17:57:56 -0700 From: "Kevin Oberman" <oberman@es.net> To: VANHULLEBUS Yvan <vanhu_bsd@zeninc.net> Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD NAT-T patch integration Message-ID: <20080629005756.4BA1B4500E@ptavv.es.net> In-Reply-To: Your message of "Sat, 28 Jun 2008 23:13:00 %2B0200." <20080628211300.GA3310@zen.inc>
next in thread | previous in thread | raw e-mail | index | archive | help
--==_Exmh_1214701076_59533P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Sat, 28 Jun 2008 23:13:00 +0200 > From: VANHULLEBUS Yvan <vanhu_bsd@zeninc.net> > 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. -- 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_1214701076_59533P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFIZt4Ukn3rs5h7N1ERApJOAKCRHsr7B6qizoPgXAoj9CTX01xFNgCfQ+Y8 nfj46S+au7AH71btVOXOYx8= =BONd -----END PGP SIGNATURE----- --==_Exmh_1214701076_59533P--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080629005756.4BA1B4500E>