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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html