Acct-Delay-Time missing with RADIUS accounting

[Jouni Malinen]

On Sun, Feb 21, 2016 at 07:34:39PM +0000, Nick Lowe wrote:
> There ought to be consideration of getting the Acct-Delay-Time
> attribute included in hostapd's RADIUS accounting.
> 
> https://tools.ietf.org/html/rfc2866#section-5.2
> 
> The justification for this would be to accommodate:
> 
> 1) RADIUS accounting consumers that do not support the Event-Timestamp
> attribute but do support the Acct-Delay-Time attribute.

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

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

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

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

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