Contents of /trunk/BUGS

This code is still less than perfect and undoubtedly has bugs.  As of this
release, the following are considered known bugs.

For a detailed list, see http://bugs.openswan.org/

* Test cases using AH for authentication currently fail. If you need this 
  functionality for interop, either use an older release (1.99) or JuanJo 
  Ciarlante's ALG patch. 

* It was our intent for Opportunistic Encryption to work with 4096 bit keys.
  Currently, there is a buffer limitation that prevents this; the additional 
  text in TXT records wasn't properly factored into the buffer length. If 
  you wish to use a key larger than the default of 2192 bits, keep the size 
  under 4k. This will be fixed in a future release.

* If there are multiple connections specified between the same two
  security gateways, either all or none must specify compression.  Otherwise
  the result is unpredictable. 

* Pluto will not retry if it can not find its key in DNS when it starts.

* Extrusion and Opportunistic Encryption do not mix well without
  Advanced Routing. (There is a workaround using advanced routing)

* Openswan on OSX/FreeBSD does not properly install the SA's into the kernel.

* Installing a new Openswan on top of an old one doesn't update kernel
  configuration options, so if new options are added, you need to start
  with a virgin kernel instead, or 'make oldconfig'

* KLIPS cannot cope with IP packets employing IP options.  Normally, 
  KLIPS strips the options when forwarding.  This has caused no trouble 
  that we know of, somewhat to our surprise.

* 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 yet to the center of the IP processing
  machinery.  For now, careful firewalling is needed. 

* 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 using the forwardcontrol parameter, or by using
  iptables start/stop scripts at the appropriate times.

* Yet another potential leak arises because the PF_KEYv2 replace form of
  addroute command is non-atomic.  There is a possibility for packets to
  slip through the eroute table to a more general eroute between deletion
  and addition of an eroute.  This is usually of no importance because the
  packets will generally end up getting dropped rather than forwarded.

* 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's %passthrough feature, 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. 

* The number of IPsec interfaces is coded at 4, but can be
  changed by editing linux/net/ipsec/ipsec_param.h. It can not
  adjusted dynamically at run-time, which is the bug.

* When building as a module, there may be a memory leak when loading/unloading
  several times. We have not identified the source of this leak. It is on
  the order of 8k. As we expect some turbulence in the kernel component
  in the early months of 2003, we are not going to pursue this at this time.
  Our test case, module-memory-01 therefore may fail.

* For various reasons, KLIPS will soon *DROP* any DF-marked packet that
  is more than "IPsec-overhead" larger than the MTU. This is to compatible
  with plpmtud (i.e. "PMTUbis") being proposed in the pmtud WG.

* Document and/or make configure option of the define IPSEC_obey_DF. It seems
  currently not to be set anywhere.

* Also document and/or make option for MSS_HACK_ / MSS_HACK (in ipsec_xmit.c)

1	This code is still less than perfect and undoubtedly has bugs. As of this
2	release, the following are considered known bugs.
3
4	For a detailed list, see http://bugs.openswan.org/
5
6	* Test cases using AH for authentication currently fail. If you need this
7	functionality for interop, either use an older release (1.99) or JuanJo
8	Ciarlante's ALG patch.
9
10	* It was our intent for Opportunistic Encryption to work with 4096 bit keys.
11	Currently, there is a buffer limitation that prevents this; the additional
12	text in TXT records wasn't properly factored into the buffer length. If
13	you wish to use a key larger than the default of 2192 bits, keep the size
14	under 4k. This will be fixed in a future release.
15
16	* If there are multiple connections specified between the same two
17	security gateways, either all or none must specify compression. Otherwise
18	the result is unpredictable.
19
20	* Pluto will not retry if it can not find its key in DNS when it starts.
21
22	* Extrusion and Opportunistic Encryption do not mix well without
23	Advanced Routing. (There is a workaround using advanced routing)
24
25	* Openswan on OSX/FreeBSD does not properly install the SA's into the kernel.
26
27	* Installing a new Openswan on top of an old one doesn't update kernel
28	configuration options, so if new options are added, you need to start
29	with a virgin kernel instead, or 'make oldconfig'
30
31	* KLIPS cannot cope with IP packets employing IP options. Normally,
32	KLIPS strips the options when forwarding. This has caused no trouble
33	that we know of, somewhat to our surprise.
34
35	* There are too many ways for packets to get around the security stuff.
36	In particular, suppose you have the following, with security gateways X
37	and Y serving subnets S and T:
38
39	S======X........Y======T
40
41	A packet which shows up at Y, in clear text, claiming to be from S, with a
42	destination in T, will be forwarded... even if there is an IPsec tunnel
43	between X and Y which ought to be encrypting all such packets. The damage
44	such packets could do is limited, but denial-of-service attacks are an
45	obvious possibility. Dealing with this is difficult in general, because
46	we aren't quite close enough yet to the center of the IP processing
47	machinery. For now, careful firewalling is needed.
48
49	* Another "packet leak" arises because at startup, shutdown, or restart,
50	there is a brief period when the network is up but IPsec is not. This
51	exposure can be reduced using the forwardcontrol parameter, or by using
52	iptables start/stop scripts at the appropriate times.
53
54	* Yet another potential leak arises because the PF_KEYv2 replace form of
55	addroute command is non-atomic. There is a possibility for packets to
56	slip through the eroute table to a more general eroute between deletion
57	and addition of an eroute. This is usually of no importance because the
58	packets will generally end up getting dropped rather than forwarded.
59
60	* Minor difficulties can arise if more than one subnet is behind a single
61	security gateway, e.g.:
62
63	S======X.........Y======T
64	\\
65	======U
66
67	If U wants to talk to S encrypted, but T wants to talk to S in clear (no
68	IPsec), it actually is possible... but it has to be done with manual
69	keying's %passthrough feature, which is a little messy if the U-S
70	connection is automatically keyed, because the two connections share a
71	route but Pluto is not aware of this.
72
73	* The number of IPsec interfaces is coded at 4, but can be
74	changed by editing linux/net/ipsec/ipsec_param.h. It can not
75	adjusted dynamically at run-time, which is the bug.
76
77	* When building as a module, there may be a memory leak when loading/unloading
78	several times. We have not identified the source of this leak. It is on
79	the order of 8k. As we expect some turbulence in the kernel component
80	in the early months of 2003, we are not going to pursue this at this time.
81	Our test case, module-memory-01 therefore may fail.
82
83	* For various reasons, KLIPS will soon DROP any DF-marked packet that
84	is more than "IPsec-overhead" larger than the MTU. This is to compatible
85	with plpmtud (i.e. "PMTUbis") being proposed in the pmtud WG.
86
87	* Document and/or make configure option of the define IPSEC_obey_DF. It seems
88	currently not to be set anywhere.
89
90	* Also document and/or make option for MSS_HACK_ / MSS_HACK (in ipsec_xmit.c)
91