Re: IPSec in 2.5 Kernel?

On 03/19/2003 10:33 AM, Ken Bantoft wrote in part:

k> [mast device] seems to be the best way to go from a technical
k> persepctive,

http://www.monmouth.com/~jsd/vpn/ipsec+routing/mast.htm

:-)

k> KLIPSv1 is, at best, an ugly hack.

Let's be careful here.  KLIPSv1 has strengths as well
as weaknesses.  It would be all-too-human for us to take
the strengths for granted and discuss the weaknesses,
but now would be a particularly good time to step back
and get some perspective.

Given a choice of:
  -- something that aims high and succeeds with a
few warts, versus
  -- something that aims low and is implemented
more cleanly,

... I would prefer the former.  I put KLIPSv1 in this
category.  It embodies some darn good ideas.  It
goes way beyond implementing the letter of the RFC
to address usability and scalability issues.

In particular, we can complain that the KLIPSv1
ipsec device does not perfectly conform to our
current vision of an ideal mast device -- but it
comes a lot closer thereto than anything else I've
seen!

To the limited extent I can figure out where the
"new kernel IPsec" venture is going, there's no
discernible evidence that usability and scalability
questions have even been asked, let alone addressed.
Maybe it will all work out nicely, but I'm worried.


On 03/19/2003 07:36 PM, Sandy Harris wrote:

s> ... the position of key kernel developers has
s> always been that they could not accept anything into the main
s> kernel tree that they weren't allowed to change.

But as Ken points out:

k> Nothing has stopped anyone from forking FreeS/WAN into something
k> like, say, Super FreeS/WAN, and including code that Hugh Daniel and
k> John Gilmour don't agree with - like NAT Traversal, and 1DES. I've
k> done it, you can do it, we can all do it.

Indeed!!!!

One could accept KLIPSv1 code or at least KLIPS ideas
and change them as much as desired.  So the can't-change
argument seems completely bogus to me.

Forking the code would have been sad but what is
apparently happening is much worse.

Starting from scratch, throwing away good ideas and
taking a large step backwards in terms of usability
and scalability seems bizarre and perverse.



 > >>I believe the mainline stuff supports some undesirable "features"
 > >>such as single DES encryption. That's OK, as long as Pluto won't
 > >>negotiate them. By making Pluto available, we may keep users away
 > >>from other daemons that will.

1) I just roll on the floor laughing when I see a
bunch of libertarians telling other people what
ciphers they can and cannot use.

2) I don't know whether to laugh or cry when I see
people use the 1DES issue as an argument against
FreeS/WAN.  It's a ridiculous argument.  Ken has
shown the correct way to deal with the issue!

 > if different distros pick different userland tools,
 > inter-op could be nothing shy of a nightmare.

That's where things are heading: porting KAME
userland tools.  Nightmare squared.

 > >>It is not enough to make Pluto run over 2.5 kernel IPsec.
 > >>The objective should be really good IPsec for the 2.6
 > >>kernel.
 > >
 > >Everyone agrees here.
 >
 > Yes.

I agree.

But are we moving in that direction, or the opposite?