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

Jan-Frederik Rieckers <rieckers@dfn.de> Thu, 07 April 2022 14:42 UTC

Return-Path: <rieckers@dfn.de>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D7B3A0115 for <radext@ietfa.amsl.com>; Thu, 7 Apr 2022 07:42:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level:
X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dfn.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNbj4wFPt0Y6 for <radext@ietfa.amsl.com>; Thu, 7 Apr 2022 07:41:55 -0700 (PDT)
Received: from c1004.mx.srv.dfn.de (c1004.mx.srv.dfn.de [194.95.239.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA3D43A00E0 for <radext@ietf.org>; Thu, 7 Apr 2022 07:41:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dfn.de; h= content-type:content-type:organization:subject:subject:from:from :content-language:user-agent:mime-version:date:date:message-id :received; s=s1; t=1649342509; x=1651156910; bh=/0eMwZ1aJjYRNwNo N1jHDLlf8KiI7yb+sjhRR1G31Hs=; b=JA7jnk/t1aJqRerhgtn/gY6TZ97hmW3D BEHZ0BkEF1r8cVbRaGTUjpBzBjatQfO7S3/iPs91irmSbrL0BG451AgtP0btv/c4 yfcY9rkOviJdBSMFm/Eq2v6jLOoJw4gImWT/TD/MKoAdlgk2bvQrrboWFwHmYl4Z tVeZ6uC740I=
Received: from mail.dfn.de (mail.dfn.de [IPv6:2001:638:d:c102::150]) by c1004.mx.srv.dfn.de (Postfix) with ESMTPS id DBAEC1200F5 for <radext@ietf.org>; Thu, 7 Apr 2022 16:41:49 +0200 (CEST)
Received: from [IPV6:2001:638:d:1016::1000] (unknown [IPv6:2001:638:d:1016::1000]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mspool2.srv.dfn.de (Postfix) with ESMTPSA id 4BC12103 for <radext@ietf.org>; Thu, 7 Apr 2022 16:41:48 +0200 (CEST)
Message-ID: <7e818ffb-4dfd-5dc0-53ba-2003b486e4bc@dfn.de>
Date: Thu, 07 Apr 2022 16:41:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
Content-Language: en-US
To: radext@ietf.org
From: Jan-Frederik Rieckers <rieckers@dfn.de>
Organization: DFN e.V.
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms070606090407010202030705"
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/70U1COsepOJFxqsVWuu4smB4rAk>
Subject: [radext] Are there RFCs for "Proxy path control" in RADIUS?
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Apr 2022 14:42:01 -0000

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: rieckers@dfn.de | 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