Acct-Delay-Time missing with RADIUS accounting

[Jouni Malinen]

On Mon, Feb 22, 2016 at 04:57:38PM +0000, Nick Lowe wrote:
> Think of this scenario:
> 
> Accounting-On sent, not received by accounting server, no ack received
> by RADIUS client therefore - queued to be resent.
> Client associates to a BSS, Start sent, received by accounting server,
> ack received by RADIUS client.
> Accounting-On resent, received by accounting server, ack received by
> RADIUS client.
> 
> The RADIUS accounting server then considers the session stale / dead.

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


On Mon, Feb 22, 2016 at 05:09:21PM +0000, Nick Lowe wrote:
> I would be happy with this but still consider adding the
> Acct-Delay-Time in to all Accounting-Request packets a much better
> solution than refusing to bring service up / or taking it down.
> It seems drastic, especially as many routers/APs frequently fail to
> complete NTP time sync for some reason. As the RADIUS protocol gives
> up a better pallet of options here, we should make use of it, in my
> opinion.

In theory, I agree. That said, I really want to get a clear confirmation
that this is a real world issue and not just theoretical protocol
discussion before spending time to work on implementing support for
Acct-Delay-Time (and commit to maintaining such functionality).

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?

-- 
Jouni Malinen                                            PGP id EFC895FA