Acct-Delay-Time missing with RADIUS accounting

[Nick Lowe]

> Are there really such cases? If someone really cares about exact timing,
> I'd recommend using Event-Timestamp..

Yes, absolutely, but this requires NTP sync which is not always
available. A relative delay computed from a monotonic timer is,
however, always available.

>> 2) To account reliably where the system clock is close to the UNIX
>> time epoch and the Event-Timestamp attribute cannot be included. This
>> is, of course, usually where NTP sync has not occurred.
>
> Which could be fixed by doing NTP sync..

Including the Acct-Delay-Time allows reliable accounting to occur
where NTP sync has not been able to complete. This happens for a
variety of reasons, some of which are transient.

>
>> This is complicated by the fact that when the attributes of any RADIUS
>> accounting packet change, the identifier associated with the packet
>> must be changed as well. This applies to the Acct-Delay-Time attribute
>> specifically, when the delay time is changed, a new identifier must be
>> generated packet.
>
> If this is for an intermediate accounting update, it would seem to make
> more sense to just generate a completely new accounting message with
> updated TX/RX statistics.

While the Acct-Delay-Time attribute should be included for
Interim-Updates with a value of 0, it does not make sense to resend
this form of Accounting-Request. Thus, the value here from hostapd
would always be 0.

It is, however, of significant value with Accounting-On, Start and
Stop (and potentially Accounting-Off) for reliability purposes where
these are resent.
Resending a Start, Stop or Accounting-On without an Acct-Delay-Time
attribute (where an Event-Timestamp attribute has not been able to be
included due to NTP sync not having completed) is unhelpful as it is
tantamount to a false assertion - the Accounting-Request must be
treated as just having occurred where information about when it did is
not available. It could actually have occurred some time before.

The transport of RADIUS is UDP which is inherently unreliable.

>
>> Is this something that you may be prepared to look at, Jouni?
>>
>> The initial packet sent should contain this attribute wth a value of
>> 0. Retries, the difference between the initial send and the time of
>> the retransmission, using a monotonic timer to calculate this.
>
> This sounds like undesired complexity for collecting information that is
> already available from Event-Timestamp and/or Acct-Session-Time
> depending on use. Event-Timestamp looks superior to this Acct-Delay-Time
> mechanism and it should really be easier to modify an accounting server
> (if one does not support that) than add more complex design to all NAS..

You send both the Acct-Delay-Time and Event-Timestamp attributes, not
one or or the other.
No modification would be possible at the accounting server to cope
with the case where a RADIUS client does not have access to a
synchronised, accurate clock.

> As such, I don't really see the point of doing this without clearly
> identified existing case where this needs to be done at the NAS and the
> server cannot be updated to support newer design (and explanation on why
> it would be possible to update NAS, but not server)..
>
> --
> Jouni Malinen                                            PGP id EFC895FA