Re: Proxies and dead home servers

[Alan DeKok <aland@nitros9.org>]

Bernard Aboba wrote:
> If the home server does not respond to the proxy server, then the
> proxy server should fail over if it has an alternative home server
> configured.

  When the proxy server doesn't have an alternative home server, then
what does it do?  If it doesn't respond to the NAS, the NAS may
erroneously believe it is dead, and reject the session.  If it does
respond with an Access-Reject, then the NAS will believe that the server
is still alive, and reject the session.

  I think that the second alternative is preferable to the first one.

> However, if the home server is busy, then it should send
> a reply rather than silently discarding incoming packets, since the
> latter will cause the NAS to retransmit.  Ideally RADIUS would have
> defined a "too busy" message that would have caused immediate failover,
> but [RFC2865] did not define such a message.

  Yes.  Hind-sight is 20-20.

> A NAS should not failover
> to another proxy unless it has evidence that they proxy itself (rather
> than the home server) is down.

  There are corner cases where the NAS may not be able to distinguish
the proxy being down from the home server being down.  e.g. The NAS
sends requests through a proxy for "users@example.com" for some time
while the "example.com" home server is down.  Then, the NAS sends a
request through a proxy for "user@example.net", while the "example.net"
home server is up.

  If the proxy doesn't respond to the requests for "example.com", then
the NAS may erroneously perform failover, and send the "example.net"
requests to a secondary proxy server.  If there's no secondary proxy
server, the NAS may decide that the proxy is down, and erroneously
reject the "example.net" request.  This will cause spurious network
outages for users trying to log in.

>  That is, if the proxy has recently
> responded to any requests at all, then lack of a response to a
> particular request is not a reason to failover to another proxy, it is
> a reason to retransmit the Request.

  Yes.

> By that logic, responding to the
> NAS should not be necessary;  the proxy does not implement its own
> retransmission logic, it mimics that of the NAS and handles failover.

  The failure case is between the proxy server and the NAS, not between
the proxy and the home server.

  If the proxy server does not respond to *any* of the retransmissions
from the NAS, then there are cases where the NAS may conclude that the
proxy server is dead, even though it is actually alive.

>  This provides the NAS with an equivalent of an "end to end" connection
> to the home server in a transport behavior sense.  This is discussed in
> RFC 3539.

  The end-to-end transport issues discussed in RFC 3539 apply only to
TCP or SCTP streams, where the client receives an explicit indication
that the connection has been closed.  With those transport protocols,
the NAS does not need to receive an AAA message from the proxy, as the
underlying transport indicates to the NAS that the connection to the
proxy is still up, and that the proxy is still alive.

  RADIUS is implemented over UDP, where the client may receive no
indication that a connection is down, because there is no connection.
So the client can't use the underlying transport protocol as an
indication that the proxy is alive.  Instead, all the NAS knows is that
the proxy has not responded.  It should reject the user, of course.  But
should it mark the proxy as dead?  If so, why?  If not, why not?

  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.  This
indicates to the NAS that the proxy is still alive, and does not change
other NAS behavior such as rejecting the user login attempt.

  Alan DeKok.

p.s.
 Section 3.4 of RFC 3539 covers the Application-Layer watchdog, but I'm
curious as to how that interacts with Section 2.6 of RFC 2865,
"Keep-Alives Considered Harmful".  I think the watchdog algorithm in RFC
3539 is useful, and could be implemented in RADIUS in spite of the
restrictions in Section 2.6 of RFC 2865.  But that's another issue.

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