Sending Accounting Response

[Alan DeKok]

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.

> 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.)

> 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.

  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.

> 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.

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

  Alan DeKok.