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

[Alan DeKok <[e-mail]>]

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.