Re: [radext] Are there RFCs for "Proxy path control" in RADIUS?

[Alan DeKok <[e-mail]>]

On Apr 7, 2022, at 10:41 AM, Jan-Frederik Rieckers <[e-mail]> wrote:
> Are there RFCs which deal with controlling the proxy path of a RADIUS request?

  RADIUS is entirely "hop by hop", and has no concept of overall paths.

  There has been discussion about this over the years, but no concrete solutions.

> My use case is the following:
> 
> A roaming operator (e.g. an eduroam NRO) operates two redundant but independent RADIUS proxies (meaning they don't have an interconnection on the management/control plane). Their servers are connected to a number of other entities (RADIUS clients and servers).
> In the normal case, all proxy servers have a connection to all other entities.
> 
> The error case is now the following:
> Entity B loses connection to proxy server 1 (e.g. through a fiber cut), but is still connected to proxy server 2.
> If a login request for B comes from entity C to the proxy server 1, the server will have no connection and either reject or drop the reqest.
> 
> What I want to send back is a temporary error, meaning "I can't reach the server for this realm in the moment, try a different proxy.", which in this case would lead to entity C trying the authentication over the second server.

  That would be very useful.

> (The problem description is a bit short, if wanted I can elaborate further, but I didn't want to put a wall of text here)

  This is a common problem in proxying.

  A proxy can send packets from a client to destinations A and B.  If B is down, then the proxy sends packets to B, never gets a response from B, and therefore never replies to the client.

  So what can the client do?  It has no idea that routing is taking place.  All it knows is that it sends packets to the proxy.  Some packets get replies, and others don't get replies.

  From the clients point of view, it's not even sure if the proxy is up!  i.e. Let's say that for 10 minutes, the client only sends packets which are proxied to B, and never to A.  The client never sees a response from the proxy,  So it will think that the proxy is dead.  And will likely fail over to another proxy.

  The client *could* send packets to the proxy which would get routed to A, but the client doesn't know it can do that.  Because it has no idea about the overall routing of packets, or the mapping between realms and home servers.

> Is there a RADIUS extension that does that?
> My short research did not reveal anything that could help me here.
> I'd be happy about any pointers to existing standards (and if there is nothing of the sort yet, also about feedback if this is something that could be put in a draft)

  There is nothing.

  You're looking for a "hop by hop" notification that the destination is still alive.  This is the Status-Server packet, documented in RFC 5997.


  You're also looking for a RADIUS routing protocol, which has to be run on the proxies.

  i.e. each proxy has a list of destination realms, and which home servers can be used for those realms.   This information could be exchanged periodically.

  That routing protocol is likely independent of RADIUS, and could be done via some other means.  The systems have to exchange lists of which destinations are available, and how they can be reached.  This information has to flow through all of the proxies, so that they are all aware of the routes.

  This routing has traditionally been done manually, by system administrators.  Since much of the interconnection depends on legal / business issues, a routing protocol doesn't make that interconnection any easier.


  Alan DeKok.