[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Question on draft-ietf-radext-management-authorization-04.txt
> For example suppose there are three sessions with a User-Name of "dave", one
> with a Service-Type of "NAS-Prompt", and two with a Service-Type of
> "Framed-Management". Of the latter two, one has a
> Framed-Management-Protocol of "Web-based" and the other has a
> Framed-Management-Protocol of "SNMP". If you want to affect the web
> session, you need to "address" the session either by an available session ID
> attribute, which is preferable in my opinion, or by the value of
> Framed-Management-Protocol, if the session ID information is not available.
Typically, the way that this kind of problem is solved is via addition of
session identification attributes, such as the Acct-Session-Id, NAS-Port
or NAS-Port-Id. Is a NAS-Port/NAS-Port-Id Attribute likely to be
available in the case of a management session (local or remote)? This is
not clear to me. If an Acct-Session-Id exists, this is probably the
cleanest way to solve the problem.
> > In this case, if it is desired to identify a single session,
> > session identification MAY be performed by using one or more of the
> > Framed-IP-Address, Framed-IPv6-Prefix/Framed-Interface-Id, Called-
> > Station-Id, Calling-Station-Id, NAS-Port, and NAS-Port-Id attributes.
> It is in the sprit of this last paragraph that I proposed that some of the
> management provisioning attributes, specifically Framed-Management-Protocol
> and Management-Transport-Protection *could* be used to further identify one
> session from another. Unfortunately, that usage also allows any of these
> "provisioning" attributes to be use alone (or in combination with others) to
> form all sorts of interesting (maybe not useful) wild-card matches.
Another way to solve the problem is to specify that one or more of the
above session identification attributes SHOULD be present in a management
Access-Request. That way those attributes are likely to be available for
session identification in the event that dynamic authorization is needed.
> We can eliminate Framed-Management-Protocol and
> Management-Transport-Protection from such usage in this document. We can't
> go back and clarify the "murkiness" that exists in RFC 5176 about using this
> sort of wild-card matching when selecting one or more sessions for action.
I think it might be worthwhile to add a section on dynamic authorization,
clarifying what session identification attributes SHOULD be included in an
Access-Request. Assuming we do this, then the remaining use of
Framed-Management-Protocol and Management-Transport-Protection in a
CoA-Request would be as a wildcard. As you say, this kind of use will
probably not be mainstream - which raises the question of whether putting
it in is worth the interoperability issues it might end up raising.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.