Subject: RE: nasreq Re: On Demand Accounting...

From: "Bernard Aboba (Exchange)" <[email-masked]>
Date: Wed, 17 Nov 1999 21:33:38 -0800

>In general, I hope we aren't eliminating requirements simply because
>they won't work in Inter-Domain networks. 

On-Demand accounting is not an inter-domain vs. intra-domain
issue. It is more related to state synchronization between
the client and server. 

The crux of the problem is the ability to obtain a reliable 
logoff indication. Since in existing AAA protocols the
Access-Accept only establishes the *start* of the connection,
this has traditionally relied on the Accounting-Stop message,
which in RADIUS is unreliable. 

Note that the definition of reliable here may go beyond
just transport reliability, e.g. if the network is partitioned,
you may still want to eventually be able to know whether
user X is logged into device Y, even if the accounting packets
relating to that user have long since been lost. 

Given the possible failure modes, it seems that in many
cases, it will be necessary for a server to be able to 
re-sync with the client. 

I'd be interested if someone can make a convincing argument
for a simpler way to obtain this capability.

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 18 Nov 1999 06:22:29 -0800 (PST)

> for a simpler way to obtain this capability. 

Good question.

My assumption is that maintaining session state information should not
be considered as part of the accounting protocol, but part of the 
authorization protocol (assuming they are different).

The proposal that Glen and I put forth requires that the authorization
server return a session lifetime, after which the user MUST be disconnected
to the network, unless a re-authorization (and possible re-authentication)
is performed with the AAA server. If a network partition occurs, there really
isn't much that can be done, but by setting a session lifetime, it gives
the AAA server a chance to eventually recover.

An alternative is some work that I did quite a few years back with Merit that
resulted in the resource management. However, having played around with this
one quite a bit, I am doubtful that we could get session state re-sync to
occur in a network as large as the Internet.

PatC

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 18 Nov 1999 09:14:24 -0800

>authorization protocol (assuming they are different).

Can we come to closure on what "on-demand accounting" capability
really means and what is required of the AAA protocol in 
order to implement it? 

The first step is to describe the scenarios in which on-demand
accounting is required. My understanding is that this was
intended to provide services such as simultaneous usage limitation
which is *very* popular among ISPs. Is "on-demand accounting"
synonymous with simultaneous usage limitation, or not? 

There are many reasons why the simultaneous usage count can
be inaccurate. As in accounting, this can be due to packet 
loss, network partition, device reboot, or server failure. 
Thus the notion of "reliable" simultaneous usage count goes
beyond transport. So if we care about simultaneous usage
limitation this results in a number of requirements. 

The packet loss issue can be adressed via providing transport
reliability in the "Accounting-STOP" packet. Soft-state in
the authorization process will also help, as Pat describes.
If the "Accounting-STOP" cannot be delivered within the
re-synchronization interval then the sesssion state will 
be aged out. 

For the box reboot case, you need some kind of "restart"
indication, transported reliably. When the server receives
this indication, it will clear all sessions on that box. 

In the network partition case the clients could
still be connected but there is no way for the server to
know this. As soon as the partition ends, you'd want the
server to become aware of the state of the client. 

Here I think the thing to do is for the server to maintain
its state until notified of a change by the client. This
could be a reboot indication, in which case the state is
cleared. However it also could be Accounting-STOP messages
delayed by the partition. The maximum time to re-sync after
the partition ends will be equal to the maximum backed off
retransmission time. For example, if the retransmission
algorithm specifies exponential backoff up to a 60 second
interval, then the maximum re-sync time will be 60 seconds.

The last case is server reboot. In this case, we should assume
that the server has committed session state to stable storage,
so that the issue is again how long it takes for the delayed
Accounting-STOP messages to propagate to it. 

Note that solving the issues above *does not* appear to require
an explicit re-sync capability. Neither does it appear to require
some kind of "aliveness" indicator -- such as defining a "heartbeat"
message that will be sent from client to server during a minimum
time interval if no other message is flowing. While absence of
such "heartbeat" messages can indicative of loss of synchronization, 
it is not useful in recovering state.

---

From: Matt Holdrege <[email-masked]>
Date: Thu, 18 Nov 1999 12:55:15 -0800

>occur in a network as large as the Internet.

Another general concern. I hope there isn't a problem with having some
feature of AAA such as session state re-sync in the protocol as long as we 
clearly describe the scalability limitations.

That's not to say that the main AAA protocol doesn't have to be very 
scalable. It clearly does.

---

From: Aydin Edguer <[email-masked]>
Date: Fri, 19 Nov 1999 15:31:45 -0500 (EST)

> synonymous with simultaneous usage limitation, or not? 

No, "on-demand accounting" is not necessarily synonymous with simultaneous
usage limitation.

Yes, getting access to "real-time" session information is important for
reliable resource limits for authorization purposes.  And being able to
set resource limits is critical for NASREQ.

However, "real-time" session information is also important for billing
information, when dealing with things like long-term sessions, where a
billing server may be interested in gathering current usage information
at the end of a billing cycle (example: number of bytes per day) rather
than trying to wait for a session to end to get data.

This was one of the reasons that the RADIUS Interim-Update was proposed
and pushed ahead.

I think that Authorization and Accounting have independent reasons for
wanting "real-time" session information.  These capabilities should be
listed as requirements for the next-gen AAA.