1 files changed, 0 insertions, 129 deletions
diff --git a/src/pluto/TODO b/src/pluto/TODO
deleted file mode 100644
index 1c22b2f5c..000000000
--- a/src/pluto/TODO
+++ /dev/null
@@ -1,129 +0,0 @@
-Pluto TODO list
-===============
-RCSID $Id: TODO 3269 2007-10-08 20:03:02Z andreas $
-
-- should all log entries that are for errors say ERROR?
-
-- Add a "plug-in" facility so that others can add features without
-  changing the mainline code.  This is how X509/LDAP/biometric stuff
-  might be added.
-
-- (internal change only) routines for outputting payloads should plug
-  "np" into the previous payload so that a payload generating routine
-  need not know what the next payload will be.  This may be more bother
-  than it is worth.
-
-- notifications, in and out
-  + delete
-  + first contact
-  + last contact? (not part of drafts, but would be nice)
-
-- Make DNS usage for asynchronous (non-blocking)
-  + looking up KEY and TXT records during negotiation
-  + perhaps not for whack command arguments and ipsec.secrets since the
-    library code uses gethostbyname
-
-- check that ipsec auto and whack to agree on what is worth reporting
-
-- Should Pluto (rather than ipsec manual) install %passthrough conns?
-  That way Pluto would know of them.
-
-- For responding to Road Warriors, how can we decide if the RW has
-  gone away?  The rekeying event is perhaps too imprecise.  Even if
-  rekeying event is good enough, how do we know if the route should be
-  torn down?  Perhaps limiting a Phase 1 ID to one IP address would
-  help (limiting a client subnet to one peer already helps).  Perhaps
-  (in some rate-limited way) we can take an ICMP host unreachable
-  as a hint to do some authenticated and reliable probe.
-
-- it is annoying that Pluto and auto have different models for public keys.
-  + auto specifies one per connection
-  + Pluto allows one to be specified per id
-  Two connections with the same id are going to use the same key:
-  the one of the last conn to be added!
-
-  I think auto ought to be fixed.  It is hard for Pluto to warn when
-  there is a conflict since the deletion of a connection doesn't
-  prompt auto to tell pluto to delete the public key.
-
-- different connections with the same host IP addresses are randomly
-  interchangeable until the ID payload is received.  At least for the
-  Responder case (and eventually for the opportunistic Initiator).
-  Worse, all Road Warriors must be considered to have the
-  indistinguishable IP addresses.  This affects ISAKMP SA negotiation.
-  Currently, there is little flexibility in this negotiation, so the
-  problem is limited to the specification of acceptable authentication
-  method(s).  Correct, but more work than seems worthwhile, would be
-  to select the conn based on what is proposed.
-
-  Warning about such confusion at connection definition time isn't great
-  because there is no confusion when explicitly initiated (a particular
-  conn is specified).  Warning for a Road Warrior conn is possible
-  since it cannot be initiated (and has been implemented).
-
-- characterize and ameliorate DOS attacks.  Lots of rate limiting.
-
-- look at John Denker's wish list: http://www.quintillion.com/moat/wish.list
-
-- use of random numbers needs to be audited.
-
-- unknown (not just unimplemented) transforms cause a negotiation to
-  fail.  Only the transform should be rejected.
-
-- we need better policy control.  Our present flags need to be
-  modulated (forbid, allow, offer, require)
-
-- HS will specify how --copyright and --version should behave
-
-- HS will initiate project-wide terminology replacing ISAKMP SA, IPSEC
-  SA, Protection Suite, Phase 1, Main Mode, Phase 2, Quick Mode, ...
-  Simplicity and clarity will be a goal.
-
-- interface discovery ought to match what is specified in ipsec.conf.
-  This probably means grokking /proc/net/ipsec_tncfg.  Documented in
-  ipsec_tncfg(5).  This won't do for Hugh's debugging setup.
-
-
-Protocol Issues
-===============
-
-Notification and delete payloads seem to be "escape hatches" for the
-protocols.  As such, anything implemented using them seems to be
-kludged without being well designed or well situated or well
-constrained in the protocols.  Often the precise meaning (if any) or
-usage is under specified.  An implementation is allowed to ignore
-them, so they cannot really matter (but they too often do).  Their
-specification ought to be scrutinized by a protocol guru.
-
-Any extra payload in last main mode message is not protected (not
-authenticated by hash).
-
-Should notification payloads be interpreted before or after the normal
-payloads (i.e. understood in the context of, executed in the context of).
-
-What is the precise result of an INITIAL_CONNECTION?  What is a
-"system" (eg. does Phase 1 Identity count)?  What is "earlier" or
-"before" (simultaneous negotiation is possible, with time being only a
-partial order)?  Could it be used for FINAL_CONTACT (needed too)?
-
-Blasting out a pile of UDP messages, especially to a particular
-destination, is likely to provoke message loss.  The exchanges are
-just that, so they individually are self-throttling.  But what about
-multiple exchanges simultaneously?  What about notifications (example:
-when shutting down, a flurry of delete notifications are likely).
-Should the RFCs be designed to protect against this problem?
-
-draft-jenkins-ipsec-rekeying-03.txt rekeying is way too complicated.
-Our solution looks sound and simple (we have the Responder install the
-incoming IPSEC SA before sending its first reply).  In "2.2.1.4
-Responder Pre-Set-up Security Hole", the draft claims that setting up
-the IPSEC SA early leaves the Responder open to replay attacks.  I
-think that this is wrong: the Message Id, since it must not be reused,
-serves to prove that this isn't a replay.
-
-The details for notification messages suggested by
-draft-ietf-ipsec-notifymsg-02.txt are over-complicated, just to make
-them machine-comprehensible.  I think this is over-engineering,
-justified only if another level of negotiation is contemplated (ugh!).
-Plain text is probably sufficient for informing humans (I admit that
-there is a problem with I18N).