The base RFCs(RFC-2865 and RFC-2866) support a user having multiple
sessions. See the definition of "session" below.
Session:
Each service provided by the NAS to a dial-in user
constitutes a session, with the beginning of the session
defined as the point where service is first provided and
the end of the session defined as the point where service
is ended. *A user may have multiple sessions* in parallel or
series if the NAS supports that, with each session
generating a separate start and stop accounting record with
its own Acct-Session-Id.
Accounting seems to be OK:
It believe that handling multiple sessions accounting is clearly supported by the RFC-2866. i.e., each susession will have its own accounting session ID. Also it appears to me that Acct-Multi-Session-Id is also used in conjunction with Accounting session ID to group the same user accounting. Though I'm not sure of the real intention of introducing Acct-Multi-Session-Id.
See the definition of Acct-Multi-Session-Id.
" This attribute is a unique Accounting ID to make it easy to link
together multiple related sessions in
a log file. Each session
linked together would have a unique
Acct-Session-Id but the same
Acct-Multi-Session-Id".
Authentication also is basically ok
After a user is authenticated, if the user wants to start a new subsession, he needs a re-authorization but not re-authentication. Though the RFC-2865 doesn't restrict having mutiple subsessions, it doesn't describe either how to handle subsessions.
IMO, we need two things for re-authorization:
a. Sending an access-request that clearly say this is an "Authorize-only"
request but not a new authentication request.
b. Attributes that describe what type of service is needed for
the new subsession. Depending on the application
new attributes can be added.
The solution for (a) could be to use the Access request with the Service Type "Authorize-Only" which is defined in RFC-3576 already.
regards
Nagi.
"Nelson, David" wrote:
Posted on behalf of Kuntal Chowdhury:>Hi all,
>
>During a recent 3GPP2-IETF co-ordination call the issue of
>authorization of multiple auxiliary sub-sessions under a PPP
>session came up. In 3GPP2 these sub sessions (termed auxiliary
>service instance) are initiated to support applications that
>need special treatments e.g. better than best effort QoS,
>header compression etc. Today, these sub sessions are not
>authorized using RADIUS messages (AR/AA). However, there are
>special accounting needs for these sub sessions i.e. separate
>accounting buckets are maintained for each of these sub
>sessions in the NAS.
>
>The intent of posting this message here is to initiate some
>discussion on sub sessions and possible RADIUS interaction.
>
>What would be the proper way to deal with these sub sessions?
>Do we need to define RADIUS procedures to handle auth and
>accounting of these sub sessions?
>Is there a possible link between the sub sessions and the need
>for sub types? Does the current (agreed) charter for RADEXT
>cover such a thing?
>
>-Kuntal
>--
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/>