"Fossies" - the Fresh Open Source Software Archive

Member "freeswan-2.06/BUGS" (10 Apr 2004, 4386 Bytes) of package /linux/misc/old/freeswan-2.06.tar.gz:


As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    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 * It was our intent for Opportunistic Encryption to work with 4096 bit keys.
    5   Currently, there is a buffer limitation that prevents this; the additional 
    6   text in TXT records wasn't properly factored into the buffer length. If 
    7   you wish to use a key larger than the default of 2192 bits, keep the size 
    8   under 4k. This will be fixed in a future release.
    9 
   10 * Module built against RedHat 7.1 2.4.2 kernels do not forward large packets.
   11   The reason for this is unknown. Upgrade to a newer kernel.
   12 
   13 * If there are multiple connections specified between the same two
   14   security gateways, either all or none must specify compression.  Otherwise
   15   the result is unpredictable. 
   16 
   17 * Pluto will not retry if it can not find its key in DNS when it starts.
   18 
   19 * Extrusion and Opportunistic Encryption do not mix well without
   20   Advanced Routing. (There is a workaround using advanced routing)
   21 
   22 * Installing a new FreeS/WAN on top of an old one doesn't update kernel
   23   configuration options, so if new options are added, you need to start
   24   with a virgin kernel instead.
   25 
   26 * KLIPS cannot cope with IP packets employing IP options.  This has
   27   caused no trouble that we know of, somewhat to our surprise.
   28 
   29 * There are some ill-defined problems with sending large packets through
   30   transport-mode connections, especially in 2.2.xx kernels.
   31 
   32 * There appears to be a kernel memory leak if rekeying occurs while a
   33   connection is carrying traffic.  The effect is small unless you are
   34   rekeying very frequently indeed.
   35 
   36 * There are too many ways for packets to get around the security stuff. 
   37   In particular, suppose you have the following, with security gateways X
   38   and Y serving subnets S and T: 
   39 
   40         S======X........Y======T
   41 
   42   A packet which shows up at Y, in clear text, claiming to be from S, with a
   43   destination in T, will be forwarded... even if there is an IPsec tunnel
   44   between X and Y which ought to be encrypting all such packets.  The damage
   45   such packets could do is limited, but denial-of-service attacks are an
   46   obvious possibility.  Dealing with this is difficult in general, because
   47   we aren't quite close enough yet to the center of the IP processing
   48   machinery.  For now, careful firewalling is needed. 
   49 
   50 * Another "packet leak" arises because at startup, shutdown, or restart,
   51   there is a brief period when the network is up but IPsec is not.  This
   52   exposure can be reduced using the forwardcontrol parameter. 
   53 
   54 * A similar leak occurs because there is no simple way to *replace* a
   55   route using the Linux 2.2.xx route(8) command.  It has to be done with a
   56   delete/add sequence, which leaves a timing window in which there is no
   57   route for the destination.  Workarounds are complex; firewalling is
   58   probably the best countermeasure right now.
   59 
   60 * Yet another potential leak arises because the PF_KEYv2 replace form of
   61   addroute command is non-atomic.  There is a possibility for packets to
   62   slip through the eroute table to a more general eroute between deletion
   63   and addition of an eroute.  This is usually of no importance because the
   64   packets will generally end up getting dropped rather than forwarded.
   65 
   66 * Minor difficulties can arise if more than one subnet is behind a single
   67   security gateway, e.g.: 
   68 
   69         S======X.........Y======T
   70                          \\
   71                            ======U
   72 
   73   If U wants to talk to S encrypted, but T wants to talk to S in clear (no
   74   IPsec), it actually is possible... but it has to be done with manual
   75   keying's %passthrough feature, which is a little messy if the U-S
   76   connection is automatically keyed, because the two connections share a
   77   route but Pluto is not aware of this. 
   78 
   79 * The number of IPsec interfaces is coded at 4, but can be
   80   changed by editing linux/net/ipsec/ipsec_param.h. It can not
   81   adjusted dynamically at run-time, which is the bug.
   82 
   83 * When building as a module, there is a memory leak when loading/unloading
   84   several times. We have not identified the source of this leak. It is on
   85   the order of 8k. As we expect some turbulence in the kernel component
   86   in the early months of 2003, we are not going to pursue this at this time.
   87   Our test case, module-memory-01 therefore fails.
   88 
   89 This file is RCSID $Id: BUGS,v 1.55 2004/04/10 04:28:28 sam Exp $