[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue 226: RFC 3576bis and Renumbering
Bernard Aboba writes...
> Session identification attributes
> Chargeable-User- 89 [RFC4372] The CUI associated with the
> Identity session. Needed where a
> privacy NAI is used, so that
> the User-Name may not be
> unique (e.g. "anonymous").
s/so that the User-Name may not be/because the User-Name may not be/
> Where the Acct-Session-Id attribute is not present in a CoA-Request
> or Disconnect-Request, it is possible that the User-Name or
> Chargeable-User-Identity attributes will not be sufficient to
> uniquely identify the session (e.g. if the same user has multiple
> sessions on the NAS). As a result, the Called-Station-Id, Calling-
> Station-Id, NAS-Port, NAS-Port-Id and Acct-Multi-Session-Id
> attributes MAY be used for session identification in addition.
s/MAY be used for session identification in addition./MAY be used as
additional session identification./
> [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] The Reply-Message Attribute is used to present a displayable
> message to the user. The message is only displayed as a result of a
> successful Disconnect-Request or CoA-Request (where a Disconnect-ACK
> or CoA-ACK is subsequently sent). Where EAP is used for
> authentication, an EAP-Message/Notification-Request Attribute is sent
> instead, and Disconnect-ACK or CoA-ACK packets contain an EAP-
> Message/Notification-Response Attribute.
>
> [Note 3] 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 value(s) of the same attribute(s).
>
> [Note 4] When included within a successful Disconnect-Request (where
> a Disconnect-ACK is subsequently sent), the Class Attribute SHOULD be
> sent unmodified by the client to the accounting server in the
> Accounting Stop packet. If the Disconnect-Request is unsuccessful,
> then the Class Attribute is not processed.
>
> [Note 5] When included within a CoA-Request, these attributes
> represent an authorization change request. Where tunnel attribute(s)
> are included within a successful CoA-Request, all existing tunnel
> attributes are removed and replaced by the new attribute(s).
>
> [Note 6] Support for the Service-Type of "Authorize Only" is OPTIONAL
> on the NAS and RADIUS server. A NAS supporting the "Authorize Only"
> Service-Type value within a CoA-Request packet MUST respond with a
> CoA-NAK containing a Service-Type Attribute with value "Authorize
> Only", and an Error-Cause Attribute with value "Request Initiated".
> The NAS then sends an Access-Request to the RADIUS server with a
> Service-Type Attribute with value "Authorize Only". This Access-
> Request SHOULD contain the NAS attributes from the CoA-Request, as
> well as the session attributes from the CoA-Request legal for
> inclusion in an Access-Request as specified in [RFC2865], [RFC2868],
>
> [RFC2869] and [RFC3162]. As noted in [RFC2869] Section 5.19, a
> Message-Authenticator attribute SHOULD be included in an Access-
> Request that does not contain a User-Password, CHAP-Password, ARAP-
> Password or EAP-Message Attribute. The RADIUS server should send
> back an Access-Accept to (re-)authorize the session or an Access-
> Reject to refuse to (re-)authorize it.
>
> A NAS that does not support the Service-Type Attribute with the value
> "Authorize Only" within a CoA-Request MUST respond with a CoA-NAK
> including no Service-Type Attribute; an Error-Cause Attribute with
> value "Unsupported Service" MAY be included.
>
> [Note 7] The State Attribute is available to be sent by the RADIUS
> server to the NAS in a CoA-Request packet and MUST be sent unmodified
> from the NAS to the RADIUS server in a subsequent ACK or NAK packet.
> If a Service-Type Attribute with value "Authorize Only" is included
> in a CoA-Request then a State Attribute MUST be present, and MUST be
> sent unmodified from the NAS to the RADIUS server in the resulting
> Access-Request sent to the RADIUS server, if any. The State
> Attribute is also available to be sent by the RADIUS server to the
> NAS in a CoA-Request that also includes a Termination-Action
> Attribute with the value of RADIUS-Request. If the client performs
> the Termination-Action by sending a new Access-Request upon
> termination of the current session, it MUST include the State
> Attribute unchanged in that Access-Request. In either usage, the
> client MUST NOT interpret the Attribute locally. A CoA-Request
> packet must have only zero or one State Attribute. Usage of the
> State Attribute is implementation dependent.
>
> [Note 8] Where included within a CoA-Request, these attributes
> represent a renumbering request. Since these attributes are not used
> for session identification, they MUST NOT be included within a
> Disconnect-Request. Note that renumbering may not be possible in all
> situations. For example, in order to change an IP address on receipt
> of a changed Framed-IP-Address address, IPCP re-negotiation could be
> required, which is not supported by all PPP implementations.
It strikes me that the large number and substantial nature of these notes
suggests that they be incorporated elsewhere in the normative text of the
document, rather as footnotes to the Table of Attributes. I think it would
substantially enhance readability of the document.
--
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/>