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

"Satyanarayana Danda (sdanda)" <> Wed, 24 September 2014 06:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7E5CE1A70FD for <>; Tue, 23 Sep 2014 23:59:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.287
X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DEk6ATt8gu5K for <>; Tue, 23 Sep 2014 23:59:42 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B033D1A1ACD for <>; Tue, 23 Sep 2014 23:59:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3670; q=dns/txt; s=iport; t=1411541982; x=1412751582; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MR1dwMs2af8YzYBKcn2BqtSG6Y/TFT5VGcs81vcnhl8=; b=nHLDj0JawDMcekn7L29O5KK6eV/qiiA+7fZHYMNBsuLHA+YdCknvfCFw uLuDkSgWEmKY6FSYNYQ2FDaqVzxFHeAsNX4TuUDJBysd9Tmn4e0wjj48a NYcG6bcydB54sEo/jNs+04UmUr44865dqyv2Hm8o8q3vr8yuJHokq2flq s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.04,587,1406592000"; d="scan'208";a="80672727"
Received: from ([]) by with ESMTP; 24 Sep 2014 06:59:41 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s8O6xf1P025562 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Sep 2014 06:59:41 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Wed, 24 Sep 2014 01:59:41 -0500
From: "Satyanarayana Danda (sdanda)" <>
To: Alan DeKok <>
Thread-Topic: [radext] Decoupling Authentication/Authorization with Accounting - Server side functionality
Thread-Index: AQHP1i7MByc6PN4k/k6kogVoHpnecZwNbRMAgAMgygA=
Date: Wed, 24 Sep 2014 06:59:40 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [radext] Decoupling Authentication/Authorization with Accounting - Server side functionality
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Sep 2014 06:59:44 -0000

Thanks a lot Alan for your response!

On 22/09/14 6:13 pm, "Alan DeKok" <> wrote:

>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
>  Ignoring packets in other situations is bad.
That case is understandable, but we can able to see the server is not
accepting with the simple reason is that,
Authentication/Authorization was not done with that. This is wired as you
>> *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.
I am not aware if any such kind of document exist already. If they are,
we can edit them otherwise, let me know how we can make use of this.
>  Alan DeKok.