rfc5080.txt

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

      Info.

   There are issues with the suggested algorithm.  Since proxies may
   modify Access-Request attributes such as NAS-IP-Address, depending on
   any attribute under control of the NAS to distinguish request
   identifiers can result in deployment problems.

   The FreeRADIUS implementation does not track EAP identifiers by NAS-
   IP-Address or other non-EAP attributes sent by the NAS.  Instead, it
   uses the EAP identifier, source Internet Protocol (IP) address, and
   the State attribute as a "key" to uniquely identify each EAP session.
   Since the State attribute is under the control of the RADIUS server,
   the uniqueness of each session is controlled by the server, not the
   NAS.  The algorithm used in FreeRADIUS is as follows:








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


      if (EAP start, or EAP identity) {
        allocate unique State Attribute
        insert session into "active session" table with
             key=(EAP identifier, State, source IP)
      } else {
        look up active session in table, with above key
      }

   This algorithm appears to work well in a variety of situations,
   including situations where home servers receive messages via
   intermediate RADIUS proxies.

   Implementations that do not use this algorithm are often restricted
   to having an EAP Identifier space per NAS, or perhaps one that is
   global to the implementation.  These restrictions are unnecessary
   when the above algorithm is used, which gives each session a unique
   EAP Identifier space.  The above algorithm SHOULD be used to track
   EAP sessions in preference to any other method.

2.2.  Overload Conditions

2.2.1.  Retransmission Behavior

   [RFC2865] Section 2.4 describes the retransmission requirements for
   RADIUS clients:

      At one extreme, RADIUS does not require a "responsive" detection
      of lost data.  The user is willing to wait several seconds for the
      authentication to complete.  The generally aggressive Transmission
      Control Protocol (TCP) retransmission (based on average round trip
      time) is not required, nor is the acknowledgment overhead of TCP.

      At the other extreme, the user is not willing to wait several
      minutes for authentication.  Therefore the reliable delivery of
      TCP data two minutes later is not useful.  The faster use of an
      alternate server allows the user to gain access before giving up.

   Some existing RADIUS clients implement excessively aggressive
   retransmission behavior, utilizing default retransmission timeouts of
   one second or less without support for congestive backoff.  When
   deployed at a large scale, these implementations are susceptible to
   congestive collapse.  For example, as the result of a power failure,
   a network with 3,000 NAS devices with a fixed retransmission timer of
   one second will continuously generate 3,000 RADIUS Access-Requests
   per second.  This is sufficient to overwhelm most RADIUS servers.






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


   Suggested solutions include:

      [a]   Jitter.  To avoid synchronization, a RADIUS client SHOULD
            incorporate induced jitter within its retransmission
            algorithm, as specified below.

      [b]   Congestive backoff.  While it is not necessary for RADIUS
            client implementations to implement complex retransmission
            algorithms, implementations SHOULD support congestive
            backoff.

   RADIUS retransmission timers are based on the model used in Dynamic
   Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315].  Variables
   used here are also borrowed from this specification.  RADIUS is a
   request/response-based protocol.  The message exchange terminates
   when the requester successfully receives the answer, or the message
   exchange is considered to have failed according to the RECOMMENDED
   retransmission mechanism described below.  Other retransmission
   mechanisms are possible, as long as they satisfy the requirements on
   jitter and congestive backoff.

   The following algorithms apply to any client that originates RADIUS
   packets, including but not limited to Access-Request, Accounting-
   Request, Disconnect-Request, and CoA-Request [RFC3576].

   The retransmission behavior is controlled and described by the
   following variables:

         RT     Retransmission timeout

         IRT    Initial retransmission time  (default 2 seconds)

         MRC    Maximum retransmission count (default 5 attempts)

         MRT    Maximum retransmission time (default 16 seconds)

         MRD    Maximum retransmission duration (default 30 seconds)

         RAND   Randomization factor

   With each message transmission or retransmission, the sender sets RT
   according to the rules given below.  If RT expires before the message
   exchange terminates, the sender re-computes RT and retransmits the
   message.







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


   Each of the computations of a new RT include a randomization factor
   (RAND), which is a random number chosen with a uniform distribution
   between -0.1 and +0.1.  The randomization factor is included to
   minimize the synchronization of messages.

   The algorithm for choosing a random number does not need to be
   cryptographically sound.  The algorithm SHOULD produce a different
   sequence of random numbers from each invocation.

   RT for the first message transmission is based on IRT:

         RT = IRT + RAND*IRT

   RT for each subsequent message retransmission is based on the
   previous value of RT:

         RT = 2*RTprev + RAND*RTprev

   MRT specifies an upper bound on the value of RT (disregarding the
   randomization added by the use of RAND).  If MRT has a value of 0,
   there is no upper limit on the value of RT.  Otherwise:

         if (RT > MRT)
            RT = MRT + RAND*MRT

   MRD specifies an upper bound on the length of time a sender may
   retransmit a message.  The message exchange fails once MRD seconds
   have elapsed since the client first transmitted the message.  MRD
   MUST be set, and SHOULD have a value between 5 and 30 seconds.  These
   values mirror the values for a server's duplicate detection cache, as
   described in the next section.

   MRC specifies an upper bound on the number of times a sender may
   retransmit a message.  If MRC is zero, the message exchange fails
   once MRD seconds have elapsed since the client first transmitted the
   message.  If MRC is non-zero, the message exchange fails when either
   the sender has transmitted the message MRC times, or when MRD seconds
   have elapsed since the client first transmitted the message.

   For Accounting-Request packets, the default values for MRC, MRD, and
   MRT SHOULD be zero.  These settings will enable a RADIUS client to
   continue sending accounting requests to a RADIUS server until the
   request is acknowledged.  If any of MRC, MRD, or MRT are non-zero,
   then the accounting information could potentially be discarded
   without being recorded.






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


2.2.2.  Duplicate Detection and Orderly Delivery

   When packets are retransmitted by a client, the server may receive
   duplicate requests.  The limitations of the transport protocol used
   by RADIUS, the User Datagram Protocol (UDP), means that the Access-
   Request packets may be received, and potentially processed, in an
   order different from the order in which the packets were sent.
   However, the discussion of the Identifier field in Section 3 of
   [RFC2865] says:

      The RADIUS server can detect a duplicate request if it has the
      same client source IP address and source UDP port and Identifier
      within a short span of time.

   Also, Section 7 of [RFC4669] defines a
   radiusAuthServDupAccessRequests object as:

      The number of duplicate Access-Request packets received.

   This text has a number of implications.  First, without duplicate
   detection, a RADIUS server may process an authentication request
   twice, leading to an erroneous conclusion that a user has logged in
   twice.  That behavior is undesirable, so duplicate detection is
   desirable.  Second, the server may track not only the duplicate
   request, but also the replies to those requests.  This behavior
   permits the server to send duplicate replies in response to duplicate
   requests, increasing network stability.

   Since Access-Request packets may also be sent by the client in
   response to an Access-Challenge from the server, those packets form a
   logically ordered stream, and, therefore have additional ordering
   requirements over Access-Request packets for different sessions.
   Implementing duplicate detection results in new packets being
   processed only once, ensuring order.

   RADIUS servers MUST therefore implement duplicate detection for
   Access-Request packets, as described in Section 3 of [RFC2865].
   Implementations MUST also cache the Responses (Access-Accept,
   Access-Challenge, or Access-Reject) that they send in response to
   Access-Request packets.  If a server receives a valid duplicate
   Access-Request for which it has already sent a Response, it MUST
   resend its original Response without reprocessing the request.  The
   server MUST silently discard any duplicate Access-Requests for which
   a Response has not yet been sent.







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


   Each cache entry SHOULD be purged after a period of time.  This time
   SHOULD be no less than 5 seconds, and no more than 30 seconds.  After
   about 30 seconds, most RADIUS clients and end users will have given
   up on the authentication request.  Therefore, there is little value
   in having a larger cache timeout.

   Cache entries MUST also be purged if the server receives a valid
   Access-Request packet that matches a cached Access-Request packet in
   source address, source port, RADIUS Identifier, and receiving socket,
   but where the Request Authenticator field is different from the one
   in the cached packet.  If the request contains a Message-
   Authenticator attribute, the request MUST be processed as described
   in [RFC3580] Section 3.2.  Packets with invalid Message-
   Authenticators MUST NOT affect the cache in any way.

   However, Access-Request packets not containing a Message-
   Authenticator attribute always affect the cache, even though they may
   be trivially forged.  To avoid this issue, server implementations may
   be configured to require the presence of a Message-Authenticator
   attribute in Access-Request packets.  Requests not containing a
   Message-Authenticator attribute MAY then be silently discarded.

   Client implementations SHOULD include a Message-Authenticator
   attribute in every Access-Request to further help mitigate this
   issue.

   When sending requests, RADIUS clients MUST NOT reuse Identifiers for
   a source IP address and source UDP port until either a valid response
   has been received, or the request has timed out.  Clients SHOULD
   allocate Identifiers via a least-recently-used (LRU) method for a
   particular source IP address and source UDP port.

   RADIUS clients do not have to perform duplicate detection.  When a
   client sends a request, it processes the first response that has a
   valid Response Authenticator as defined in [RFC2865] Section 3.  Any
   later responses MUST be silently discarded, as they do not match a
   pending request.  That is, later responses are treated exactly the
   same as unsolicited responses, and are silently discarded.

2.2.3.  Server Response to Overload

   Some RADIUS server implementations are not robust in response to
   overload, dropping packets with even probability across multiple
   sessions.  In an overload situation, this results in a high failure
   rate for multi-round authentication protocols such as EAP [RFC3579].
   Typically, users will continually retry in an attempt to gain access,
   increasing the load even further.




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


   A more sensible approach is for a RADIUS server to preferentially
   accept RADIUS Access-Request packets containing a valid State
   attribute, so that multi-round authentication conversations, once
   begun, will be more likely to succeed.  Similarly, a server that is
   proxying requests should preferentially process Access-Accept,
   Access-Challenge, or Access-Reject packets from home servers before
   processing new requests from a NAS.