[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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?
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.
Accounting-Session ID is also poor because accounting session ids can
change without >reauthentication.
Can you explain this more?
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.
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.
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/>