Re: Proxies and dead home servers

[Alan DeKok <aland@nitros9.org>]

David B. Nelson wrote:
> Alan DeKok Writes ...
>  
>>   In addition, proxies can't know if the client sending them packets is
>> a NAS or is instead another proxy.
> 
> Why not?  Every RADIUS client-server "hop" is protected by a hop-by-hop
> shared secret, keyed at the server by the client's source IP address.
> What's to prevent a server implementation (e.g. in a proxy) from storing a
> NAS/Proxy flag in the local configurations store, along with the shared
> secret?

  Nothing.  Which is why the next sentence started with "Even if they
are configured to treat the client as another proxy ..."

>> So at the minimum, *one* server in the proxy chain (the one local 
>> to the NAS) needs to always respond to the NAS, otherwise the NAS 
>> will think it's down.
> 
> Unless NASes have implemented a form of NAI routing.  I remember one such
> implementation in the DECserver NAS (circa 1985).  It was "pre-NAI" but
> worked similarly, using Kerberos domain syntax.  The "domain decoration" was
> used to select from an arbitrarily long list of possible RADIUS servers.

  To be honest, I haven't seen that in the deployments I work with.  My
experience has been that if your expectations are the
lowest-common-denominator for NASes, you might be aiming a little high.

  I've also seen servers that don't respond to NASes take peoples
networks down.

  Another issue with NAI routing is that when a server goes down, each
route has to discover that independently.  The NAS (or proxying server)
can't know that a server is down, because it may only be the *route*
that's down.  So if N routes are passing through a dead server, some
multiple of N users will get rejected before the NAS decides that all N
routes are down.  If the *server* is marked dead, then all routes can
immediately start using backup servers.

  If the goal is to increase network stability and minimize the number
of users who are rejected due to network outages, then what I'm
proposing appears to do that.  The only users who get rejected are the
ones who's NAI routes are down, and then only for so long as those
routes are down.  I'm unsure as to why alternatives would be preferred.

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