?completeness of IPsec feature-set

?completeness of IPsec feature-set

[John S. Denker]

Hi --

I've been unable to find much discussion of what IPsec
features should be built into 2.5 / 2.6 to ensure a
reasonable level of usability and scalability.

For example, consider the challenge of establishing an
ordinary VPN where N-1 of the gateways have changeable
wild-side IP addresses.  AFAICT nobody knows how to get
racoon to do this.

People were hoping that the new IPsec implementation
would be a step forward.  If it can't support road
warriors it might be considered a step backwards.

Mr. Atkins recently offered to look into the road-warrior
issue in particular ...
http://lists.freeswan.org/pipermail/design/2003-March/004575.html

... but the overall question remains:  What has been
done to ensure completeness and coherence of the
design in general?

Is there a document somewhere listing the set of
desirable features and the status thereof?  If not,
it's high time to create one.

If you want to know what sort of features I'm talking
about, please see
http://www.monmouth.com/~jsd/vpn/ipsec+routing/feature-list.htm

Some of the listed features are obvious and already implemented
or at least promised.  But others may be less obvious and their
status is not clear.

Re: ?completeness of IPsec feature-set

[bert hubert]

On Thu, Mar 27, 2003 at 06:13:59AM -0500, John S. Denker wrote:

> For example, consider the challenge of establishing an
> ordinary VPN where N-1 of the gateways have changeable
> wild-side IP addresses.  AFAICT nobody knows how to get
> racoon to do this.

Racoon is just an IKE daemon - Linux is not bound to it.  The OpenBSD one
(isakpmd)  also works under linux. You are free to write your own.

Regards,

bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl                         Consulting

Re: ?completeness of IPsec feature-set

[John S. Denker]

On 03/27/2003 08:36 AM, bert hubert wrote:
>
> Racoon is just an IKE daemon - Linux is not bound to it.  

That's true.  But until today there had been no
discussion on netdev of any userspace tools except
KAME, as far as google and I can tell.  It seems
high time to begin such a discussion.

 > You are free to write your own.

I think before I did that I would throw away all
the linux-2.5 built-in IPsec features and use
FreeS/WAN, which has a reasonably complete feature-set.

It's amusing that some people flame FreeS/WAN,
alleging "it's _not_ integrated, and this is a
major problem" ... and alleging that the linux-2.5
stuff solves this problem.  Somehow I don't understand
how telling people to write their own key-exchange
daemon is the winning "integrated" solution.

 > The OpenBSD one (isakpmd) also works under linux.

Folks who wish to pursue this option are encouraged
to look at
   http://www.uwsg.iu.edu/hypermail/linux/kernel/0301.3/0582.html
which announces a port of isakmpd to linux-2.5,
available from
   http://bender.thinknerd.de/~thomas/isakmpd-linux-2.5/

BSD IPsec in general and isakmpd in particular have
a better design and vastly better documentation than
KAME.

However, the existence of isakmpd does not answer all
questions about the completeness of the IPsec feature-
set.

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.

I ask again:  Is there a document somewhere listing the
set of desirable features and the status thereof?  Or
otherwise is there something to reassure would-be users
that a complete feature-set will be provided?

http://www.monmouth.com/~jsd/vpn/ipsec+routing/feature-list.htm

Re: ?completeness of IPsec feature-set

[bert hubert]

On Thu, Mar 27, 2003 at 04:48:37PM -0500, John S. Denker wrote:

> I think before I did that I would throw away all the linux-2.5 built-in
> IPsec features and use FreeS/WAN, which has a reasonably complete
> feature-set.

:-) 

> It's amusing that some people flame FreeS/WAN, alleging "it's _not_
> integrated, and this is a major problem" ... and alleging that the
> linux-2.5 stuff solves this problem.  Somehow I don't understand how
> telling people to write their own key-exchange daemon is the winning
> "integrated" solution.

I sense some... anger. 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.

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

> I ask again:  Is there a document somewhere listing the set of desirable
> features and the status thereof?  Or otherwise is there something to
> reassure would-be users that a complete feature-set will be provided?

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

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

Some time ago I took a small shot at porting the freeswan ike to the
standardised IPSEC ioctls add PF_KEY protocol but it differed too wildly. It
may well be useful to continue this effort.

Regards,

bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl                         Consulting

Re: ?completeness of IPsec feature-set

[John S. Denker]

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.

Re: ?completeness of IPsec feature-set

[James Morris]

On Thu, 27 Mar 2003, bert hubert wrote:

> Right now, the kernel side of things is nearly complete. I sorely miss IPSEC
> NAT traversal

Derek Atkins is working on NAT-T.


- James
-- 
James Morris
<jmorris@intercode.com.au>

Re: ?completeness of IPsec feature-set

[Pekka Savola]

On Thu, 27 Mar 2003, bert hubert wrote:
> > I ask again:  Is there a document somewhere listing the set of desirable
> > features and the status thereof?  Or otherwise is there something to
> > reassure would-be users that a complete feature-set will be provided?
> 
> Right now, the kernel side of things is nearly complete. I sorely miss IPSEC
> NAT traversal which appears to be pretty patented.

Note that at least some IPR-claimants have decreed IPsec NAT-traversal a 
roualty free technology in interests to promote its use, see 
http://www.ietf.org/ipr

It seems SSH and ipunplugged offer RF terms (to the extent of implementing
the IETF standards track implementation, which it isn't at the moment)
while Microsoft and Cisco don't.

I'm particularly interested if this is considered to be a problem.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: ?completeness of IPsec feature-set

[bert hubert]

On Fri, Mar 28, 2003 at 08:32:48AM +0200, Pekka Savola wrote:

> It seems SSH and ipunplugged offer RF terms (to the extent of implementing
> the IETF standards track implementation, which it isn't at the moment)
> while Microsoft and Cisco don't.
> 
> I'm particularly interested if this is considered to be a problem.

The suggestion from Linus is to continue coding and leave this to people who
can actually read and understand legalese. We are not qualified to determine
what is allowed and what is not.

There is some precedent, IBM holds a blanket patent on 'compression' but has
promised not to enforce it, I think. There is libz in the kernel.

But leave it to the people who care and code onwards is what Linus says and
I would tend to agree.

Regards,

bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl                         Consulting