Re: IPSec in 2.5 Kernel?

"John S. Denker" <[email protected]> writes:

> 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.

Then you haven't been paying attenion.  Either that
or you have a very warped view of "usability and
scalability".  Knowing what I know about you, I think
it's probably the former rather than the later, but
I could be wrong.

FreeS/WAN has a lot of problems, both architecturally
as well as the implementation.  Sure, it does a lot
of things well, but there are a lot of things it does not
do well.  Frankly, it's _not_ integrated, and this is
a major problem.

With frees/wan you cannot set fine-grained policy.
You cannot set a per-socket policy.  You cannot use
certificates (except with the super-free/swan code).
You don't get 2401-compliant inbound packet processing
(which means that someone can insert traffic into your
VPN).  You cannot even have multiple interfaces with
the same IP Address, let alone successfully route
packets after IPsec processing unless you want to
"route it to the next-hop".

John, I highly suggest you actually look at the code
and learn what the linux-2.5 stack can do before you
go making gross assumptions of what can or cannot
be done.  Making statements about scalability and
usability .......  *shakes head*

> 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.

Hey, the frees/wan people did it to themselves, and
there is nobody to blame but then.  Could the kernel
developers have forked the code?  Sure.  But then
the code would have diverged due to the unwillingness
to accept patches, and frankly that's just as bad.
At least now everyone can work on it.

Besides, the klips code needed to be re-written,
badly.  So, once you acknowledge that klips needed
to be redone, what's left?  Pluto?  Well, pluto
just uses pfkey -- so that should mostly work
anyways.  Admittedly I didn't look at what extra
pfkey extentions exist in frees/wan, but the core
is pretty much the same.

>  > 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.

Been there, done that, already been released.
So, why is this a nightmare?  The configuration of
KAME is arguably just as bad as pluto -- just
different.  Indeed, I would argue that racoon
has more configuration features than pluto,
but I guess it all depends what you're used to
using.

>  > >>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?

Personally, I think we're moving in that direction.
But I guess it depends what your goals are.

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email protected]             www.ihtfp.com