RE: Proxies and dead home servers

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Alan DeKok <> allegedly scribbled on Monday, June 11, 2007 4:48 AM:

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

Boringly enough, I posed this exact question thousands of years ago to
the (really smart) guy who developed the RADIUS server for what was at
the time the largest access network in the world (> 1 million users).
His answer is still valid, I think: nothing.  

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

No.  You're confusing a "Proxy Server" with a _real_ Server.  The above
does not apply to proxies; to see why, extend the confusion to the
client side of the proxy.  If the proxy is a real client, it will
discern that no answer is forthcoming by means of the traditional method
of multiple time-out and retry, right?  If the proxy clients timeout
period is the same as that of the NAS, it will multiply identical but
slightly staggered requests before giving up & returning (in your
scenario below) an Access-Reject slightly _after_ the NAS has given up &
tried a different proxy (if available).  If the proxy client's time out
is too short, though, it risks returning spurious Access-Rejects due to
end servers that are just a little bit slow.  Basically, the time-out &
retry behavior in a proxied network MUST be driven by the NAS, not the
proxies or total chaos results.    This is not to say that a proxy must
blindly forward requests to dead servers. It should certainly note the
responsiveness of upstream entities: if one appears to be dead & there
is an alternate path available, it should be used but decisions about
the health of the upstream entities must be based upon either passive
observation or possibly locally generated (& blatantly illegal ;-)
probes, not through the imitation of a real client 

> The only safe response is an Access-Reject, I think. 

For reasons outlined above, the only safe response is none.

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