Re: [radext] More bad behavior

Yasin KAPLAN <yasin.kaplan@kaplansoft.com> Tue, 05 September 2023 09:07 UTC

Return-Path: <yasin.kaplan@kaplansoft.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 64920C15153D for <radext@ietfa.amsl.com>; Tue, 5 Sep 2023 02:07:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kaplansoft.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 tuOdC-alYxBE for <radext@ietfa.amsl.com>; Tue, 5 Sep 2023 02:07:11 -0700 (PDT)
Received: from mail.kaplansoft.com (mail.kaplansoft.com [178.18.207.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C2EEC151538 for <radext@ietf.org>; Tue, 5 Sep 2023 02:07:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaplansoft.com; s=ks; h=from:to:subject:message-id; bh=AjatWwQRKMsF/FPBP/6tMmohhu65wTHufHoWuLJlgH0=; b=2WMpCU2LAqzhZvZnWllR8d5fVFhgT7S8A5+BL0x1iDnfngqNSYl/JN7Ybtpc+w1HT9OsI3on2hqb5Bnze7MRq0kXxaZQA3vkn9ya7gxVI5wb59oYnbkUu9fT4PLAseGHCntPXqBq2klqCZ02/sECc8VKKrtqkvvGVWI/BKzEJuS2IB0Xqa0rtYQes7N9nmKAUTvtY/Qjgxu4eYteCiQQJtOZHfm1OgJ0JiR/QcAZz1yEeiC59o8k40BR7K3PWEM0qAEjHV2ulFgTpc3E4Hcdl0yPDQucWumtAPw49w9ZJd1dGDgxsN4yZUP/rO9mMXarLVn1m18VlXYGPpJ8pzPWgQ==
Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by mail.kaplansoft.com (TekSMTP v/1.5); Tue, 05 Sep 2023 09:06:59 +0000 (UTC)
Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-401b393ddd2so21879545e9.0 for <radext@ietf.org>; Tue, 05 Sep 2023 02:06:58 -0700 (PDT)
X-Gm-Message-State: AOJu0YwZRYNgkhVSbE9i5YVGHzuEb5Vo/nE4mPvHTO8kvhkwmysJvlSn VzdUuaif/XxMFAbEg3H4SNamvRWq4fHdJ4hA1RE=
X-Google-Smtp-Source: AGHT+IHyo2TZsVo+d/CJZNhDK3t4iN54Ns7nlzWpXejzEBoqWPdDCH/wLO/L4KkFDqSqjaOfNJ6tFHHkIiaLEboUHPg=
X-Received: by 2002:a7b:cd07:0:b0:401:aa8f:7565 with SMTP id f7-20020a7bcd07000000b00401aa8f7565mr8880981wmj.34.1693904806776; Tue, 05 Sep 2023 02:06:46 -0700 (PDT)
MIME-Version: 1.0
References: <D8A1FC3E-EC1A-48F4-87B9-B5E454FA4B40@deployingradius.com>
In-Reply-To: <D8A1FC3E-EC1A-48F4-87B9-B5E454FA4B40@deployingradius.com>
Reply-To: yasin.kaplan@kaplansoft.com
From: Yasin KAPLAN <yasin.kaplan@kaplansoft.com>
Date: Tue, 05 Sep 2023 12:06:33 +0300
X-Gmail-Original-Message-ID: <CAMAo9NbGX1bXg3mOQ3_nvSCAhR6e-WzzDQBVunYn1Xz+8VMZmA@mail.gmail.com>
Message-ID: <CAMAo9NbGX1bXg3mOQ3_nvSCAhR6e-WzzDQBVunYn1Xz+8VMZmA@mail.gmail.com>
To: radext@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004a9599060498f2af"
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/5fyU6ZsrHSkiN2SYnqiNPMEgmvc>
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 09:07:16 -0000

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.

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.

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.

On Mon, Sep 4, 2023 at 8:48 PM Alan DeKok <yasin.kaplan@kaplansoft.com>
wrote:

>   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.
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext
>


-- 



*Yasin KAPLAN*
KaplanSoft

Buyukdere Cd. No:67-71, Alba Is Mrk. K:9 /29 Sisli, Istanbul, Türkiye


*Tel Mobile*

: +90 (212) 356 12 12
: +90 (532) 218 12 74



*This e-mail and the attached documents may contain confidential or
privileged information intended for the named addressee only. If you are
not the addressee or an employee or other authorized representative of the
said addressee, take notice that any reproduction or communication of said
documents or their contents is prohibited. If you have received this e-mail
by mistake, please notify the sender, if necessary, delete this e-mail
without copying or disclosing it. Kaplan Bilişim ve Yazılım Ticaret Ltd.
(İTO Reg.# 798840) accepts no liability for this email's content.*