idnits 2.17.1 draft-massameno-radius-lb-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 June 2020) is 1400 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Note 1' is mentioned on line 241, but not defined == Missing Reference: 'RFC2782' is mentioned on line 715, but not defined Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D.J. Massameno, Ed. 3 Internet-Draft Yale University 4 Intended status: Informational 25 June 2020 5 Expires: 27 December 2020 7 RADIUS Extensions for Server Load Balancing 8 draft-massameno-radius-lb-00 10 Abstract 12 This document describes a method for a Network Access Server (NAS) to 13 dynamically discover all available RADIUS servers. It defines a new 14 message type within the STATUS-SERVER message, which is requested by 15 the NAS and provided by the RADIUS server. The NAS is then able to 16 load balance its RADIUS messages across multiple RADIUS servers based 17 on priority and weight supplied by the initial server. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 27 December 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Overall Message Exchange Summary . . . . . . . . . . . . . . 4 56 2.1. Attributes Needed for Status-Server-LB . . . . . . . . . 5 57 2.2. Table of Attributes . . . . . . . . . . . . . . . . . . . 5 58 2.3. Required Status-Server-LB Attributes . . . . . . . . . . 6 59 2.3.1. NAS-IP Address and/or NAS-Identifier . . . . . . . . 6 60 2.3.2. Message-Authenticator . . . . . . . . . . . . . . . . 6 61 3. LB-Request Attribute . . . . . . . . . . . . . . . . . . . . 6 62 4. LB-Response Attribute . . . . . . . . . . . . . . . . . . . . 7 63 4.1. LB-Response Attribute Format . . . . . . . . . . . . . . 8 64 5. The SVR-Record TLV . . . . . . . . . . . . . . . . . . . . . 8 65 5.1. SVR-Record-IPv4 . . . . . . . . . . . . . . . . . . . . . 8 66 5.2. SVR-Record-IPv6 . . . . . . . . . . . . . . . . . . . . . 9 67 5.3. Table of Sub-Attributes . . . . . . . . . . . . . . . . . 10 68 6. Sub-Attributes Needed for SVR-Record TLV . . . . . . . . . . 11 69 6.1. LB-TTL . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 6.2. LB-Priority . . . . . . . . . . . . . . . . . . . . . . . 12 71 6.3. LB-Weight . . . . . . . . . . . . . . . . . . . . . . . . 12 72 6.4. LB-IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 6.5. LB-IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 7. Load Balancing Rules . . . . . . . . . . . . . . . . . . . . 15 75 7.1. Session-Based Load Balancing . . . . . . . . . . . . . . 15 76 7.2. Load Balancing Weight . . . . . . . . . . . . . . . . . . 15 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 78 8.1. Clear Text Transmission . . . . . . . . . . . . . . . . . 16 79 8.2. Reconnaissance . . . . . . . . . . . . . . . . . . . . . 16 80 8.3. MD5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 9. NAS identifying Initial RADIUS Servers . . . . . . . . . . . 16 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 86 1. Introduction 88 Modern networks require Authentication, Authorization and Accounting 89 (AAA) services for a wide range of deployment scenarios. Many of 90 these scenarios are mission critical and require fault tolerance and 91 increased up-time. Most network equipment can be configured to 92 access multiple back-end RAIDUS servers. When one server fails the 93 equipment switches to the other RADIUS server. 95 The configuration of multiple RADIUS servers within the Network 96 Access Server (RADIUS Client) currently has a number of limitations 97 within contemporary implementations. There may be a limitation in 98 the number of RADIUS servers that can be easily configured and 99 maintained. Also, until a failure is detected, the Network Access 100 Server will likely only use one RADIUS server, even if multiple are 101 configured. 103 To relieve these limitations, some installations choose to use a load 104 balancer between the Network Access Server and the RADIUS server. 105 This has the advantage of supporting an arbitrarily large number of 106 RADIUS servers. The load balancer can be configured to distribute 107 the load evenly based on a defined algorithm. Proportional load 108 distribution may be a desirable property when trying to scale out to 109 multiple back-end RADIUS servers for the purposes of increasing 110 capacity. 112 The RADIUS extensions in this document achieve the load balancing 113 property without using a separate load balancing device. With the 114 removal of the external load balancer the operational complexity of 115 the entire system will decrease. Also, as opposed to a third-party 116 device, the NAS and RADIUS servers are the best devices to determine 117 the operational status of the necessary components, thereby assisting 118 in fault detection and avoidance. 120 1.1. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 1.2. Terminology 128 This document frequently uses the following terms: 130 session 131 Each service provided by the NAS to a user 132 attempting to connect (a dial-in user in the 133 original RADIUS specifications) constitutes a 134 session. The beginning of the session is defined as 135 the point where service is first provided and the 136 end of the session defined as the point where 137 service is ended. A user may have multiple sessions 138 in parallel or series if supported by the NAS. 140 calling-station 141 This is the user or device that wishes access to the 142 network. It connects to the NAS and, in most cases, 143 presents identifying information. 145 NAS 146 This is a Network Access Server. This is the device 147 that receives the incoming connection from a 148 calling-station that wishes access to the network. 149 Some vendors call this the Network Access Device 150 (NAD). The NAS then communicates with the RADIUS 151 Server on behalf of the calling-station. 153 RADIUS Server 154 This is the machine that implements the server side 155 of the RADIUS protocol. 157 AAA services 158 The RADIUS protocol serves the functions of 159 Authentication (identity), Authorization (what the 160 user is allowed to do and how their connection 161 should be configured), and Accounting (a record of 162 the actions taken for the connection). 164 PDU 165 The Protocol Data Unit is the organization of data 166 in a formal specification that is serialized and 167 transmitted between entities on a network. 169 2. Overall Message Exchange Summary 171 The RADIUS protocol [RFC2865] defines a PDU for transporting messages 172 within UDP. The operation of the Code, Identifier, Length, and 173 Authenticator fields are specified in RFC2865. The operation of the 174 Status-Server message is specified in [RFC5997]. 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Code | Identifier | Length | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | | 182 | Authenticator | 183 | | 184 | | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Attributes ... 187 +-+-+-+-+-+-+-+-+-+-+-+-+- 189 Figure 1 191 Code 192 12 for Status-Server. This is the code used in RFC5997. 194 Identifier 195 The Identifier field MUST be changed whenever the content of the 196 Attributes field changes, and whenever a valid reply has been 197 received for a previous request. For retransmissions, the 198 Identifier MUST remain unchanged. 200 Authenticator 201 The Request Authenticator value MUST be changed each time a new 202 Identifier is used. The Authenticator does not authenticate the 203 identity of the NAS or the RADIUS server. The Message- 204 Authenticator (Attribute 80) [RFC3579] MUST be used to authenticate 205 both sides of the message exchange. 207 Length 208 The Length field is two octets. It indicates the length of the 209 packet including the Code, Identifier, Length, Authenticator and 210 Attribute fields. Octets outside the range of the Length field 211 MUST be treated as padding and ignored on reception. If the packet 212 is shorter than the Length field indicates, it MUST be silently 213 discarded. The minimum length is 20 and maximum length is 4096. 215 Attributes 216 The Attribute field is variable in length, and contains the list of 217 Attributes that are required for the type of service, as well as 218 any desired optional Attributes. 220 2.1. Attributes Needed for Status-Server-LB 222 The conversation between the NAS and the RADIUS server for the 223 purposes of the load-balance function involves a sending an LB- 224 Request attribute to the server. The server then responds with an 225 LB-Response attribute. Both MUST contain a RADIUS attribute Message- 226 Authenticator [RFC3579]. 228 2.2. Table of Attributes 230 The following table provides a guide to which attributes may be found 231 in which kinds of packets, and in what quantity. 233 LB-Request LB-Response # Attribute 234 0-1 0 4 NAS-IP-Address [Note 1] 235 0-1 0 32 NAS-Identifier [Note 1] 236 1 1 80 Message-Authenticator 237 1 1 191 LB-Request / LB-Response 239 Figure 2 241 [Note 1] A Status-Server message MUST contain either a NAS-IP-Address 242 or a NAS-Identifier (or both). 244 0 This attribute MUST NOT be present in packet. 0-1 Zero or one 245 instance of this attribute MAY be present in packet. 1 Exactly one 246 instance of this attribute MUST be present in packet. 248 2.3. Required Status-Server-LB Attributes 250 The required attributes for a valid LB-Request message are outlined 251 here. 253 2.3.1. NAS-IP Address and/or NAS-Identifier 255 The NAS-IP-Address or the NAS-Identifier or both attributes are 256 required in an LB-Request message. These are specified in [RFC2865] 257 as Attributes 4 and 32 respectively. This will identify the NAS to 258 the RADIUS server. 260 2.3.2. Message-Authenticator 262 In a normal RADIUS access-request message the Request Authenticator 263 field is hashed with the identity material from the calling-station 264 and the RADIUS shared secret. In an LB-Request message there is no 265 calling-station, so this mechanism cannot be used. 267 RFC3579 specifies Attribute 80 that computes an MD5 hash across the 268 entire RADIUS PDU combined with the shared secret. This mechanism 269 must be used in all LB-Request and LB-Response PDUs. 271 3. LB-Request Attribute 273 The conversation between the NAS and the server to implement the 274 Status-Server-LB protocol MUST include a RADIUS message with the LB- 275 Request attribute. This message informs the server that the NAS 276 would like to discover all RADIUS servers that are available to 277 handle RADIUS authentication requests. The NAS anticipates a Status- 278 Server-LB response in the form of an LB-Response PDU. 280 The Attributes field in the RADIUS message shall be arranged as 281 follows. 283 0 1 2 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Type=191 | Length |S|R|R|R|R|R|R|R|R|R|R|R|R|R|R|R| 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Figure 3 291 Type 292 191 for Status-Server Load Balancing. 294 Length 295 = 4 297 The length field calculates the length of the attribute, which 298 includes the type, length and capabilities field. 300 Server-Status-LB Bit (S-bit) 301 This bit is to indicate the client can process Status-Server-LB as 302 described in this document. It MUST be set to indicate compliance 303 with this standard. 305 R-Bit 306 These bits are reserved for future capabilities of the protocol. 307 These MUST be set to zero on transmission and ignored on receipt. 309 A NAS that sends an LB-Request attribute but does not receive an LB- 310 Response attribute MUST continue normally as if it had not sent the 311 LB-Request attribute. 313 4. LB-Response Attribute 315 When the server receives a Status-Server packet from the NAS and it 316 contains an LB-Request attribute it SHOULD respond with a Status- 317 Server message that contains an LB-Response attribute. In scenarios 318 where the administrator does not want to convey load-balancer 319 information to the NAS the RADIUS server MAY choose to not respond. 321 If the initial Status-Server message included attributes other than 322 the LB-Request attribute the server MAY choose to respond but simply 323 omit the LB-Response attribute. 325 4.1. LB-Response Attribute Format 327 The Attributes field in the RADIUS message shall be arranged as 328 follows. 330 0 1 2 331 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 333 | Type=191 | Length | Server_Info ... 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 336 Figure 4 338 Type 339 191 for Status-Server Load Balancing. 341 Length 342 >= 3 344 The length field calculates the length in octets of the Type field, 345 Length field, and the concatenation of all the server_info PDUs. 347 Server_Info 348 The String field is one or more server_info PDUs. Each PDU defines 349 the status of a single server and its defining characteristics. 351 5. The SVR-Record TLV 353 The SVR-Record (Server Record) TLV is a family of Type-Length-Value 354 attributes that holds multiple sub-attributes as described in 355 Section 5. Each SVR-Record type supports a particular address 356 family. SVR-Record-IPv4 and SVR-Record-IPv6 are defined in this 357 document. Other address families may be supported by future 358 standards. 360 In order to support more than six SVR-Records in one RADIUS packet 361 these attributes are allocated in the Long-Extended-Type Attribute 362 defined in [RFC6929]. 364 5.1. SVR-Record-IPv4 366 Description 367 This attribute indicates a SVR-Record that contains information 368 about an IPv4 RADIUS server. This attribute conforms to the TLV- 369 Data type described in [RFC8044]. 371 A summary of the SVR-Record_ipv4 Attribute format is shown below. 372 The fields are transmitted from left to right. 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | TLV-Type | TLV-Length | TLV-Data ... 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 Figure 5 382 Type 383 245.TBD1 for SVR-Record-IPv4. 385 Length 386 The TLV-Length field is one octet and indicates the length of this 387 TLV, including the TLV-Type, TLV-Length, and TLV-Value fields. It 388 MUST have a value between 3 and 255. If a client or server 389 receives a TLV with an invalid TLV-Length, then the attribute that 390 encapsulates that TLV MUST be considered to be an invalid attribute 391 and is handled as per [RFC6929], Section 2.8. 393 TLVs having a TLV-Length of two (2) MUST NOT be sent; omit the 394 entire TLV instead. 396 TLV-Data 397 The TLV-Data for the SVR-Record-IPv6 attribute indicates the usage 398 of one RADIUS server that has an IPv6 address. It must include 399 sub-attributes for LB-TTL, LB-priority, LB-Weight and LB-IPv4. 401 5.2. SVR-Record-IPv6 403 Description 404 This attribute indicates an SVR-Record that contains information 405 about an IPv6 RADIUS server. This attribute conforms to the TLV- 406 Data type described in RFC8044. 408 A summary of the SVR-Record-IPv6 Attribute format is shown below. 409 The fields are transmitted from left to right. 411 0 1 2 3 412 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | TLV-Type | TLV-Length | TLV-Data ... 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Figure 6 419 Type 420 245.TBD2 for SVR-Record-IPv6. 422 Length 423 The TLV-Length field is one octet and indicates the length of this 424 TLV, including the TLV-Type, TLV-Length, and TLV-Value fields. It 425 MUST have a value between 3 and 255. If a client or server 426 receives a TLV with an invalid TLV-Length, then the attribute that 427 encapsulates that TLV MUST be considered to be an invalid attribute 428 and is handled as per [RFC6929], Section 2.8. 430 TLVs having a TLV-Length of two (2) MUST NOT be sent; omit the 431 entire TLV instead. 433 TLV-Data 434 The TLV-Data for the SVR-Record-IPv6 attribute indicates the usage 435 of one RADIUS server that has an IPv6 address. It must include 436 sub-attributes for LB-TTL, LB-priority, LB-Weight and LB-IPv6. 438 5.3. Table of Sub-Attributes 440 The following table provides a guide to which sub-attributes may be 441 found in which kinds of packets and in what quantity. 443 SVR-Record-IPv4 SVR-Record-IPv6 # Sub-Attribute 444 1 1 1 LB-TTL 445 1 1 2 LB-priority 446 1 1 3 LB-Weight 447 1 0 4 LB-IPv4 448 0 1 5 LB-IPv6 450 Figure 7 452 The following table defines the meaning of the above table entries. 454 0 This attribute MUST NOT be present in TLV. 455 0+ Zero or more instances of this attribute MAY be 456 present in packet. 457 0-1 Zero or one instance of this attribute MAY be present 458 in packet. 459 1 Exactly one instance of this attribute MUST 460 be present in packet. 462 Figure 8 464 6. Sub-Attributes Needed for SVR-Record TLV 466 The server_info field contains multiple SVR-Records. Each SVR-Record 467 will contain multiple sub-fields that are documented in this section. 469 6.1. LB-TTL 471 Description 472 This attribute indicates how long the NAS should consider the SVR- 473 Record valid. 475 A summary of the User-Name Attribute format is shown below. The 476 fields are transmitted from left to right. 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Type | Length | integer 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 integer (cont) | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Figure 9 488 Type 489 1 for LB-TTL 491 Length 492 6 494 integer 495 This field indicates the number of seconds this SVR-Record should 496 be in-use and considered valid. If the TTL is 0, the entry SHOULD 497 be removed from the cache immediately. If the value is 0xffffffff, 498 the recipient can decide locally how long to store the mapping. It 499 conforms to the integer data type specified in RFC8044. 501 6.2. LB-Priority 503 Description 504 This attribute indicates the priority of the SVR-Record. 506 A summary of the LB-priority Attribute format is shown below. The 507 fields are transmitted from left to right. 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Type | Length | integer 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 integer (cont) | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 Figure 10 519 Type 520 2 for LB-Priority 522 Length 523 6 525 integer 526 This field indicates the priority of this target host. A NAS MUST 527 attempt to use the target RADIUS server with the lowest-numbered 528 priority it can reach; target servers with the same priority SHOULD 529 be used in an order defined by the LB-Weight field. An SVR-Record 530 with a lower-numbered LB-priority should always used be before an 531 SVR-Record of a higher-numbered LB-priority, regardless of LB- 532 Weight. It conforms to the integer data type specified in RFC8044. 534 6.3. LB-Weight 536 Description 537 This attribute indicates the weighting of the SVR-Record relative 538 to other SVR-Record of the same priority. 540 A summary of the LB-Weight Attribute format is shown below. The 541 fields are transmitted from left to right. 543 0 1 2 3 544 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 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Type | Length | integer 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 integer (cont) | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 Figure 11 553 Type 554 3 for LB-Weight 556 Length 557 6 559 integer 560 The weight field specifies a relative weight for entries with the 561 same priority. Larger weights SHOULD be given a proportionately 562 higher probability of being used for AAA services. SVR-Record with 563 a lower-numbered LB-priority should always be used before SVR- 564 Record of a higher-numbered LB-priority, regardless of LB-Weight. 565 It conforms to the integer data type specified in RFC8044. 567 6.4. LB-IPv4 569 Description 570 This attribute indicates the IPv4 address of the SVR-Record. 572 A summary of the LB-IPv4 Attribute format is shown below. The 573 fields are transmitted from left to right. 575 0 1 2 3 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Type | Length | Address... 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 ... Address ... (cont) | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 Figure 12 585 Type 586 4 for LB-IPv4 588 Address 589 6 591 Address 592 This is the IPv4 address of the SVR-Record. While taking into 593 consideration the LB-priority and LB-Weight attributes the NAS 594 SHOULD attempt to use this address as a RADIUS server. All 595 considerations for client and server authentication mechanisms MUST 596 still be observed. It conforms to the ipv4addr data type specified 597 in RFC8044. 599 6.5. LB-IPv6 601 Description 602 This attribute indicates the IPv6 address of the SVR-Record. 604 A summary of the LB-IPv6 Attribute format is shown below. The 605 fields are transmitted from left to right. 607 0 1 2 3 608 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 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Type | Length | Address... 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 ... Address ... 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 ... Address ... 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 ... Address ... 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 ... Address ... | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 Figure 13 623 Type 624 5 for LB-IPv4 626 Length 627 18 629 Address 630 This is the IPv6 address of the SVR-Record. While taking into 631 consideration the LB-priority and LB-Weight attributes the NAS 632 SHOULD attempt to use this address as a RADIUS server. All 633 considerations for client and server authentication mechanisms MUST 634 still be observed. It conforms to the ipv6addr data type specified 635 in RFC8044. 637 7. Load Balancing Rules 639 When there are multiple SVR-Records available with the same LB- 640 priority, a non-zero weight, and excluding those SVR-Records with an 641 inferior LB-priority, the NAS MUST distribute the AAA messages across 642 those servers. 644 7.1. Session-Based Load Balancing 646 RADIUS servers may cache user data after retrieving that data from a 647 back-end database. If a NAS queries a RADIUS server for a particular 648 user the server cache will be populated. If the NAS then uses the 649 same RADIUS server for subsequent queries for the same user it will 650 represent a cache hit. Sending the query to a different RADIUS 651 server may represent a cache miss. A cache miss may be an expensive 652 operation in terms of time and other server resources. Under these 653 Status-Server-LB rules the NAS MUST send all RADIUS messages relative 654 to a particular session to the same RADIUS server to maximize the 655 probability of a cache-hit. 657 A NAS may terminate multiple sessions from multiple calling-stations. 658 It SHOULD use whatever means is available from the conversation with 659 the calling-station to uniquely identify sessions. Examples include, 660 but are not limited to, the RADIUS attributes User Name and Calling- 661 Station-Id. 663 7.2. Load Balancing Weight 665 The weight field specifies a relative weight for entries with the 666 same priority. Larger weights SHOULD be given a proportionately 667 higher probability of being used for AAA services. The NAS should 668 attempt to maintain the proper distribution of sessions based on LB- 669 Weight, but MUST retain the properties of Session-Based Load 670 Balancing described in Section 7.1 672 8. Security Considerations 674 RADIUS Server Load Balancing has many of the same security 675 implications as the base RADIUS protocol. 677 8.1. Clear Text Transmission 679 The RADIUS protocol is unencrypted clear-text on the wire. The 680 Message-Authenticator attribute is required and protects the RADIUS 681 message from tampering, but it does not encrypt the data. The Server 682 Load Balance extensions to RADIUS do not communicate any user 683 identity information or user-authentication materials. Being able to 684 view the LB-Request or LB Response PDU in clear-text does not 685 compromise any of this data. 687 8.2. Reconnaissance 689 If an attacker could impersonate a NAS then they would be able to use 690 the LB-Request to gain a list of available RADIUS servers. This is 691 additional information the attacker may not have access to otherwise. 692 Each RADIUS message is authenticated with the Message-Authenticator 693 attribute, so the attacker would need access to the shared secret to 694 correctly submit a valid LB-Request. 696 8.3. MD5 698 The RADIUS Response Authenticator and the Message-Authenticator 699 attribute both rely on the integrity of the MD5 algorithm. If an 700 attacker is able to reverse-engineer the shared secret by using a 701 weakness in the MD5 algorithm, then the Message-Authenticator 702 attribute will no longer provide message integrity. 704 This document recommends the development of better mechanisms for 705 authenticating messages within the RADIUS protocol using more modern 706 encryption standards. 708 9. NAS identifying Initial RADIUS Servers 710 For a NAS to use the RADIUS Server Load Balancing service it must be 711 able to contact an initial RADIUS server. Options include static 712 configuration of an initial seed RADIUS server. Other 713 implementations may use a DNS SRV record of the form 714 _radius._udp.name. The format and use of the SRV record is described 715 in [RFC2782]. 717 Implementation-specific mechanisms may be employed but are generally 718 outside the scope of this document. 720 10. IANA Considerations 722 This implementation used Attribute 191 for the LB-Request and LB- 723 Response PDU. An official registration is requested from IANA. 725 The Vendor Specified Attribute 26 may be used to encapsulate the LB- 726 Request and LB-Response PDU where no vendor interoperability is 727 required. 729 11. References 731 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 732 Requirement Levels", BCP 14, RFC 2119, 733 DOI 10.17487/RFC2119, March 1997, 734 . 736 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 737 "Remote Authentication Dial In User Service (RADIUS)", 738 BCP 14, RFC 2865, DOI 10.17487/RFC2865, June 2000, 739 . 741 [RFC3579] Aboba, B., Calhoun, P., and W. Simpson, "RADIUS (Remote 742 Authentication Dial In User Service) Support For 743 Extensible Authentication Protocol (EAP)", BCP 14, 744 RFC 3579, DOI 10.17487/RFC3579, September 2003, 745 . 747 [RFC5997] Dekok, A., "Use of Status-Server Packets in the Remote 748 Authentication Dial In User Service (RADIUS) Protocol", 749 BCP 14, RFC RFC5997, DOI 10.17487/RFC5997, August 2010, 750 . 752 [RFC6929] Dekok, A., "Remote Authentication Dial-In User Service 753 (RADIUS) Protocol Extensions", BCP 14, RFC 6929, 754 DOI 10.17487/RFC6929, April 2013, 755 . 757 [RFC8044] Dekok, A., "Data Types in RADIUS", BCP 14, RFC 8044, 758 DOI 10.17487/RFC8044, January 2017, 759 . 761 Author's Address 763 Daniel Massameno (editor) 764 Yale University 765 150 Munson Street 766 New Haven, CT 06492 767 United States of America 769 Email: dan.massameno@yale.edu