708 lines
31 KiB
HTML
708 lines
31 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>Introduction to FreeS/WAN</TITLE>
|
|
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
|
|
<STYLE TYPE="text/css"><!--
|
|
BODY { font-family: serif }
|
|
H1 { font-family: sans-serif }
|
|
H2 { font-family: sans-serif }
|
|
H3 { font-family: sans-serif }
|
|
H4 { font-family: sans-serif }
|
|
H5 { font-family: sans-serif }
|
|
H6 { font-family: sans-serif }
|
|
SUB { font-size: smaller }
|
|
SUP { font-size: smaller }
|
|
PRE { font-family: monospace }
|
|
--></STYLE>
|
|
</HEAD>
|
|
<BODY>
|
|
<A HREF="toc.html">Contents</A>
|
|
<A HREF="trouble.html">Previous</A>
|
|
<A HREF="interop.html">Next</A>
|
|
<HR>
|
|
<H1><A name="compat">Linux FreeS/WAN Compatibility Guide</A></H1>
|
|
<P>Much of this document is quoted directly from the Linux FreeS/WAN<A href="mail.html">
|
|
mailing list</A>. Thanks very much to the community of testers,
|
|
patchers and commenters there, especially the ones quoted below but
|
|
also various contributors we haven't quoted.</P>
|
|
<H2><A name="spec">Implemented parts of the IPsec Specification</A></H2>
|
|
<P>In general, do not expect Linux FreeS/WAN to do everything yet. This
|
|
is a work-in-progress and some parts of the IPsec specification are not
|
|
yet implemented.</P>
|
|
<H3><A name="in">In Linux FreeS/WAN</A></H3>
|
|
<P>Things we do, as of version 1.96:</P>
|
|
<UL>
|
|
<LI>key management methods
|
|
<DL>
|
|
<DT>manually keyed</DT>
|
|
<DD>using keys stored in /etc/ipsec.conf</DD>
|
|
<DT>automatically keyed</DT>
|
|
<DD>Automatically negotiating session keys as required. All connections
|
|
are automatically re-keyed periodically. The<A href="glossary.html#Pluto">
|
|
Pluto</A> daemon implements this using the<A href="glossary.html#IKE">
|
|
IKE</A> protocol.</DD>
|
|
</DL>
|
|
</LI>
|
|
<LI>Methods of authenticating gateways for IKE
|
|
<DL>
|
|
<DT>shared secrets</DT>
|
|
<DD>stored in<A href="manpage.d/ipsec.secrets.5.html"> ipsec.secrets(5)</A>
|
|
</DD>
|
|
<DT><A href="glossary.html#RSA">RSA</A> signatures</DT>
|
|
<DD>For details, see<A href="manpage.d/ipsec_pluto.8.html"> pluto(8)</A>
|
|
.</DD>
|
|
<DT>looking up RSA authentication keys from<A href="glossary.html#DNS">
|
|
DNS</A>.</DT>
|
|
<DD>Note that this technique cannot be fully secure until<A href="glossary.html#SDNS">
|
|
secure DNS</A> is widely deployed.</DD>
|
|
</DL>
|
|
</LI>
|
|
<LI>groups for<A href="glossary.html#DH"> Diffie-Hellman</A> key
|
|
negotiation
|
|
<DL>
|
|
<DT>group 2, modp 1024-bit</DT>
|
|
<DT>group 5, modp 1536-bit</DT>
|
|
<DD>We implement these two groups.
|
|
<P>In negotiating a keying connection (ISAKMP SA, Phase 1) we propose
|
|
both groups when we are the initiator, and accept either when a peer
|
|
proposes them. Once the keying connection is made, we propose only the
|
|
alternative agreed there for data connections (IPsec SA's, Phase 2)
|
|
negotiated over that keying connection.</P>
|
|
</DD>
|
|
</DL>
|
|
</LI>
|
|
<LI>encryption transforms
|
|
<DL>
|
|
<DT><A href="glossary.html#DES">DES</A></DT>
|
|
<DD>DES is in the source code since it is needed to implement 3DES, but
|
|
single DES is not made available to users because<A href="politics.html#desnotsecure">
|
|
DES is insecure</A>.</DD>
|
|
<DT><A href="glossary.html#3DES">Triple DES</A></DT>
|
|
<DD>implemented, and used as the default encryption in Linux FreeS/WAN.</DD>
|
|
</DL>
|
|
</LI>
|
|
<LI>authentication transforms
|
|
<DL>
|
|
<DT><A href="glossary.html#HMAC">HMAC</A> using<A href="glossary.html#MD5">
|
|
MD5</A></DT>
|
|
<DD>implemented, may be used in IKE or by by AH or ESP transforms.</DD>
|
|
<DT><A href="glossary.html#HMAC">HMAC</A> using<A href="glossary.html#SHA">
|
|
SHA</A></DT>
|
|
<DD>implemented, may be used in IKE or by AH or ESP transforms.</DD>
|
|
</DL>
|
|
<P>In negotiations, we propose both of these and accept either.</P>
|
|
</LI>
|
|
<LI>compression transforms
|
|
<DL>
|
|
<DT>IPComp</DT>
|
|
<DD>IPComp as described in RFC 2393 was added for FreeS/WAN 1.6. Note
|
|
that Pluto becomes confused if you ask it to do IPComp when the kernel
|
|
cannot.</DD>
|
|
</DL>
|
|
</LI>
|
|
</UL>
|
|
<P>All combinations of implemented transforms are supported. Note that
|
|
some form of packet-level<STRONG> authentication is required whenever
|
|
encryption is used</STRONG>. Without it, the encryption will not be
|
|
secure.</P>
|
|
<H3><A name="dropped">Deliberately omitted</A></H3>
|
|
We do not implement everything in the RFCs because some of those things
|
|
are insecure. See our discussions of avoiding<A href="politics.html#weak">
|
|
bogus security</A>.
|
|
<P>Things we deliberately omit which are required in the RFCs are:</P>
|
|
<UL>
|
|
<LI>null encryption (to use ESP as an authentication-only service)</LI>
|
|
<LI>single DES</LI>
|
|
<LI>DH group 1, a 768-bit modp group</LI>
|
|
</UL>
|
|
<P>Since these are the only encryption algorithms and DH group the RFCs
|
|
require, it is possible in theory to have a standards-conforming
|
|
implementation which will not interpoperate with FreeS/WAN. Such an
|
|
implementation would be inherently insecure, so we do not consider this
|
|
a problem.</P>
|
|
<P>Anyway, most implementations sensibly include more secure options as
|
|
well, so dropping null encryption, single DES and Group 1 does not
|
|
greatly hinder interoperation in practice.</P>
|
|
<P>We also do not implement some optional features allowed by the RFCs:</P>
|
|
<UL>
|
|
<LI>aggressive mode for negotiation of the keying channel or ISAKMP SA.
|
|
This mode is a little faster than main mode, but exposes more
|
|
information to an eavesdropper.</LI>
|
|
</UL>
|
|
<P>In theory, this should cause no interoperation problems since all
|
|
implementations are required to support the more secure main mode,
|
|
whether or not they also allow aggressive mode.</P>
|
|
<P>In practice, it does sometimes produce problems with implementations
|
|
such as Windows 2000 where aggressive mode is the default. Typically,
|
|
these are easily solved with a configuration change that overrides that
|
|
default.</P>
|
|
<H3><A name="not">Not (yet) in Linux FreeS/WAN</A></H3>
|
|
<P>Things we don't yet do, as of version 1.96:</P>
|
|
<UL>
|
|
<LI>key management methods
|
|
<UL>
|
|
<LI>authenticate key negotiations via local<A href="glossary.html#PKI">
|
|
PKI</A> server, but see links to user<A href="web.html#patch"> patches</A>
|
|
</LI>
|
|
<LI>authenticate key negotiations via<A href="glossary.html#SDNS">
|
|
secure DNS</A></LI>
|
|
<LI>unauthenticated key management, using<A href="glossary.html#DH">
|
|
Diffie-Hellman</A> key agreement protocol without authentication.
|
|
Arguably, this would be worth doing since it is secure against all
|
|
passive attacks. On the other hand, it is vulnerable to an active<A href="glossary.html#middle">
|
|
man-in-the-middle attack</A>.</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>encryption transforms
|
|
<P>Currently<A href="glossary.html#3DES"> Triple DES</A> is the only
|
|
encryption method Pluto will negotiate.</P>
|
|
<P>No additional encryption transforms are implemented, though the RFCs
|
|
allow them and some other IPsec implementations support various of
|
|
them. We are not eager to add more. See this<A href="faq.html#other.cipher">
|
|
FAQ question</A>.</P>
|
|
<P><A href="glossary.html#AES">AES</A>, the successor to the DES
|
|
standard, is an excellent candidate for inclusion in FreeS/WAN, see
|
|
links to user<A href="web.html#patch"> patches</A>.</P>
|
|
</LI>
|
|
<LI>authentication transforms
|
|
<P>No optional additional authentication transforms are currently
|
|
implemented. Likely<A href="glossary.html#SHA-256"> SHA-256, SHA-384
|
|
and SHA-512</A> will be added when AES is.</P>
|
|
</LI>
|
|
<LI>Policy checking on decrypted packets
|
|
<P>To fully comply with the RFCs, it is not enough just to accept only
|
|
packets which survive any firewall rules in place to limit what IPsec
|
|
packets get in, and then pass KLIPS authentication. That is what
|
|
FreeS/WAN currently does.</P>
|
|
<P>We should also apply additional tests, for example ensuring that all
|
|
packets emerging from a particular tunnel have source and destination
|
|
addresses that fall within the subnets defined for that tunnel, and
|
|
that packets with those addresses that did not emerge from the
|
|
appropriate tunnel are disallowed.</P>
|
|
<P>This will be done as part of a KLIPS rewrite. See these<A href="intro.html#applied">
|
|
links</A> and the<A href="mail.html"> design mailing list</A> for
|
|
discussion.</P>
|
|
</LI>
|
|
</UL>
|
|
<H2><A name="pfkey">Our PF-Key implementation</A></H2>
|
|
<P>We use PF-key Version Two for communication between the KLIPS kernel
|
|
code and the Pluto Daemon. PF-Key v2 is defined by<A href="http://www.normos.org/ietf/rfc/rfc2367.txt">
|
|
RFC 2367</A>.</P>
|
|
<P>The "PF" stands for Protocol Family. PF-Inet defines a
|
|
kernel/userspace interface for the TCP/IP Internet protocols (TCP/IP),
|
|
and other members of the PF series handle Netware, Appletalk, etc.
|
|
PF-Key is just a PF for key-related matters.</P>
|
|
<H3><A name="pfk.port">PF-Key portability</A></H3>
|
|
<P>PF-Key came out of Berkeley Unix work and is used in the various BSD
|
|
IPsec implementations, and in Solaris. This means there is some hope of
|
|
porting our Pluto(8) to one of the BSD distributions, or of running
|
|
their photurisd(8) on Linux if you prefer<A href="glossary.html#photuris">
|
|
Photuris</A> key management over IKE.</P>
|
|
<P>It is, however, more complex than that. The PK-Key RFC deliberately
|
|
deals only with keying, not policy management. The three PF-Key
|
|
implementations we have looked at -- ours, OpenBSD and KAME -- all have
|
|
extensions to deal with security policy, and the extensions are
|
|
different. There have been discussions aimed at sorting out the
|
|
differences, perhaps for a version three PF-Key spec. All players are
|
|
in favour of this, but everyone involved is busy and it is not clear
|
|
whether or when these discussions might bear fruit.</P>
|
|
<H2><A name="otherk">Kernels other than the latest 2.2.x and 2.4.y</A></H2>
|
|
<P>We develop and test on Redhat Linux using the most recent kernel in
|
|
the 2.2 and 2.4 series. In general, we recommend you use the latest
|
|
kernel in one of those series. Complications and caveats are discussed
|
|
below.</P>
|
|
<H3><A name="kernel.2.0">2.0.x kernels</A></H3>
|
|
<P>Consider upgrading to the 2.2 kernel series. If you want to stay with
|
|
the 2.0 series, then we strongly recommend 2.0.39. Some useful security
|
|
patches were added in 2.0.38.</P>
|
|
<P>Various versions of the code have run at various times on most 2.0.xx
|
|
kernels, but the current version is only lightly tested on 2.0.39, and
|
|
not at all on older kernels.</P>
|
|
<P>Some of our patches for older kernels are shipped in 2.0.37 and
|
|
later, so they are no longer provided in FreeS/WAN. This means recent
|
|
versions of FreeS/WAN will probably not compile on anything earlier
|
|
than 2.0.37.</P>
|
|
<H3><A name="kernel.production">2.2 and 2.4 kernels</A></H3>
|
|
<DL>
|
|
<DT>FreeS/WAN 1.0</DT>
|
|
<DD>ran only on 2.0 kernels</DD>
|
|
<DT>FreeS/WAN 1.1 to 1.8</DT>
|
|
<DD>ran on 2.0 or 2.2 kernels
|
|
<BR> ran on some development kernels, 2.3 or 2.4-test</DD>
|
|
<DT>FreeS/WAN 1.9 to 1.96</DT>
|
|
<DD>runs on 2.0, 2.2 or 2.4 kernels</DD>
|
|
</DL>
|
|
<P>In general,<STRONG> we suggest the latest 2.2 kernel or 2.4 for
|
|
production use</STRONG>.</P>
|
|
<P>Of course no release can be guaranteed to run on kernels more recent
|
|
than it is, so quite often there will be no stable FreeS/WAN for the
|
|
absolute latest kernel. See the<A href="faq.html#k.versions"> FAQ</A>
|
|
for discussion.</P>
|
|
<H2><A name="otherdist">Intel Linux distributions other than Redhat</A></H2>
|
|
<P>We develop and test on Redhat 6.1 for 2.2 kernels, and on Redhat 7.1
|
|
or 7.2 for 2.4, so minor changes may be required for other
|
|
distributions.</P>
|
|
<H3><A name="rh7">Redhat 7.0</A></H3>
|
|
<P>There are some problems with FreeS/WAN on Redhat 7.0. They are
|
|
soluble, but we recommend you upgrade to a later Redhat instead..</P>
|
|
<P>Redhat 7 ships with two compilers.</P>
|
|
<UL>
|
|
<LI>Their<VAR> gcc</VAR> is version 2.96. Various people, including the
|
|
GNU compiler developers and Linus, have said fairly emphatically that
|
|
using this was a mistake. 2.96 is a development version, not intended
|
|
for production use. In particular, it will not compile a Linux kernel.</LI>
|
|
<LI>Redhat therefore also ship a separate compiler, which they call<VAR>
|
|
kgcc</VAR>, for compiling kernels.</LI>
|
|
</UL>
|
|
<P>Kernel Makefiles have<VAR> gcc</VAR> as a default, and must be
|
|
adjusted to use<VAR> kgcc</VAR> before a kernel will compile on 7.0.
|
|
This mailing list message gives details:</P>
|
|
<PRE>Subject: Re: AW: Installing IPsec on Redhat 7.0
|
|
Date: Thu, 1 Feb 2001 14:32:52 -0200 (BRST)
|
|
From: Mads Rasmussen <mads@cit.com.br>
|
|
|
|
> From www.redhat.com/support/docs/gotchas/7.0/gotchas-7-6.html#ss6.1
|
|
|
|
cd to /usr/src/linux and open the Makefile in your favorite editor. You
|
|
will need to look for a line similar to this:
|
|
|
|
CC = $(CROSS_COMPILE)gcc -D__KERNEL__ -I$(HPATH)
|
|
|
|
This line specifies which C compiler to use to build the kernel. It should
|
|
be changed to:
|
|
|
|
CC = $(CROSS_COMPILE)kgcc -D__KERNEL__ -I$(HPATH)
|
|
|
|
for Red Hat Linux 7. The kgcc compiler is egcs 2.91.66. From here you can
|
|
proceed with the typical compiling steps.</PRE>
|
|
<P>Check the<A href="mail.html"> mailing list</A> archive for more
|
|
recent news.</P>
|
|
<H3><A name="suse">SuSE Linux</A></H3>
|
|
<P>SuSE 6.3 and later versions, at least in Europe, ship with FreeS/WAN
|
|
included.</P>
|
|
<P>FreeS/WAN packages distributed for SuSE 7.0-7.2 were somehow
|
|
miscompiled. You can find fixed packages on<A HREF="http://www.suse.de/~garloff/linux/FreeSWAN">
|
|
Kurt Garloff's page</A>.</P>
|
|
<P>Here are some notes for an earlier SuSE version.</P>
|
|
<H4>SuSE Linux 5.3</H4>
|
|
<PRE>Date: Mon, 30 Nov 1998
|
|
From: Peter Onion <ponion@srd.bt.co.uk>
|
|
|
|
... I got Saturdays snapshot working between my two SUSE5.3 machines at home.
|
|
|
|
The mods to the install process are quite simple. From memory and looking at
|
|
the files on the SUSE53 machine here at work....
|
|
|
|
And extra link in each of the /etc/init.d/rc?.d directories called K35ipsec
|
|
which SUSE use to shut a service down.
|
|
|
|
A few mods in /etc/init.d/ipsec to cope with the different places that SUSE
|
|
put config info, and remove the inculsion of /etc/rc.d/init.d/functions and .
|
|
/etc/sysconfig/network as they don't exists and 1st one isn't needed anyway.
|
|
|
|
insert ". /etc/rc.config" to pick up the SUSE config info and use
|
|
|
|
if test -n "$NETCONFIG" -a "$NETCONFIG" != "YAST_ASK" ; then
|
|
|
|
to replace
|
|
|
|
[ ${NETWORKING} = "no" ] && exit 0
|
|
|
|
Create /etc/sysconfig as SUSE doesn't have one.
|
|
|
|
I think that was all (but I prob forgot something)....</PRE>
|
|
<P>You may also need to fiddle initialisation scripts to ensure that<VAR>
|
|
/var/run/pluto.pid</VAR> is removed when rebooting. If this file is
|
|
present, Pluto does not come up correctly.</P>
|
|
<H3><A name="slack">Slackware</A></H3>
|
|
<PRE>Subject: Re: linux-IPsec: Slackware distribution
|
|
Date: Thu, 15 Apr 1999 12:07:01 -0700
|
|
From: Evan Brewer <dmessiah@silcon.com>
|
|
|
|
> Very shortly, I will be needing to install IPsec on at least gateways that
|
|
> are running Slackware. . . .
|
|
|
|
The only trick to getting it up is that on the slackware dist there is no
|
|
init.d directory in /etc/rc.d .. so create one. Then, what I do is take the
|
|
IPsec startup script which normally gets put into the init.d directory, and
|
|
put it in /etc/rc.d and name ir rc.ipsec .. then I symlink it to the file
|
|
in init.d. The only file in the dist you need to really edit is the
|
|
utils/Makefile, setup4:
|
|
|
|
Everything else should be just fine.</PRE>
|
|
<P>A year or so later:</P>
|
|
<PRE>Subject: Re: HTML Docs- Need some cleanup?
|
|
Date: Mon, 8 Jan 2001
|
|
From: Jody McIntyre <jodym@oeone.com>
|
|
|
|
I have successfully installed FreeS/WAN on several Slackware 7.1 machines.
|
|
FreeS/WAN installed its rc.ipsec file in /etc/rc.d. I had to manually call
|
|
this script from rc.inet2. This seems to be an easier method than Evan
|
|
Brewer's.</PRE>
|
|
<H3><A name="deb">Debian</A></H3>
|
|
<P>A recent (Nov 2001) mailing list points to a<A href="http://www.thing.dyndns.org/debian/vpn.htm">
|
|
web page</A> on setting up several types of tunnel, including IPsec, on
|
|
Debian.</P>
|
|
<P>Some older information:</P>
|
|
<PRE>Subject: FreeS/WAN 1.0 on Debian 2.1
|
|
Date: Tue, 20 Apr 1999
|
|
From: Tim Miller <cerebus+counterpane@haybaler.sackheads.org>
|
|
|
|
Compiled and installed without error on a Debian 2.1 system
|
|
with kernel-source-2.0.36 after pointing RCDIR in utils/Makefile to
|
|
/etc/init.d.
|
|
|
|
/var/lock/subsys/ doesn't exist on Debian boxen, needs to be
|
|
created; not a fatal error.
|
|
|
|
Finally, IPsec scripts appear to be dependant on GNU awk
|
|
(gawk); the default Debian awk (mawk-1.3.3-2) had fatal difficulties.
|
|
With gawk installed and /etc/alternatives/awk linked to /usr/bin/gawk
|
|
operation appears flawless.</PRE>
|
|
<P>The scripts in question have been modified since this was posted. Awk
|
|
versions should no longer be a problem.</P>
|
|
<H3><A name="caldera">Caldera</A></H3>
|
|
<PRE>Subject: Re: HTML Docs- Need some cleanup?
|
|
Date: Mon, 08 Jan 2001
|
|
From: Andy Bradford <andyb@calderasystems.com>
|
|
|
|
On Sun, 07 Jan 2001 22:59:05 EST, Sandy Harris wrote:
|
|
|
|
> Intel Linux distributions other than Redhat 5.x and 6.x
|
|
> Redhat 7.0
|
|
> SuSE Linux
|
|
> SuSE Linux 5.3
|
|
> Slackware
|
|
> Debian
|
|
|
|
Can you please include Caldera in this list? I have tested it since
|
|
FreeS/Wan 1.1 and it works great with our systems---provided one
|
|
follows the FreeS/Wan documentation. :-)
|
|
|
|
Thank you,
|
|
Andy</PRE>
|
|
<H2><A name="CPUs">CPUs other than Intel</A></H2>
|
|
<P>FreeS/WAN has been run sucessfully on a number of different CPU
|
|
architectures. If you have tried it on one not listed here, please post
|
|
to the<A href="mail.html"> mailing list</A>.</P>
|
|
<H3><A name=" strongarm">Corel Netwinder (StrongARM CPU)</A></H3>
|
|
<PRE>Subject: linux-ipsec: Netwinder diffs
|
|
Date: Wed, 06 Jan 1999
|
|
From: rhatfield@plaintree.com
|
|
|
|
I had a mistake in my IPsec-auto, so I got things working this morning.
|
|
|
|
Following are the diffs for my changes. Probably not the best and cleanest way
|
|
of doing it, but it works. . . . </PRE>
|
|
<P>These diffs are in the 0.92 and later distributions, so these should
|
|
work out-of-the-box on Netwinder.</P>
|
|
<H3><A name="yellowdog">Yellow Dog Linux on Power PC</A></H3>
|
|
<PRE>Subject: Compiling FreeS/WAN 1.1 on YellowDog Linux (PPC)
|
|
Date: 11 Dec 1999
|
|
From: Darron Froese <darron@fudgehead.com>
|
|
|
|
I'm summarizing here for the record - because it's taken me many hours to do
|
|
this (multiple times) and because I want to see IPsec on more linuxes than
|
|
just x86.
|
|
|
|
Also, I can't remember if I actually did summarize it before... ;-) I'm
|
|
working too many late hours.
|
|
|
|
That said - here goes.
|
|
|
|
1. Get your linux kernel and unpack into /usr/src/linux/ - I used 2.2.13.
|
|
<http://www.kernel.org/pub/linux/kernel/v2.2/linux-2.2.13.tar.bz2>
|
|
|
|
2. Get FreeS/WAN and unpack into /usr/src/freeswan-1.1
|
|
<ftp://ftp.xs4all.nl/pub/crypto/freeswan/freeswan-1.1.tar.gz>
|
|
|
|
3. Get the gmp src rpm from here:
|
|
<ftp://ftp.yellowdoglinux.com//pub/yellowdog/champion-1.1/SRPMS/SRPMS/gmp-2.0.2-9a.src.rpm>
|
|
|
|
4. Su to root and do this: rpm --rebuild gmp-2.0.2-9a.src.rpm
|
|
|
|
You will see a lot of text fly by and when you start to see the rpm
|
|
recompiling like this:
|
|
|
|
Executing: %build
|
|
+ umask 022
|
|
+ cd /usr/src/redhat/BUILD
|
|
+ cd gmp-2.0.2
|
|
+ libtoolize --copy --force
|
|
Remember to add `AM_PROG_LIBTOOL' to `configure.in'.
|
|
You should add the contents of `/usr/share/aclocal/libtool.m4' to
|
|
`aclocal.m4'.
|
|
+ CFLAGS=-O2 -fsigned-char
|
|
+ ./configure --prefix=/usr
|
|
|
|
Hit Control-C to stop the rebuild. NOTE: We're doing this because for some
|
|
reason the gmp source provided with FreeS/WAN 1.1 won't build properly on
|
|
ydl.
|
|
|
|
cd /usr/src/redhat/BUILD/
|
|
cp -ar gmp-2.0.2 /usr/src/freeswan-1.1/
|
|
cd /usr/src/freeswan-1.1/
|
|
rm -rf gmp
|
|
mv gmp-2.0.2 gmp
|
|
|
|
5. Open the freeswan Makefile and change the line that says:
|
|
KERNEL=$(b)zimage (or something like that) to
|
|
KERNEL=vmlinux
|
|
|
|
6. cd ../linux/
|
|
|
|
7. make menuconfig
|
|
Select an option or two and then exit - saving your changes.
|
|
|
|
8. cd ../freeswan-1.1/ ; make menugo
|
|
|
|
That will start the whole process going - once that's finished compiling,
|
|
you have to install your new kernel and reboot.
|
|
|
|
That should build FreeS/WAN on ydl (I tried it on 1.1).</PRE>
|
|
And a later message on the same topic:
|
|
<PRE>Subject: Re: FreeS/WAN, PGPnet and E-mail
|
|
Date: Sat, 22 Jan 2000
|
|
From: Darron Froese <darron@fudgehead.com>
|
|
|
|
on 1/22/00 6:47 PM, Philip Trauring at philip@trauring.com wrote:
|
|
|
|
> I have a PowerMac G3 ...
|
|
|
|
The PowerMac G3 can run YDL 1.1 just fine. It should also be able to run
|
|
FreeS/WAN 1.2patch1 with a couple minor modifications:
|
|
|
|
1. In the Makefile it specifies a bzimage for the kernel compile - you have
|
|
to change that to vmlinux for the PPC.
|
|
|
|
2. The gmp source that comes with FreeS/WAN (for whatever reason) fails to
|
|
compile. I have gotten around this by getting the gmp src rpm from here:
|
|
|
|
ftp://ftp.yellowdoglinux.com//pub/yellowdog/champion-1.1/SRPMS/SRPMS/gmp-2.0.2-9a.src.rpm
|
|
|
|
If you rip the source out of there - and place it where the gmp source
|
|
resides it will compile just fine.</PRE>
|
|
<P>FreeS/WAN no longer includes GMP source.</P>
|
|
<H3><A name="mklinux">Mklinux</A></H3>
|
|
<P>One user reports success on the Mach-based<STRONG> m</STRONG>icro<STRONG>
|
|
k</STRONG>ernel Linux.</P>
|
|
<PRE>Subject: Smiles on sparc and ppc
|
|
Date: Fri, 10 Mar 2000
|
|
From: Jake Hill <jah@alien.bt.co.uk>
|
|
|
|
You may or may not be interested to know that I have successfully built
|
|
FreeS/WAN on a number of non intel alpha architectures; namely on ppc
|
|
and sparc and also on osfmach3/ppc (MkLinux). I can report that it just
|
|
works, mostly, with few changes.</PRE>
|
|
<H3><A name="alpha">Alpha 64-bit processors</A></H3>
|
|
<PRE>Subject: IT WORKS (again) between intel & alpha :-)))))
|
|
Date: Fri, 29 Jan 1999
|
|
From: Peter Onion <ponion@srd.bt.co.uk>
|
|
|
|
Well I'm happy to report that I've got an IPsec connection between by intel & alpha machines again :-))
|
|
|
|
If you look back on this list to 7th of December I wrote...
|
|
|
|
-On 07-Dec-98 Peter Onion wrote:
|
|
->
|
|
-> I've about had enuf of wandering around inside the kernel trying to find out
|
|
-> just what is corrupting outgoing packets...
|
|
-
|
|
-Its 7:30 in the evening .....
|
|
-
|
|
-I FIXED IT :-))))))))))))))))))))))))))))))))
|
|
-
|
|
-It was my own fault :-((((((((((((((((((
|
|
-
|
|
-If you ask me very nicly I'll tell you where I was a little too over keen to
|
|
-change unsigned long int __u32 :-) OPSE ...
|
|
-
|
|
-So tomorrow it will full steam ahead to produce a set of diffs/patches against
|
|
-0.91
|
|
-
|
|
-Peter Onion.</PRE>
|
|
<P>In general (there have been some glitches), FreeS/WAN has been
|
|
running on Alphas since then.</P>
|
|
<H3><A name="SPARC">Sun SPARC processors</A></H3>
|
|
<P>Several users have reported success with FreeS/WAN on SPARC Linux.
|
|
Here is one mailing list message:</P>
|
|
<PRE>Subject: Smiles on sparc and ppc
|
|
Date: Fri, 10 Mar 2000
|
|
From: Jake Hill <jah@alien.bt.co.uk>
|
|
|
|
You may or may not be interested to know that I have successfully built
|
|
FreeS/WAN on a number of non intel alpha architectures; namely on ppc
|
|
and sparc and also on osfmach3/ppc (MkLinux). I can report that it just
|
|
works, mostly, with few changes.
|
|
|
|
I have a question, before I make up some patches. I need to hack
|
|
gmp/mpn/powerpc32/*.s to build them. Is this ok? The changes are
|
|
trivial, but could I also use a different version of gmp? Is it vanilla
|
|
here?
|
|
|
|
I guess my only real headache is from ipchains, which appears to stop
|
|
running when IPsec has been started for a while. This is with 2.2.14 on
|
|
sparc.</PRE>
|
|
<P>This message, from a different mailing list, may be relevant for
|
|
anyone working with FreeS/WAN on Suns:</P>
|
|
<PRE>Subject: UltraSPARC DES assembler
|
|
Date: Thu, 13 Apr 2000
|
|
From: svolaf@inet.uni2.dk (Svend Olaf Mikkelsen)
|
|
To: coderpunks@toad.com
|
|
|
|
An UltraSPARC assembler version of the LibDES/SSLeay/OpenSSL des_enc.c
|
|
file is available at http://inet.uni2.dk/~svolaf/des.htm.
|
|
|
|
This brings DES on UltraSPARC from slower than Pentium at the same
|
|
clock speed to significantly faster.</PRE>
|
|
<H3><A name="mips">MIPS processors</A></H3>
|
|
<P>We know FreeS/WAN runs on at least some MIPS processors because<A href="http://www.lasat.com">
|
|
Lasat</A> manufacture an IPsec box based on an embedded MIPS running
|
|
Linux with FreeS/WAN. We have no details.</P>
|
|
<H3><A name="crusoe">Transmeta Crusoe</A></H3>
|
|
<P>The Merilus<A href="http://www.merilus.com/products/fc/index.shtml">
|
|
Firecard</A>, a Linux firewall on a PCI card, is based on a Crusoe
|
|
processor and supports FreeS/WAN.</P>
|
|
<H3><A name="coldfire">Motorola Coldfire</A></H3>
|
|
<PRE>Subject: Re: Crypto hardware support
|
|
Date: Mon, 03 Jul 2000
|
|
From: Dan DeVault <devault@tampabay.rr.com>
|
|
|
|
.... I have been running
|
|
uClinux with FreeS/WAN 1.4 on a system built by Moreton Bay (
|
|
http://www.moretonbay.com ) and it was using a Coldfire processor
|
|
and was able to do the Triple DES encryption at just about
|
|
1 mbit / sec rate....... they put a Hi/Fn 7901 hardware encryption
|
|
chip on their board and now their system does over 25 mbit of 3DES
|
|
encryption........ pretty significant increase if you ask me.</PRE>
|
|
<H2><A name="multiprocessor">Multiprocessor machines</A></H2>
|
|
<P>FreeS/WAN is designed to work on SMP (symmetric multi-processing)
|
|
Linux machines and is regularly tested on dual processor x86 machines.</P>
|
|
<P>We do not know of any testing on multi-processor machines with other
|
|
CPU architectures or with more than two CPUs. Anyone who does test
|
|
this, please report results to the<A href="mail.html"> mailing list</A>
|
|
.</P>
|
|
<P>The current design does not make particularly efficient use of
|
|
multiprocessor machines; some of the kernel work is single-threaded.</P>
|
|
<H2><A name="hardware">Support for crypto hardware</A></H2>
|
|
<P>Supporting hardware cryptography accelerators has not been a high
|
|
priority for the development team because it raises a number of fairly
|
|
complex issues:</P>
|
|
<UL>
|
|
<LI>Can you trust the hardware? If it is not Open Source, how do you
|
|
audit its security? Even if it is, how do you check that the design has
|
|
no concealed traps?</LI>
|
|
<LI>If an interface is added for such hardware, can that interface be
|
|
subverted or misused?</LI>
|
|
<LI>Is hardware acceleration actually a performance win? It clearly is
|
|
in many cases, but on a fast machine it might be better to use the CPU
|
|
for the encryption than to pay the overheads of moving data to and from
|
|
a crypto board.</LI>
|
|
<LI>the current KLIPS code does not provide a clean interface for
|
|
hardware accelerators</LI>
|
|
</UL>
|
|
<P>That said, we have a<A href="#coldfire"> report</A> of FreeS/WAN
|
|
working with one crypto accelerator and some work is going on to modify
|
|
KLIPS to create a clean generic interface to such products. See this<A href="http://www.jukie.net/~bart/linux-ipsec/">
|
|
web page</A> for some of the design discussion.</P>
|
|
<P>More recently, a patch to support some hardware accelerators has been
|
|
posted:</P>
|
|
<PRE>Subject: [Design] [PATCH] H/W acceleration patch
|
|
Date: Tue, 18 Sep 2001
|
|
From: "Martin Gadbois" <martin.gadbois@colubris.com>
|
|
|
|
Finally!!
|
|
Here's a web site with H/W acceleration patch for FreeS/WAN 1.91, including
|
|
S/W and Hifn 7901 crypto support.
|
|
|
|
http://sources.colubris.com/
|
|
|
|
Martin Gadbois</PRE>
|
|
<P>Hardware accelerators could take performance well beyond what
|
|
FreeS/WAN can do in software (discussed<A href="performance.html"> here</A>
|
|
). Here is some discussion off the IETF IPsec list, October 2001:</P>
|
|
<PRE> ... Currently shipping chips deliver, 600 mbps throughput on a single
|
|
stream of 3DES IPsec traffic. There are also chips that use multiple
|
|
cores to do 2.4 gbps. We (Cavium) and others have announced even faster
|
|
chips. ... Mid 2002 versions will handle at line rate (OC48 and OC192)
|
|
IPsec and SSL/TLS traffic not only 3DES CBC but also AES and arc4.</PRE>
|
|
<P>The patches to date support chips that have been in production for
|
|
some time, not the state-of-the-art latest-and-greatest devices
|
|
described in that post. However, they may still outperform software and
|
|
they almost certainly reduce CPU overhead.</P>
|
|
<H2><A name="ipv6">IP version 6 (IPng)</A></H2>
|
|
<P>The Internet currently runs on version four of the IP protocols. IPv4
|
|
is what is in the standard Linux IP stack, and what FreeS/WAN was built
|
|
for. In IPv4, IPsec is an optional feature.</P>
|
|
<P>The next version of the IP protocol suite is version six, usually
|
|
abbreviated either as "IPv6" or as "IPng" for "IP: the next
|
|
generation". For IPv6, IPsec is a required feature. Any machine doing
|
|
IPv6 is required to support IPsec, much as any machine doing (any
|
|
version of) IP is required to support ICMP.</P>
|
|
<P>There is a Linux implementation of IPv6 in Linux kernels 2.2 and
|
|
above. For details, see the<A href="http://www.cs-ipv6.lancs.ac.uk/ipv6/systems/linux/faq/">
|
|
FAQ</A>. It does not yet support IPsec. The<A href="http://www.linux-ipv6.org/">
|
|
USAGI</A> project are also working on IPv6 for Linux.</P>
|
|
<P>FreeS/WAN was originally built for the current standard, IPv4, but we
|
|
are interested in seeing it work with IPv6. Some progress has been
|
|
made, and a patched version with IPv6 support is<A href="http://www.ipv6.iabg.de/downloadframe/index.html">
|
|
available</A>. For more recent information, check the<A href="mail.html">
|
|
mailing list</A>.</P>
|
|
<H3><A name="v6.back">IPv6 background</A></H3>
|
|
<P>IPv6 has been specified by an IETF<A href="http://www.ietf.org/html.charters/ipngwg-charter.html">
|
|
working group</A>. The group's page lists over 30 RFCs to date, and
|
|
many Internet Drafts as well. The overview is<A href="http://www.ietf.org/rfc/rfc2460.txt">
|
|
RFC 2460</A>. Major features include:</P>
|
|
<UL>
|
|
<LI>expansion of the address space from 32 to 128 bits,</LI>
|
|
<LI>changes to improve support for
|
|
<UL>
|
|
<LI>mobile IP</LI>
|
|
<LI>automatic network configuration</LI>
|
|
<LI>quality of service routing</LI>
|
|
<LI>...</LI>
|
|
</UL>
|
|
</LI>
|
|
<LI>improved security via IPsec</LI>
|
|
</UL>
|
|
<P>A number of projects are working on IPv6 implementation. A prominent
|
|
Open Source effort is<A href="http://www.kame.net/"> KAME</A>, a
|
|
collaboration among several large Japanese companies to implement IPv6
|
|
for Berkeley Unix. Other major players are also working on IPv6. For
|
|
example, see pages at:</P>
|
|
<UL>
|
|
<LI><A href="http://playground.sun.com/pub/ipng/html/ipng-main.html">Sun</A>
|
|
</LI>
|
|
<LI><A href="http://www.cisco.com/warp/public/732/ipv6/index.html">Cisco</A>
|
|
</LI>
|
|
<LI><A href="http://www.microsoft.com/windows2000/techinfo/howitworks/communications/networkbasics/IPv6.asp">
|
|
Microsoft</A></LI>
|
|
</UL>
|
|
<P>The<A href="http://www.6bone.net/"> 6bone</A> (IPv6 backbone) testbed
|
|
network has been up for some time. There is an active<A href="http://www.ipv6.org/">
|
|
IPv6 user group</A>.</P>
|
|
<P>One of the design goals for IPv6 was that it must be possible to
|
|
convert from v4 to v6 via a gradual transition process. Imagine the
|
|
mess if there were a "flag day" after which the entire Internet used
|
|
v6, and all software designed for v4 stopped working. Almost every
|
|
computer on the planet would need major software changes! There would
|
|
be huge costs to replace older equipment. Implementers would be worked
|
|
to death before "the day", systems administrators and technical support
|
|
would be completely swamped after it. The bugs in every implementation
|
|
would all bite simultaneously. Large chunks of the net would almost
|
|
certainly be down for substantial time periods. ...</P>
|
|
<P>Fortunately, the design avoids any "flag day". It is therefore a
|
|
little tricky to tell how quickly IPv6 will take over. The transition
|
|
has certainly begun. For examples, see announcements from<A href="http://www.mailbase.ac.uk/lists/internet2/2000-03/0016.html">
|
|
NTT</A> and<A href="http://www.vnunet.com/News/1102383"> Nokia</A>.
|
|
However, it is not yet clear how quickly the process will gain
|
|
momentum, or when it will be completed. Likely large parts of the
|
|
Internet will remain with IPv4 for years to come.</P>
|
|
<HR>
|
|
<A HREF="toc.html">Contents</A>
|
|
<A HREF="trouble.html">Previous</A>
|
|
<A HREF="interop.html">Next</A>
|
|
</BODY>
|
|
</HTML>
|