Re: request to recharter

[Alan DeKok <aland@nitros9.org>]

Bernard Aboba wrote:
> Since RFC 3539 already defines the transport profile and failover algorithms
> for AAA running over TCP/SCTP, I am not clear what remaining work is
> required in that area. 

  Partly psychological... people are more likely to read a "RADIUS over
TCP" document than an "AAA over TCP" document.  Also, standardizing TCP
as a RADIUS transport would require the publication of *some* kind of
document, if I understand the IETF process correctly.  We couldn't just
announce that it's OK...

  The "RADIUS over TCP" document could reference existing RADIUS
practices, and explain in excruciating detail why they won't work for TCP.

  Also, some issues relating to RADIUS PDU's over a stream transport may
be discussed.  e.g. receiving half a RADIUS packet and then a FIN is
*not* a problem.  The MIB counters for
radiusAuthServMalformedAccessRequests should NOT be incremented.  e.g.
receiving a PDU with malformed attributes means that the TCP connection
SHOULD be closed.

  Many RADIUS practices related to handling error cases require a PDU to
be "silently discarded".  This won't work for TCP.  The connection has
to be closed, too.  The existing RFC's have to be audited, and a new
document issued which explains the correct behavior.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>