The ability to use NAS or session identification
attributes to map to unique/multiple sessions is beyond the scope of
this document.
Therefore it isn't clear that sending a Disconnect-Request with a User-Name/CUI attribute
will necessarily terminate *all* the user's sessions if there are more than one.
Do we need to say something like "all sessions matching the NAS & session
identification attributes are affected by CoA/Disconnect-Requests?"
[Avi2] Yes. I think that this is the best apporoach. Perhaps an example or two would make it clear. If the NAS receives a session ID that identifies the User Session only such as NAI, and if the user had multiple sessions such as IP sessions, then ALL the sessions associated with that user are affected.
[BA] Also, unless the NAS
previously received Framed-IP-Address or
Framed-IPv6-Prefix/Framed-Interface-Id attributes in an Access-Accept it
typically will not know the user's IP address. This is the situation
with most NAS-Port-Type values, with the exception of PPP or protocols
depending on PPP (e.g. PPPOE, PPPOA, L2TP, PPTP, etc.)
[Avi] In most cases that I am aware of,
the NAS is the Point of Attachement to the internet and it knows the IP
address(es) assigned to the user. So it is IP Session aware. In any
case, there are scenarios where it is IP session aware and it should be
possible to make modification to those Sessions using DM or COA using the IP
address as the Session Identifier.
[BA] Where the NAS is a pure L2
device (e.g. IEEE 802 switch, 802.11 AP), it has no awareness of L3, and
so does not track the IP addresses of clients.
[Avi2] Then receiving an IP address makes
no sense to the NAS either as a session identifier or as a new IP
address.
Where the NAS does track the IP
address of clients, it would be possible to use IP address attributes for
*either* identification *or* change, but not both in the same
packet.
[Avi2] Just for the record. I am not
aware of any application where we want to change the IP address using
RADIUS. Infact, in most cases we never want to change the IP address
since that breaks IP Session Continuity. Why would anyone want to change
the IP address? But lets say that we do want to support such a feature.
Who knows what the future will bring.
So the choices
are:
1. Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier
attributes in Disconnect-Request & CoA-Request packets, only for
identification. Changing the address would require a
Service-Type=Authorize Only. This was what we had in -05.
[Avi2] This is inefficient. If you were to
have a reason to change an IP address mid session that you should be able to
do so with either approach. As I said above, I cant think of any
reason to change an IP address. So I could live with
this.
2. Allow
Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier attributes in
Disconnect-Requests for identification. In CoA-Request packets allow
them only for address change.
[Avi2]
No. This is inconsistant. And it does not allow me to
changes something relating to a specific IP
Session.
3. Allow Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier address attributes in Disconnect-Request &
CoA-Request packets only for address change. Invent new attributes for
identification. This was previously proposed for -07.
[Avi2] No. See
4.
4. Allow
Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier address attributes in Disconnect-Request &
CoA-Request packets only for identification. Invent new attributes for
address change.
[Avi2] Yes. I think this option is
the most appealing to me.
5. Prohibit use of Framed-IP-Address/Framed-IPv6-Prefix/Framed-Identifier attributes for session identification.
Permit their use only in CoA-Request packets, for use in address change.
This is what we have in -07.
[Avi2]
No. Because of what I stated earlier. It is uncommon
to change the IP address. It is most common to change some aspect
of an IP session.
I think this more or less describes
the choices available on this issue. Are there any more?
[Avi2] I think 4 is the right choice.
And we can use that model for any other session identifier that can
also be changed dynamically.
[Avi] Yes I agree that
it "can" be used. But Alan seems to make it mandatory. And to
mandatory require that it be sent
in the Access-Request packet. I dont agree with
that. I think if the deployement requires it to be in the access
request then it can be sent. The current RFCs are fine.
[BA]
I don't think we can make it mandatory to include
Acct-Session-Id/Acct-Multi-Session-Id. But I would like to be clear
about what other attributes MAY/SHOULD be included, and what happens when they
are included (e.g. how the NAS selects the affected sessions).
[Avi2] VSA must be allowed for session
identification. See below.
[Avi2] The problem is that there is no
definition for what a session is. Therefore we cant be specific in the
definition here. In general a NAS will maintain one or more Sessions for
a given user. These sessions are going to be related to each other
like a tree. The top most session is the user session - the
authenticated session. That session will have subsessions, and thus
subsession may have further subsessions. The NAS will use the
information received to identify one of those sessions. Then that session and
its subsession will be affected.
[BA] RFC 3576 Section 3 (or RFC 3576bis)
does not include VSAs for the purpose of session identification.
However, RFC 3576bis Section 2.3 does say this:
Within this specification attributes can be used for
identification, authorization or other purposes. RADIUS Attribute
specifications created after publication of this document SHOULD
state whether an attribute can be included in CoA or Disconnect
messages and if so, which messages it can be included in and
whether it serves as an identification or authorization attribute.
I don't intrinsically see anything wrong with using VSAs for session identification,
assuming that they are not required, and that sending them to a NAS which doesn't
support them generate an appropriate error message (e.g. 401 (Unsupported Attribute)).
So maybe we should add VSAs to the Session Identification list, as well as a paragraph
stating that their use is optional.
[Avi2] Yes I agree. I think we better be explicit about VSAs.