Re: [radext] More bad behavior

Alan DeKok <aland@deployingradius.com> Tue, 05 September 2023 11:11 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 6970BC14CF1C for <radext@ietfa.amsl.com>; Tue, 5 Sep 2023 04:11:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 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, 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 7J5JkBOSMJjY for <radext@ietfa.amsl.com>; Tue, 5 Sep 2023 04:11:01 -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 EB784C15154A for <radext@ietf.org>; Tue, 5 Sep 2023 04:11:00 -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 A906A308; Tue, 5 Sep 2023 11:10:57 +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: <CAMAo9NbGX1bXg3mOQ3_nvSCAhR6e-WzzDQBVunYn1Xz+8VMZmA@mail.gmail.com>
Date: Tue, 05 Sep 2023 07:10:56 -0400
Cc: radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <FD4EA564-FAB8-4FF0-9226-5DF1655042A7@deployingradius.com>
References: <D8A1FC3E-EC1A-48F4-87B9-B5E454FA4B40@deployingradius.com> <CAMAo9NbGX1bXg3mOQ3_nvSCAhR6e-WzzDQBVunYn1Xz+8VMZmA@mail.gmail.com>
To: yasin.kaplan@kaplansoft.com
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/28N0f3Vy1AS4nHlp19X-hXiHyVY>
Subject: Re: [radext] More bad behavior
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: Tue, 05 Sep 2023 11:11:05 -0000

On Sep 5, 2023, at 5:06 AM, Yasin KAPLAN <yasin.kaplan@kaplansoft.com> wrote:
> There may be a couple of reasons why a RADIUS server cannot process/record the received accounting requests as you stated. Replying with an Error-Cause would be more useful and this should have minimum impact on existing RADIUS client/server implementations. RADIUS clients have limited resources to keep failed RADIUS accounting requests for retrying. Replying with an Error-Cause would eliminate unnecessary resource usage on the client side.

  That's good.

> RADIUS clients should disconnect user sessions if a predefined amount of RADIUS interim updates cannot be processed to prevent revenue loss if RADIUS accounting is being used for billing purposes.

  That's bad.

  I disagree so strongly that I'm not sure how to say anything other than "No".

  There are many, many, situations where accounting has little to do with billing.  There are many situations where faults are transient (e.g. 30s - 5min).  Do we really want to say that hundreds of thousands of users get kicked off of a GGSN because of some transient upstream network fault?

  No, I don't think we do.

> Some systems may implement only  RADIUS accounting so there should not be a problem to receive and process accounting packets without authentication. A RADIUS server can emit a disconnect request for an un-authenticated session when a RADIUS accounting start is received without authentication if the network policy mandates it.

  RADIUS clients should not implement policy.

  RADIUS servers should implement policy.  Server send policy to the NAS, where it is applied.

  If the RADIUS server wants the client to disconnect users, it can send instructions to the client.  This could be a disconnect packet, or even a new attribute in an Access-Accept, such as "max accounting failure time".

  But the client should never make these decisions on its own.  And vendors should never put such "features" into their products.

  Alan DeKok.