Date: Sat, 28 Jun 2008 23:13:00 +0200 From: VANHULLEBUS Yvan <vanhu_bsd@zeninc.net> To: freebsd-net@freebsd.org Subject: Re: FreeBSD NAT-T patch integration Message-ID: <20080628211300.GA3310@zen.inc> In-Reply-To: <m24p7edij8.wl%gnn@neville-neil.com> References: <48ca67dd60c19f94b4f21bbe88854da7@localhost> <86c7b60b19e63e9188701611ac0f6f17@localhost> <4863F479.8010206@elischer.org> <m24p7edij8.wl%gnn@neville-neil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.... Yvan. -- NETASQ http://www.netasq.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080628211300.GA3310>