RE: Issue 226: RFC 3576bis and Renumbering

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

See inline... 

-----Original Message-----
From: Alan DeKok [mailto:aland@nitros9.org] 
Sent: Wednesday, May 30, 2007 3:59 AM
To: Avi Lior
Cc: Bernard Aboba; David B. Nelson; radiusext@ops.ietf.org; Bernard
Aboba
Subject: Re: Issue 226: RFC 3576bis and Renumbering

Avi Lior wrote:
> [Avi] Yes I agree that it "can" be used.  But Alan seems to make it 
> mandatory.

  To clarify: If Acct-Session-Id is improper for any reason, we should
create a new session identification attribute specifically for this use.

[Avi] It is in WiMAX and 3GPP2.  Hence we invented a correaltion-id in
3GPP2 and in WiMAX.  These attributes are placed in
Acct-Multi-Session-Id.  In these SDO we can contorl (DM,COA) the
'sessions' using these attributes and other paramets such as IP address
etc. There is no need for Acct-Session-Id other then to correlate
Start,Interims,Stop.

I don't think we need to add a new attribute.

> [Avi] I agree that the IP Address is not *required*.  I think that 
> nothing should be *required*  because different scenarios will use 
> different session identifiers.

  How does the CoA client know what to send as session identifiers?  How
does the recipient of the CoA message know what to do, given that the
session identifiers you talk about can apply to many sessions?

[Avi] The COA Client will send the session identifiers that are
appropriate to identify the session it wants to control (DM.COA)

So here are some examples:

[1] If the COA/DM Client sends just the User Identity (CUI and/or NAI)
and/or some other identity that identifies the subscription session (in
WiMAX it's the AAA-Session-ID) Then the COA/DM Server will effect or
delete all the 'sessions' that are associated with that user.  

[2] If the COA/DM Client, in addtion to one sends includes an IP
address, then only the IP session associated with that subscription will
be modified.

[3] If the COA/DM Client, in addition to [2] Includes a flow-id (in
WiMAX PDFID) then only the flow(s) associated with that IP Session
(identified in [2]) of the Subscription (identified in[1]) will be
modified/deleted.

  My proposal involves  mandating a new session key.  This key ensures
that everyone agrees which session the CoA request applies to.  I would
recommend *also* using Acct-Session-Id, because it applies to the
individual sessions you want to control.

[Avi] Sorry.  Not needed. It works fine as you can see/

  Every single session you want to control can be individually addressed
using those two keys.  There is no need for a guesswork: "try CUI, or
maybe Framed-IP-Address, or maybe something else will work".

[Avi] We have all the identifiers we need. What makes you think that
another session identifier will help? I don't get it!  What I described
above is very deterministic.  We have this already working.

  If those two keys are NOT sufficient, then I again question how RADIUS
is being used to control sessions it knows nothing about.

[Avi] Can you please show me in the examples I gave you where RADIUS is
asked to control session it is not aware of?

>  Furthermore, I think they should be used in combination.  For 
> example, User-Name + Accounting Session Id to delete the session 
> associated with Accounting session id is better practice then just 
> using Accounting Session Id.

  And for sessions that don't have User-Name, which attribute do you
choose, and why?  That's why I suggest using a new key.  It avoids all
of the problems with guessing which attribute will be accepted by the
NAS as a session key.

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