Sending Accounting Response

[Padam J Singh]

Alan DeKok wrote:
> Padam J Singh wrote:
>> The attributes I want to send are VSAs anyway, so I fail to see how this
>> violates the RFC.
> 
>   It doesn't.  Technically.  But it's a bad idea.
> 
>   Can you explain why you need to send the attributes, and what the NAS
> does with them?
The reason I would like to use this is because the NAS I am building is
a network controller which offers advance features like speed select in
the same session, add new IP filter policies applied live on an update.
I do not want to implement an out of band service (SNMP/SOAP) to achieve
the same for something what the RADIUS protocols says is allowed, and FR
claiming it adheres to that RFC.

I have also checked up the diameter protocol - sending attributes in an
accounting answer is a *very* acceptable thing. I have even confirmed
with the RADIUS Server used by Oracle in their BRM applications used in
most telcos that sending VSAs in Accounting-Response is OK and supported.

The only other option left is to use CoA. However, the radius client
libraries that would form part of the NAS do not implement CoA. I have
read up the source code of all radius client libraries offered part of
FR and even made by others - none of them have a library which could be
used to listen for radius packets on a given port and accept and
acknowledge CoA/Packet of disconnect. So I would have to write this from
scratch, and would be most happy to contribute back to community.

> 
>> The standard install of FR also includes the following in
>> attr.accounting_response:
> 
>   Yes... I know.
> 
>> The filter does allow any VSA - I wonder why the modules are not written
>> to facilitate sending the attributes to the NAS.
> 
>   Because only one out of ten thousand users need to send attributes in
> an Accounting-Response.  And they can't explain why they need to do it.
> 

Googling for the same suggests a whole lot more users are asking the
same question. In my opinion anyone implementing Voice billing and real
time rating would love to have this.

The reason it is traditionally not required is because NASs are
generally dumb, and wouldn't require to even look for attributes in
updates. However, the new generation billing requirements are forcing
more intelligence onto these NASs.


>   If the requested functionality isn't used for anything, it won't be
> added to the server.
> 

I guess the rational thing to do if the worlds best RADIUS server cannot
do this out of the box, then use Diameter or implement CoA.

>   Alan DeKok.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
> 

-- 
PGP Id 9EED2E09