[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is provisioning services in Accounting-Request packets bad?

Avi Lior wrote:
> Okay.  I think I understand....
> 
> The RADIUS server sends an access-accept to the NAS and at the same time more or less, it sends an Accounting Request message to the Back Office to provisiong something (a firewall).
>
> Weird.  This is instead of the NAS generating an accounting request message.

  Yes. and yes.

> But given that what is wrong with this?
> 
> For one, the session may not have started on the NAS so you have provisioned something that may have not happened.  In the case of the FW, this could be bad - you opened a hole for something that isnt really there etc.

  Sure.  But RADIUS isn't really a generic provisioning API.

> But is this still problematic in general.
> 
> The general case is:
> 
> 1) Does the specification require that an Accounting message be generate by a NAS only.  Or can it be generated by a proxy or server?

  The "naive" expectation is that accounting messages are tied to
sessions, and generated by the same system that originated the
Access-Request.

> I am not sure what the answer to one should be.  I would think no. But there could be corner cases where the real NAS cant generate accounting and the next hop AAA proxy can.  Certainly in some deployments the NAS is not really a single entity.  So  making a rule could break these corner cases.

  Sure.  If the same "administrative system" creates Access-Requests &&
Accounting-Requests, it doesn't matter which box creates what, so long
as they all communicate.  But that's very different from having the
system sending an Access-Accept create an Accounting-Request packet.

> But what is the real problem here? Other than potential problems for particular use cases.  I think we should remain silent.

  It complicates network design.  It potentially allows for unlimited
growth in the number of RADIUS packets based on a login.  If the
Access-Request is proxied multiple times. and each proxy "invents"
another RADIUS packet... bad things can happen.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>