RE: Issue 224: RFC 3576bis and Renumbering

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

Hi Bernard, 

See inline please....

-----Original Message-----
From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] 
Sent: Sunday, March 25, 2007 12:53 PM
To: Avi Lior; radiusext@ops.ietf.org
Subject: RE: Issue 224: RFC 3576bis and Renumbering

>First in response to Framed-IP, Framed-IPv6 etc
>
>Framed-IP-Address and the other attributes are very valid session 
>identifier and I dont think we should >remove from them session 
>identification.

Are you actually using Framed-IP-Address and/or
Framed-IPv6-Prefix/Framed-Interface-Id this way?

[Avi] Does it matter if I use it this way.  Are we designing for what we
are doing today or the future?  If we take this away what could I use in
the futre if I want to do this? 
So now the pragmatic answer.  In WiMAX and other technologies we have
the concept of a Network Access Session and IP Session.  RADIUS performs
Network Access Authentication (802.16e) and then one or more IP Sessions
can be established (typically using MIP/RADIUS interactions).  

>The other attributes used for session identification are not as good.  
>For example, if identity hiding is >used User-Name is not useable as a 
>session identifier.

Right.  There could be 10 "anonymous" users on the same NAS.

[Avi] Or more likely like 000s of anonymous users on the same NAS

>Accounting-Session ID is also poor because accounting session ids can 
>change without >reauthentication.

Can you explain this more?
[Avi] A change in QoS for example can trigger a stop and a start.  The
Acct-Session-ID will change.  The change in QoS can come from anywhere.
To correlate to the session we use Acct-MultiSession-Id or Framed-IP
address, or even Class, etc....


>NAS-Port ???  I am not sure if that is used.

It seems harmless though, since this is not an attribute that could be
changed in a CoA-Request.

[Avi]I agree.

>Also Framed-IP is used to identify an IP-Session of the a user.  A user

>can have several IP sessions: >serveral IPv4 sessions and IPv6 sessions

>all associated with the same authentication.  We may want to 
>>specifically target the COA to an IP session and thus we need the IP 
>address attributes to achieve >that.

OK.

>Therefore,  I think there needs to be a scheme where we can use an 
>attribute both for session >identification and also to change the value

>of that attribute.  I can propose two approaches:
>
>-Where we have a session identification attribute, if we want to modify

>that session identification >attribute then we can send two values: the

>first value identifies the session and the next value will >change the 
>value.
>
>-A more explicit method is to introduce new attributes such as 
>New-Framed-IP-Address.

This seems like the kind of problem that Service-Type="Authorize-Only"
is helpful in solving.  Just identify the session (you can use
Framed-IPv6-Prefix/Framed-Interface-Id) and then send a new
Framed-IPv6-Prefix attribute in response to the Access-Request.

[Avi] Sure but that is very in efficient right?  We have a push model
lets not cripple it.  Before we thought that the these valid session
identifiers were immutable now we are seeing that that is not the case
(at least for some of them and in the future others will come up).  Lets
fix this correctly so we don't have to do this again. For now I favour
not reallying on the inefficient semantics of COA with Authorize-Only.
And I prefer the explicit use of attributes.  So for renumbering lets
create a new attribute(s) for them.  Others can be introduced in the
future.  We can add text to provide such guidance in 3576bis.


>The second point I want to make speaks to your statement that states 
>that only attributes that appear >in the table can appear in a COA
message.
>This is not good because as we see, everytime someone >creates a new 
>attribute then we would have to bis 3576 again.  Which is bad.

Right.

>Perhaps we can put some text that says that future attributes may be 
>allowed  in COA messages.  And >it would be up to those specific RFCs 
>to spec. that their attributes can go into the COA message.

Yes, we should say that.

>Delegated Prefix should have done that.

It did, actually.  The document states that it is legal for inclusion in
a CoA-Request.

>My final point, as you are adding Delegated Prefix to 3576.  We should 
>also add CUI to 3576.  It can >be an excellent user identification 
>attribute especially when User-Name does not work.

Thanks.  I had forgotten about that.
\



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