Sending Accounting Response

[Padam J Singh]

Alan DeKok wrote:
> Padam J Singh wrote:
>> 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,
> 
>   The RFC's do NOT say this.  They say that VSA's are permitted, but
> they do not say what changes the NAS is permitted (or not permitted) to
> do when it receives those VSA's.
>
I agree on that completely - I am only looking for the ability to send
attributes and not derive any semantics about it between RADIUS and NAS.

>> and FR
>> claiming it adheres to that RFC.
> 
>   We are not just following the RFC's, we are actively leading the
> creation of new standards.  See RFC 5080, and the IETF RADEXT WG.
> (guidelines document, RADIUS over TCP document, Status-Server document,
> etc.)
Again, I agree and quote that FR is the best, kudos to the whole
community to make it the best.
> 
>> I have also checked up the diameter protocol - sending attributes in an
>> accounting answer is a *very* acceptable thing. 
> 
>   Yes.  Diameter is not RADIUS.
> 
>> 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.
> 
>   That doesn't mean it's a good idea.  Vendors implement all sorts of
> broken things that get forbidden by later documents.
> 
>> 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. 
> 
>   Adding CoA support to freeradius-client isn't hard.  It's likely not
> more than 40-50 lines of code to enable sending && receiving CoA packets.
> 
>> 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.
> 
>   What you are really talking about is a Dynamic Authorization *Server*.
>  See Section 1.3 of RFC 5176.
> 
>   i.e. you do *not* want a RADIUS client.  You want a RADIUS server that
> receives CoA packets, and processes them through a policy.  This is a
> lot more complicated than just sending && receiving CoA packets.
>

It is vital that this is written in a way that this can either be part
of the RADIUS Server, or can be embedded onto a NAS. It is vital that
the consideration for the CoA component to be independent and also be
available as a library. This would enable for example a call switching
agent running on an embedded device to be able to directly receive CoA
messages by enabling callbacks or message queues.

>   I expect that FreeRADIUS will likely have complete support for CoA
> within 6-9 months.  If you're willing to wait, you can just use that.
> 

I couldn't find any open implementation of CoA for NASs, so will start
writing that.

>> 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.
> 
>   That's what CoA is for.  Using Accounting-Response is wrong.
> 
>> 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.
> 
>   Then they need to implement CoA.  See the WiMAX standards, where they
> require CoA for next generation billing requirements.
> 
>> 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.
> 
>   FreeRADIUS can do this.  See "man unlang" for how to add attributes to
> the Accounting-Response.  But it's *not* tied into the default behavior,
> because almost no one needs it.
> 
I would be able to send back attributes using unlang, or jradius.

>   And the people who need it *should* implement CoA.
> 

I agree to it - but in absence of a good client library to receive CoA
messages, the simplest way out would be been account-response attributes.

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

-- 
PGP Id 9EED2E09