[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]



Internet Engineering Task Force                      D.J. Massameno, Ed.
Internet-Draft                                           Yale University
Intended status: Informational                              25 June 2020
Expires: 27 December 2020


              RADIUS Extensions for Server Load Balancing
                      draft-massameno-radius-lb-00

Abstract

   This document describes a method for a Network Access Server (NAS) to
   dynamically discover all available RADIUS servers.  It defines a new
   message type within the STATUS-SERVER message, which is requested by
   the NAS and provided by the RADIUS server.  The NAS is then able to
   load balance its RADIUS messages across multiple RADIUS servers based
   on priority and weight supplied by the initial server.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 27 December 2020.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.



Massameno               Expires 27 December 2020                [Page 1]


Internet-Draft                  radius-lb                      June 2020


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Overall Message Exchange Summary  . . . . . . . . . . . . . .   4
     2.1.  Attributes Needed for Status-Server-LB  . . . . . . . . .   5
     2.2.  Table of Attributes . . . . . . . . . . . . . . . . . . .   5
     2.3.  Required Status-Server-LB Attributes  . . . . . . . . . .   6
       2.3.1.  NAS-IP Address and/or NAS-Identifier  . . . . . . . .   6
       2.3.2.  Message-Authenticator . . . . . . . . . . . . . . . .   6
   3.  LB-Request Attribute  . . . . . . . . . . . . . . . . . . . .   6
   4.  LB-Response Attribute . . . . . . . . . . . . . . . . . . . .   7
     4.1.  LB-Response Attribute Format  . . . . . . . . . . . . . .   8
   5.  The SVR-Record TLV  . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  SVR-Record-IPv4 . . . . . . . . . . . . . . . . . . . . .   8
     5.2.  SVR-Record-IPv6 . . . . . . . . . . . . . . . . . . . . .   9
     5.3.  Table of Sub-Attributes . . . . . . . . . . . . . . . . .  10
   6.  Sub-Attributes Needed for SVR-Record TLV  . . . . . . . . . .  11
     6.1.  LB-TTL  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     6.2.  LB-Priority . . . . . . . . . . . . . . . . . . . . . . .  12
     6.3.  LB-Weight . . . . . . . . . . . . . . . . . . . . . . . .  12
     6.4.  LB-IPv4 . . . . . . . . . . . . . . . . . . . . . . . . .  13
     6.5.  LB-IPv6 . . . . . . . . . . . . . . . . . . . . . . . . .  14
   7.  Load Balancing Rules  . . . . . . . . . . . . . . . . . . . .  15
     7.1.  Session-Based Load Balancing  . . . . . . . . . . . . . .  15
     7.2.  Load Balancing Weight . . . . . . . . . . . . . . . . . .  15
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
     8.1.  Clear Text Transmission . . . . . . . . . . . . . . . . .  16
     8.2.  Reconnaissance  . . . . . . . . . . . . . . . . . . . . .  16
     8.3.  MD5 . . . . . . . . . . . . . . . . . . . . . . . . . . .  16
   9.  NAS identifying Initial RADIUS Servers  . . . . . . . . . . .  16
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   Modern networks require Authentication, Authorization and Accounting
   (AAA) services for a wide range of deployment scenarios.  Many of
   these scenarios are mission critical and require fault tolerance and
   increased up-time.  Most network equipment can be configured to
   access multiple back-end RAIDUS servers.  When one server fails the
   equipment switches to the other RADIUS server.

   The configuration of multiple RADIUS servers within the Network
   Access Server (RADIUS Client) currently has a number of limitations
   within contemporary implementations.  There may be a limitation in



Massameno               Expires 27 December 2020                [Page 2]


Internet-Draft                  radius-lb                      June 2020


   the number of RADIUS servers that can be easily configured and
   maintained.  Also, until a failure is detected, the Network Access
   Server will likely only use one RADIUS server, even if multiple are
   configured.

   To relieve these limitations, some installations choose to use a load
   balancer between the Network Access Server and the RADIUS server.
   This has the advantage of supporting an arbitrarily large number of
   RADIUS servers.  The load balancer can be configured to distribute
   the load evenly based on a defined algorithm.  Proportional load
   distribution may be a desirable property when trying to scale out to
   multiple back-end RADIUS servers for the purposes of increasing
   capacity.

   The RADIUS extensions in this document achieve the load balancing
   property without using a separate load balancing device.  With the
   removal of the external load balancer the operational complexity of
   the entire system will decrease.  Also, as opposed to a third-party
   device, the NAS and RADIUS servers are the best devices to determine
   the operational status of the necessary components, thereby assisting
   in fault detection and avoidance.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

1.2.  Terminology

   This document frequently uses the following terms:

   session
                    Each service provided by the NAS to a user
                    attempting to connect (a dial-in user in the
                    original RADIUS specifications) constitutes a
                    session.  The beginning of the session is defined as
                    the point where service is first provided and the
                    end of the session defined as the point where
                    service is ended.  A user may have multiple sessions
                    in parallel or series if supported by the NAS.

   calling-station
                    This is the user or device that wishes access to the
                    network.  It connects to the NAS and, in most cases,
                    presents identifying information.





Massameno               Expires 27 December 2020                [Page 3]


Internet-Draft                  radius-lb                      June 2020


   NAS
                    This is a Network Access Server.  This is the device
                    that receives the incoming connection from a
                    calling-station that wishes access to the network.
                    Some vendors call this the Network Access Device
                    (NAD).  The NAS then communicates with the RADIUS
                    Server on behalf of the calling-station.

   RADIUS Server
                    This is the machine that implements the server side
                    of the RADIUS protocol.

   AAA services
                    The RADIUS protocol serves the functions of
                    Authentication (identity), Authorization (what the
                    user is allowed to do and how their connection
                    should be configured), and Accounting (a record of
                    the actions taken for the connection).

   PDU
                    The Protocol Data Unit is the organization of data
                    in a formal specification that is serialized and
                    transmitted between entities on a network.

2.  Overall Message Exchange Summary

   The RADIUS protocol [RFC2865] defines a PDU for transporting messages
   within UDP.  The operation of the Code, Identifier, Length, and
   Authenticator fields are specified in RFC2865.  The operation of the
   Status-Server message is specified in [RFC5997].

       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 ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-


                                  Figure 1





Massameno               Expires 27 December 2020                [Page 4]


Internet-Draft                  radius-lb                      June 2020


   Code
     12 for Status-Server.  This is the code used in RFC5997.

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

   Authenticator
     The Request Authenticator value MUST be changed each time a new
     Identifier is used.  The Authenticator does not authenticate the
     identity of the NAS or the RADIUS server.  The Message-
     Authenticator (Attribute 80) [RFC3579] MUST be used to authenticate
     both sides of the message exchange.

   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 maximum length is 4096.

   Attributes
     The Attribute field is variable in length, and contains the list of
     Attributes that are required for the type of service, as well as
     any desired optional Attributes.

2.1.  Attributes Needed for Status-Server-LB

   The conversation between the NAS and the RADIUS server for the
   purposes of the load-balance function involves a sending an LB-
   Request attribute to the server.  The server then responds with an
   LB-Response attribute.  Both MUST contain a RADIUS attribute Message-
   Authenticator [RFC3579].

2.2.  Table of Attributes

   The following table provides a guide to which attributes may be found
   in which kinds of packets, and in what quantity.










Massameno               Expires 27 December 2020                [Page 5]


Internet-Draft                  radius-lb                      June 2020


      LB-Request    LB-Response   #     Attribute
      0-1           0             4     NAS-IP-Address [Note 1]
      0-1           0             32    NAS-Identifier [Note 1]
      1             1             80    Message-Authenticator
      1             1             191   LB-Request / LB-Response



                                  Figure 2

   [Note 1] A Status-Server message MUST contain either a NAS-IP-Address
   or a NAS-Identifier (or both).

   0 This attribute MUST NOT be present in packet. 0-1 Zero or one
   instance of this attribute MAY be present in packet. 1 Exactly one
   instance of this attribute MUST be present in packet.

2.3.  Required Status-Server-LB Attributes

   The required attributes for a valid LB-Request message are outlined
   here.

2.3.1.  NAS-IP Address and/or NAS-Identifier

   The NAS-IP-Address or the NAS-Identifier or both attributes are
   required in an LB-Request message.  These are specified in [RFC2865]
   as Attributes 4 and 32 respectively.  This will identify the NAS to
   the RADIUS server.

2.3.2.  Message-Authenticator

   In a normal RADIUS access-request message the Request Authenticator
   field is hashed with the identity material from the calling-station
   and the RADIUS shared secret.  In an LB-Request message there is no
   calling-station, so this mechanism cannot be used.

   RFC3579 specifies Attribute 80 that computes an MD5 hash across the
   entire RADIUS PDU combined with the shared secret.  This mechanism
   must be used in all LB-Request and LB-Response PDUs.

3.  LB-Request Attribute

   The conversation between the NAS and the server to implement the
   Status-Server-LB protocol MUST include a RADIUS message with the LB-
   Request attribute.  This message informs the server that the NAS
   would like to discover all RADIUS servers that are available to
   handle RADIUS authentication requests.  The NAS anticipates a Status-
   Server-LB response in the form of an LB-Response PDU.



Massameno               Expires 27 December 2020                [Page 6]


Internet-Draft                  radius-lb                      June 2020


   The Attributes field in the RADIUS message shall be arranged as
   follows.

       0                   1                   2
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type=191    |    Length     |S|R|R|R|R|R|R|R|R|R|R|R|R|R|R|R|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                                  Figure 3

   Type
     191 for Status-Server Load Balancing.

   Length
     = 4

     The length field calculates the length of the attribute, which
     includes the type, length and capabilities field.

   Server-Status-LB Bit (S-bit)
     This bit is to indicate the client can process Status-Server-LB as
     described in this document.  It MUST be set to indicate compliance
     with this standard.

   R-Bit
     These bits are reserved for future capabilities of the protocol.
     These MUST be set to zero on transmission and ignored on receipt.

   A NAS that sends an LB-Request attribute but does not receive an LB-
   Response attribute MUST continue normally as if it had not sent the
   LB-Request attribute.

4.  LB-Response Attribute

   When the server receives a Status-Server packet from the NAS and it
   contains an LB-Request attribute it SHOULD respond with a Status-
   Server message that contains an LB-Response attribute.  In scenarios
   where the administrator does not want to convey load-balancer
   information to the NAS the RADIUS server MAY choose to not respond.

   If the initial Status-Server message included attributes other than
   the LB-Request attribute the server MAY choose to respond but simply
   omit the LB-Response attribute.





Massameno               Expires 27 December 2020                [Page 7]


Internet-Draft                  radius-lb                      June 2020


4.1.  LB-Response Attribute Format

   The Attributes field in the RADIUS message shall be arranged as
   follows.

       0                   1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
      |   Type=191    |    Length     |  Server_Info ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-



                                  Figure 4

   Type
     191 for Status-Server Load Balancing.

   Length
     >= 3

     The length field calculates the length in octets of the Type field,
     Length field, and the concatenation of all the server_info PDUs.

   Server_Info
     The String field is one or more server_info PDUs.  Each PDU defines
     the status of a single server and its defining characteristics.

5.  The SVR-Record TLV

   The SVR-Record (Server Record) TLV is a family of Type-Length-Value
   attributes that holds multiple sub-attributes as described in
   Section 5.  Each SVR-Record type supports a particular address
   family.  SVR-Record-IPv4 and SVR-Record-IPv6 are defined in this
   document.  Other address families may be supported by future
   standards.

   In order to support more than six SVR-Records in one RADIUS packet
   these attributes are allocated in the Long-Extended-Type Attribute
   defined in [RFC6929].

5.1.  SVR-Record-IPv4

   Description
     This attribute indicates a SVR-Record that contains information
     about an IPv4 RADIUS server.  This attribute conforms to the TLV-
     Data type described in [RFC8044].




Massameno               Expires 27 December 2020                [Page 8]


Internet-Draft                  radius-lb                      June 2020


     A summary of the SVR-Record_ipv4 Attribute format is shown below.
     The fields are transmitted from left to right.

      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   TLV-Type    |  TLV-Length   |     TLV-Data ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




                                   Figure 5

   Type
     245.TBD1 for SVR-Record-IPv4.

   Length
     The TLV-Length field is one octet and indicates the length of this
     TLV, including the TLV-Type, TLV-Length, and TLV-Value fields.  It
     MUST have a value between 3 and 255.  If a client or server
     receives a TLV with an invalid TLV-Length, then the attribute that
     encapsulates that TLV MUST be considered to be an invalid attribute
     and is handled as per [RFC6929], Section 2.8.

     TLVs having a TLV-Length of two (2) MUST NOT be sent; omit the
     entire TLV instead.

   TLV-Data
     The TLV-Data for the SVR-Record-IPv6 attribute indicates the usage
     of one RADIUS server that has an IPv6 address.  It must include
     sub-attributes for LB-TTL, LB-priority, LB-Weight and LB-IPv4.

5.2.  SVR-Record-IPv6

   Description
     This attribute indicates an SVR-Record that contains information
     about an IPv6 RADIUS server.  This attribute conforms to the TLV-
     Data type described in RFC8044.

     A summary of the SVR-Record-IPv6 Attribute format is shown below.
     The fields are transmitted from left to right.









Massameno               Expires 27 December 2020                [Page 9]


Internet-Draft                  radius-lb                      June 2020


      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   TLV-Type    |  TLV-Length   |     TLV-Data ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




                                   Figure 6

   Type
     245.TBD2 for SVR-Record-IPv6.

   Length
     The TLV-Length field is one octet and indicates the length of this
     TLV, including the TLV-Type, TLV-Length, and TLV-Value fields.  It
     MUST have a value between 3 and 255.  If a client or server
     receives a TLV with an invalid TLV-Length, then the attribute that
     encapsulates that TLV MUST be considered to be an invalid attribute
     and is handled as per [RFC6929], Section 2.8.

     TLVs having a TLV-Length of two (2) MUST NOT be sent; omit the
     entire TLV instead.

   TLV-Data
     The TLV-Data for the SVR-Record-IPv6 attribute indicates the usage
     of one RADIUS server that has an IPv6 address.  It must include
     sub-attributes for LB-TTL, LB-priority, LB-Weight and LB-IPv6.

5.3.  Table of Sub-Attributes

   The following table provides a guide to which sub-attributes may be
   found in which kinds of packets and in what quantity.

      SVR-Record-IPv4   SVR-Record-IPv6   #    Sub-Attribute
      1                 1                 1    LB-TTL
      1                 1                 2    LB-priority
      1                 1                 3    LB-Weight
      1                 0                 4    LB-IPv4
      0                 1                 5    LB-IPv6


                                  Figure 7

   The following table defines the meaning of the above table entries.





Massameno               Expires 27 December 2020               [Page 10]


Internet-Draft                  radius-lb                      June 2020


   0     This attribute MUST NOT be present in TLV.
   0+    Zero or more instances of this attribute MAY be
         present in packet.
   0-1   Zero or one instance of this attribute MAY be present
         in packet.
   1     Exactly one instance of this attribute MUST
         be present in packet.



                                  Figure 8

6.  Sub-Attributes Needed for SVR-Record TLV

   The server_info field contains multiple SVR-Records.  Each SVR-Record
   will contain multiple sub-fields that are documented in this section.

6.1.  LB-TTL

   Description
     This attribute indicates how long the NAS should consider the SVR-
     Record valid.

     A summary of the User-Name Attribute format is shown below.  The
     fields are transmitted from left to right.

     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |            integer
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            integer  (cont)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




                                   Figure 9

   Type
     1 for LB-TTL

   Length
     6

   integer
     This field indicates the number of seconds this SVR-Record should
     be in-use and considered valid.  If the TTL is 0, the entry SHOULD



Massameno               Expires 27 December 2020               [Page 11]


Internet-Draft                  radius-lb                      June 2020


     be removed from the cache immediately.  If the value is 0xffffffff,
     the recipient can decide locally how long to store the mapping.  It
     conforms to the integer data type specified in RFC8044.

6.2.  LB-Priority

   Description
     This attribute indicates the priority of the SVR-Record.

     A summary of the LB-priority Attribute format is shown below.  The
     fields are transmitted from left to right.

     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |            integer
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            integer  (cont)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




                                  Figure 10

   Type
     2 for LB-Priority

   Length
     6

   integer
     This field indicates the priority of this target host.  A NAS MUST
     attempt to use the target RADIUS server with the lowest-numbered
     priority it can reach; target servers with the same priority SHOULD
     be used in an order defined by the LB-Weight field.  An SVR-Record
     with a lower-numbered LB-priority should always used be before an
     SVR-Record of a higher-numbered LB-priority, regardless of LB-
     Weight.  It conforms to the integer data type specified in RFC8044.

6.3.  LB-Weight

   Description
     This attribute indicates the weighting of the SVR-Record relative
     to other SVR-Record of the same priority.

     A summary of the LB-Weight Attribute format is shown below.  The
     fields are transmitted from left to right.



Massameno               Expires 27 December 2020               [Page 12]


Internet-Draft                  radius-lb                      June 2020


     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |            integer
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            integer  (cont)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




                                  Figure 11

   Type
     3 for LB-Weight

   Length
     6

   integer
     The weight field specifies a relative weight for entries with the
     same priority.  Larger weights SHOULD be given a proportionately
     higher probability of being used for AAA services.  SVR-Record with
     a lower-numbered LB-priority should always be used before SVR-
     Record of a higher-numbered LB-priority, regardless of LB-Weight.
     It conforms to the integer data type specified in RFC8044.

6.4.  LB-IPv4

   Description
     This attribute indicates the IPv4 address of the SVR-Record.

     A summary of the LB-IPv4 Attribute format is shown below.  The
     fields are transmitted from left to right.

     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |            Address...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         ... Address ...  (cont)     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




                                  Figure 12




Massameno               Expires 27 December 2020               [Page 13]


Internet-Draft                  radius-lb                      June 2020


   Type
     4 for LB-IPv4

   Address
     6

   Address
     This is the IPv4 address of the SVR-Record.  While taking into
     consideration the LB-priority and LB-Weight attributes the NAS
     SHOULD attempt to use this address as a RADIUS server.  All
     considerations for client and server authentication mechanisms MUST
     still be observed.  It conforms to the ipv4addr data type specified
     in RFC8044.

6.5.  LB-IPv6

   Description
     This attribute indicates the IPv6 address of the SVR-Record.

     A summary of the LB-IPv6 Attribute format is shown below.  The
     fields are transmitted from left to right.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |            Address...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             ... Address ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             ... Address ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             ... Address ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             ... Address ...         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                                  Figure 13

   Type
     5 for LB-IPv4

   Length
     18

   Address
     This is the IPv6 address of the SVR-Record.  While taking into
     consideration the LB-priority and LB-Weight attributes the NAS



Massameno               Expires 27 December 2020               [Page 14]


Internet-Draft                  radius-lb                      June 2020


     SHOULD attempt to use this address as a RADIUS server.  All
     considerations for client and server authentication mechanisms MUST
     still be observed.  It conforms to the ipv6addr data type specified
     in RFC8044.

7.  Load Balancing Rules

   When there are multiple SVR-Records available with the same LB-
   priority, a non-zero weight, and excluding those SVR-Records with an
   inferior LB-priority, the NAS MUST distribute the AAA messages across
   those servers.

7.1.  Session-Based Load Balancing

   RADIUS servers may cache user data after retrieving that data from a
   back-end database.  If a NAS queries a RADIUS server for a particular
   user the server cache will be populated.  If the NAS then uses the
   same RADIUS server for subsequent queries for the same user it will
   represent a cache hit.  Sending the query to a different RADIUS
   server may represent a cache miss.  A cache miss may be an expensive
   operation in terms of time and other server resources.  Under these
   Status-Server-LB rules the NAS MUST send all RADIUS messages relative
   to a particular session to the same RADIUS server to maximize the
   probability of a cache-hit.

   A NAS may terminate multiple sessions from multiple calling-stations.
   It SHOULD use whatever means is available from the conversation with
   the calling-station to uniquely identify sessions.  Examples include,
   but are not limited to, the RADIUS attributes User Name and Calling-
   Station-Id.

7.2.  Load Balancing Weight

   The weight field specifies a relative weight for entries with the
   same priority.  Larger weights SHOULD be given a proportionately
   higher probability of being used for AAA services.  The NAS should
   attempt to maintain the proper distribution of sessions based on LB-
   Weight, but MUST retain the properties of Session-Based Load
   Balancing described in Section 7.1

8.  Security Considerations

   RADIUS Server Load Balancing has many of the same security
   implications as the base RADIUS protocol.







Massameno               Expires 27 December 2020               [Page 15]


Internet-Draft                  radius-lb                      June 2020


8.1.  Clear Text Transmission

   The RADIUS protocol is unencrypted clear-text on the wire.  The
   Message-Authenticator attribute is required and protects the RADIUS
   message from tampering, but it does not encrypt the data.  The Server
   Load Balance extensions to RADIUS do not communicate any user
   identity information or user-authentication materials.  Being able to
   view the LB-Request or LB Response PDU in clear-text does not
   compromise any of this data.

8.2.  Reconnaissance

   If an attacker could impersonate a NAS then they would be able to use
   the LB-Request to gain a list of available RADIUS servers.  This is
   additional information the attacker may not have access to otherwise.
   Each RADIUS message is authenticated with the Message-Authenticator
   attribute, so the attacker would need access to the shared secret to
   correctly submit a valid LB-Request.

8.3.  MD5

   The RADIUS Response Authenticator and the Message-Authenticator
   attribute both rely on the integrity of the MD5 algorithm.  If an
   attacker is able to reverse-engineer the shared secret by using a
   weakness in the MD5 algorithm, then the Message-Authenticator
   attribute will no longer provide message integrity.

   This document recommends the development of better mechanisms for
   authenticating messages within the RADIUS protocol using more modern
   encryption standards.

9.  NAS identifying Initial RADIUS Servers

   For a NAS to use the RADIUS Server Load Balancing service it must be
   able to contact an initial RADIUS server.  Options include static
   configuration of an initial seed RADIUS server.  Other
   implementations may use a DNS SRV record of the form
   _radius._udp.name.  The format and use of the SRV record is described
   in [RFC2782].

   Implementation-specific mechanisms may be employed but are generally
   outside the scope of this document.

10.  IANA Considerations

   This implementation used Attribute 191 for the LB-Request and LB-
   Response PDU.  An official registration is requested from IANA.




Massameno               Expires 27 December 2020               [Page 16]


Internet-Draft                  radius-lb                      June 2020


   The Vendor Specified Attribute 26 may be used to encapsulate the LB-
   Request and LB-Response PDU where no vendor interoperability is
   required.

11.  References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              BCP 14, RFC 2865, DOI 10.17487/RFC2865, June 2000,
              <https://www.rfc-editor.org/info/rfc2865>.

   [RFC3579]  Aboba, B., Calhoun, P., and W. Simpson, "RADIUS (Remote
              Authentication Dial In User Service) Support For
              Extensible Authentication Protocol (EAP)", BCP 14,
              RFC 3579, DOI 10.17487/RFC3579, September 2003,
              <https://www.rfc-editor.org/info/rfc3579>.

   [RFC5997]  Dekok, A., "Use of Status-Server Packets in the Remote
              Authentication Dial In User Service (RADIUS) Protocol",
              BCP 14, RFC RFC5997, DOI 10.17487/RFC5997, August 2010,
              <https://www.rfc-editor.org/info/rfc5997>.

   [RFC6929]  Dekok, A., "Remote Authentication Dial-In User Service
              (RADIUS) Protocol Extensions", BCP 14, RFC 6929,
              DOI 10.17487/RFC6929, April 2013,
              <https://www.rfc-editor.org/info/rfc6929>.

   [RFC8044]  Dekok, A., "Data Types in RADIUS", BCP 14, RFC 8044,
              DOI 10.17487/RFC8044, January 2017,
              <https://www.rfc-editor.org/info/rfc8044>.

Author's Address

   Daniel Massameno (editor)
   Yale University
   150 Munson Street
   New Haven, CT 06492
   United States of America

   Email: dan.massameno@yale.edu






Massameno               Expires 27 December 2020               [Page 17]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/