freeswan/pluto/TODO

   1 Pluto TODO list
   2 ===============
   3 RCSID $Id: TODO,v 1.7 2002/01/15 21:03:51 dhr Exp $
   4
   5 - should all log entries that are for errors say ERROR?
   6
   7 - Add a "plug-in" facility so that others can add features without
   8   changing the mainline code.  This is how X509/LDAP/biometric stuff
   9   might be added.
  10
  11 - (internal change only) routines for outputting payloads should plug
  12   "np" into the previous payload so that a payload generating routine
  13   need not know what the next payload will be.  This may be more bother
  14   than it is worth.
  15
  16 - notifications, in and out
  17   + delete
  18   + first contact
  19   + last contact? (not part of drafts, but would be nice)
  20
  21 - Make DNS usage for asynchronous (non-blocking)
  22   + looking up KEY and TXT records during negotiation
  23   + perhaps not for whack command arguments and ipsec.secrets since the
  24     library code uses gethostbyname
  25
  26 - check that ipsec auto and whack to agree on what is worth reporting
  27
  28 - Should Pluto (rather than ipsec manual) install %passthrough conns?
  29   That way Pluto would know of them.
  30
  31 - For responding to Road Warriors, how can we decide if the RW has
  32   gone away?  The rekeying event is perhaps too imprecise.  Even if
  33   rekeying event is good enough, how do we know if the route should be
  34   torn down?  Perhaps limiting a Phase 1 ID to one IP address would
  35   help (limiting a client subnet to one peer already helps).  Perhaps
  36   (in some rate-limited way) we can take an ICMP host unreachable
  37   as a hint to do some authenticated and reliable probe.
  38
  39 - it is annoying that Pluto and auto have different models for public keys.
  40   + auto specifies one per connection
  41   + Pluto allows one to be specified per id
  42   Two connections with the same id are going to use the same key:
  43   the one of the last conn to be added!
  44
  45   I think auto ought to be fixed.  It is hard for Pluto to warn when
  46   there is a conflict since the deletion of a connection doesn't
  47   prompt auto to tell pluto to delete the public key.
  48
  49 - different connections with the same host IP addresses are randomly
  50   interchangeable until the ID payload is received.  At least for the
  51   Responder case (and eventually for the opportunistic Initiator).
  52   Worse, all Road Warriors must be considered to have the
  53   indistinguishable IP addresses.  This affects ISAKMP SA negotiation.
  54   Currently, there is little flexibility in this negotiation, so the
  55   problem is limited to the specification of acceptable authentication
  56   method(s).  Correct, but more work than seems worthwhile, would be
  57   to select the conn based on what is proposed.
  58
  59   Warning about such confusion at connection definition time isn't great
  60   because there is no confusion when explicitly initiated (a particular
  61   conn is specified).  Warning for a Road Warrior conn is possible
  62   since it cannot be initiated (and has been implemented).
  63
  64 - characterize and ameliorate DOS attacks.  Lots of rate limiting.
  65
  66 - look at John Denker's wish list: http://www.quintillion.com/moat/wish.list
  67
  68 - use of random numbers needs to be audited.
  69
  70 - unknown (not just unimplemented) transforms cause a negotiation to
  71   fail.  Only the transform should be rejected.
  72
  73 - we need better policy control.  Our present flags need to be
  74   modulated (forbid, allow, offer, require)
  75
  76 - HS will specify how --copyright and --version should behave
  77
  78 - HS will initiate project-wide terminology replacing ISAKMP SA, IPSEC
  79   SA, Protection Suite, Phase 1, Main Mode, Phase 2, Quick Mode, ...
  80   Simplicity and clarity will be a goal.
  81
  82 - interface discovery ought to match what is specified in ipsec.conf.
  83   This probably means grokking /proc/net/ipsec_tncfg.  Documented in
  84   ipsec_tncfg(5).  This won't do for Hugh's debugging setup.
  85
  86
  87 Protocol Issues
  88 ===============
  89
  90 Notification and delete payloads seem to be "escape hatches" for the
  91 protocols.  As such, anything implemented using them seems to be
  92 kludged without being well designed or well situated or well
  93 constrained in the protocols.  Often the precise meaning (if any) or
  94 usage is under specified.  An implementation is allowed to ignore
  95 them, so they cannot really matter (but they too often do).  Their
  96 specification ought to be scrutinized by a protocol guru.
  97
  98 Any extra payload in last main mode message is not protected (not
  99 authenticated by hash).
 100
 101 Should notification payloads be interpreted before or after the normal
 102 payloads (i.e. understood in the context of, executed in the context of).
 103
 104 What is the precise result of an INITIAL_CONNECTION?  What is a
 105 "system" (eg. does Phase 1 Identity count)?  What is "earlier" or
 106 "before" (simultaneous negotiation is possible, with time being only a
 107 partial order)?  Could it be used for FINAL_CONTACT (needed too)?
 108
 109 Blasting out a pile of UDP messages, especially to a particular
 110 destination, is likely to provoke message loss.  The exchanges are
 111 just that, so they individually are self-throttling.  But what about
 112 multiple exchanges simultaneously?  What about notifications (example:
 113 when shutting down, a flurry of delete notifications are likely).
 114 Should the RFCs be designed to protect against this problem?
 115
 116 draft-jenkins-ipsec-rekeying-03.txt rekeying is way too complicated.
 117 Our solution looks sound and simple (we have the Responder install the
 118 incoming IPSEC SA before sending its first reply).  In "2.2.1.4
 119 Responder Pre-Set-up Security Hole", the draft claims that setting up
 120 the IPSEC SA early leaves the Responder open to replay attacks.  I
 121 think that this is wrong: the Message Id, since it must not be reused,
 122 serves to prove that this isn't a replay.
 123
 124 The details for notification messages suggested by
 125 draft-ietf-ipsec-notifymsg-02.txt are over-complicated, just to make
 126 them machine-comprehensible.  I think this is over-engineering,
 127 justified only if another level of negotiation is contemplated (ugh!).
 128 Plain text is probably sufficient for informing humans (I admit that
 129 there is a problem with I18N).