Re: ?completeness of IPsec feature-set

["John S. Denker" <jsd@monmouth.com>]

On 03/27/2003 04:58 PM, bert hubert wrote:
> 
> Linux provides the RFC PF_KEY protocol and also uses
> the RFC ioctls to support IPSEC. Any compliant IKE will work against it.
 > That is how development works in the kernel.

Saying it's not a kernel problem isn't the same
as saying it's not a problem.  I was told this
was the proper list to raise such questions.  If
it isn't, please point me to a more-appropriate
list.

Certain parties are touting linux-2.5 IPsec as
a complete and "integrated" solution.  Either
the claims need to be toned down or (preferably)
thelevel of integration needs to go up.  In any
case a "status report" clarifying what remains
to be done would be helpful.

>>For example, BSD provides an "enc0" device and documents using it to
>>implement network security rules.  Alas I see no sign that linux-2.5
>>provides this feature.  If I am overlooking something, please explain.
> 
> 'enc0' is an internal abstraction, do you need it? 

We agree is an abstraction... but I wouldn't have
called it "internal".  It is a documented interface,
so the better half of it is external.

As to need, I get 1290 hits from
   http://www.google.com/search?q=enc0
so there is prima facie evidence that people use it.

Uses include
  -- mentioning it in packet-filtering rules.
  -- using it to communicate with userspace about
     things like MTU and default source address.
  -- mentioning it in routing rules.

If you have evidence that everything that can be
done with enc0 can be conveniently done without
enc0, please share it.

> Right now, the kernel side of things is nearly complete. I sorely miss IPSEC
> NAT traversal which appears to be pretty patented.

Do you mean these patents
   http://www.ietf.org/ietf/IPR/SSH-NAT
or others?

Also, I have heard reports that NAT-traversal
was "coming soon" to linux-2.5.  Again, a
coherent status report would be helpful.

>>http://www.monmouth.com/~jsd/vpn/ipsec+routing/feature-list.htm
> 
> 
> This is mostly about userspace. The current attitude is that the kernel
> provides the hooks and we then hope people start coding against that
> interface. A large amount of the things you suggest can be implemented
> today.

A large amount, yes.  But perhaps not all;  the
enc0 question is a case in point.

Again: saying it's not a kernel problem isn't the
same as saying it's not a problem.

Commonly real-world usability and scalability depend
on "making the whole offer".  Users really aren't
interested in something that provides 60% or even 99%
of a working solution if the remainder is not readily
available.