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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DCB44C14F743 for <>; Sun, 2 Oct 2022 07:27:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Status: No, score=-2.108 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_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 d_mUkGcb3Whp for <>; Sun, 2 Oct 2022 07:27:46 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::432]) (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 C672EC15E6F4 for <>; Sun, 2 Oct 2022 07:27:13 -0700 (PDT)
Received: by with SMTP id b7so5805788wrq.9 for <>; Sun, 02 Oct 2022 07:27:13 -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:to:from :from:to:cc:subject:date; bh=QhfEJsw7sRZQs9hdQ2kSRlrcOALkJhDn467I6F0n+Os=; b=a/VS0c74RDA2AqHN568uRTy3dCY5Y4ZP+Q/NRm1EVd31CGJDbHdiuWlPF5wkX+PJYc YS+bGYYbLAcSE/2ceXNGXcNpj/E/wid/ULPwq5cpXc52GyxD2yxyqYmdq6JuxgsMbPv8 1DKbUhPL/UCjOR/U7/dTRDa6TVp/CGblqNGTFxyGTLYDHkZjD5lF0atEdY6FrnBUPRfJ k6uwV8BG67D3vHzVZh9UNbNjBpLxNJtI5YlIPWsUY9zidmK9eNktNJTkbNeGDTK2v8Aa B3U6F6Of31AgiM7s2+We9w6sSToWgxhzkf5X2JkpcQMjgPilSglhGx4vgAO76gGJwVdz jYLQ==
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:to:from :x-gm-message-state:from:to:cc:subject:date; bh=QhfEJsw7sRZQs9hdQ2kSRlrcOALkJhDn467I6F0n+Os=; b=CII+GoErfF2UHU9eIChtGs1rylciXO1plcT0h+SXfmL3Ag7Mq6Mr6yJ2gihG7RT9kx 0IXdaf//BsQTWCJkFR9bgaY7NwwpWmOAdf2MIE15ESfu8olrX1G8dOQ/JBrsTmqJUS18 hGDgQsB6nGZj+m8C40LQuUeNIqWEVQRZwSw+76FCjN8Nju4Avr89Ucuhha3mQ9ZX6Qqu 5kqjakPfKqOvDU+5LEVA5bAXCqrnNXZIQloZZNSJ+Mygmn4cDdzRHytsi5w634PWthny dzR+JhJxwJZYB2NOTMqRP5E62nPJJeVImYSBYItoWIwkATaiaYtdQYUjjClDWGbdrbVY 4Y7g==
X-Gm-Message-State: ACrzQf1kCkb9AICHSDucUm6TVBGFqEsntfycMp5SmTh9gfuezYFj33Vi Qx8OWiQ/wsUnp7oeairGgQsK6rPDkp8=
X-Google-Smtp-Source: AMsMyM7O+TmRwi1BIOiJAijIIxcc/VTu6AAxAU/U9DBDUaQiMmgx036hvpbkCStE7TIjFZZz6DuKSA==
X-Received: by 2002:a5d:5887:0:b0:22b:107e:7e39 with SMTP id n7-20020a5d5887000000b0022b107e7e39mr11107798wrf.694.1664720831483; Sun, 02 Oct 2022 07:27:11 -0700 (PDT)
Received: from TABLET7VKS5QAO ([2a00:23c6:fa18:ec01:0:34ec:d881:5eac]) by with ESMTPSA id v4-20020a5d4b04000000b00228d7078c4esm7475075wrq.4.2022. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Oct 2022 07:27:10 -0700 (PDT)
To: 'Alan DeKok' <>,
References: <>
In-Reply-To: <>
Date: Sun, 02 Oct 2022 15:27:10 +0100
Message-ID: <009601d8d66b$0f411d80$2dc35880$>
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+2e1eKz9tPCw
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 14:27:46 -0000

Something I'd find useful is a RADIUS equivalent of traceroute.

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)
* 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

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.

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.