Date: Sun, 29 Jun 2008 13:07:03 -0700 From: Julian Elischer <julian@elischer.org> To: Kevin Oberman <oberman@es.net> Cc: freebsd-net@freebsd.org, VANHULLEBUS Yvan <vanhu_bsd@zeninc.net> Subject: Re: FreeBSD NAT-T patch integration Message-ID: <4867EB67.1020900@elischer.org> In-Reply-To: <20080629005756.4BA1B4500E@ptavv.es.net> References: <20080629005756.4BA1B4500E@ptavv.es.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Kevin Oberman wrote: >> 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. 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"?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4867EB67.1020900>