Requirements:

• Implementation disconnected API (so current radius module might be amended to also implement - at least part of - the API if someone so chooses, or as interim steps).

• Detach all modules from direct integration with radius, must utilize the API.

• Radius module must not be (directly) aware of the influence options can have on other aspects of the protocol (eg, if radius provides keys for MPPE, there is no reason radius should integrate into MPPE, however, MPPE could be aware that radius might supply keys).

• generally non-blocking, unless requested to block (radius potentially blocks the pppd process #559).

• Support for (need to check if all of these are even part of the spec):

  • radius/udp
  • radius/dtls
  • radius/tcp
  • radius/tls

• Support for the relevant spoof protection mechanisms (RADIUS protocol RFC 2865 susceptible to forgery attacks #480).

• Ability for other modules (including core systems, but eg, also dhcpv6proxy) to add arbirary TLVs to accounting updates.

• Ability for other modules to query arbitrary TLVs from the Access-Accept (at the very least, an Access-Reject could contain URLs that stuff may want access to, and also Access-Challenge potentially needs to be handled somehow - which I believe is how 2FA can potentially be implemented in some cases, but I'd have to check up on RFCs).

• If possible the API structure should be versioned such that additional functions can be added to the END of the API structure, and if the implemented API is older than the version against which the requester was compiled, we need to either fail, or have some sensible fail-safe (eg, the requested must give the size of the struct, and we zero-pad a block of memory to NULL those function pointers).