Re: [radext] BoF request for IETF 115

Alan DeKok <> Sun, 02 October 2022 18:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6BC37C14F6EB for <>; Sun, 2 Oct 2022 11:36:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Mj9ZVfl7cN2F for <>; Sun, 2 Oct 2022 11:36:51 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id DF7E9C14F612 for <>; Sun, 2 Oct 2022 11:36:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 8F334115; Sun, 2 Oct 2022 18:36:44 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.\))
From: Alan DeKok <>
In-Reply-To: <009601d8d66b$0f411d80$2dc35880$>
Date: Sun, 02 Oct 2022 14:36:42 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <009601d8d66b$0f411d80$2dc35880$>
To: "<>" <>
X-Mailer: Apple Mail (2.3696.
Archived-At: <>
Subject: Re: [radext] BoF request for IETF 115
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 02 Oct 2022 18:36:53 -0000

On Oct 2, 2022, at 10:27 AM, wrote:
> Something I'd find useful is a RADIUS equivalent of traceroute.

  There are privacy implications for operators.  They might agree to connections on one hop, but there are multiple other hops they don't control.  Do they agree to sharing their information with operators they don't know?

  That being said, a roaming group could require such information sharing for its members.

> This would allow a RADIUS client to probe the path towards a named realm
> across none, one or more proxies.
> I think this might be useful because
> * the RADIUS protocol offers limited diagnostic information across proxies
> (e.g., realm availability)

  We've needed a realm routing protocol for a very long time.  Unfortunately, there have been few people prepared to work on it.  It's not a simple problem.

  But hop-by-hop querying may be simpler.

> * troubleshooting RADIUS issues in federated environments often requires
> coordinating with multiple parties to establish what they are seeing
> * there are multiple RADIUS transports, each with their own failure modes; a
> path could incorporate two or more of these
> * there are multiple discovery methods, such as RFC7585, that have their own
> failure modes; a path could incorporate two or more of these


  One question would be: does this method probe one connection, or does it "flood fill" across multiple connections?

> I imagine it would operate similarly to Status-Server, but traverse proxies
> and provide reporting on the availability of the next hop, the transport(s),
> realm discovery method(s), failure reasons, etc.

  A new packet type would work well here.

> Even if the work of radext is wildly successful, we will be operating in a
> hybrid environment with RFC2865 for many years. I think this could be a
> useful tool to help the adoption and operation of new protocols.

  I agree.

  Alan DeKok.