doc/compat.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
   2 <HTML>
   3 <HEAD>
   4 <TITLE>Introduction to FreeS/WAN</TITLE>
   5 <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
   6 <STYLE TYPE="text/css"><!--
   7 BODY { font-family: serif }
   8 H1 { font-family: sans-serif }
   9 H2 { font-family: sans-serif }
  10 H3 { font-family: sans-serif }
  11 H4 { font-family: sans-serif }
  12 H5 { font-family: sans-serif }
  13 H6 { font-family: sans-serif }
  14 SUB { font-size: smaller }
  15 SUP { font-size: smaller }
  16 PRE { font-family: monospace }
  17 --></STYLE>
  18 </HEAD>
  19 <BODY>
  20 <A HREF="toc.html">Contents</A>
  21 <A HREF="trouble.html">Previous</A>
  22 <A HREF="interop.html">Next</A>
  23 <HR>
  24 <H1><A name="compat">Linux FreeS/WAN Compatibility Guide</A></H1>
  25 <P>Much of this document is quoted directly from the Linux FreeS/WAN<A href="mail.html">
  26  mailing list</A>. Thanks very much to the community of testers,
  27  patchers and commenters there, especially the ones quoted below but
  28  also various contributors we haven't quoted.</P>
  29 <H2><A name="spec">Implemented parts of the IPsec Specification</A></H2>
  30 <P>In general, do not expect Linux FreeS/WAN to do everything yet. This
  31  is a work-in-progress and some parts of the IPsec specification are not
  32  yet implemented.</P>
  33 <H3><A name="in">In Linux FreeS/WAN</A></H3>
  34 <P>Things we do, as of version 1.96:</P>
  35 <UL>
  36 <LI>key management methods
  37 <DL>
  38 <DT>manually keyed</DT>
  39 <DD>using keys stored in /etc/ipsec.conf</DD>
  40 <DT>automatically keyed</DT>
  41 <DD>Automatically negotiating session keys as required. All connections
  42  are automatically re-keyed periodically. The<A href="glossary.html#Pluto">
  43  Pluto</A> daemon implements this using the<A href="glossary.html#IKE">
  44  IKE</A> protocol.</DD>
  45 </DL>
  46 </LI>
  47 <LI>Methods of authenticating gateways for IKE
  48 <DL>
  49 <DT>shared secrets</DT>
  50 <DD>stored in<A href="manpage.d/ipsec.secrets.5.html"> ipsec.secrets(5)</A>
  51 </DD>
  52 <DT><A href="glossary.html#RSA">RSA</A> signatures</DT>
  53 <DD>For details, see<A href="manpage.d/ipsec_pluto.8.html"> pluto(8)</A>
  54 .</DD>
  55 <DT>looking up RSA authentication keys from<A href="glossary.html#DNS">
  56  DNS</A>.</DT>
  57 <DD>Note that this technique cannot be fully secure until<A href="glossary.html#SDNS">
  58  secure DNS</A> is widely deployed.</DD>
  59 </DL>
  60 </LI>
  61 <LI>groups for<A href="glossary.html#DH"> Diffie-Hellman</A> key
  62  negotiation
  63 <DL>
  64 <DT>group 2, modp 1024-bit</DT>
  65 <DT>group 5, modp 1536-bit</DT>
  66 <DD>We implement these two groups.
  67 <P>In negotiating a keying connection (ISAKMP SA, Phase 1) we propose
  68  both groups when we are the initiator, and accept either when a peer
  69  proposes them. Once the keying connection is made, we propose only the
  70  alternative agreed there for data connections (IPsec SA's, Phase 2)
  71  negotiated over that keying connection.</P>
  72 </DD>
  73 </DL>
  74 </LI>
  75 <LI>encryption transforms
  76 <DL>
  77 <DT><A href="glossary.html#DES">DES</A></DT>
  78 <DD>DES is in the source code since it is needed to implement 3DES, but
  79  single DES is not made available to users because<A href="politics.html#desnotsecure">
  80  DES is insecure</A>.</DD>
  81 <DT><A href="glossary.html#3DES">Triple DES</A></DT>
  82 <DD>implemented, and used as the default encryption in Linux FreeS/WAN.</DD>
  83 </DL>
  84 </LI>
  85 <LI>authentication transforms
  86 <DL>
  87 <DT><A href="glossary.html#HMAC">HMAC</A> using<A href="glossary.html#MD5">
  88  MD5</A></DT>
  89 <DD>implemented, may be used in IKE or by by AH or ESP transforms.</DD>
  90 <DT><A href="glossary.html#HMAC">HMAC</A> using<A href="glossary.html#SHA">
  91  SHA</A></DT>
  92 <DD>implemented, may be used in IKE or by AH or ESP transforms.</DD>
  93 </DL>
  94 <P>In negotiations, we propose both of these and accept either.</P>
  95 </LI>
  96 <LI>compression transforms
  97 <DL>
  98 <DT>IPComp</DT>
  99 <DD>IPComp as described in RFC 2393 was added for FreeS/WAN 1.6. Note
 100  that Pluto becomes confused if you ask it to do IPComp when the kernel
 101  cannot.</DD>
 102 </DL>
 103 </LI>
 104 </UL>
 105 <P>All combinations of implemented transforms are supported. Note that
 106  some form of packet-level<STRONG> authentication is required whenever
 107  encryption is used</STRONG>. Without it, the encryption will not be
 108  secure.</P>
 109 <H3><A name="dropped">Deliberately omitted</A></H3>
 110  We do not implement everything in the RFCs because some of those things
 111  are insecure. See our discussions of avoiding<A href="politics.html#weak">
 112  bogus security</A>.
 113 <P>Things we deliberately omit which are required in the RFCs are:</P>
 114 <UL>
 115 <LI>null encryption (to use ESP as an authentication-only service)</LI>
 116 <LI>single DES</LI>
 117 <LI>DH group 1, a 768-bit modp group</LI>
 118 </UL>
 119 <P>Since these are the only encryption algorithms and DH group the RFCs
 120  require, it is possible in theory to have a standards-conforming
 121  implementation which will not interpoperate with FreeS/WAN. Such an
 122  implementation would be inherently insecure, so we do not consider this
 123  a problem.</P>
 124 <P>Anyway, most implementations sensibly include more secure options as
 125  well, so dropping null encryption, single DES and Group 1 does not
 126  greatly hinder interoperation in practice.</P>
 127 <P>We also do not implement some optional features allowed by the RFCs:</P>
 128 <UL>
 129 <LI>aggressive mode for negotiation of the keying channel or ISAKMP SA.
 130  This mode is a little faster than main mode, but exposes more
 131  information to an eavesdropper.</LI>
 132 </UL>
 133 <P>In theory, this should cause no interoperation problems since all
 134  implementations are required to support the more secure main mode,
 135  whether or not they also allow aggressive mode.</P>
 136 <P>In practice, it does sometimes produce problems with implementations
 137  such as Windows 2000 where aggressive mode is the default. Typically,
 138  these are easily solved with a configuration change that overrides that
 139  default.</P>
 140 <H3><A name="not">Not (yet) in Linux FreeS/WAN</A></H3>
 141 <P>Things we don't yet do, as of version 1.96:</P>
 142 <UL>
 143 <LI>key management methods
 144 <UL>
 145 <LI>authenticate key negotiations via local<A href="glossary.html#PKI">
 146  PKI</A> server, but see links to user<A href="web.html#patch"> patches</A>
 147 </LI>
 148 <LI>authenticate key negotiations via<A href="glossary.html#SDNS">
 149  secure DNS</A></LI>
 150 <LI>unauthenticated key management, using<A href="glossary.html#DH">
 151  Diffie-Hellman</A> key agreement protocol without authentication.
 152  Arguably, this would be worth doing since it is secure against all
 153  passive attacks. On the other hand, it is vulnerable to an active<A href="glossary.html#middle">
 154  man-in-the-middle attack</A>.</LI>
 155 </UL>
 156 </LI>
 157 <LI>encryption transforms
 158 <P>Currently<A href="glossary.html#3DES"> Triple DES</A> is the only
 159  encryption method Pluto will negotiate.</P>
 160 <P>No additional encryption transforms are implemented, though the RFCs
 161  allow them and some other IPsec implementations support various of
 162  them. We are not eager to add more. See this<A href="faq.html#other.cipher">
 163  FAQ question</A>.</P>
 164 <P><A href="glossary.html#AES">AES</A>, the successor to the DES
 165  standard, is an excellent candidate for inclusion in FreeS/WAN, see
 166  links to user<A href="web.html#patch"> patches</A>.</P>
 167 </LI>
 168 <LI>authentication transforms
 169 <P>No optional additional authentication transforms are currently
 170  implemented. Likely<A href="glossary.html#SHA-256"> SHA-256, SHA-384
 171  and SHA-512</A> will be added when AES is.</P>
 172 </LI>
 173 <LI>Policy checking on decrypted packets
 174 <P>To fully comply with the RFCs, it is not enough just to accept only
 175  packets which survive any firewall rules in place to limit what IPsec
 176  packets get in, and then pass KLIPS authentication. That is what
 177  FreeS/WAN currently does.</P>
 178 <P>We should also apply additional tests, for example ensuring that all
 179  packets emerging from a particular tunnel have source and destination
 180  addresses that fall within the subnets defined for that tunnel, and
 181  that packets with those addresses that did not emerge from the
 182  appropriate tunnel are disallowed.</P>
 183 <P>This will be done as part of a KLIPS rewrite. See these<A href="intro.html#applied">
 184  links</A> and the<A href="mail.html"> design mailing list</A> for
 185  discussion.</P>
 186 </LI>
 187 </UL>
 188 <H2><A name="pfkey">Our PF-Key implementation</A></H2>
 189 <P>We use PF-key Version Two for communication between the KLIPS kernel
 190  code and the Pluto Daemon. PF-Key v2 is defined by<A href="http://www.normos.org/ietf/rfc/rfc2367.txt">
 191  RFC 2367</A>.</P>
 192 <P>The &quot;PF&quot; stands for Protocol Family. PF-Inet defines a
 193  kernel/userspace interface for the TCP/IP Internet protocols (TCP/IP),
 194  and other members of the PF series handle Netware, Appletalk, etc.
 195  PF-Key is just a PF for key-related matters.</P>
 196 <H3><A name="pfk.port">PF-Key portability</A></H3>
 197 <P>PF-Key came out of Berkeley Unix work and is used in the various BSD
 198  IPsec implementations, and in Solaris. This means there is some hope of
 199  porting our Pluto(8) to one of the BSD distributions, or of running
 200  their photurisd(8) on Linux if you prefer<A href="glossary.html#photuris">
 201  Photuris</A> key management over IKE.</P>
 202 <P>It is, however, more complex than that. The PK-Key RFC deliberately
 203  deals only with keying, not policy management. The three PF-Key
 204  implementations we have looked at -- ours, OpenBSD and KAME -- all have
 205  extensions to deal with security policy, and the extensions are
 206  different. There have been discussions aimed at sorting out the
 207  differences, perhaps for a version three PF-Key spec. All players are
 208  in favour of this, but everyone involved is busy and it is not clear
 209  whether or when these discussions might bear fruit.</P>
 210 <H2><A name="otherk">Kernels other than the latest 2.2.x and 2.4.y</A></H2>
 211 <P>We develop and test on Redhat Linux using the most recent kernel in
 212  the 2.2 and 2.4 series. In general, we recommend you use the latest
 213  kernel in one of those series. Complications and caveats are discussed
 214  below.</P>
 215 <H3><A name="kernel.2.0">2.0.x kernels</A></H3>
 216 <P>Consider upgrading to the 2.2 kernel series. If you want to stay with
 217  the 2.0 series, then we strongly recommend 2.0.39. Some useful security
 218  patches were added in 2.0.38.</P>
 219 <P>Various versions of the code have run at various times on most 2.0.xx
 220  kernels, but the current version is only lightly tested on 2.0.39, and
 221  not at all on older kernels.</P>
 222 <P>Some of our patches for older kernels are shipped in 2.0.37 and
 223  later, so they are no longer provided in FreeS/WAN. This means recent
 224  versions of FreeS/WAN will probably not compile on anything earlier
 225  than 2.0.37.</P>
 226 <H3><A name="kernel.production">2.2 and 2.4 kernels</A></H3>
 227 <DL>
 228 <DT>FreeS/WAN 1.0</DT>
 229 <DD>ran only on 2.0 kernels</DD>
 230 <DT>FreeS/WAN 1.1 to 1.8</DT>
 231 <DD>ran on 2.0 or 2.2 kernels
 232 <BR> ran on some development kernels, 2.3 or 2.4-test</DD>
 233 <DT>FreeS/WAN 1.9 to 1.96</DT>
 234 <DD>runs on 2.0, 2.2 or 2.4 kernels</DD>
 235 </DL>
 236 <P>In general,<STRONG> we suggest the latest 2.2 kernel or 2.4 for
 237  production use</STRONG>.</P>
 238 <P>Of course no release can be guaranteed to run on kernels more recent
 239  than it is, so quite often there will be no stable FreeS/WAN for the
 240  absolute latest kernel. See the<A href="faq.html#k.versions"> FAQ</A>
 241  for discussion.</P>
 242 <H2><A name="otherdist">Intel Linux distributions other than Redhat</A></H2>
 243 <P>We develop and test on Redhat 6.1 for 2.2 kernels, and on Redhat 7.1
 244  or 7.2 for 2.4, so minor changes may be required for other
 245  distributions.</P>
 246 <H3><A name="rh7">Redhat 7.0</A></H3>
 247 <P>There are some problems with FreeS/WAN on Redhat 7.0. They are
 248  soluble, but we recommend you upgrade to a later Redhat instead..</P>
 249 <P>Redhat 7 ships with two compilers.</P>
 250 <UL>
 251 <LI>Their<VAR> gcc</VAR> is version 2.96. Various people, including the
 252  GNU compiler developers and Linus, have said fairly emphatically that
 253  using this was a mistake. 2.96 is a development version, not intended
 254  for production use. In particular, it will not compile a Linux kernel.</LI>
 255 <LI>Redhat therefore also ship a separate compiler, which they call<VAR>
 256  kgcc</VAR>, for compiling kernels.</LI>
 257 </UL>
 258 <P>Kernel Makefiles have<VAR> gcc</VAR> as a default, and must be
 259  adjusted to use<VAR> kgcc</VAR> before a kernel will compile on 7.0.
 260  This mailing list message gives details:</P>
 261 <PRE>Subject: Re: AW: Installing IPsec on Redhat 7.0
 262    Date: Thu, 1 Feb 2001 14:32:52 -0200 (BRST)
 263   From: Mads Rasmussen &lt;mads@cit.com.br&gt;
 264
 265 &gt; From www.redhat.com/support/docs/gotchas/7.0/gotchas-7-6.html#ss6.1
 266
 267 cd to /usr/src/linux and open the Makefile in your favorite editor. You
 268 will need to look for a line similar to this:
 269
 270 CC = $(CROSS_COMPILE)gcc -D__KERNEL__ -I$(HPATH)
 271
 272 This line specifies which C compiler to use to build the kernel. It should
 273 be changed to:
 274
 275 CC = $(CROSS_COMPILE)kgcc -D__KERNEL__ -I$(HPATH)
 276
 277 for Red Hat Linux 7. The kgcc compiler is egcs 2.91.66. From here you can
 278 proceed with the typical compiling steps.</PRE>
 279 <P>Check the<A href="mail.html"> mailing list</A> archive for more
 280  recent news.</P>
 281 <H3><A name="suse">SuSE Linux</A></H3>
 282 <P>SuSE 6.3 and later versions, at least in Europe, ship with FreeS/WAN
 283  included.</P>
 284 <P>FreeS/WAN packages distributed for SuSE 7.0-7.2 were somehow
 285  miscompiled. You can find fixed packages on<A HREF="http://www.suse.de/~garloff/linux/FreeSWAN">
 286  Kurt Garloff's page</A>.</P>
 287 <P>Here are some notes for an earlier SuSE version.</P>
 288 <H4>SuSE Linux 5.3</H4>
 289 <PRE>Date: Mon, 30 Nov 1998
 290 From: Peter Onion &lt;ponion@srd.bt.co.uk&gt;
 291
 292 ... I got Saturdays snapshot working between my two SUSE5.3 machines at home.
 293
 294 The mods to the install process are quite simple.  From memory and looking at
 295 the files on the SUSE53 machine here at work....
 296
 297 And extra link in each of the /etc/init.d/rc?.d directories called K35ipsec
 298 which SUSE use to shut a service down.
 299
 300 A few mods in /etc/init.d/ipsec  to cope with the different places that SUSE
 301 put config info, and remove the inculsion of /etc/rc.d/init.d/functions and .
 302 /etc/sysconfig/network as they don't exists and 1st one isn't needed anyway.
 303
 304 insert &quot;. /etc/rc.config&quot; to pick up the SUSE config info and use
 305
 306   if test -n &quot;$NETCONFIG&quot; -a &quot;$NETCONFIG&quot; != &quot;YAST_ASK&quot; ; then
 307
 308 to replace
 309
 310   [ ${NETWORKING} = &quot;no&quot; ] &amp;&amp; exit 0
 311
 312 Create /etc/sysconfig  as SUSE doesn't have one.
 313
 314 I think that was all (but I prob forgot something)....</PRE>
 315 <P>You may also need to fiddle initialisation scripts to ensure that<VAR>
 316  /var/run/pluto.pid</VAR> is removed when rebooting. If this file is
 317  present, Pluto does not come up correctly.</P>
 318 <H3><A name="slack">Slackware</A></H3>
 319 <PRE>Subject: Re: linux-IPsec: Slackware distribution
 320   Date:  Thu, 15 Apr 1999 12:07:01 -0700
 321   From:  Evan Brewer &lt;dmessiah@silcon.com&gt;
 322
 323 &gt; Very shortly, I will be needing to install IPsec on at least gateways that
 324 &gt; are running Slackware. . . .
 325
 326 The only trick to getting it up is that on the slackware dist there is no
 327 init.d directory in /etc/rc.d .. so create one.  Then, what I do is take the
 328 IPsec startup script which normally gets put into the init.d directory, and
 329 put it in /etc/rc.d and name ir rc.ipsec .. then I symlink it to the file
 330 in init.d.  The only file in the dist you need to really edit is the
 331 utils/Makefile, setup4:
 332
 333 Everything else should be just fine.</PRE>
 334 <P>A year or so later:</P>
 335 <PRE>Subject: Re: HTML Docs- Need some cleanup?
 336    Date: Mon, 8 Jan 2001
 337    From: Jody McIntyre &lt;jodym@oeone.com&gt;
 338
 339 I have successfully installed FreeS/WAN on several Slackware 7.1 machines.
 340 FreeS/WAN installed its rc.ipsec file in /etc/rc.d.  I had to manually call
 341 this script from rc.inet2.  This seems to be an easier method than Evan
 342 Brewer's.</PRE>
 343 <H3><A name="deb">Debian</A></H3>
 344 <P>A recent (Nov 2001) mailing list points to a<A href="http://www.thing.dyndns.org/debian/vpn.htm">
 345  web page</A> on setting up several types of tunnel, including IPsec, on
 346  Debian.</P>
 347 <P>Some older information:</P>
 348 <PRE>Subject: FreeS/WAN 1.0 on Debian 2.1
 349    Date: Tue, 20 Apr 1999
 350   From:  Tim Miller &lt;cerebus+counterpane@haybaler.sackheads.org&gt;
 351
 352         Compiled and installed without error on a Debian 2.1 system
 353 with kernel-source-2.0.36 after pointing RCDIR in utils/Makefile to
 354 /etc/init.d.
 355
 356         /var/lock/subsys/ doesn't exist on Debian boxen, needs to be
 357 created; not a fatal error.
 358
 359         Finally, IPsec scripts appear to be dependant on GNU awk
 360 (gawk); the default Debian awk (mawk-1.3.3-2) had fatal difficulties.
 361 With gawk installed and /etc/alternatives/awk linked to /usr/bin/gawk
 362 operation appears flawless.</PRE>
 363 <P>The scripts in question have been modified since this was posted. Awk
 364  versions should no longer be a problem.</P>
 365 <H3><A name="caldera">Caldera</A></H3>
 366 <PRE>Subject: Re: HTML Docs- Need some cleanup?
 367    Date: Mon, 08 Jan 2001
 368    From: Andy Bradford &lt;andyb@calderasystems.com&gt;
 369
 370 On Sun, 07 Jan 2001 22:59:05 EST, Sandy Harris wrote:
 371
 372 &gt;     Intel Linux distributions other than Redhat 5.x and 6.x
 373 &gt;         Redhat 7.0
 374 &gt;         SuSE Linux
 375 &gt;             SuSE Linux 5.3
 376 &gt;         Slackware
 377 &gt;         Debian
 378
 379 Can you please include Caldera in this list?  I have tested it since
 380 FreeS/Wan 1.1 and it works great with our systems---provided one
 381 follows the FreeS/Wan documentation. :-)
 382
 383 Thank you,
 384 Andy</PRE>
 385 <H2><A name="CPUs">CPUs other than Intel</A></H2>
 386 <P>FreeS/WAN has been run sucessfully on a number of different CPU
 387  architectures. If you have tried it on one not listed here, please post
 388  to the<A href="mail.html"> mailing list</A>.</P>
 389 <H3><A name=" strongarm">Corel Netwinder (StrongARM CPU)</A></H3>
 390 <PRE>Subject: linux-ipsec: Netwinder diffs
 391 Date: Wed, 06 Jan 1999
 392 From: rhatfield@plaintree.com
 393
 394 I had a mistake in my IPsec-auto, so I got things working this morning.
 395
 396 Following are the diffs for my changes.  Probably not the best and cleanest way
 397 of doing it, but it works. . . . </PRE>
 398 <P>These diffs are in the 0.92 and later distributions, so these should
 399  work out-of-the-box on Netwinder.</P>
 400 <H3><A name="yellowdog">Yellow Dog Linux on Power PC</A></H3>
 401 <PRE>Subject:  Compiling FreeS/WAN 1.1 on YellowDog Linux (PPC)
 402    Date:  11 Dec 1999
 403    From:  Darron Froese &lt;darron@fudgehead.com&gt;
 404
 405 I'm summarizing here for the record - because it's taken me many hours to do
 406 this (multiple times) and because I want to see IPsec on more linuxes than
 407 just x86.
 408
 409 Also, I can't remember if I actually did summarize it before... ;-) I'm
 410 working too many late hours.
 411
 412 That said - here goes.
 413
 414 1. Get your linux kernel and unpack into /usr/src/linux/ - I used 2.2.13.
 415 &lt;http://www.kernel.org/pub/linux/kernel/v2.2/linux-2.2.13.tar.bz2&gt;
 416
 417 2. Get FreeS/WAN and unpack into /usr/src/freeswan-1.1
 418 &lt;ftp://ftp.xs4all.nl/pub/crypto/freeswan/freeswan-1.1.tar.gz&gt;
 419
 420 3. Get the gmp src rpm from here:
 421 &lt;ftp://ftp.yellowdoglinux.com//pub/yellowdog/champion-1.1/SRPMS/SRPMS/gmp-2.0.2-9a.src.rpm&gt;
 422
 423 4. Su to root and do this: rpm --rebuild gmp-2.0.2-9a.src.rpm
 424
 425 You will see a lot of text fly by and when you start to see the rpm
 426 recompiling like this:
 427
 428 Executing: %build
 429 + umask 022
 430 + cd /usr/src/redhat/BUILD
 431 + cd gmp-2.0.2
 432 + libtoolize --copy --force
 433 Remember to add `AM_PROG_LIBTOOL' to `configure.in'.
 434 You should add the contents of `/usr/share/aclocal/libtool.m4' to
 435 `aclocal.m4'.
 436 + CFLAGS=-O2 -fsigned-char
 437 + ./configure --prefix=/usr
 438
 439 Hit Control-C to stop the rebuild. NOTE: We're doing this because for some
 440 reason the gmp source provided with FreeS/WAN 1.1 won't build properly on
 441 ydl.
 442
 443 cd /usr/src/redhat/BUILD/
 444 cp -ar gmp-2.0.2 /usr/src/freeswan-1.1/
 445 cd /usr/src/freeswan-1.1/
 446 rm -rf gmp
 447 mv gmp-2.0.2 gmp
 448
 449 5. Open the freeswan Makefile and change the line that says:
 450 KERNEL=$(b)zimage (or something like that) to
 451 KERNEL=vmlinux
 452
 453 6. cd ../linux/
 454
 455 7. make menuconfig
 456 Select an option or two and then exit - saving your changes.
 457
 458 8. cd ../freeswan-1.1/ ; make menugo
 459
 460 That will start the whole process going - once that's finished compiling,
 461 you have to install your new kernel and reboot.
 462
 463 That should build FreeS/WAN on ydl (I tried it on 1.1).</PRE>
 464  And a later message on the same topic:
 465 <PRE>Subject: Re: FreeS/WAN, PGPnet and E-mail
 466    Date: Sat, 22 Jan 2000
 467    From: Darron Froese &lt;darron@fudgehead.com&gt;
 468
 469 on 1/22/00 6:47 PM, Philip Trauring at philip@trauring.com wrote:
 470
 471 &gt; I have a PowerMac G3 ...
 472
 473 The PowerMac G3 can run YDL 1.1 just fine. It should also be able to run
 474 FreeS/WAN 1.2patch1 with a couple minor modifications:
 475
 476 1. In the Makefile it specifies a bzimage for the kernel compile - you have
 477 to change that to vmlinux for the PPC.
 478
 479 2. The gmp source that comes with FreeS/WAN (for whatever reason) fails to
 480 compile. I have gotten around this by getting the gmp src rpm from here:
 481
 482 ftp://ftp.yellowdoglinux.com//pub/yellowdog/champion-1.1/SRPMS/SRPMS/gmp-2.0.2-9a.src.rpm
 483
 484 If you rip the source out of there - and place it where the gmp source
 485 resides it will compile just fine.</PRE>
 486 <P>FreeS/WAN no longer includes GMP source.</P>
 487 <H3><A name="mklinux">Mklinux</A></H3>
 488 <P>One user reports success on the Mach-based<STRONG> m</STRONG>icro<STRONG>
 489 k</STRONG>ernel Linux.</P>
 490 <PRE>Subject: Smiles on sparc and ppc
 491    Date: Fri, 10 Mar 2000
 492    From: Jake Hill &lt;jah@alien.bt.co.uk&gt;
 493
 494 You may or may not be interested to know that I have successfully built
 495 FreeS/WAN on a number of non intel alpha architectures; namely on ppc
 496 and sparc and also on osfmach3/ppc (MkLinux). I can report that it just
 497 works, mostly, with few changes.</PRE>
 498 <H3><A name="alpha">Alpha 64-bit processors</A></H3>
 499 <PRE>Subject: IT WORKS (again) between intel &amp; alpha :-)))))
 500    Date: Fri, 29 Jan 1999
 501    From: Peter Onion &lt;ponion@srd.bt.co.uk&gt;
 502
 503 Well I'm happy to report that I've got an IPsec connection between by intel &amp; alpha machines again :-))
 504
 505 If you look back on this list to 7th of December I wrote...
 506
 507 -On 07-Dec-98 Peter Onion wrote:
 508 -&gt;
 509 -&gt; I've about had enuf of wandering around inside the kernel trying to find out
 510 -&gt; just what is corrupting outgoing packets...
 511 -
 512 -Its 7:30 in the evening .....
 513 -
 514 -I FIXED IT  :-))))))))))))))))))))))))))))))))
 515 -
 516 -It was my own fault :-((((((((((((((((((
 517 -
 518 -If you ask me very nicly I'll tell you where I was a little too over keen to
 519 -change unsigned long int __u32 :-)  OPSE ...
 520 -
 521 -So tomorrow it will full steam ahead to produce a set of diffs/patches against
 522 -0.91
 523 -
 524 -Peter Onion.</PRE>
 525 <P>In general (there have been some glitches), FreeS/WAN has been
 526  running on Alphas since then.</P>
 527 <H3><A name="SPARC">Sun SPARC processors</A></H3>
 528 <P>Several users have reported success with FreeS/WAN on SPARC Linux.
 529  Here is one mailing list message:</P>
 530 <PRE>Subject: Smiles on sparc and ppc
 531    Date: Fri, 10 Mar 2000
 532    From: Jake Hill &lt;jah@alien.bt.co.uk&gt;
 533
 534 You may or may not be interested to know that I have successfully built
 535 FreeS/WAN on a number of non intel alpha architectures; namely on ppc
 536 and sparc and also on osfmach3/ppc (MkLinux). I can report that it just
 537 works, mostly, with few changes.
 538
 539 I have a question, before I make up some patches. I need to hack
 540 gmp/mpn/powerpc32/*.s to build them. Is this ok? The changes are
 541 trivial, but could I also use a different version of gmp? Is it vanilla
 542 here?
 543
 544 I guess my only real headache is from ipchains, which appears to stop
 545 running when IPsec has been started for a while. This is with 2.2.14 on
 546 sparc.</PRE>
 547 <P>This message, from a different mailing list, may be relevant for
 548  anyone working with FreeS/WAN on Suns:</P>
 549 <PRE>Subject: UltraSPARC DES assembler
 550    Date: Thu, 13 Apr 2000
 551    From: svolaf@inet.uni2.dk (Svend Olaf Mikkelsen)
 552      To: coderpunks@toad.com
 553
 554 An UltraSPARC assembler version of the LibDES/SSLeay/OpenSSL des_enc.c
 555 file is available at http://inet.uni2.dk/~svolaf/des.htm.
 556
 557 This brings DES on UltraSPARC from slower than Pentium at the same
 558 clock speed to significantly faster.</PRE>
 559 <H3><A name="mips">MIPS processors</A></H3>
 560 <P>We know FreeS/WAN runs on at least some MIPS processors because<A href="http://www.lasat.com">
 561  Lasat</A> manufacture an IPsec box based on an embedded MIPS running
 562  Linux with FreeS/WAN. We have no details.</P>
 563 <H3><A name="crusoe">Transmeta Crusoe</A></H3>
 564 <P>The Merilus<A href="http://www.merilus.com/products/fc/index.shtml">
 565  Firecard</A>, a Linux firewall on a PCI card, is based on a Crusoe
 566  processor and supports FreeS/WAN.</P>
 567 <H3><A name="coldfire">Motorola Coldfire</A></H3>
 568 <PRE>Subject: Re: Crypto hardware support
 569    Date: Mon, 03 Jul 2000
 570    From: Dan DeVault &lt;devault@tampabay.rr.com&gt;
 571
 572 .... I have been running
 573 uClinux with FreeS/WAN 1.4 on a system built by Moreton Bay  (
 574 http://www.moretonbay.com )  and it was using a Coldfire processor
 575 and was able to do the Triple DES encryption at just about
 576 1 mbit / sec rate.......  they put a Hi/Fn 7901 hardware encryption
 577 chip on their board and now their system does over 25 mbit of 3DES
 578 encryption........ pretty significant increase if you ask me.</PRE>
 579 <H2><A name="multiprocessor">Multiprocessor machines</A></H2>
 580 <P>FreeS/WAN is designed to work on SMP (symmetric multi-processing)
 581  Linux machines and is regularly tested on dual processor x86 machines.</P>
 582 <P>We do not know of any testing on multi-processor machines with other
 583  CPU architectures or with more than two CPUs. Anyone who does test
 584  this, please report results to the<A href="mail.html"> mailing list</A>
 585 .</P>
 586 <P>The current design does not make particularly efficient use of
 587  multiprocessor machines; some of the kernel work is single-threaded.</P>
 588 <H2><A name="hardware">Support for crypto hardware</A></H2>
 589 <P>Supporting hardware cryptography accelerators has not been a high
 590  priority for the development team because it raises a number of fairly
 591  complex issues:</P>
 592 <UL>
 593 <LI>Can you trust the hardware? If it is not Open Source, how do you
 594  audit its security? Even if it is, how do you check that the design has
 595  no concealed traps?</LI>
 596 <LI>If an interface is added for such hardware, can that interface be
 597  subverted or misused?</LI>
 598 <LI>Is hardware acceleration actually a performance win? It clearly is
 599  in many cases, but on a fast machine it might be better to use the CPU
 600  for the encryption than to pay the overheads of moving data to and from
 601  a crypto board.</LI>
 602 <LI>the current KLIPS code does not provide a clean interface for
 603  hardware accelerators</LI>
 604 </UL>
 605 <P>That said, we have a<A href="#coldfire"> report</A> of FreeS/WAN
 606  working with one crypto accelerator and some work is going on to modify
 607  KLIPS to create a clean generic interface to such products. See this<A href="http://www.jukie.net/~bart/linux-ipsec/">
 608  web page</A> for some of the design discussion.</P>
 609 <P>More recently, a patch to support some hardware accelerators has been
 610  posted:</P>
 611 <PRE>Subject: [Design] [PATCH] H/W acceleration patch
 612    Date: Tue, 18 Sep 2001
 613    From: &quot;Martin Gadbois&quot; &lt;martin.gadbois@colubris.com&gt;
 614
 615 Finally!!
 616 Here's a web site with H/W acceleration patch for FreeS/WAN 1.91, including
 617 S/W and Hifn 7901 crypto support.
 618
 619 http://sources.colubris.com/
 620
 621 Martin Gadbois</PRE>
 622 <P>Hardware accelerators could take performance well beyond what
 623  FreeS/WAN can do in software (discussed<A href="performance.html"> here</A>
 624 ). Here is some discussion off the IETF IPsec list, October 2001:</P>
 625 <PRE> ... Currently shipping chips deliver, 600 mbps throughput on a single
 626  stream of 3DES IPsec traffic.  There are also chips that use multiple
 627  cores to do 2.4 gbps.  We (Cavium) and others have announced even faster
 628  chips. ... Mid 2002 versions will handle at line rate (OC48 and OC192)
 629  IPsec and SSL/TLS traffic not only 3DES CBC but also AES and arc4.</PRE>
 630 <P>The patches to date support chips that have been in production for
 631  some time, not the state-of-the-art latest-and-greatest devices
 632  described in that post. However, they may still outperform software and
 633  they almost certainly reduce CPU overhead.</P>
 634 <H2><A name="ipv6">IP version 6 (IPng)</A></H2>
 635 <P>The Internet currently runs on version four of the IP protocols. IPv4
 636  is what is in the standard Linux IP stack, and what FreeS/WAN was built
 637  for. In IPv4, IPsec is an optional feature.</P>
 638 <P>The next version of the IP protocol suite is version six, usually
 639  abbreviated either as &quot;IPv6&quot; or as &quot;IPng&quot; for &quot;IP: the next
 640  generation&quot;. For IPv6, IPsec is a required feature. Any machine doing
 641  IPv6 is required to support IPsec, much as any machine doing (any
 642  version of) IP is required to support ICMP.</P>
 643 <P>There is a Linux implementation of IPv6 in Linux kernels 2.2 and
 644  above. For details, see the<A href="http://www.cs-ipv6.lancs.ac.uk/ipv6/systems/linux/faq/">
 645  FAQ</A>. It does not yet support IPsec. The<A href="http://www.linux-ipv6.org/">
 646  USAGI</A> project are also working on IPv6 for Linux.</P>
 647 <P>FreeS/WAN was originally built for the current standard, IPv4, but we
 648  are interested in seeing it work with IPv6. Some progress has been
 649  made, and a patched version with IPv6 support is<A href="http://www.ipv6.iabg.de/downloadframe/index.html">
 650  available</A>. For more recent information, check the<A href="mail.html">
 651  mailing list</A>.</P>
 652 <H3><A name="v6.back">IPv6 background</A></H3>
 653 <P>IPv6 has been specified by an IETF<A href="http://www.ietf.org/html.charters/ipngwg-charter.html">
 654  working group</A>. The group's page lists over 30 RFCs to date, and
 655  many Internet Drafts as well. The overview is<A href="http://www.ietf.org/rfc/rfc2460.txt">
 656  RFC 2460</A>. Major features include:</P>
 657 <UL>
 658 <LI>expansion of the address space from 32 to 128 bits,</LI>
 659 <LI>changes to improve support for
 660 <UL>
 661 <LI>mobile IP</LI>
 662 <LI>automatic network configuration</LI>
 663 <LI>quality of service routing</LI>
 664 <LI>...</LI>
 665 </UL>
 666 </LI>
 667 <LI>improved security via IPsec</LI>
 668 </UL>
 669 <P>A number of projects are working on IPv6 implementation. A prominent
 670  Open Source effort is<A href="http://www.kame.net/"> KAME</A>, a
 671  collaboration among several large Japanese companies to implement IPv6
 672  for Berkeley Unix. Other major players are also working on IPv6. For
 673  example, see pages at:</P>
 674 <UL>
 675 <LI><A href="http://playground.sun.com/pub/ipng/html/ipng-main.html">Sun</A>
 676 </LI>
 677 <LI><A href="http://www.cisco.com/warp/public/732/ipv6/index.html">Cisco</A>
 678 </LI>
 679 <LI><A href="http://www.microsoft.com/windows2000/techinfo/howitworks/communications/networkbasics/IPv6.asp">
 680 Microsoft</A></LI>
 681 </UL>
 682 <P>The<A href="http://www.6bone.net/"> 6bone</A> (IPv6 backbone) testbed
 683  network has been up for some time. There is an active<A href="http://www.ipv6.org/">
 684  IPv6 user group</A>.</P>
 685 <P>One of the design goals for IPv6 was that it must be possible to
 686  convert from v4 to v6 via a gradual transition process. Imagine the
 687  mess if there were a &quot;flag day&quot; after which the entire Internet used
 688  v6, and all software designed for v4 stopped working. Almost every
 689  computer on the planet would need major software changes! There would
 690  be huge costs to replace older equipment. Implementers would be worked
 691  to death before &quot;the day&quot;, systems administrators and technical support
 692  would be completely swamped after it. The bugs in every implementation
 693  would all bite simultaneously. Large chunks of the net would almost
 694  certainly be down for substantial time periods. ...</P>
 695 <P>Fortunately, the design avoids any &quot;flag day&quot;. It is therefore a
 696  little tricky to tell how quickly IPv6 will take over. The transition
 697  has certainly begun. For examples, see announcements from<A href="http://www.mailbase.ac.uk/lists/internet2/2000-03/0016.html">
 698  NTT</A> and<A href="http://www.vnunet.com/News/1102383"> Nokia</A>.
 699  However, it is not yet clear how quickly the process will gain
 700  momentum, or when it will be completed. Likely large parts of the
 701  Internet will remain with IPv4 for years to come.</P>
 702 <HR>
 703 <A HREF="toc.html">Contents</A>
 704 <A HREF="trouble.html">Previous</A>
 705 <A HREF="interop.html">Next</A>
 706 </BODY>
 707 </HTML>