[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue 226: RFC 3576bis and Renumbering
Alan DeKok <mailto:firstname.lastname@example.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
>> deploying RADIUS accounting is mandatory AND
>> an undefined but incestuous relationship between separate RADIUS
>> RADIUS Accounting servers is also mandatory OR
>> the RADIUS and RADIUS Accounting servers must be one and the
> 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
> 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
> 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
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.