Sending Accounting Response
Padam J Singh
padam.singh at inventum.cc
Mon Dec 15 11:49:50 CET 2008
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,
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
>> 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
More information about the Freeradius-Users