rfc3576.txt

radius协议的经典实现

2.2.  Change-of-Authorization Messages (CoA)

   CoA-Request packets contain information for dynamically changing
   session authorizations.  This is typically used to change data
   filters.  The data filters can be of either the ingress or egress
   kind, and are sent in addition to the identification attributes as
   described in section 3.  The port used, and packet format (described
   in Section 2.3.), are the same as that for Disconnect-Request
   Messages.

   The following attribute MAY be sent in a CoA-Request:

   Filter-ID (11) - Indicates the name of a data filter list to be
                    applied for the session that the identification
                    attributes map to.

   +----------+      CoA-Request         +----------+
   |          |  <--------------------   |          |
   |   NAS    |                          |  RADIUS  |
   |          |     CoA-Response         |  Server  |
   |          |   ---------------------> |          |
   +----------+                          +----------+

   The NAS responds to a CoA-Request sent by a RADIUS server with a
   CoA-ACK if the NAS is able to successfully change the authorizations
   for the user session, or a CoA-NAK if the Request is unsuccessful.  A
   NAS MUST respond to a CoA-Request including a Service-Type Attribute



Chiba, et al.                Informational                      [Page 6]

RFC 3576       Dynamic Authorization Extensions to RADIUS      July 2003


   with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST NOT be
   sent.  A NAS MUST respond to a CoA-Request including a Service-Type
   Attribute with an unsupported value with a CoA-NAK; an Error-Cause
   Attribute with value "Unsupported Service" MAY be included.

2.3.  Packet Format

   For either Disconnect-Request or CoA-Request messages UDP port 3799
   is used as the destination port.  For responses, the source and
   destination ports are reversed.  Exactly one RADIUS packet is
   encapsulated in the UDP Data field.

   A summary of the data format is shown below.  The fields are
   transmitted from left to right.

   The packet format consists of the fields: Code, Identifier, Length,
   Authenticator, and Attributes in Type:Length:Value (TLV) format.  All
   fields hold the same meaning as those described in RADIUS [RFC2865].
   The Authenticator field MUST be calculated in the same way as is
   specified for an Accounting-Request in [RFC2866].

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                         Authenticator                         |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attributes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

   Code

      The Code field is one octet, and identifies the type of RADIUS
      packet.  Packets received with an invalid Code field MUST be
      silently discarded.  RADIUS codes (decimal) for this extension are
      assigned as follows:

      40 - Disconnect-Request [RFC2882]
      41 - Disconnect-ACK [RFC2882]
      42 - Disconnect-NAK [RFC2882]
      43 - CoA-Request [RFC2882]
      44 - CoA-ACK [RFC2882]
      45 - CoA-NAK [RFC2882]




Chiba, et al.                Informational                      [Page 7]

RFC 3576       Dynamic Authorization Extensions to RADIUS      July 2003


   Identifier

      The Identifier field is one octet, and aids in matching requests
      and replies.  The RADIUS client can detect a duplicate request if
      it has the same server source IP address and source UDP port and
      Identifier within a short span of time.

      Unlike RADIUS as defined in [RFC2865], the responsibility for
      retransmission of Disconnect-Request and CoA-Request messages lies
      with the RADIUS server.  If after sending these messages, the
      RADIUS server does not receive a response, it will retransmit.

      The Identifier field MUST be changed whenever the content of the
      Attributes field changes, or whenever a valid reply has been
      received for a previous request.  For retransmissions where the
      contents are identical, the Identifier MUST remain unchanged.

      If the RADIUS server is retransmitting a Disconnect-Request or
      CoA-Request to the same client as before, and the Attributes have
      not changed, the same Request Authenticator, Identifier and source
      port MUST be used.  If any Attributes have changed, a new
      Authenticator and Identifier MUST be used.

      Note that if the Event-Timestamp Attribute is included, it will be
      updated when the packet is retransmitted, changing the content of
      the Attributes field and requiring a new Identifier and Request
      Authenticator.

      If the Request to a primary proxy fails, a secondary proxy must be
      queried, if available.  Issues relating to failover algorithms are
      described in [AAATransport].  Since this represents a new request,
      a new Request Authenticator and Identifier MUST be used.  However,
      where the RADIUS server is sending directly to the client,
      failover typically does not make sense, since Disconnect or CoA
      messages need to be delivered to the NAS where the session
      resides.

   Length

      The Length field is two octets.  It indicates the length of the
      packet including the Code, Identifier, Length, Authenticator and
      Attribute fields.  Octets outside the range of the Length field
      MUST be treated as padding and ignored on reception.  If the
      packet is shorter than the Length field indicates, it MUST be
      silently discarded.  The minimum length is 20 and the maximum
      length is 4096.





Chiba, et al.                Informational                      [Page 8]

RFC 3576       Dynamic Authorization Extensions to RADIUS      July 2003


   Authenticator

      The Authenticator field is sixteen (16) octets.  The most
      significant octet is transmitted first.  This value is used to
      authenticate the messages between the RADIUS server and client.

   Request Authenticator

      In Request packets, the Authenticator value is a 16 octet MD5
      [RFC1321] checksum, called the Request Authenticator.  The Request
      Authenticator is calculated the same way as for an Accounting-
      Request, specified in [RFC2866].

      Note that the Request Authenticator of a Disconnect or CoA-Request
      cannot be done the same way as the Request Authenticator of a
      RADIUS Access-Request, because there is no User-Password Attribute
      in a Disconnect-Request or CoA-Request.

   Response Authenticator

      The Authenticator field in a Response packet (e.g. Disconnect-ACK,
      Disconnect-NAK, CoA-ACK, or CoA-NAK) is called the Response
      Authenticator, and contains a one-way MD5 hash calculated over a
      stream of octets consisting of the Code, Identifier, Length, the
      Request Authenticator field from the packet being replied to, and
      the response Attributes if any, followed by the shared secret.
      The resulting 16 octet MD5 hash value is stored in the
      Authenticator field of the Response packet.

   Administrative note: As noted in [RFC2865] Section 3, the secret
   (password shared between the client and the RADIUS server) SHOULD be
   at least as large and unguessable as a well-chosen password.  RADIUS
   clients MUST use the source IP address of the RADIUS UDP packet to
   decide which shared secret to use, so that requests can be proxied.

   Attributes

      In Disconnect and CoA-Request messages, all Attributes are treated
      as mandatory.  A NAS MUST respond to a CoA-Request containing one
      or more unsupported Attributes or Attribute values with a CoA-NAK;
      a Disconnect-Request containing one or more unsupported Attributes
      or Attribute values MUST be answered with a Disconnect-NAK.  State
      changes resulting from a CoA-Request MUST be atomic: if the
      Request is successful, a CoA-ACK is sent, and all requested
      authorization changes MUST be made.  If the CoA-Request is
      unsuccessful, a CoA-NAK MUST be sent, and the requested





Chiba, et al.                Informational                      [Page 9]

RFC 3576       Dynamic Authorization Extensions to RADIUS      July 2003


      authorization changes MUST NOT be made.  Similarly, a state change
      MUST NOT occur as a result of an unsuccessful Disconnect-Request;
      here a Disconnect-NAK MUST be sent.

      Since within this specification attributes may be used for
      identification, authorization or other purposes, even if a NAS
      implements an attribute for use with RADIUS authentication and
      accounting, it may not support inclusion of that attribute within
      Disconnect-Request or CoA-Request messages, given the difference
      in attribute semantics.  This is true even for attributes
      specified within [RFC2865], [RFC2868], [RFC2869] or [RFC3162] as
      allowable within Access-Accept messages.

      As a result, attributes beyond those specified in Section 3.2.
      SHOULD NOT be included within Disconnect or CoA messages since
      this could produce unpredictable results.

      When using a forwarding proxy, the proxy must be able to alter the
      packet as it passes through in each direction.  When the proxy
      forwards a Disconnect or CoA-Request, it MAY add a Proxy-State
      Attribute, and when the proxy forwards a response, it MUST remove
      its Proxy-State Attribute if it added one.  Proxy-State is always
      added or removed after any other Proxy-States, but no other
      assumptions regarding its location within the list of Attributes
      can be made.  Since Disconnect and CoA responses are authenticated
      on the entire packet contents, the stripping of the Proxy-State
      Attribute invalidates the integrity check - so the proxy needs to
      recompute it.  A forwarding proxy MUST NOT modify existing Proxy-
      State, State, or Class Attributes present in the packet.

      If there are any Proxy-State Attributes in a Disconnect-Request or
      CoA-Request received from the server, the forwarding proxy MUST
      include those Proxy-State Attributes in its response to the
      server.  The forwarding proxy MAY include the Proxy-State
      Attributes in the Disconnect-Request or CoA-Request when it
      forwards the request, or it MAY omit them in the forwarded
      request.  If the forwarding proxy omits the Proxy-State Attributes
      in the request, it MUST attach them to the response before sending
      it to the server.












Chiba, et al.                Informational                     [Page 10]

RFC 3576       Dynamic Authorization Extensions to RADIUS      July 2003


3.  Attributes

   In Disconnect-Request and CoA-Request packets, certain attributes are
   used to uniquely identify the NAS as well as a user session on the
   NAS.  All NAS identification attributes included in a Request message
   MUST match in order for a Disconnect-Request or CoA-Request to be
   successful; otherwise a Disconnect-NAK or CoA-NAK SHOULD be sent.
   For session identification attributes, the User-Name and Acct-
   Session-Id Attributes, if included, MUST match in order for a
   Disconnect-Request or CoA-Request to be successful; other session
   identification attributes SHOULD match.  Where a mismatch of session
   identification attributes is detected, a Disconnect-NAK or CoA-NAK
   SHOULD  be sent.  The ability to use NAS or session identification
   attributes to map to unique/multiple sessions is beyond the scope of
   this document.  Identification attributes include NAS and session
   identification attributes, as described below.

   NAS identification attributes

   Attribute             #    Reference  Description
   ---------            ---   ---------  -----------
   NAS-IP-Address        4    [RFC2865]  The IPv4 address of the NAS.
   NAS-Identifier       32    [RFC2865]  String identifying the NAS.
   NAS-IPv6-Address     95    [RFC3162]  The IPv6 address of the NAS.