Re: IPSec in 2.5 Kernel?

I wrote:

 > >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 11:18 PM, Derek Atkins wrote:

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

What should I have been paying attention to?
Where are the scalability and usability issues
discussed?

 > With frees/wan
...
 > you don't get 2401-compliant inbound packet processing
 > (which means that someone can insert traffic into your
 > VPN).

That's misleading;  see below.

 > Frankly, it's _not_ integrated, and this is a
 > major problem.

True, it's not "integrated".

I've said on various occasions that the package one
downloads from freeswan.org is like "hamburger helper",
i.e. it contains some useful ingredients but certainly
not all the necessary ingredients.  It relies on
things like netfilter to implement much of the security
policy.  I consider this a reasonable modular design.

When I use FreeS/WAN to build VPNs, I do "get"
inbound processing that prevents traffic insertion.

The opposite of a modular design is an "integrated"
design.  Whether you favor one over the other is a
matter of taste.  An extreme example of integration
at the expense of modularity is MS windows.  Be
careful what you wish for.

I don't understand why having an spdadd command
distinct from the iptables command is a paragon of
"integration".

 > You cannot .... successfully route
 > packets after IPsec processing unless you want to
 > "route it to the next-hop".

a) FreeS/WAN has issues with that, but most users
won't notice.

b) The issues are fixable.

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

What assumptions have I allegedly made?

What statements have I allegedly made?

I asked some questions.  The strongest "statements"
I recall making concern the lack of information.

Where in the code (or elsewhere) are scalability
and usability issues discussed?  I've looked without
success.  Please provide a more-specific clue as to
where I should look.

More generally, where are the goals of the project
documented?

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

Well, maybe I've got a giant blind spot, but I've
been unable to find documentation how to use the
KAME tools to build an automatically-keyed
subnet-to-subnets VPN where N-1 of the gateways
have dynamic wild-side addresses.  This is something
lots of customers want.

I get 5 hits (none useful) from:
   http://www.google.com/search?q=raccoon+vpn+dhcp+documentation

Even if it turns out to be easy for an expert to do,
the lack of documentation is _ipso facto_ a usability
issue.

If making such a VPN easy to set up is a goal of
the project, please let us know.  That would be
very reassuring.