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

"Satyanarayana Danda (sdanda)" <sdanda@cisco.com> Mon, 22 September 2014 06:31 UTC

Return-Path: <sdanda@cisco.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 478CA1A1A33 for <radext@ietfa.amsl.com>; Sun, 21 Sep 2014 23:31:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.586
X-Spam-Status: No, score=-12.586 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 72PpmAlcXUrk for <radext@ietfa.amsl.com>; Sun, 21 Sep 2014 23:31:13 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29A31A1A43 for <radext@ietf.org>; Sun, 21 Sep 2014 23:31:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6298; q=dns/txt; s=iport; t=1411367473; x=1412577073; h=from:to:subject:date:message-id:mime-version; bh=DB/FYUiD0CwJ1mi4UxxwRr9k6UVCfv0w8D4RuugL9ho=; b=GSoPTGPW2JpUUDInjTYOIV1OqBdpY+lrBE9oNeuawRmxRhqBe20W2UeQ eYbHTCPrQVrBctGbY7c/JRBJQrZJO9ZQHgVxMB723i/UOn3Ws8GkOd4hS x7Wsj/cbGpOEMBzizhNwC40NRfuGX6dFiprVhj9BZsfRfhpYyvC18v2dV g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.04,570,1406592000"; d="scan'208,217"; a="79999095"
Received: from alln-core-1.cisco.com ([]) by alln-iport-2.cisco.com with ESMTP; 22 Sep 2014 06:31:12 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com []) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s8M6VBEi026566 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <radext@ietf.org>; Mon, 22 Sep 2014 06:31:11 GMT
Received: from xmb-rcd-x14.cisco.com ([]) by xhc-rcd-x09.cisco.com ([]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 01:31:11 -0500
From: "Satyanarayana Danda (sdanda)" <sdanda@cisco.com>
To: "radext@ietf.org" <radext@ietf.org>
Thread-Topic: Decoupling Authentication/Authorization with Accounting - Server side functionality
Thread-Index: AQHP1i7MByc6PN4k/k6kogVoHpnecQ==
Date: Mon, 22 Sep 2014 06:31:10 +0000
Message-ID: <D045C000.1B2F7%sdanda@cisco.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D045C0001B2F7sdandaciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/KFfebWSpKi9YHvhtRDN_G608CWw
Subject: [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 06:31:15 -0000

Hi Friends,

Have been observing and facing challenges with  a few Radius Servers on the following aspect explained as follows.
>From protocol stand point, we don’t seem to have any standard behaviour and hence
Thought of checking with global audience on your valuable inputs and further steps to take this forward.


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 BRAS/NAS/BNG side. To mention a few known use-cases

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.

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.

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.

Please let me know your comments/feedback to take this further.