Here are some things on our "wish list" -- i.e. features we would like
to see added to FreeS/WAN.


@ [__] Make IPsec play nicely with routing daemons e.g. gated.  We
  now have multiple portals (mt-portal as well as Whitney).  Each
  portal should advertise routes that it provides to the moats.  Each
  moat should have a tunnel to more than one portal.

  This is super-important.

  See general discussion of routing / redesign issues at
  http://www.quintillion.com/fdis/moat/ipsec+routing/

@ [__] It sure would be nice to have some sort of "principles of
  operation" document that explains where the IPsec engine sits in
  relation to the kernel routing tables, the ipchains engine, and
  other stuff, so that users could find new ways of putting the pieces
  together without having to try all possibilities.

@ [__] Make IPsec play nicely with DHCP.  Almost all road warriors
  use DHCP.  DHCP implies possibly delayed or denied network
  interface configuration.  DHCP implies possibly changeable
  network interface configuration.

@ [__] Address inertia for road warriors.
  That is, suppose the fixed end suddenly reboots.  Suppose it
  has remembered the address where each moat was last seen, and now
  automatically --up{}s each connection.  With very high probability
  the moat is still there, and the --up succeeds.

  But freeswan 1.5 makes no attempt to remember where the roadies
  were last seen.  The roadies are high and dry; until their
  connections time out at their end, they will not be able to say
  anything useful to the fixed end.  This could go on for an hour or
  more (depending on ikelifetime). This definitely does not uphold the
  quality standards that my customers expect.

  So here's a suggestion: In the .conf file on the left (fixed) end,
  the right=... item should be replaced by *two* items, which might
  take the form:


	respond-to-right=24.0.0.0/8	# road warrior wildcard


	initiate-to-right=24.4.251.46	# last known domicile of this moat

  and we ask pluto to keep the memorized value of initiate-to-right up
  to date, directly or via the _updown scripts.

  Yes, I know this requires keeping a database that persists across
  reboots, which has not heretofore been done.  But it is important.

  Yes, I know the scenario in question (reboot of one end) could be
  handled by keepalives under the control of the other end, but 
  keepalives don't scale well.  The responsibility should be on
  the end that reboots, because it knows it rebooted.

@ [__] Collect more statistics in KLIPS.  Sequence numbers are nice,
  but it would be great to see:
   -- number of packets out
   -- time of last packet out
   -- number of good packets in
   -- time of last good packet in
   -- number of error packets in
   -- time of last error packet in

@ [__] Connect said traffic monitoring to an SNMP agent.

@ [__] Docs must emphasize that encryption is not equal to security.
Showing you have some encrypted packets flowing is fine, but then you
need to show that *no* insecure traffic is flowing elsewhere.  This
has many consequences including: 

  Setup.html should include discussion of necessity of firewalling.  
  Setup.html should include detailed validation instructions; looking
  with tcpdump is a nice thing to do but hardly constitutes a proof
  of correctness.
  Smarter forwardcontrol; see 
http://www.quintillion.com/fdis/moat/ipsec+routing/#sec_forwardcontrol

@ [__] Get rid of N^2 algorithm in "ipsec --add"

@ [__] Snapshot filenames should be named according to the snapshot
they contain.  A symlink from the generic "snapshot.tar.gz" to the
most-recent snapshot would preserve compatibility.

@ [__] The "ipsec auto" command should set its exit status
appropriately, e.g. "ipsec auto --delete asdfasfsadf" should return an
error status.

==== //// ==== //// ==== //// ==== //// ==== //// ==== //// ==== ////

Testing issues

* [__] Test under load:  lots of traffic, lots of tunnels

* [__] Test /proc/net/ipsec_spi during load;  check syntax, check for
  side-effects.

* [__] Test with packets lost enroute, including asymmetric loss

* [__] Test "auto --replace" during load

* [__] Alarm if cleartext seen on wire

* [__] Ship test tools (validation suite) with the product.

* [__] User interface:  misconfigure in typical ways and make sure
  appropriate error messages are produced.