RE: RFC3576bis and Session State

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

Hi Alan,
 

-----Original Message-----
From: Alan DeKok [mailto:aland@nitros9.org] 
Sent: Tuesday, May 29, 2007 4:39 AM
To: Avi Lior
Cc: David B. Nelson; radiusext@ops.ietf.org
Subject: Re: RFC3576bis and Session State

Avi Lior wrote:
>   Which is why I didn't suggest that the server receive accounting 
> messages.  What I said was that it should receive a 
> protocol-independent session identification key... sometimes called
Acct-Session-Id.
> 
> [Avi] Yes but it can only receive one and there can be many Accounting

> Session Ids, and they can change.

  Then we need a new session identification attribute that doesn't
change.

[Avi] Yes we have done that in WIMAX and in 3GPP2.  In WiMAX we have a
session key for the entire user session.  It is generated by the AAA and
sent to the NAS.  The NAS includes it in all subsequent AAA exchanges
and puts it in the Accounting as Acct-Multi-Session ID.  It also
survives mobility, that is when the MS hands off to another NAS and
reauthentication takes place, the same AAA session id is returned from
the HAAA to the new NAS.  And thus, we can correlate accounting that is
generated across different NASes.

[Avi] But note that this session id is *not* really required for COA or
DM. We can use NAI or CUI.  It is useful for other reasons and could be
usefull for COA and DM.  Again I designed this Session Key into WiMAX so
I cant really argue against this.


> [Avi] It may want to kill all the "sessions" that are associated with 
> a given User Identity.  The po0int of the above is that there are many

> things you can call a "session". You seem to focus on only one of them

> which is a session represented by a Start/Stop record.

  No.  I'm focusing on a session key that is independent of protocol,
NAI, CUI, or anything else.  If you pick an attribute that MAY be used
as a key, I can pick a scenario where that attribute does not exist, and
is therefore useless for CoA.

  We can say that the RADIUS server trolls through it's database,
looking for an attribute that *might* be a session key, or we can say
that the RADIUS server uses the session key sent to it by the NAS.  I
have my belief about which one is simpler to implement, deploy, and be
interoperable.

[Avi] I agree. But this Session Key is not enough.  It can only be used
to effect the entire user session.  If you want to effect or target
other sessions (sub-sessions for a lack of a better term), such as IP
sessions etc, you need another identifier to classify the COA/DM
message.

[Avi] In WiMAX the AAA sends a session id to the NAS in an Access
Accept, this session ID is then sent in any Access-Requests associated
with that user. It can also be sent in COA/DM messages.




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