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

From: Jan-Frederik Rieckers <[email-masked]>
Date: Thu, 7 Apr 2022 16:41:47 +0200

Hi to all,

I hope someone on this list can answer this question, I have been 
digging a little bit but haven't found anything yet.

Are there RFCs which deal with controlling the proxy path of a RADIUS 
request?

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.

(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)

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)

Greetings,
Janfred

PS: I know, the WG is not active any more, this is the most likely place 
to find someone who knows of a standard, if it exists and if not maybe 
this could be future work for a recharter.

-- 
E-Mail: [email-masked] | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pronouns: he/him
__________________________________________________________________________________

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network
Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
www.dfn.de

Vorstand: Prof. Dr. Odej Kao (Vorsitzender) | Dr. Rainer Bockholt | 
Christian Zens
Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 1366/23822

---

From: Alan DeKok <[email-masked]>
Date: Thu, 7 Apr 2022 11:19:23 -0400

On Apr 7, 2022, at 10:41 AM, Jan-Frederik Rieckers <[email-masked]> 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.

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

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