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

From: "Satyanarayana Danda (sdanda)" <[email-masked]>
Date: Mon, 22 Sep 2014 06:31:10 +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.

Problem:

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.

Thanks
Satya

---

From: Alan DeKok <[email-masked]>
Date: Mon, 22 Sep 2014 08:43:30 -0400

Satyanarayana Danda (sdanda) wrote:
> 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.

  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.

---

From: "Satyanarayana Danda (sdanda)" <[email-masked]>
Date: Wed, 24 Sep 2014 06:59:40 +0000

Thanks a lot Alan for your response!

On 22/09/14 6:13 pm, "Alan DeKok" <[email-masked]> wrote:

>> Some of the Radius Servers doesn¹t seem to be allowing receiving of
>> Accounting requests
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
mentioned.
>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.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 24 Sep 2014 09:12:23 -0400

> we can edit them otherwise, let me know how we can make use of this.

  We would need another 3-4 issues to make a document.  For now, I don't
think there's enough content to gain WG adoption.

  Alan DeKok.