rfc5080.txt

使用最广泛的radius的linux的源码

   These methods will allow some users to gain access to the network,
   reducing the load created by ongoing access attempts.

2.3.  Accounting Issues

2.3.1.  Attributes Allowed in an Interim Update

   [RFC2866] indicates that Acct-Input-Octets, Acct-Output-Octets,
   Acct-Session-Time, Acct-Input-Packets, Acct-Output-Packets and Acct-
   Terminate-Cause attributes "can only be present in Accounting-Request
   records where the Acct-Status-Type is set to Stop".

   However [RFC2869] Section 2.1 states:

      It is envisioned that an Interim Accounting record (with Acct-
      Status-Type = Interim-Update (3)) would contain all of the
      attributes normally found in an Accounting Stop message with the
      exception of the Acct-Term-Cause attribute.

   Although [RFC2869] does not indicate that it updates [RFC2866], this
   is an oversight, and the above attributes are allowable in an Interim
   Accounting record.

2.3.2.  Acct-Session-Id and Acct-Multi-Session-Id

   [RFC2866] Section 5.5 describes Acct-Session-Id as Text within the
   figure summarizing the attribute format, but then goes on to state
   that "The String field SHOULD be a string of UTF-8 encoded 10646
   characters".

   [RFC2865] defines the Text type as "containing UTF-8 encoded 10646
   characters", which is compatible with the description of Acct-
   Session-Id.  Since other attributes are consistently described as
   "Text" within both the figure summarizing the attribute format, and
   the following attribute definition, it appears that this is a
   typographical error, and that Acct-Session-Id is of type Text, and
   not of type String.






Nelson & DeKok              Standards Track                    [Page 12]

RFC 5080                 RADIUS Issues & Fixes             December 2007


   The definition of the Acct-Multi-Session-Id attribute also has
   typographical errors.  It says:

      A summary of the Acct-Session-Id attribute format ...

   This text should read:

      A summary of the Acct-Multi-Session-Id attribute format ...

   The Acct-Multi-Session-Id attribute is also defined as being of type
   String.  However, the language in the text strongly recommends that
   implementors consider the attribute as being of type Text.  It is
   unclear why the type String was chosen for this attribute when the
   type Text would be sufficient.  This attribute SHOULD be treated as
   Text.

2.3.3.  Request Authenticator

   [RFC2866] Section 4.1 states:

      The Request Authenticator of an Accounting-Request contains a 16-
      octet MD5 hash value calculated according to the method described
      in "Request Authenticator" above.

   However, the text does not indicate any action to take when an
   Accounting-Request packet contains an invalid Request Authenticator.
   The following text should be considered to be part of the above
   description:

      The Request Authenticator field MUST contain the correct data, as
      given by the above calculation.  Invalid packets are silently
      discarded.  Note that some early implementations always set the
      Request Authenticator to all zeros.  New implementations of RADIUS
      clients MUST use the above algorithm to calculate the Request
      Authenticator field.  New RADIUS server implementations MUST
      silently discard invalid packets.

2.3.4.  Interim-Accounting-Interval

   [RFC2869] Section 2.1 states:

      It is also possible to statically configure an interim value on
      the NAS itself.  Note that a locally configured value on the NAS
      MUST override the value found in an Access-Accept.

   This requirement may be phrased too strongly.  It is conceivable that
   a NAS implementation has a setting for a "minimum" value of Interim-
   Accounting-Interval, based on resource constraints in the NAS, and



Nelson & DeKok              Standards Track                    [Page 13]

RFC 5080                 RADIUS Issues & Fixes             December 2007


   network loading in the local environment of the NAS.  In such cases,
   the value administratively provisioned in the NAS should not be
   over-ridden by a smaller value from an Access-Accept message.  The
   NAS's value could be over-ridden by a larger one, however.  The
   intent is that the NAS sends accounting information at fixed
   intervals that are short enough so that the potential loss of
   billable revenue is limited, but also that the accounting updates are
   infrequent enough so that the NAS, network, and RADIUS server are not
   overloaded.

2.3.5.  Counter Values in the RADIUS Management Information Base (MIB)

   The RADIUS Authentication and Authorization Client MIB module
   ([RFC2618] [RFC4668]) includes counters of packet statistics.  In the
   descriptive text of the MIB module, formulas are provided for certain
   counter objects.  Implementors have noted apparent inconsistencies in
   the formulas that could result in negative values.

   Since the original MIB module specified in [RFC2618] had been widely
   implemented, the RADEXT WG chose not to change the object definitions
   or to create new ones within the revised MIB module [RFC4668].
   However, this section explains the issues and provides guidance for
   implementors regarding the interpretation of the textual description
   and comments for certain MIB objects.

   The issues raised can be summarized as follows:

   Issue (1):

   -- TotalIncomingPackets = Accepts + Rejects + Challenges +
   UnknownTypes
   --
   -- TotalIncomingPackets - MalformedResponses - BadAuthenticators -
   -- UnknownTypes - PacketsDropped = Successfully received
   --
   -- AccessRequests + PendingRequests + ClientTimeouts =
   -- Successfully Received

   It appears that the value of "Successfully Received" could be
   negative, since various counters are subtracted from
   TotalIncomingPackets that are not included in the calculation of
   TotalIncomingPackets.

   It also appears that "AccessRequests + PendingRequests +
   ClientTimeouts = Successfully Received" should read "AccessRequests +
   PendingRequests + ClientTimeouts = Successfully Transmitted".





Nelson & DeKok              Standards Track                    [Page 14]

RFC 5080                 RADIUS Issues & Fixes             December 2007


   "TotalIncomingPackets" and "Successfully Received" are temporary
   variables, i.e., not objects within the MIB module.  The comment text
   in the MIB modules is intended, therefore, to aid in understanding.
   What's of consequence is the consistency of values of the objects in
   the MIB module, and that does not appear to be impacted by the
   inconsistencies noted above.  It does appear, however, that the
   "Successfully Received" variable should be labeled "Successfully
   Transmitted".

   In addition, the definition of Accept, Reject or Challenge counters
   indicates that they MUST be incremented before the message is
   validated.  If the message is invalid, one of MalformedResponses,
   BadAuthenticators, or PacketsDropped counters will be additionally
   incremented.  In that case, the first two equations are consistent,
   i.e., "Successfully Received" could not be negative.

   Issue (2):

   It appears that the radiusAuthClientPendingRequests counter is
   decremented upon retransmission.  That would mean a retransmitted
   packet is not considered as being pending, although such
   retransmissions can still be considered as being pending requests.

   The definition of this MIB object in [RFC2618] is as follows:

      The number of RADIUS Access-Request packets destined for this
      server that have not yet timed out or received a response.  This
      variable is incremented when an Access-Request is sent and
      decremented due to receipt of an Access-Accept, Access-Reject or
      Access-Challenge, a timeout or retransmission.

   This object purports to count the number of pending request packets.
   It is open to interpretation whether or not retransmissions of a
   request are to be counted as additional pending packets.  In either
   event, it seems appropriate to treat retransmissions consistently
   with respect to incrementing and decrementing this counter.

2.4.  Multiple Filter-ID Attributes

   [RFC2865] Section 5.11 states:

      Zero or more Filter-Id attributes MAY be sent in an Access-Accept
      packet.








Nelson & DeKok              Standards Track                    [Page 15]

RFC 5080                 RADIUS Issues & Fixes             December 2007


   In practice, the behavior of a RADIUS client receiving multiple
   Filter-ID attributes is implementation dependent.  For example, some
   implementations treat multiple instances of the Filter-ID attribute
   as alternative filters; the first Filter-ID attribute having a name
   matching a locally defined filter is used, and the remaining ones are
   discarded.  Other implementations may combine matching filters.

   As a result, the interpretation of multiple Filter-ID attributes is
   undefined within RADIUS.  The sending of multiple Filter-ID
   attributes within an Access-Accept SHOULD be avoided within
   heterogeneous deployments and roaming scenarios, where it is likely
   to produce unpredictable results.

2.5.  Mandatory and Optional Attributes

   RADIUS attributes do not explicitly state whether they are optional
   or mandatory.  Nevertheless, there are instances where RADIUS
   attributes need to be treated as mandatory.

   [RFC2865] Section 1.1 states:

      A NAS that does not implement a given service MUST NOT implement
      the RADIUS attributes for that service.  For example, a NAS that
      is unable to offer Apple Remote Access Protocol (ARAP) service
      MUST NOT implement the RADIUS attributes for ARAP.  A NAS MUST
      treat a RADIUS access-accept authorizing an unavailable service as
      an access-reject instead.

   With respect to the Service-Type attribute, [RFC2865] Section 5.6
   says:

      This Attribute indicates the type of service the user has
      requested, or the type of service to be provided.  It MAY be used
      in both Access-Request and Access-Accept packets.  A NAS is not
      required to implement all of these service types, and MUST treat
      unknown or unsupported Service-Types as though an Access-Reject
      had been received instead.

   [RFC2865] Section 5 states:

      A RADIUS server MAY ignore Attributes with an unknown Type.

      A RADIUS client MAY ignore Attributes with an unknown Type.








Nelson & DeKok              Standards Track                    [Page 16]

RFC 5080                 RADIUS Issues & Fixes             December 2007


   With respect to Vendor-Specific Attributes (VSAs), [RFC2865] Section
   5.26 states:

      Servers not equipped to interpret the vendor-specific information
      sent by a client MUST ignore it (although it may be reported).
      Clients which do not receive desired vendor-specific information
      SHOULD make an attempt to operate without it, although they may do
      so (and report they are doing so) in a degraded mode.

   It is possible for either a standard attribute or a VSA to represent
   a request for an unavailable service.  However, where the Type,
   Vendor-ID, or Vendor-Type is unknown, a RADIUS client will not know
   whether or not the attribute defines a service.

   In general, it is best for a RADIUS client to err on the side of
   caution.  On receiving an Access-Accept including an attribute of
   known Type for an unimplemented service, a RADIUS client MUST treat
   it as an Access-Reject, as directed in [RFC2865] Section 1.1.  On
   receiving an Access-Accept including an attribute of unknown Type, a
   RADIUS client SHOULD assume that it is a potential service
   definition, and treat it as an Access-Reject.  Unknown VSAs SHOULD be
   ignored by RADIUS clients.

   In order to avoid introducing changes in default behavior, existing
   implementations that do not obey this recommendation should make the
   behavior configurable, with the legacy behavior being enabled by
   default.  A configuration flag such as "treat unknown attributes as
   reject" can be exposed to the system administrator.  If the flag is
   set to true, then Access-Accepts containing unknown attributes are
   treated as Access-Rejects.  If the flag is set to false, then unknown
   attributes in Access-Accepts are silently ignored.

   On receiving a packet including an attribute of unknown Type, RADIUS
   authentication server implementations SHOULD ignore such attributes.
   However, RADIUS accounting server implementations typically do not
   need to understand attributes in order to write them to stable
   storage or pass them to the billing engine.  Therefore, accounting
   server implementations SHOULD be equipped to handle unknown
   attributes.

   To avoid misinterpretation of service requests encoded within VSAs,
   RADIUS servers SHOULD NOT send VSAs containing service requests to
   RADIUS clients that are not known to understand them.  For example, a