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

["Satyanarayana Danda (sdanda)" <[e-mail]>]

Thanks a lot Alan for your response!


On 22/09/14 6:13 pm, "Alan DeKok" <[e-mail]> 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
>them.
>
>  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
mentioned.
>
>> *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.