Re: [radext] Decoupling Authentication/Authorization with Accounting - Server side functionality

Alan DeKok <aland@deployingradius.com> Mon, 22 September 2014 12:43 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18751A1AB8 for <radext@ietfa.amsl.com>; Mon, 22 Sep 2014 05:43:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvwm7grbmpeE for <radext@ietfa.amsl.com>; Mon, 22 Sep 2014 05:43:33 -0700 (PDT)
Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1AC1A1AB6 for <radext@ietf.org>; Mon, 22 Sep 2014 05:43:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id D041322407D8; Mon, 22 Sep 2014 14:43:31 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at power.freeradius.org
Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qT706P0nkHt1; Mon, 22 Sep 2014 14:43:31 +0200 (CEST)
Received: from Thor.local (unknown [70.50.218.244]) by power.freeradius.org (Postfix) with ESMTPSA id 3B77222402FA; Mon, 22 Sep 2014 14:43:31 +0200 (CEST)
Message-ID: <54201972.7050403@deployingradius.com>
Date: Mon, 22 Sep 2014 08:43:30 -0400
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: "Satyanarayana Danda (sdanda)" <sdanda@cisco.com>
References: <D045C000.1B2F7%sdanda@cisco.com>
In-Reply-To: <D045C000.1B2F7%sdanda@cisco.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/JAIODyVhLB29VSnp7YCR8xg_4nU
Cc: "radext@ietf.org" <radext@ietf.org>
Subject: Re: [radext] Decoupling Authentication/Authorization with Accounting - Server side functionality
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 22 Sep 2014 12:43:35 -0000

Satyanarayana Danda (sdanda) wrote:
> Some of the Radius Servers doesn’t seem to be allowing receiving of
> Accounting requests
> From BRAS/NAS/BNG in case the respective Subscriber/User is not
> authenticated/Authorised before when he was given network access.
> This restriction is making a few deployments to face challenges from

  This is technically within the standards.  Only because the standards
are silent on a *lot* of behavior.  They assume that people implementing
RADIUS are reasonable.

> *Use-Case 1:*
> 
> Most of the BRAS/NAS/BNG devices would support LOCAL
> Authentication/Authorisation where the respective User/Subscriber gets
> Authenticated/Authorised locally. But due to space constraints or
> persistent restrictions, BRAS/NAS/BNG device would be using Radius
> protocol for Accounting.
> With the restriction/issue as outlined above, the Radius Server seems to
> be dropping/ignoring the Accounting request.

  The only reason (IMHO) to drop Accounting-Request packets is when the
server is *unable* to store packets locally.  i.e. the server normally
logs packets, but suddenly the disk is full, or the database is down,
etc.  So the server can't log accounting packets, and starts to ignore them.

  Ignoring packets in other situations is bad.

> *Use-Case 2:*
> 
> Another use-case is that, with the BRAS/NAS/BNG User/Subscriber
> redundancy (e.g geo-redundancy)  where the Subscriber/User session gets 
> moved to different BRAS/NAS/BNG time to time. The Subscriber/User gets
> Authenticated/Authorised once with the Radius Server and the change of
> Subscriber's
> Current attachment point (BRAS/NAS/BNG) information would get exchanged
> time to time by exchanging either Accounting START or Accounting INTERIM
> records with the Radius
> Server. In this case, the User/Subscriber was not
> Authenticated/Authorised from the new BRAS/NAS/BNG device and hence
> respective Accounting records get dropped.

  Which is exactly why the server should NOT drop accounting packets.

  I see the above scenario all of the time.  Packets go to the wrong
server, go missing, fail-over happens, etc.  It is the responsibility of
the RADIUS ecosystem (DB, etc.) to process all of the accounting data.

  This may mean post-processing, to merge records.  It may mean
discarding DB records for users which don't exist.  etc.

> Having said that, we might have a few use-cases which I may not aware
> of, but due to the restriction as mentioned might see same challenges.
> IMO, we should be looking at some means of standardising the behaviour
> at least as a an informational thing.

  I can't think of any "normal operation" scenario where a server should
drop accounting packets.  That's just weird.

  So far as fixing RADIUS goes, I would put recommendations into an
"implementation and deployment" guide.  It should be informational, but
could talk about "best practices" for operating a RADIUS server.

  If this is the only issue, the document would be small.  It would be
good to get a larger list of operational issues, too.

  Alan DeKok.