Acct-Delay-Time missing with RADIUS accounting

[Nick Lowe]

> I understand that this type of sequence can be seen on a RADIUS server,
> but I'm not that interested in theoretical discussion in this front
> unless a real world case can be identified.
>
> I don't see how one would implement a RADIUS server to do something like
> this.. Are Accounting On/Off really used to override Accounting
> Start/Stop information on a session? Is this a case for a deployed
> server today? I would have assumed the sessions would be kept separate
> and On/Off messages more or less ignored for any practical purpose..

Easily! Yes, the Accounting-On notifies the server that service has
become available, and, as a logical consequence any sessions it
considers existing for the NAS are stale.
FreeRADIUS and Radiator can do this.
The Accounting-Off cannot be relied upon as you commonly may not get
this - think of NAS losing power, rebooting unexpectedly etc. Some
NASes don't send it.

The purpose of RADIUS accounting is to acccount, we should try to make
sure that it is as accurate as possible.

> Can an example deployed server implementation that uses local RX time
> stamp and Acct-Delay-Time instead of Event-Timestamp (or
> Acct-Session-Time as far as duration of the session is concerned) be
> identified?

Modern RADIUS accounting consumers/servers will all support the
Event-Timestamp attribute and tgey should be fixed where they don't
(no disagreement here!), again the primary concern is where the
Event-Timestamp cannot be populated because NTP sync hasn't completed
successfully on the NAS. This is a realistic, common scenario that
happens quite frequently. I don't think not offering service is
reasonable when we can do better.

There is also a common race observed in NASes where hostapd/its
equivalent and NTP sync take place independently during startup.
There, the initial Accounting-On and a few Starts will contain no
Event-Timestamp. NTP sync can also have delayed completion due to
other issues, or no completion at all.

Nick