freeswan/doc/src/compat.html

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