[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Additional comments on draft-ietf-radext-management-authorization-03.txt



More follow up:

I could also envision permitting Framed-Management-Protocol and
Management-Transport-Protection as session identification attributes is a
CoA-Request, similar to their usage in a Disconnect-Request message.

> Add the following text to Section 12 (as currently numbered):
> 
> Change-of-Authorization Messages
> 
>    Request   ACK   NAK    #     Attribute
> 
>       0       0     0   TBA-2   Framed-Management-Protocol
>       0       0     0   TBA-3   Management-Transport-Protection
>       0-1     0     0   TBA-4   Management-Policy-Id (Note 2)
>       0-1     0     0   TBA-5   Management-Privilege-Level (Note 2)

    Request   ACK   NAK    #     Attribute
 
       0-1     0     0   TBA-2   Framed-Management-Protocol (Note 1)
       0-1     0     0   TBA-3   Management-Transport-Protection (Note 1)
       0-1     0     0   TBA-4   Management-Policy-Id (Note 2)
       0-1     0     0   TBA-5   Management-Privilege-Level (Note 2)

I don't think it makes any sense to allow re-provisioning of the session
transport parameters, as that would almost certainly require a disconnect
and re-establishment of the session.

> Disconnect Messages
> 
>    Request   ACK   NAK   #   Attribute
> 
>       0-1     0     0   TBA-2   Framed-Management-Protocol (Note 1)
>       0-1     0     0   TBA-3   Management-Transport-Protection (Note 1)
>       0       0     0   TBA-4   Management-Policy-Id
>       0       0     0   TBA-5   Management-Privilege-Level
> 
> 
> 
> (Note 1) Where NAS or session identification attributes are included
>    in Disconnect-Request or CoA-Request packets, they are used for
>    identification purposes only.  These attributes MUST NOT be used for
>    purposes other than identification (e.g., within CoA-Request packets
>    to request authorization changes).
> 
> (Note 2) When included within a CoA-Request, these attributes
>    represent an authorization change request.  When one of these
>    attributes is omitted from a CoA-Request, the NAS assumes that the
>    attribute value is to remain unchanged.  Attributes included in a
>    CoA-Request replace all existing values of the same attribute(s).

Similar logic applies to the Disconnect-Request case.  Those attributes
which might aid in distinguishing one of a user's concurrent sessions from
among others may be useful.  The primary indicator here is likely to be the
Service-Type, but that is already permitted by RFC 5176.  We only need to
discuss the newly introduced attributes, in this document.

I'm planning to crate a -04 version of the draft today, to submit prior to
the upcoming "blackout" period on ID submissions.  Now would be a good time
to submit comments on this issue (or any other open issue against -03).  :-)



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