IETF Logo Mail Archive

Re: [radext] New Version Notification for draft-dekok-radext-reverse-coa-00.txt

Alan DeKok <aland@deployingradius.com> Fri, 21 October 2022 15:02 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 64B1EC14CE2D for <radext@ietfa.amsl.com>; Fri, 21 Oct 2022 08:02:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 qncb0x8LcvFa for <radext@ietfa.amsl.com>; Fri, 21 Oct 2022 08:02:09 -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 DDDEFC14F73E for <radext@ietf.org>; Fri, 21 Oct 2022 08:02:08 -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 1A409579; Fri, 21 Oct 2022 15:02:05 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <047301d8e55c$92cefbe0$b86cf3a0$@gmail.com>
Date: Fri, 21 Oct 2022 11:02:04 -0400
Cc: radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <68A3BE8A-E6A5-459D-9281-0DD9EBFE89FF@deployingradius.com>
References: <166629465625.34785.2651702131105040@ietfa.amsl.com> <BC1CF7DC-A028-4D37-BA22-81D2AF5081B2@deployingradius.com> <047301d8e55c$92cefbe0$b86cf3a0$@gmail.com>
To: josh.howlett@gmail.com
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/iFhS3vJb6m-3KGjtTygwtUTBC5E>
Subject: Re: [radext] New Version Notification for draft-dekok-radext-reverse-coa-00.txt
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: Fri, 21 Oct 2022 15:02:10 -0000

On Oct 21, 2022, at 10:51 AM, <josh.howlett@gmail.com> <josh.howlett@gmail.com> wrote:
> RADIUS is a classic client/server protocol, with requests and challenges being transmitted in lockstep by NASes and servers respectively. I think it could be argued that CoA and related use cases point to a need for an explicitly peer-orientated model, as an exchange of requests and responses between RADIUS entities (regardless of their functional role as a NAS or whatever).

  Perhaps.. I don't see the need for e NAS to send CoAs to a home server.  So it's still largely "client / server".  It's just that for some packet flows, the roles are reversed.

  I think the key point is that the roles are flow-specific.  i.e. Access-Request is *always* NAS to home server.  CoA is *always* home server to NAS.

  Proxies (by their nature) have to deal with both flows.  But each "kind" of packet flow only flows in one direction.

> I understand that is the intended effect of CoA, and it is a great solution for the RFC2865 world. But looking forwards, I do wonder if there is value in making a break with the past, and defining a RADIUS message/routing model that accommodates bidirectional flows more naturally. That would not be backwards compatible, and so might not be worth the cost; but I am curious in opinions…

  I'd like to know more about use cases.  I can't think of a lot right now.

  Alan DeKok.

v2.23.0 | Report a Bug | By Email