Re: Proxies and dead home servers

[Alan DeKok <aland@nitros9.org>]

Bernard Aboba wrote:

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

> That depends on the proxy retransmission and backoff behavior.   For
> example, assume that the RTT between the proxy and home server is high
> (e.g. several seconds).  If the proxy doesn't estimate RTT or back off
> its retransmission timer, then it might retransmit several times
> before concluding that the server is dead.  When the server finally
> responds, it is too late because the proxy has already sent an Access-Reject.  

  For one, I'm not aware of proxy implementations that have aggressively
low timeouts.  Deployments that have static timeouts configured
aggressively low will discover that their users are rejected (by the
proxy or even by the NAS), and will fix their timeouts.

  Most fixed timeouts are set to 15-30 seconds.  Those numbers are
chosen *not* from analyzing the network, but from understanding user
behavior.  A slow, low-bandwidth satellite link might have delays of
tens of seconds.  A proxy that properly estimates RTT and adapts to the
slow network without using fixed timeouts is probably wrong... because
the user has given up and walked away.

  As for sending an Access-Reject, I'm not sure it's a problem.  In this
scenario, the NAS thinks the proxy is alive, the proxy thinks the home
server is alive, and one poor user gets told "no".  Given that he's
waited probably 30 seconds for that "no", the delay *already* serves as
an indication that something's gone wrong.

> The discussion in the Appendix applies to UDP as well.  The issue is
> whether the proxy behavior satisfies "conservation of packets". 

  OK.

>> My $0.02 is that it may be useful for the proxy to synthesize an
>> Access-Reject to the NAS when the home server does not respond.
> I would agree as long as the proxy implements appropriate retransmission
> and backoff logic.

  Hmm... That comes back to a question from a few months ago.  Most
RADIUS servers appear to operate as "synchronous" proxies.  i.e. They
retransmit only when the NAS retransmits.

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