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?"
[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.
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.
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.
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.
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.
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.
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.
I think this more or less describes the choices available on this issue. Are there any more?
[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).
Where only an Access-Request is
available, with no Acct-Session-Id, other session identification attributes can
be used (NAS-Port/NAS-Port-Id, User-Name).
[Avi] Yes I agree and even
VSAs.
[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.
[BA] So
it's hard to imagine a case where the IP address is *required* as a session
identifier. And there are quite a few situations in which the NAS
will be unable to identify the session by IP address. Given this,
encouraging the use of the IP address as a session identifier seems like a bad
idea.
[Avi] I agree that the IP Address is
not *required*. I think that nothing should
be *required* because different scenarios will use different
session identifiers. Furthermore, I think they should be used in
combination. For example, User-Name + Accounting Session Id to delete
the session associated with Accounting session id is better practice then just
using Accounting Session Id.
[BA] RFC 3576 allows this, and RFC 3576bis does too.