freeswan/BUGS

   1 This code is still less than perfect and undoubtedly has bugs.  As of this
   2 release, the following are considered *serious* bugs:
   3
   4 * Module built against RedHat 7.1 2.4.2 kernels do not forward large packets.
   5   The reason for this is unknown. Upgrade to a newer kernel.
   6
   7 * If there are multiple connections specified between the same two
   8   security gateways, either all or none must specify compression.  Otherwise
   9   the result is unpredictable.
  10
  11 * Installing a new FreeS/WAN on top of an old one doesn't update kernel
  12 configuration options, so if new options are added, you need to start
  13 with a virgin kernel instead.
  14
  15 * KLIPS cannot cope with IP packets employing IP options.  This has
  16 caused no trouble that we know of, somewhat to our surprise.
  17
  18 * There are some ill-defined problems with sending large packets through
  19 transport-mode connections, especially in 2.2.xx kernels.
  20
  21 * There appears to be a kernel memory leak if rekeying occurs while a
  22 connection is carrying traffic.  The effect is small unless you are
  23 rekeying very frequently indeed.
  24
  25 * There are too many ways for packets to get around the security stuff.
  26 In particular, suppose you have the following, with security gateways X
  27 and Y serving subnets S and T:
  28
  29         S======X........Y======T
  30
  31 A packet which shows up at Y, in clear text, claiming to be from S, with a
  32 destination in T, will be forwarded... even if there is an IPsec tunnel
  33 between X and Y which ought to be encrypting all such packets.  The damage
  34 such packets could do is limited, but denial-of-service attacks are an
  35 obvious possibility.  Dealing with this is difficult in general, because
  36 we aren't quite close enough yet to the center of the IP processing
  37 machinery.  For now, careful firewalling is needed.
  38
  39 * Another "packet leak" arises because at startup, shutdown, or restart,
  40 there is a brief period when the network is up but IPsec is not.  This
  41 exposure can be reduced using the forwardcontrol parameter.
  42
  43 * A similar leak occurs because there is no simple way to *replace* a
  44 route using the Linux 2.2.xx route(8) command.  It has to be done with a
  45 delete/add sequence, which leaves a timing window in which there is no
  46 route for the destination.  Workarounds are complex; firewalling is
  47 probably the best countermeasure right now.
  48
  49 * Yet another potential leak arises because the PF_KEYv2 replace form of
  50 addroute command is non-atomic.  There is a possibility for packets to
  51 slip through the eroute table to a more general eroute between deletion
  52 and addition of an eroute.  This is usually of no importance because the
  53 packets will generally end up getting dropped rather than forwarded.
  54
  55 * Minor difficulties can arise if more than one subnet is behind a single
  56 security gateway, e.g.:
  57
  58         S======X.........Y======T
  59                          \\
  60                            ======U
  61
  62 If U wants to talk to S encrypted, but T wants to talk to S in clear (no
  63 IPsec), it actually is possible... but it has to be done with manual
  64 keying's %passthrough feature, which is a little messy if the U-S
  65 connection is automatically keyed, because the two connections share a
  66 route but Pluto is not aware of this.
  67
  68 * The number of IPsec interfaces is hardcoded at 4 rather than being
  69 configurable (although at least it's not 2 any more).
  70
  71
  72
  73 This file is RCSID $Id: BUGS,v 1.46.2.1 2002/04/12 15:40:49 mcr Exp $