[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Help - IPSEC beginner
Arvind Devarajan wrote:
>
> hi all,
> as a part of my Masters, i am developing the IPSec code - ground up.
> well, as it stands, i am very new to IPSec, and have just managed to go
> through the RFC 2401. My project is for 2.5 months from now.
I'd say your best bet would be to look at one of the several open source
implementations of IPSEC:
Linux FreeS/WAN http://www.freeswan.org
Open BSD http://www.openbsd.org
KAME: http://www.kame.net/
Porting one of those to your Xkernel might be much easier than building
IPSEC from the ground up. At the very least, there should be considerable
code you can use.
> i know that this is too short a time to do anything much in IPSec,
Consider negotiating with your supervisor and the implementers of one of
the systems listed to find a project that's useful and is reasonable in
your time frame.
e.g. FreeS/WAN has only a rudimentary SPDB at this stage and does not
support the Rijndael AES cipher yet and ...
Other possibilities:
Many systems support RSA signatures for authentication of gateways
doing IKE, but there are many different formats for storing the public
keys involved. See recent messages such as this one, Oct 10:
Michael Richardson wrote:
>
> >>>>> "Angelos" == Angelos D Keromytis <angelos@dsl.cis.upenn.edu> writes:
> Angelos> I would in fact argue for removal of preshared-key
> Angelos> authentication; it was useful for debugging or for very simple
> Angelos> setups, but the protocol complexity introduced both directly
> Angelos> (because of the need to support 2 or 3 auth methods) and
> Angelos> indirectly (encourages addition of other authentication
> Angelos> mechanisms) are simply not worth it.
>
> I would agree to this on one condition only:
>
> That the spec lists a simple, well known format (i.e. PKCS10) by which
> self-signed certificates can be loaded into the trusted store, and by which
> they will be produced. That implementations *MUST* support this.
>
> Debugging a CA system as well as IKE is simply a non-starter.
Other formats were suggested elsewhere in the thread. At least until such a
standard format is agreed on and widely implemented, it would be useful to
have some sort of translation software that converts among a number of the
more common formats to facilitate interoperation among IPSEC implementations
that use different formats. Some such converters already exist, e.g. for
FreeS/WAN and PGP keyring or X.509 certificate formats. See FreeS/WAN docs
for details.
Could you, in your time frame, implement a general-purpose translator?
All the implementations listed above (and I think, some others) use PF-key v2
(RFC 2367) for communication between their kernel code and their daemons.
Howver, as I understand it, v2 does not handle policy so each implementation
has added extensions to do that. The extensions are similar, but different.
I understand the implementers have talked about this, and they all think
a common set of extensions would be a good idea, and likely not really
difficult, but they're all busy with other things.
Could you sort this out in your timeframe, develop a common set of
extensions based on ideas from those implementers, and change one or more
implementations to use them?
This might have large payoffs. It would make daemons portable across
implementations so, for example, you could use OpenBSD's Photuris daemon
on Linux or FreeS/WAN's IKE daemon on *BSD. Also, it might get your name
on a PF-key v3 RFC as well as on a thesis.
Follow-Ups:
References: