This code is still preliminary and undoubtedly has assorted bugs.  As of
version 1.00, the following are considered *serious* bugs:

* The number of IPSEC interfaces is hardcoded at 2 rather than being
configurable.

* There are too many ways for packets to get around the security stuff. 
In particular, suppose you have the following, with security gateways X
and Y serving subnets S and T: 

        S======X........Y======T

A packet which shows up at Y, in clear text, claiming to be from S, with a
destination in T, will be forwarded... even if there is an IPSEC tunnel
between X and Y which ought to be encrypting all such packets.  The damage
such packets could do is limited, but denial-of-service attacks are an
obvious possibility.  Dealing with this is difficult in general, because
we aren't quite close enough to the center of the IP processing machinery
in the Linux 2.0.xx kernels.  The move to 2.2.xx should fix this.

* Another "packet leak" arises because at startup, shutdown, or restart,
there is a brief period when the network is up but IPSEC is not.  This
exposure can be reduced (not eliminated) using the somewhat-ill-documented
forwardcontrol parameter.

* Minor difficulties can arise if more than one subnet is behind a single
security gateway, e.g.: 

        S======X.........Y======T
                         \\
                           ======U

If U wants to talk to S encrypted, but T wants to talk to S in clear (no
IPSEC), it actually is possible... but it has to be done with manual
"keying", which is a little messy if the U-S connection is automatically
keyed, because the two connections share a route but Pluto is not aware
of this.



This file is RCSID $Id: BUGS,v 1.21 1999/04/10 20:52:14 henry Exp $
