Short term items:

* Separate accounting from authentication. I.e., allow a client which
  is authenticated with certificates to report stats using radius.

* Move the banned list into the main process. That would allow faster
  rejection of banned clients.

* Use the UDP address to report the client's IP when sniproxy or haproxy
  are being used.

* When a user (IP) gets into the BAN list multiple times, disable it for
  longer time (or should we drop this functionality altogether and rely
  on PAM handling that?)

* Add support for memcached, to allow sharing server state.

* Give each worker a limited number of accesses to the security module.

Long term items:

* Think how the DTLS part can use better negotiation of algorithms and DTLS
  is negotiated properly. Using PSK ciphersuites seem to be like a solution, 
  but that would require a new protocol to be implemented in openconnect
  client and ocserv. 

* Certificate authentication to the security module. Possibly that is just
  wishful thinking. To verify the TLS client certificate verify signature 
  one needs in addition to the signature, the contents of all the handshake 
  messages, and knowledge of the negotiated TLS version, as well as being 
  able to select the server hello random. That could be done sanely only if 
  gnutls provided facilities to set the server hello random, and override the 
  client signature verification at an early stage before data are hashed 
  (to verify that the set random value was present in the handshake).
  However, the complexity required to implement that may in fact reduce
  security rather than increase it.

* Allow for a non-root mode where all networking is handled using something
  like slirp (e.g., https://github.com/SPICE/slirp)
