RFC3576bis and Session State

[Alan DeKok <aland@nitros9.org>]

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.

  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.

> >   Once the Acct-Session-Id is available to the authentication server,
> > it can be used to tie authentication sessions 
>
> which don't exist

  The NAS thinks they do.  That's all that really matters.

  If the authentication server receives a session ID attribute in an 
Access-Request packet, the possible options are:

  1) Session exists on the NAS when the CoA packet is sent
  2) Session does not exist on the NAS when the CoA packet is sent.

  For condition (1), CoA works as desired.  For condition (2), the NAS 
sends a CoA-Nak, and the authentication server can nuke it's session for 
that ID.

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

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

  Note that the failure condition you're worried about is exactly the 
same as the failure condition when other attributes are used for session 
identification.  So suggesting that we use Acct-Session-Id changes nothing.

  The failure you're worried about is that the machine sending CoA may 
not have access to the accounting data.  The simple answer, then, is 
"design your network so that the machine needing data can access it".

> 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

  Well, yes.  That's been true for a long time now.

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

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

  My suggestion is only relevant to new implementations of CoA, in 
which case they're changing anyways...

  Alan DeKok.

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