RE: Issue 226: RFC 3576bis and Renumbering

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Alan DeKok <mailto:aland@nitros9.org> allegedly scribbled on Friday, May
25, 2007 2:03 AM:

> Glen Zorn (gwz) wrote:
>> Making Acct-Session-Id a MUST would ensure Diameter compatibility.
>> User-Name probably needs to be at least a MAY for the same reason.
>> 
>> There are just a few problems with this idea (in the absence of
>> RADIUS accounting).
> 
>   The suggestion was to require Acct-Session-Id in Access-Request,
> which would make it useful independent of accounting. 
> 
>> So, basically, what you are saying seems to be that
>> 
>> 1.
>> 	deploying RADIUS accounting is mandatory AND
> 
>   No.
> 
>> 2.
>> 	an undefined but incestuous relationship between separate RADIUS
and
>> RADIUS Accounting servers is also mandatory OR
> 
>   No.
> 
>> 3.
>> 	the RADIUS and RADIUS Accounting servers must be one and the
same
> 
>   No.
> 
>   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.

> The NAS does not currently share this information with the
> authentication server.  It SHOULD make this information available to
> the authentication server.     
> 
>   Once the Acct-Session-Id is available to the authentication server,
> it can be used to tie authentication sessions 

which don't exist

> to accounting sessions

which may or may not exist, since accounting support isn't mandatory

> in a better way than what is done right now.  

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

> It can also be used as
> a key to control parameters related to the session... like CoA.   

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? 
 
> 
>   Alan DeKok.

I really think it's been painfully obvious for some time (at least since
the publication of RFC 3576) that RADIUS servers are no longer the nice,
stateless things they were presumed to be by RFC 2865 and that RADIUS
servers need a way to keep track of user sessions _outside_ of
accounting.  Since both the RADIUS server and client have to change to
support your suggestion, it would be really cool if we could actually
_solve_ that problem here instead of just applying YABA, don't you
think?

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