RE: Draft-chiba-11 comments.

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

I agree with your comments about restricting the use of any attribute that
can be used to identify a session.  I also agree about 2866 (actually I
shouldn't have included them because these don't appear in Access Accept)

We basically have a philosophical difference on how to determine what is
allowed for change of authorization.  Which is fine so I will adopt your
philosophy but I don't have the knowledge or the time to argue for
attributes.  So I have listed the ones that I think should be allowed for
change of authorization and noted the ones that I don't know about.

The following are all candidates (NOTE: there maybe others that I missed).

>    Request   Accept   Reject   Challenge   #    Attribute
>    0-1       0-1      0        0            6   Service-Type

Used to identify a service for which the COA applies.  It deosnt change the
service-type but it MAY be used to categories CoA.

>    0         0+       0        0           11   Filter-Id
Yes
>    0         0+       0+       0+          18   Reply-Message
Yes
>    0         0+       0        0           22   Framed-Route
It should be possible to change routing on the client. Not 100% sure about.

>    0         0-1      0        0           23   Framed-IPX-Network
Not sure about this.

>    0-1       0-1      0        0-1         24   State
Yes, especially if need to change Terminate-Action

>    0         0+       0        0           25   Class
Class attribute is used as a cookie by some implemenation.  Changing the
Class attribute mid-session should be possible.

>    0+        0+       0        0+          26   Vendor-Specific
Yes
>    0         0-1      0        0-1         27   Session-Timeout
Yes
>    0         0-1      0        0-1         28   Idle-Timeout
Yes
>    0         0-1      0        0           29   Termination-Action
Yes
>    0+        0+       0+       0+          33   Proxy-State
Yes
>    0-1       0-1      0        0           62   Port-Limit
Yes

Regarding Tunnels -- not a tunnel expert but should it be possible to change
a tunnel mid session?
>    0+        0+       0        0           64   Tunnel-Type
>    0+        0+       0        0           65   Tunnel-Medium-Type
>    0+        0+       0        0           66   Tunnel-Client-Endpoint
>    0+        0+       0        0           67   Tunnel-Server-Endpoint
>    0         0+       0        0           69   Tunnel-Password
>    0+        0+       0        0           81   Tunnel-Private-Group-ID
>    0         0+       0        0           82   Tunnel-Assignment-ID
>    0+        0+       0        0           83   Tunnel-Preference
>    0+        0+       0        0           90   Tunnel-Client-Auth-ID
>    0+        0+       0        0           91   Tunnel-Server-Auth-ID

Don't know about the following either:
>    0         0-1      0        0-1         71   ARAP-Features
>    0         0-1      0        0           72   ARAP-Zone-Access
>    0         0+       0        0           78   Configuration-Token
>    0         0-1      0        0-1         84   ARAP-Challenge-Response


>    0+        0+       0+       0+          79   EAP-Message [Note 1]
>    0-1       0-1      0-1      0-1         80   Message-Authenticator
You have them as note 2.

>    0         0-1      0        0           85   Acct-Interim-Interval
Yes. 

Don't know about these:
>    0         0-1      0        0           88   Framed-Pool
>    0         0+       0        0           99   Framed-IPv6-Route
>    0         0-1      0        0          100   Framed-IPv6-Pool





> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com] 
> Sent: Monday, April 07, 2003 3:55 PM
> To: Avi Lior
> Cc: 'mchiba@cisco.com'; 'gdommety@cisco.com'; 
> 'meklund@cisco.com'; 'david@mitton.com'; 'iesg@ietf.org'
> Subject: Re: Draft-chiba-11 comments.
> 
> 
> > I have some concern.  There are some attributes in the 
> attribute table 
> > that are not listed, eg. Framed-IP-route, Class etc are 
> they allowed 
> > in CoA?
> 
> RADIUS attributes included in CoA or Disconnect messages do 
> not have the same semantic meaning as they do in RFC 
> 2865-2869, and RFC 3162. For example, in RFC 2865, 
> Framed-IP-Address means "assign this IP address". However, in 
> draft-chiba it means "apply the command to the session 
> matching this IP address". This semantic confusion means that 
> unless the meaning of an attribute is explicitly defined in 
> the draft, then it SHOULD NOT be used, because it isn't clear 
> what should be done with it.
> 
> > We think that all attributes (in 2865, 2866, 2869 etc.) that are 
> > allowed in an Access Accept message must be listed in the 
> table with 
> > explicit role in the CoA.
> 
> Since these aren't accounting messages, I'm not clear why 
> accounting attributes are relevant, with the exception of the 
> ones listed in the draft.
> 
> For the other attributes, we'd need an explanation of what 
> they do to consider including them. Merely citing RFC 2865 
> isn't enough because in this protocol attributes could be 
> used for identification instead of their normal meaning.
> 
> > Further, we think that unless there is a good reason to disallow 
> > certain attributes that they will be allowed for CoA.  If 
> they are not 
> > allowed, a reason must be given as to why in a Note.  We can then 
> > argue as to whether the reason to exclude makes sense -- 
> and document 
> > the reason to avoid further discussion.
> 
> Given the semantic confusion, I'd probably lean the other 
> way. Unless we know what an attribute will do, there's no 
> point in saying that it's ok to include it. Something as 
> simple as Tunnel Group ID could be confusing -- is this used 
> for identification or is the Tunnel ID supposed to be changed 
> to the new value?
> 
>