FreeBSD NAT-T patch integration

[Kevin Oberman]

> Date: Sun, 29 Jun 2008 13:07:03 -0700
> From: Julian Elischer <julian at elischer.org>
> Sender: owner-freebsd-net at freebsd.org
> 
> Kevin Oberman wrote:
> >> Date: Sat, 28 Jun 2008 23:13:00 +0200
> >> From: VANHULLEBUS Yvan <vanhu_bsd at zeninc.net>
> >> Sender: owner-freebsd-net at 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 at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 224 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080629/a1d162c4/attachment.pgp