RE: Issue 224: RFC 3576bis and Renumbering

Hi Bernard,

This issue is raising a couple of other issues. This email addresses the following:

-Why I dont think it is a good idea to remove Framed-Ip from session idenftication.

-Need to have a method for avoiding bising 3576 when new attributes are added.

-Need to add CUI from 4372 to 3576bis as a session identifier.

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.

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.

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

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

Also Framed-IP is used to identify an IP-Session of the a user. A user can have several IP sessions: serveal 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 acheive that.

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.

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.

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.

Delegated Prefix should have done that.

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.

Issue 224: RFC 3576bis and Renumbering
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: March 19, 2007
Reference:
Document: RFC 3576bis-00
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

During the 16ng meeting, the need for renumbering support in 3576bis was
discussed. This would involve changing the Framed-IPv6-Prefix and
Delegated-IPv6-Prefix attributes in a CoA-Request, so that the new prefixes
could be advertised. In reviewing RFC 3576, it appears that
Framed-IPv6-Prefix is used as an identifying attribute and therefore it
cannot be changed in a CoA-Request (although it would be possible to use
Service-Type="Authorize Only" to change it). The same thing is true of
Framed-IP-Address and Framed-Interface-Id, although these attributes are
typically used with PPP, so they would only be effective if the user was
able to renegotiate NCP in mid-session, which most implementations don't
support.

In rereading RFC 3576, it also seems to imply that only the attributes
listed in the table can be included in a CoA-Request, which would limit the
ability to include a Delegated-IPv6-Prefix attribute. However, the point is
really that a NAS might not support an attribute that is being changed (new
or old), so that the text should make that point instead.

Assuming that existing implementations aren't using the Framed-IP-Address,
Framed-IPv6-Prefix and Framed-Interface-Id attributes for session
identification, my recommendation is that we consider removing them from the
list of session identification attributes. Attributes such as
Acct-Session-Id, User-Name, NAS-Port, etc. remain and should be adequate for
session identification.

We also should add the VLAN attributes defined in RFC 4675 to the list of
attributes.

The required changes are as follows:

Change:

"This is true even for attributes
specified within [RFC2865], [RFC2868], [RFC2869],
[RFC3162] or [RFC3579] as allowable within Access-Accept packets.
As a result, if attributes beyond those specified in Section 3.5

To:

"This is true even for attributes specified as allowable within
Access-Accept packets (such as within
[RFC2865],[RFC2868],[RFC2869],[RFC3162],[RFC3579],[RFC4675],
[RFCFilter][RFCDelegated]). As a result, if unsupported attributes"

Remove Framed-IP-Address, Framed-Interface-Id and Framed-IPv6-Prefix from
the list of session identification attributes.

In the Attribute Table, change Framed-IP-Address, Framed-Interface-Id and
Framed-IPv6-Prefix from [Note 1] (Session Identification Attributes) to
[Note 3] authorization attributes changeable in a CoA-Request. Remove them
from the attributes includable in a Disconnect-Request. Add
Delegated-IPv6-Prefix as changeable in a CoA-Request (0+) [Note 3]. Add
Egress-VLANID, Ingress-Filters, Egress-VLAN-Name, User-Priority-Table
Attributes as changeable in the CoA-Request.

Add references to RFC 4675 and the Delegated-IPv6-Prefix documents.

Add the following statements to Appendix A:

Updated CoA-Request Attribute Table to include Filter-Rule,
Delegated-IPv6-Prefix, Egress-VLANID, Ingress-Filters, Egress-VLAN-Name,
User-Priority-Table Attributes.

Clarified use of Framed-IPv6-Prefix, Framed-IP-Address,
Delegated-IPv6-Prefix in renumbering.

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