RE: RFC3576bis and Session State

[Bernard Aboba <bernard_aboba@hotmail.com>]

> Date: Sat, 26 May 2007 16:16:31 +0100
> From: aland@nitros9.org
> To: bernard_aboba@hotmail.com
> Subject: Re: RFC3576bis and Session State
> 
> Bernard Aboba wrote:
> >  > I suggest we can request that they implement it now, *if* they also
> >  > support CoA or Disconnect request.
> > 
> > [BA] Are you suggesting that NASes implementing RFC 3576bis SHOULD send 
> > the Acct-Session-Id within an Access-Request?
> 
>    Yes.  Or, Acct-Multi-Session-Id, which may address Avi's concerns 
> over multiple Acct-Session-Id's for one "session".\

[BA]  Hmm...  Perhaps we need a change in Section 3 from:

"As noted in [RFC2866] Section 5.5:

An Accounting-Request packet MUST have an Acct-Session-Id.  An
Access-Request packet MAY have an Acct-Session-Id; if it does,
then the NAS MUST use the same Acct-Session-Id in the Accounting-Request
packets for that session.

Since the Acct-Session-Id is optional in Access-Requests,
if the Dynamic Authorization Client only has access to
attributes sent to or by the RADIUS authentication server, then it
will not necessarily know the Acct-Session-Id of the session it is attempting
to target.

Where the Acct-Session-Id Attribute is not present in
a CoA-Request or Disconnect-Request,
it is possible that the User-Name or Chargeable-User-Identity
attributes will not be sufficient to uniquely identify the session (e.g. if the same
user has multiple sessions on the NAS, or the privacy NAI is used).
As a result, one or more of the Acct-Multi-Session-Id,
Called-Station-Id, Calling-Station-Id, NAS-Port and NAS-Port-Id attributes
MAY be used as additional session identification."

To something like this: 

"A NAS implementing this specification SHOULD send an Acct-Session-Id or Acct-Multi-Session-Id Attribute within an Access-Request.  However, where the Acct-Session-Id or Acct-Multi-Session-Id is not included within an Access-Request, unless the Dynamic Authorization Client has access to accounting data, it is possible that the Dynamic Authorization Client will not know the Acct-Session-Id or Acct-Multi-Session-Id of the session it is attempting to target.

Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not present in a CoA-Request or Disconnect-Request, it is possible that the User-Name or Chargeable-User-Identity attributes will not be sufficient to uniquely identify the session (e.g. if the same user has multiple sessions on the NAS or the privacy NAI is used).  As a result, one or more of the Called-Station-Id, Calling-Station-Id,  NAS-Port and NAS-Port-Id attributes MAY be used as additional session identification." 


I can add a sentence to Section saying "A NAS implementing this specification SHOULD send
an Acct-Session-Id or Acct-Multi-Session-Id Attribute within an Access-Request." 

> 
>    Requiring this would avoid the issue of Framed-IP-Address being used 
> as both a key for the session, and the target of the change request, 
> which was the start of this thread.

[BA] Actually, it seems like it might make it unnecessary to use an IP address as a session identification attribute.
 
>    Requiring a session identification attribute would avoid the ad-hoc 
> session identification.  i.e. IPv4, IPv6, and fields from other 
> protocols used to identify sessions?  Are we going to update the RFC's 
> every time someone uses RADIUS to authorize a new protocol?
>
>    Or, we can define a protocol-independent key, and use that for all 
> protocols, old and new.

[BA] That seems like a better idea. 

> 
>    Alan DeKok.