RE: RFC3576bis and Session State

["Avi Lior" <avi@bridgewatersystems.com>]

Alan,

Again I am not opposed to using Accounting-Session-ID.

Please see inline.... 

-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
On Behalf Of Alan DeKok
Sent: Saturday, May 26, 2007 10:39 AM
To: Glen Zorn (gwz)
Cc: Bernard Aboba; radiusext@ops.ietf.org
Subject: RFC3576bis and Session State

Glen Zorn (gwz) wrote:
...
>>   What I'm saying is that the NAS knows what a session is: the user 
>> is connected to it.  The NAS has the information that ties 
>> authentication packets to accounting packets:  the Acct-Session-Id.
> 
> Only if it supports RADIUS accounting, which I believe you stated is 
> not mandatory.

Alan wrote:

   The NAS can send Acct-Session-Id in an Access-Request without ever
sending an Accounting-Request packet.  This is permitted by the existing
specifications.

[Avi]  But it may not be sufficient.  Since an Access-Request can only
contain a single Accouting Session ID and there could be many sessions
each having their own Accounting Session Ids.  Also accounting session
id may change without an access request.  

Therefore Acct-Session-Id can only be useful in simple deployements.
Which is fine.

In cases where there are many Acct-Session-Ids then the AAA server may
need to hunt for them in the accounting stream (which is what Glen is
eluding to).

 
> presumably by letting the RADIUS server grovel through thousands of 
> accounting records (if they exist).  Of course, knowing the location 
> and format of these records doesn't constitute an "undefined but 
> incestuous relationship".

   Maybe I'm missing something.  I thought I was proposing that the
authentication server track sessions by ID sent in Access-Request, not
in Accounting-Request.

[Avi] It can only track one of them since you can only have one in an
Access Request.

> OK, one simple question: when and how does the RADIUS server (since 
> it's not necessarily the same as the accounting server & therefore 
> will not necessarily receive Accounting Stop records) know that the 
> session has ended and that it can therefore discard that data?

   When it is the same as the accounting server, there's no problem. 
When it isn't, it can use attributes like "Session-Timeout" to track
when the session is supposed to end.

[Avi] But how does it know when the session ended as opposed to when it
was suppose to end.  Session-Timeout can be really long.  So that
doesn't really work right?


> and that RADIUS
> servers need a way to keep track of user sessions _outside_ of 
> accounting.

   Mostly.  There are few deployments where the authentication server
needs access to the accounting data.  There are many deployments where
the accounting data triggers CoA packets... in which case the sender of
the CoA has access to the accounting information.

[Avi] Doesn't really scale Alan.  There are many many accounting
sessions being generated in some deployements for each
Access-Authentication.  These include interims but even without those
the ratio can be more then 10:1. 


--

to unsubscribe send a message to radiusext-request@ops.ietf.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>