From: bert hubert <ahu@ds9a.nl>
To: "John S. Denker" <jsd@monmouth.com>
Cc: netdev <netdev@oss.sgi.com>
Subject: Re: ?completeness of IPsec feature-set
Date: Thu, 27 Mar 2003 22:58:39 +0100 [thread overview]
Message-ID: <20030327215839.GA31029@outpost.ds9a.nl> (raw)
In-Reply-To: <3E8371B5.7030200@monmouth.com>
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
next prev parent reply other threads:[~2003-03-27 21:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-27 11:13 ?completeness of IPsec feature-set John S. Denker
2003-03-27 13:36 ` bert hubert
2003-03-27 21:48 ` John S. Denker
2003-03-27 21:58 ` bert hubert [this message]
2003-03-27 22:58 ` John S. Denker
2003-03-27 23:21 ` James Morris
2003-03-28 6:32 ` Pekka Savola
2003-03-28 10:19 ` bert hubert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030327215839.GA31029@outpost.ds9a.nl \
--to=ahu@ds9a.nl \
--cc=jsd@monmouth.com \
--cc=netdev@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).