Re: [radext] BoF request for IETF 115 Sun, 02 October 2022 20:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A3E8CC14F727 for <>; Sun, 2 Oct 2022 13:53:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Status: No, score=-2.107 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rzkwd-kEu4tB for <>; Sun, 2 Oct 2022 13:53:08 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::433]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id DB458C14F724 for <>; Sun, 2 Oct 2022 13:53:03 -0700 (PDT)
Received: by with SMTP id r6so14154462wru.8 for <>; Sun, 02 Oct 2022 13:53:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=thread-index:content-language:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:from:to:cc:subject:date; bh=sS23BRvmPtR5WL0OGdrgDAnDlZklTb4BGcEV/4+Jxok=; b=cjjNHLVozHuj91Mzlr6NymQadLQQEtR0ZscB3LHE2CU1fQvj1Y5lvGbvFWBwy5kMgv jXu9K6Pzt5qMhIC3I+pyEAr0Qul2/iTIzNOgsvtmpPFAjyiTxnz82LRoGUcT5NiwI1nB wZnkJPdedkuIbYiGeRakRbSd7WXdFoydvJlLPyFFWuKk8MTCCFe4wDSXSMv2quVpbxE0 lxLfnL26aLetMHoG6jbapdhkqlAw1kz78l/uyqBMQc+t7uTmX4HozfDW3NAb36MB+c5Y mzm/wI8A4mL8C+i1UPYxSPF7pBXZUHg5qETVQEcNWgkHJmh6SmiJMJEjj/Km+pnhVoOi ujAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=thread-index:content-language:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:x-gm-message-state:from:to:cc:subject:date; bh=sS23BRvmPtR5WL0OGdrgDAnDlZklTb4BGcEV/4+Jxok=; b=dvtBAqoomGTkzEyKIZ4BrvGsOB+NoOBT+qam0YQEBCESynHeoTZyZxMc83Ilq1AF1a A3RPMWVoNNSpnB46BlB1DnruMKxlqpnrRHm7d2NCpGWkGOFrEPCCt8tEQNe0jCbkelvn xY0JHi5QPYdV8NV8zZePDL8sb4kSIlw4IatwmUpwLh9OKYTzKxGV2g7fDYiOiEfHnhIZ vMaXM52XNLZDlDPENBjT7p9ZFMECFasirUuwaR6qcxLaRUK2aG/7kybScK8ewhMlEZOJ moEirh/7BCaqy1VhJL2c0sKqrKd9hKzns9h1vk+QMmZZWes9qFoJQHsU03rYFc1YBxyV S36g==
X-Gm-Message-State: ACrzQf2pPUAg0N8XOv/EZ3FK1byJrSd2pDkSXZDCAKv3uVYGneHajQk9 ofuo9EEQW4/sJGDw5JkggPI=
X-Google-Smtp-Source: AMsMyM79yJAiVFoC5JhBQiyrqR84w12lqR7GFleiiHgW+wAU0ImuV9/ZdAw+SARhdgZTyJVWKNJKRw==
X-Received: by 2002:adf:fbc3:0:b0:22c:8a19:1762 with SMTP id d3-20020adffbc3000000b0022c8a191762mr11145948wrs.169.1664743981708; Sun, 02 Oct 2022 13:53:01 -0700 (PDT)
Received: from TABLET7VKS5QAO ([2a00:23c6:fa18:ec01:0:34ec:d881:5eac]) by with ESMTPSA id l2-20020a1c7902000000b003b33943ce5esm15573567wme.32.2022. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Oct 2022 13:53:01 -0700 (PDT)
To: 'Alan DeKok' <>
References: <> <009601d8d66b$0f411d80$2dc35880$> <>
In-Reply-To: <>
Date: Sun, 02 Oct 2022 21:53:01 +0100
Message-ID: <00af01d8d6a0$f62aef70$e280ce50$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-language: en-gb
Thread-Index: AQJXjSAhih2tw0Q2YQEtxrjz+2e1eAFzGXGIAo2pVkis3hjiIA==
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 20:53:10 -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
> know?
>   That being said, a roaming group could require such information sharing
> its members.

This perhaps touches on a wider issue. RADIUS and EAP implementations tend
towards less privacy-preserving default configurations. Something else on my
wish-list is a persistent targeted identifier, similar to CUI but with
well-specified semantics, that is bound to the identity within the
authenticating EAP method. It is possible to get this outcome this with some
RADIUS and EAP products today, with configuration effort. I think a
standardised approach that reduced the configuration effort is desirable; to
get "privacy by default" for users, without compromising operators'
legitimate needs to know their users.
> > 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.
> there have been few people prepared to work on it.  It's not a simple
> problem.

I think there are people who might be prepared to work on it. However, I
think a realm routing protocol is orthogonal to a diagnostic tool:
traceroute is agnostic to RIP, BGP, etc. We need both. Although perhaps not
in this charter :-)

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

Absent a robust routing protocol, "flood fill" might be risky.

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

I agree.

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

In a similar vein, I think some guidance on operating hybrid environments
might be desirable. That might have already been mentioned?