Re: [radext] BoF request for IETF 115

Margaret Cullen <mrcullen42@gmail.com> Mon, 03 October 2022 08:46 UTC

Return-Path: <mrcullen42@gmail.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 C998CC14CE41 for <radext@ietfa.amsl.com>; Mon, 3 Oct 2022 01:46:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.853
X-Spam-Level:
X-Spam-Status: No, score=-6.853 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 AtS35H84B1YU for <radext@ietfa.amsl.com>; Mon, 3 Oct 2022 01:46:25 -0700 (PDT)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 02EBBC14CF1D for <radext@ietf.org>; Mon, 3 Oct 2022 01:46:24 -0700 (PDT)
Received: by mail-qt1-x82d.google.com with SMTP id s18so5966845qtx.6 for <radext@ietf.org>; Mon, 03 Oct 2022 01:46:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:date:cc:in-reply-to:from:subject :mime-version:content-transfer-encoding:from:to:cc:subject:date; bh=PhmzMvhhKtojsZkJSZdHbDXNVnXNZJRkKk6/SN9RLYQ=; b=KuKV00DosudEjOm8ovpI+H+y5HXpgcMkpjVrtB711dLc1Tym3sBrCw4ETXyxr8aHll 4bb7OZASjg1MDsGyXgqckv0JcY2/0U+S9rk9c+ujfjVs8NH4+YFDRt8JD5qNG5ddNLm8 m4ZAOQMmryNZspFUlXAP51yaAwzxEu6pB9b5c8pWbd+NBUBds587d0u2M+SxeMtoZ4bh gCCqlrxigFuJGULxJxFOXy8Bpv9CjsobZQiSyhciYmwYrx13G0Vkf05Mlv0hEhvWdOS5 jZ4IiraT9KhMwdvaHqNwNO1nXNXq144Rpm2YLDvBFsWUbQDgkNM2sl0cSRocsxL42plk FIug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:date:cc:in-reply-to:from:subject :mime-version:content-transfer-encoding:x-gm-message-state:from:to :cc:subject:date; bh=PhmzMvhhKtojsZkJSZdHbDXNVnXNZJRkKk6/SN9RLYQ=; b=Vj3DYqr6nJC54v5QKhzrmpKiEZKYiHvMHRcJqbkg+AwK5H8zzW7wpJK/yJGpwPm7Vw rInyfAE4H/Hq6Gz7nfBVM6lNMks1OLmkgKDeNp8EMm+ExFi7TEvEMlV0BkVZ+cmdUTsW VwBGHhUk9OxIuT+jcHEAJ6K/tkoIbO1HdsxOG2vl3ZV7KIvIYUWO6UzjnEIgrtROVN1x faxjzLn4OBrDveug+uQYxpUxyaay4vd154FY9XA/5+fi14aW/fCFIJP1zrX2kggoCTwn Zl6raZZfJp57ph6K+wbj/R92TVseYy+KrYc3+CX43m5SgLQrjBdxC1jMwsjuWjvOEdXY OOlw==
X-Gm-Message-State: ACrzQf2fcscbP48DU8QiUKwdjUk0G3zCHPp4wAYIIWisz/rJky/Cegpz Jc7uywd3bfO21wFdjEa0AcSuqQBQ2y18Cg==
X-Google-Smtp-Source: AMsMyM4JMldKJ8txxhk1pso8UkREIxbFpK0qVWbBWNxfpJMhBhdC9DG6wPlOshHS9UoQhaopBfdfZQ==
X-Received: by 2002:ac8:580d:0:b0:35c:3fcc:2442 with SMTP id g13-20020ac8580d000000b0035c3fcc2442mr15069996qtg.501.1664786783716; Mon, 03 Oct 2022 01:46:23 -0700 (PDT)
Received: from smtpclient.apple ([2601:18c:502:ea50:7c7c:4638:b34a:44e0]) by smtp.gmail.com with ESMTPSA id bi41-20020a05620a31a900b006bb0f9b89cfsm11077557qkb.87.2022.10.03.01.46.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 Oct 2022 01:46:23 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-F1508E43-6C21-4ED6-B8F6-CCD5BC86CEFE"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
From: Margaret Cullen <mrcullen42@gmail.com>
In-Reply-To: <B32CF523-A160-4F6E-9904-8FE6151D3F11@deployingradius.com>
Cc: josh.howlett@gmail.com, radext@ietf.org
Date: Mon, 03 Oct 2022 04:46:21 -0400
Message-Id: <90C64DF1-C646-47D4-9449-2698A96A6A4B@gmail.com>
References: <B32CF523-A160-4F6E-9904-8FE6151D3F11@deployingradius.com>
To: Alan DeKok <aland@deployingradius.com>
X-Mailer: iPhone Mail (19G82)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/UuGuAJQl3UP9R7IQRQezH8LTnjk>
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: Mon, 03 Oct 2022 08:46:26 -0000


> On Oct 2, 2022, at 2:36 PM, Alan DeKok <aland@deployingradius.com> wrote:
> 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?

In our efforts to operate and support a large, proxied RADIUS fabric, we often wish we had a Status-Server equivalent that would cross proxies (like a multi-hop RADIUS ping), with or without a path tracing capability.

I’d be happy to contribute to an effort to provide something like that, if others agree it is needed.

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

Several years ago, a group of us designed a realm routing protocol for ABFAB called the “Trust Router Protocol”.  It has been documented in an Internet Draft, implemented as an open source project, and used (to a limited degree) in a production service.  It could be a good starting point if others agree that a realm routing protocol would be useful.

https://datatracker.ietf.org/doc/html/draft-mrw-abfab-trust-router-02

https://github.com/painless-security/trust-router

Margaret