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

[Avi Lior <avi@bridgewatersystems.com>]

See inline..

BTW I am not defending the specific use case  - and I am not critizing it either.  I don't have enough information.

I am concerned though that we may put in place rules/guidelines that would hinder good network design.

So specifically:

>   Sure.  But RADIUS isn't really a generic provisioning API.
[AL>] You are right RADIUS isn't a provisioning API or a provisioning system.  But the information obtained from RADIUS is being used to provision something.  Just like RADIUS is not a billing API nor a Billing system but rather the information provided by RADIUS is useful in generating a bill for the subscriber.  
The information being generated by RADIUS is used for many purposes.

In this particular case I think your issue is with using accounting messages to provision a firewall.  I think it is that the accounting message is generated along the proxy chain (okay the extreme end of the proxy chain but nevertheless the proxy chain). Right?


>   The "naive" expectation is that accounting messages are tied to
> sessions, and generated by the same system that originated the
> Access-Request.
[AL>] The accounting message is still being tied to a session in this case.  And it is the same system.  The system appears to be distributed.  The real problem is that it is generated by the "same system that originated the Access-Request" Right?

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

In the specific use case, the logical entities are all communicating.  I am not sure what you mean by "Administrative System".  Who is to say that the NAS and Server or not in the same adimistrative domain.  I don't know much details about the use case.  I don't know what the Admisitrative Domain has to do with this?

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

Sure.  But who is to say that following a similar approach wouldn't simplify the network design.  We don't know enough details but perhaps in this case this was the best most economical approach to the problem.  It seems weird sitting at the IETF level.  

I am not sure what general guidance you would propose here that would help and not hinder.

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