Pluto TODO list
===============

- should all log entries that are for errors say ERROR?

- use RSAREF?  This would allow some USAnians to use RSA Sig authentication
  legally.

- 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.

- notifications, in and out
  + delete
  + first contact
  + last contact? (not part of drafts, but would be nice)

- DNSsec / ADNS.  For auth keying material and network topology.

- asynchronous DNS for resolving domain names in ipsec.secrets and
  whack connection definitions.

- get a protocol expert to pronounce on soundness of early installation
  of inbound SA.  Comment on jenkins-rekeying.

- get ipsec auto and whack to agree on what is worth reporting

- support %passthrough

- How should ISAKMP SA negotiation be handled by Responder?  Identity
  of Initiator is unknown.  Currently only Authentication Method is
  up in the air.

- 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?

- 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).

  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).

- IPv6 support!  We need some infrastructure to use.  KAME has an
  interesting document: http://www.kame.net/newsletter/19980604/
  I think we should save memory by using a less-universal union.

- characterize and ameliorate DOS attacks

- describe our rekeying to community & contrast with Jenkins

- look at John Denker's wish list: http://www.quintillion.com/moat/wish.list

- use of random numbers needs to be audited.


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 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).
