Re: FreeBSD NAT-T patch integration
- From: "Bjoern A. Zeeb" <bzeeb-lists@xxxxxxxxxxxxxxxxxx>
- Date: Sat, 28 Jun 2008 18:49:10 +0000 (UTC)
Replying to the (randomly) last posting in this thread...
okay, as patience seems to be a problem with some people and I
do not want to say this on two fronts (public and internal)
here are my comments. Yes, they will not be what you expect
but seriously, as I said before in other contexts:
IPsec is about security and not features.
If you were worried about security you would have reviewed
this patch in detail before, maybe side by side with the RFCs
and contributed changes back to the author.
So basically I know the hands that are seriously thinking about
spending time on FreeBSD in-tree-IPsec in the not so distant
future and have done in the past. The ten fingers attached to
those hands are typing this email. I know others would really
like to but cannot find the timeshare. I know others but they
haven't yet committed themselves to anything but a hit-and-run
Why in the future and not now? Basically because it's my free time,
mostly evenings and weekends that I can spend on FreeBSD. If
you want to change that, talk to my employer who'll happily let
me work on FreeBSD if you pay for it;-) My current (private) project
is called ``jails'' and I'll finish this first. The next project is
IPsec again along with other security stuff and vimage reviews
that not many people have committed themselves to either but lots
of people crying for it.
Where is FreeBSD with IPsec?
I thought I'd say again what I said a few months back, which
was "in a very good position" but to get back to that it'll
take me a while. There are about a dozen serious PRs, lots of
them came in late after 7 because people did not test their things
after the transition, a batch of features, enhancements,
patches on new stuff, and probably even more of I cannot think
at the moment. I have 5 private (non public) `issues' about
IPsec on my private list in addition to all this.
IPsec is about security, so bug fixes first, then features.
So what about NAT-T, which has been around for not as long as
the jail patches I am working on at the moment?
A lot of you are talking about "I have done testing". Right,
good-good-scenario is what I get from the mails.
Some say "this is mandatory to connect to vendor XYZ". Screw
the vendor, if you have no NAT and still need it. I have (had)
IPsecs to those boxes, since ~2000, and didn't need it if
there was no NAT (why would I) - so please stop the
propaganda/marketing or give the full facts.
People ask about review. The reason it's not in (yet) is that
I haven't had enough time to do the close line-by-line review
and give all the feedback to Yvan. The reason for that, as I have
stated multiple times before, is the lack of contiguous time.
It needs to be contiguous - you cannot do this this Sunday and
Thursday evening again having fought 10 different fires in the
meantime. Why do I think this needs to be done?
IPsec is about security and not about features.
The current plan is (let me quote from a mail sent to Yvan
on June 13:
"Your patch will soon need more changes (due to FreeBSD changes)
and chances are good that if you don't do that step for HEAD but
force me to do it that you'll get the entire review."
So you know my plan on this now.
Some say "there are #ifdefs around the code - what's the problem
committing but not enabling'. If the project is going to ship
it, the project will have to maintain it, deal with the bugs,
possibly issue SAs if there is a serious bug, have to make sure
to keep ABI compatibilities for STABLE branches, ... that's a
lot more hands than only mine if it gets there, so do not ask
to screw others as well if you can avoid it.
"But it works" - yes it does, as long as everyone behaves.
You may find UDP packets eaten without any notice, you may
have experienced panics, you may have found it work on one machine
and not on the other, you may have tried to use it with FreeBSD
base user space *oops* does not work but your setkey, libipsec, ..
come from ipsec-tools anyway. You may.... Been there,...
These days I am absolutely no longer worried about missing #ifdefs,
style or other minor issues. What am I worried about? Go to line one,
After all this, let me say that the patch is good, else not that lot
of people would use it (though I bet a lot do without knowing how
and why;) and I really appreciate all the work done by Yvan and
possibly others the patch was based on.
But it's not finished yet. If you have read Yvan's mail this
gives you an initial list. I'd say there is more missing to the
RFCs and a bit more to FreeBSD and the line-by-line review but that's
nothing most of you would probably `need' when saying "it works
for me", "it works in our bundled software". That's why you have
So what's the moral of the story?
I have lately tried to explain to someone some aspects of what
"to care" means. So if you know what "to care" means - the moral
might be "If it's committed now - who cares?"
Maybe it's - if I have to read another two dozen mails in this
thread and another half a dozen internally it'll simply waste
another of my Saturday afternoons.
Bjoern A. Zeeb Stop bit received. Insert coin for new game.
freebsd-net@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"
- Prev by Date: Re: kern/125079: [ppp] host routes added by ppp with gateway flag (regression)
- Next by Date: Re: kern/125003: [gif] incorrect EtherIP header format.
- Previous by thread: Re: FreeBSD NAT-T patch integration
- Next by thread: Re: FreeBSD NAT-T patch integration