racct and radpostauth

[Arran Cudbard-Bell]

On 9 Sep 2011, at 16:27, Bjørn Mork wrote:

> Arran Cudbard-Bell <a.cudbardb at freeradius.org> writes:
> 
>> RFC 2866:
>> 
>>   When a client is configured to use RADIUS Accounting, at the start of
>>   service delivery it will generate an Accounting Start packet
>>   describing the type of service being delivered and the user it is
>>   being delivered to, and will send that to the RADIUS Accounting
>>   server, which will send back an acknowledgement that the packet has
>>   been received.  At the end of service delivery the client will
>>   generate an Accounting Stop packet describing the type of service
>>   that was delivered and optionally statistics such as elapsed time,
>>   input and output octets, or input and output packets.  It will send
>>   that to the RADIUS Accounting server, which will send back an
>>   acknowledgement that the packet has been received.
>> 
>> The NAS never provides a service so it should not be sending any
>> accounting packets. Just because people demanded it and the vendor
>> caved, it doesn't mean its correct or compliant.
> 
> No, of course not.  But it may be useful in some settings.
> 
> And I really cannot see anything in the above RFC quote which forbids
> sending radius accounting packets without providing a service.  It just
> states when packets should be sent, and says nothing about when the
> shouldn't be sent.

The RFC defines the situations when these types of packets should be transmitted. If a NAS sent an additional Access-Request packet when receiving an Access-Accept or Access-Reject from the server you'd assume it was broken.

If the NAS starts sending Accounting-Stop packets for sessions which never existed you'd assume the same (unless of course you explicitly configured that behaviour).

> 
> Of course, you may choose to read RFC 2866 as "anything not explicitly
> allowed, is forbidden", but I don't think you'll ever make a vendor read
> the RFCs like that..

The only reason that they allow this behaviour is because its configurable. This behaviour is absolutely not standards compliant, and no matter how they interpret the RFCs, it doesn't change that fact.

Arran Cudbard-Bell
a.cudbardb at freeradius.org

RADIUS - Waging war on ignorance and apathy one Access-Challenge at a time.