[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is provisioning services in Accounting-Request packets bad?
Avi Lior wrote:
> 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?
Yes.
> [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?
Yes.
> 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?
What I mean is that the "NAS" functionality may be split across more
than 1 machine. If so, they are all managed by the same people.
> 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.
RADIUS isn't a generic provisioning system?
I could use accounting packets to provision new users, rather than
using direct DB writes. If the administration system doesn't have write
access to the database, it could use RADIUS to send the new user
credentials to the RADIUS server, which would write them to the DB.
It's possible, but weird, and likely not recommended.
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/>