[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is provisioning services in Accounting-Request packets bad?
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.
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.
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?
2) Does the specification allow a Proxy to add attributes to accounting.
The answer to 2 is yes.
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.
But what is the real problem here? Other than potential problems for particular use cases. I think we should remain silent.
On 15-06-2010, at 15:35 , Alan DeKok wrote:
> Bernard Aboba wrote:
>> Alan DeKok said:
>>
>> " The NAS sends an Access-Request to the RADIUS server. The RADIUS
>> server originates the Accounting-Request."
>>
>> So this requires the NAS to act as an Accounting Server?
>
> Nope. A third machine receives the Accounting-Request.
>
>> What if doesn't respond? Does the RADIUS server keep retransmitting the
>> Accounting-Request??
>
> Nope. The time frames are 'too short' for retransmits to be relevant.
>
> 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/>
Avi Lior
avi@bridgewatersystems.com
office: +1 613-591-9104x6417
cell: +1 613-796-4183
--
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/>