[radext] More bad behavior

Alan DeKok <aland@deployingradius.com> Mon, 04 September 2023 17:47 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 D992CC131923 for <radext@ietfa.amsl.com>; Mon, 4 Sep 2023 10:47:53 -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 bhNUte_XUQZG for <radext@ietfa.amsl.com>; Mon, 4 Sep 2023 10:47:52 -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 11443C131920 for <radext@ietf.org>; Mon, 4 Sep 2023 10:47:51 -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 8FD02211 for <radext@ietf.org>; Mon, 4 Sep 2023 17:47:47 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
From: Alan DeKok <aland@deployingradius.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Message-Id: <D8A1FC3E-EC1A-48F4-87B9-B5E454FA4B40@deployingradius.com>
Date: Mon, 04 Sep 2023 13:47:45 -0400
To: radext@ietf.org
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/CpvzU-Arsn25iC49qR9Q59H3gyc>
Subject: [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: Mon, 04 Sep 2023 17:47:53 -0000

  I might just post a weekly or monthly summary of craziness seen in the wild.

  This week I've updated the Wiki:  https://github.com/radext-wg/issues-and-fixes-2/wiki/Sessions-and-Accounting

  Summary below:

## Bad packets vs Local failure

RFC 2866 Section 2 says:

   If the RADIUS accounting server is unable to successfully record the
   accounting packet it MUST NOT send an Accounting-Response
   acknowledgment to the client.

The issue of "my DB is down" is very very different from the issue of "I don't know what to do with this packet. Especially if such a packet arrives in the middle of a stream of packets which are recorded. Failure to respond to one packet can cause spurious errors.

The solution may be to reply with a Protocol-Error packet. But many systems don't support them.

Or instead perhaps send an Accounting-Response with Error-Cause = ... unknown? So systems which support that can say "this data wasn't recorded". And systems which don't support it will just keep going.

i.e. not recording bad data is likely better than failing to record good data, because of some ??? issue with bad data.

## Tying Access-Request to Accounting-Request

Some systems may look for Access-Request packets as a "session start", and then refuse to record accounting packets if no prior Access-Accept was sent. i.e. it only sends responses for sessions it believes should exist.

This behavior is almost always wrong.

In a proxying / fail-over / load-balance system, some servers may not see Access-Request packets for a session. But the accounting data is still never the less OK.

Systems should record such data for later processing.