Re: [radext] BoF request for IETF 115

Alan DeKok <aland@deployingradius.com> Sun, 02 October 2022 18:36 UTC

Return-Path: <aland@deployingradius.com>
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 6BC37C14F6EB for <radext@ietfa.amsl.com>; Sun, 2 Oct 2022 11:36:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
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 mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mj9ZVfl7cN2F for <radext@ietfa.amsl.com>; Sun, 2 Oct 2022 11:36:51 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (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 ietfa.amsl.com (Postfix) with ESMTPS id DF7E9C14F612 for <radext@ietf.org>; Sun, 2 Oct 2022 11:36:49 -0700 (PDT)
Received: from smtpclient.apple (135-23-95-173.cpe.pppoe.ca [135.23.95.173]) by mail.networkradius.com (Postfix) with ESMTPSA id 8F334115; Sun, 2 Oct 2022 18:36:44 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <009601d8d66b$0f411d80$2dc35880$@gmail.com>
Date: Sun, 02 Oct 2022 14:36:42 -0400
Cc: radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B32CF523-A160-4F6E-9904-8FE6151D3F11@deployingradius.com>
References: <5D005CCD-AF06-488A-AE48-5738B35EA4A2@deployingradius.com> <009601d8d66b$0f411d80$2dc35880$@gmail.com>
To: "<josh.howlett@gmail.com>" <josh.howlett@gmail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/xWSkcLYmTbPoHqSqpdx9HAnZ0wk>
Subject: Re: [radext] BoF request for IETF 115
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.39
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: Sun, 02 Oct 2022 18:36:53 -0000

On Oct 2, 2022, at 10:27 AM, josh.howlett@gmail.com 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

  Yes.

  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.