[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proxies and dead home servers
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.
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.
A NAS should not failover to another proxy unless it has evidence that they proxy itself (rather than the home server) is down. 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.
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. 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.
> Date: Mon, 11 Jun 2007 13:47:35 +0200
> From: aland@nitros9.org
> To: radiusext@ops.ietf.org
> Subject: Proxies and dead home servers
>
> I've recently come across an issue which the RFC's don't clearly
> address, but which can have major implications in a proxying environment.
>
> Suppose we have a proxy chain as follows:
>
> NAS --> Proxy Server --> Home Server
>
> If the Home Server does not respond to a proxied Access-Request, what
> does the Proxy Server do with it? RFC 2865 Section 4.1 says:
>
> Upon receipt of an Access-Request from a valid client, an
> appropriate reply MUST be transmitted.
>
> This would seem to indicate that the Proxy Server MUST respond to the
> NAS, even if the Home Server does not respond to the Proxy Server. The
> only safe response is an Access-Reject, I think.
>
> There are implementations that do not behave this way, but I think
> their impact is small.
>
> 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/>