diff options
Diffstat (limited to 'doc/compat.html')
| -rw-r--r-- | doc/compat.html | 707 |
1 files changed, 0 insertions, 707 deletions
diff --git a/doc/compat.html b/doc/compat.html deleted file mode 100644 index f01efa64c..000000000 --- a/doc/compat.html +++ /dev/null @@ -1,707 +0,0 @@ -<!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> |