Re: [radext] Accounting and Protocol-Error (was: Review of draft-ietf-radext-radiusdtls)

Alan DeKok <aland@deployingradius.com> Fri, 12 April 2024 21:25 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 1E032C14F703 for <radext@ietfa.amsl.com>; Fri, 12 Apr 2024 14:25:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 p_UIp4jeXT1g for <radext@ietfa.amsl.com>; Fri, 12 Apr 2024 14:25:07 -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 D6F24C14F6A9 for <radext@ietf.org>; Fri, 12 Apr 2024 14:25:06 -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 D448D55A; Fri, 12 Apr 2024 21:25:02 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <a0538e50-9219-47db-9cf8-87a52a9413c1@dfn.de>
Date: Fri, 12 Apr 2024 17:25:01 -0400
Cc: radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2CC92E0A-FDC3-46A5-9376-F38F958EF484@deployingradius.com>
References: <CA9BEA9C-39EF-4764-A0FE-D122413B37F7@deployingradius.com> <47fb04d9-a224-457f-b169-d94e29fe007e@dfn.de> <a0538e50-9219-47db-9cf8-87a52a9413c1@dfn.de>
To: Jan-Frederik Rieckers <rieckers@dfn.de>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/5bQyQLua_xeEG9qAW3vWmCNNKv8>
Subject: Re: [radext] Accounting and Protocol-Error (was: Review of draft-ietf-radext-radiusdtls)
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, 12 Apr 2024 21:25:09 -0000

On Apr 10, 2024, at 3:58 AM, Jan-Frederik Rieckers <rieckers@dfn.de> wrote:
> Protocol-Error is defined in RFC7930, which is experimental, as far as I can see.
> (Could we just ask the IESG to change this to Proposed Standard without a bis document? I'm not sure about the process here. I haven't read the document fully yet, but it's on my reading list.)

  There is a process for that, yes.

> I don't have a very strong opinion about this, but since this changes the original RFC6614/7360 spec, we should make an informed decision, especially because this affects clients.
> Clients are the part where the current bis document changes the least, i.e. by not mandating both TLS and DTLS.
> 
> Changing the response from Accounting-Response to Protocol-Error would mean that clients need to adjust their implementation.

  That is the biggest issue.

  It would be very nice to have the ability to say "No, please send this accounting packet somewhere else".  But that solution would require a lot of careful design.

  TBH, that may be a good use for ALPN.

  Alan DeKok.