IETF Logo Mail Archive

Re: [radext] configuration auto-discovery [was: draft-cullen-radextra-status-realm-00]

Margaret Cullen <mrcullen42@gmail.com> Sun, 13 August 2023 23:04 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 EAC06C14E513 for <radext@ietfa.amsl.com>; Sun, 13 Aug 2023 16:04:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.858
X-Spam-Level:
X-Spam-Status: No, score=-1.858 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, RCVD_IN_DNSWL_NONE=-0.0001, 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: 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 mlLTQStpsUHt for <radext@ietfa.amsl.com>; Sun, 13 Aug 2023 16:04:40 -0700 (PDT)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 89117C151540 for <radext@ietf.org>; Sun, 13 Aug 2023 16:04:40 -0700 (PDT)
Received: by mail-ot1-x336.google.com with SMTP id 46e09a7af769-6bc886d1504so3393420a34.0 for <radext@ietf.org>; Sun, 13 Aug 2023 16:04:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691967879; x=1692572679; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=YfTQ1moSgZsA59sCqMt7aNRx/7Yd6ktYyhyKumfx2rY=; b=OX6KrnQSVLAmqneNe1pUvzFwhTKHJ0FtEGwAhabKbZRxEmwwPUdcoBLd7HwHrAcfTh jIZrIXC5xXHND/gILPZ6w62+miA8bUgTd/nNo1VlSxYp4bJiVveIZ+iBi058TCruY1w5 uODUtoqy7ZTJFPz2ucfP3XIxOPCy/ylBMAuTlXA89FP0A1jcFmnU/M1ZdA2TLkvsxVuM aZ6ZIPezDZ8103HNSEkG3atLlZoNi+gigBmcqWXnTSzkhsXt3XcE3vuhzlc8jmQTN+2M dNnaM9JjPuvWL/jmQUYZLxA5pHa5LAN0Kt+b3Zkk6Z2ncYjUI5RBF6BH+7qp8GFZykb7 FWug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691967879; x=1692572679; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=YfTQ1moSgZsA59sCqMt7aNRx/7Yd6ktYyhyKumfx2rY=; b=R1RWIZ6aAS9yPSEljFGO/ru1jij3FVYWvAx1rk9bPxhlOlfiqNhROb2CWRVuJPHcHu Djc7FEHeoyLkEjIW7XAV14bfEiHxZlkrmiiiXlLwpkJAjRsgr3trlTuiQf+x728S9y80 EdKycDwWABbulFHk7kvpKK9bhknNfXWtvDPoyQ+vU59K2WgUsGGsdSfC/isSQz8VOVx1 S8cI5dUNxgN2Mlu/YZYTcntSekt00Zrd1c/N9jqtGccnFHcTtUiZJ8hjZ8OqIDTM4w1b Yeojop5Ct8bO8+qz8p4JDZvTf4IcxNWpTihRwa9EJzIeYs7M+qHwf1w9k2wsbjGLCVqL AEqw==
X-Gm-Message-State: AOJu0YygtqUNv5wMqJG3P6BcbC4/k/GwuVRIhJFY8m45oYncNAwXldfg Bk1Ij/aPwWbFmZVWZdi3XJcPDKBF4Ms=
X-Google-Smtp-Source: AGHT+IED04qdnwtCRFH2iPVRWgoFIJvflgUDMNhS8ozm+0qaKdrc6nc0vStHwX8/D3P7bhMt5aYzMA==
X-Received: by 2002:a05:6870:390d:b0:1b0:4fc5:2e4b with SMTP id b13-20020a056870390d00b001b04fc52e4bmr7150784oap.9.1691967878671; Sun, 13 Aug 2023 16:04:38 -0700 (PDT)
Received: from smtpclient.apple ([2601:18c:503:9630:5cc4:c81a:a38c:14b]) by smtp.gmail.com with ESMTPSA id s27-20020a05620a031b00b00767e98535b7sm2629469qkm.67.2023.08.13.16.04.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 13 Aug 2023 16:04:38 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Margaret Cullen <mrcullen42@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Sun, 13 Aug 2023 19:04:27 -0400
Message-Id: <0A840344-C119-4931-BA7E-174DA1693B70@gmail.com>
References: <5B16D759-758E-4701-8C7E-4A563AC74274@gmail.com>
Cc: Alan DeKok <aland@deployingradius.com>, Alexander Clouter <alex+ietf@coremem.com>, radext@ietf.org
In-Reply-To: <5B16D759-758E-4701-8C7E-4A563AC74274@gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
X-Mailer: iPhone Mail (20F75)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/DaF5WXY_asGjhDdD-6KYavRAcZY>
Subject: Re: [radext] configuration auto-discovery [was: draft-cullen-radextra-status-realm-00]
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, 13 Aug 2023 23:04:46 -0000

[Chair hat on]

Defining a RADIUS routing protocol is quite obviously outside the charter of this WG.  If anyone actually wants to discuss that topic in depth, we should probably do that elsewhere. 

It is potentially in scope to document implementation advice, and I think it makes sense to discuss if we could provide some good advice about failover, etc.

[Chair hat off]

“RADIUS routing protocol” is sort of a misnomer for what the expired Trust Router ID defined.  It was actually a definition of how to run the Babel routing protocol (as specified by the IETF routing area) to route requests over RADIUS proxy paths, which are similar in many ways to IP routing paths.  It’s not a good idea to define special-purpose routing protocols, any more than it is to define special-purpose crypto for several reasons, including the ones Bernard cited.

Margaret


> On Aug 13, 2023, at 2:23 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> 
> On Aug 11, 2023, at 06:45, Alan DeKok <aland@deployingradius.com> wrote:
>> 
>> Any RADIUS routing protocol is going to take time to do.  The existence of dynamic discovery (RFC7585) makes it less critical in some areas.
> 
> [BA] Before embarking on the design of a routing protocol (which is an IPR minefield and could generate lots of route flap traffic) it would first be useful to define use cases not already handled by dynamic discovery or existing failover mechanisms. Personally I have never encountered such a use case and have often disabled routing protocols on NAS devices to avoid route flaps.

v2.23.0 | Report a Bug | By Email