Re: Request for Review: Status Server Document

[Alan DeKok <aland@deployingradius.com>]

Glen Zorn wrote:
> Existing implementations or not, RADIUS "ping" is just as wasteful of
> processing power & bandwidth as it was 10 years ago.

  It's not a "keep-alive".  That's bad.  It is the watchdog timer
recommended in RFC 3539.  The draft discusses why using existing RADIUS
codes such as Access-Request is not a good idea.  It also discusses why
it's useful, and why it's not a "keep-alive".

>  A far better idea IMHO
> is to have the server tell its clients when it recovers from a failure/admin
> reboot/etc.

  I agree, mostly.  Some complications:

- clients don't historically listen on a port for unsolicited RADIUS
packets (RFC 5176 is not widely deployed)

- clients may be behind NATs or firewalls.   The forward path is well
tested, deployed, with firewall traversal rules.  The backwards path is not.

- this would involve defining a new port (maybe), new packet codes
(could we re-use Status-Server?), and new behavior.  The existing
practice has multiple implementations, is widely used, and meets most of
the needs for client to server status checking.

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