idnits 2.17.1 draft-ietf-radext-status-server-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (16 December 2008) is 5609 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Note 1' is mentioned on line 929, but not defined ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Alan DeKok 3 INTERNET-DRAFT FreeRADIUS 4 Category: Proposed Standard 5 6 Expires: June 16, 2009 7 16 December 2008 9 Use of Status-Server Packets in the 10 Remote Authentication Dial In User Service (RADIUS) Protocol 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 This Internet-Draft will expire on June 16, 2009. 30 Copyright Notice 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Copyright (c) 2008 IETF Trust and the persons identified as the 36 document authors. All rights reserved. This document is subject to 37 BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 38 Documents (http://trustee.ietf.org/license-info) in effect on the 39 date of publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. 43 Abstract 45 RFC 2865 defines a Status-Server code for use in RADIUS, but labels 46 it as "Experimental" without further discussion. This document 47 describes a practical use for the Status-Server packet code, which is 48 to let clients query the status of a RADIUS server. These queries, 49 and responses (if any) enable the client to make more informed 50 decisions. The result is a more stable, and more robust RADIUS 51 architecture. 53 Table of Contents 55 1. Introduction ............................................. 4 56 1.1. Terminology ......................................... 4 57 1.2. Requirements Language ............................... 5 58 2. Problem Statement ........................................ 6 59 2.1. Overloading Access-Request .......................... 6 60 2.1.1. Recommendation against Access-Request .......... 7 61 2.2. Overloading Accounting-Request ...................... 7 62 2.2.1. Recommendation against Accounting-Request ...... 8 63 2.3. Status-Server as a Solution ......................... 8 64 2.3.1. Status-Server to the RADIUS Authentication port. 8 65 2.3.2. Status-Server to the RADIUS Accounting port .... 9 66 3. Packet Format ............................................ 9 67 3.1. Single definition for Status-Server ................. 11 68 4. Implementation notes ..................................... 11 69 4.1. Client Requirements ................................. 12 70 4.2. Server Requirements ................................. 14 71 4.3. More Robust Fail-over with Status-Server ............ 15 72 4.4. Proxy Server handling of Status-Server .............. 16 73 4.5. Realm Routing ....................................... 16 74 4.6. Management Information Base (MIB) Considerations .... 18 75 4.6.1. Interaction with RADIUS Server MIB modules ..... 18 76 4.6.2. Interaction with RADIUS Client MIB modules ..... 19 77 5. Additional considerations ................................ 19 78 5.1. Local site testing .................................. 19 79 5.2. RADIUS over reliable transports ..................... 21 80 5.3. Other uses for Status-Server ........................ 21 81 6. Table of Attributes ...................................... 21 82 7. Examples ................................................. 22 83 7.1. Minimal Query to Authentication Port ................ 22 84 7.2. Minimal Query to Accounting Port .................... 23 85 7.3. Verbose Query and Response .......................... 24 86 8. IANA Considerations ...................................... 25 87 9. Security Considerations .................................. 25 88 10. References .............................................. 25 89 10.1. Normative references ............................... 25 90 10.2. Informative references ............................. 25 92 1. Introduction 94 The RADIUS Working Group was formed in 1995 to document the protocol 95 of the same name, and created a number of standards surrounding the 96 protocol. It also defined experimental commands within the protocol, 97 without elaborating further on the potential uses of those commands. 98 One of the commands so defined was Status-Server ([RFC2865] Section 99 3.). 101 This document describes how some current implementations are using 102 Status-Server packets as a method for querying the status of a RADIUS 103 server. These queries do not otherwise affect the normal operation 104 of a server, and do not result in any side effects other than perhaps 105 incrementing an internal packet counter. 107 These queries are not intended to implement the application-layer 108 watchdog messages described in [RFC3539] Section 3.4. That document 109 describes Authentication, Authorization, and Accounting (AAA) 110 protocols that run over reliable transports which handle 111 retransmissions internally. Since RADIUS runs over the User Datagram 112 Protocol (UDP) rather than Transport Control Protocol (TCP), the full 113 watchdog mechanism is not applicable here. 115 The rest of this document is laid out as follows. Section 2 contains 116 the problem statement, and explanations as to why some possible 117 solutions can have unwanted side effects. Section 3 defines the 118 Status-Server packet format. Section 4 contains client and server 119 requirements, along with some implementation notes. Section 5 lists 120 additional considerations not covered in the other sections. The 121 remaining text contains a RADIUS table of attributes, and discusses 122 security considerations not covered elsewhere in the document. 124 1.1. Terminology 126 This document uses the following terms: 128 Network Access Server (NAS) 129 The device providing access to the network. Also known as the 130 Authenticator (in IEEE 802.1x terminology) or RADIUS client. 132 Home Server 133 A RADIUS server that is authoritative for user authorization and 134 authentication. 136 Proxy Server 137 A RADIUS server that acts as a Home Server to the NAS, but in turn 138 proxies the request to another Proxy Server, or to a Home Server. 140 silently discard 141 This means the implementation discards the packet without further 142 processing. The implementation MAY provide the capability of 143 logging the error, including the contents of the silently discarded 144 packet, and SHOULD record the event in a statistics counter. 146 1.2. Requirements Language 148 In this document, several words are used to signify the requirements 149 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 150 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 151 and "OPTIONAL" in this document are to be interpreted as described in 152 [RFC2119]. 154 2. Problem Statement 156 It is often useful to know if a RADIUS server is alive and responding 157 to requests. The most accurate way to obtain this information is to 158 query the server via application protocol traffic, as other methods 159 are either less accurate, or cannot be performed remotely. 161 The reasons for wanting to know the status of a server are many. The 162 administrator may simply be curious if the server is responding, and 163 may not have access to NAS or traffic data that would give him that 164 information. The queries may also be performed automatically by a 165 NAS or proxy server, which is configured to send packets to a RADIUS 166 server, and where that server may not be responding. That is, while 167 [RFC2865] Section 2.6 indicates that sending Keep-Alives is harmful, 168 it may be useful to send "Are you Alive" queries to a server once it 169 has been marked "dead" due to prior unresponsiveness. 171 The occasional query to a "dead" server offers little additional load 172 on the network or server, and permits clients to more quickly 173 discover when the server returns to a responsive state. Overall, 174 status queries can be a useful part of the deployment of a RADIUS 175 server. 177 2.1. Overloading Access-Request 179 One possible solution to the problem of querying server status is for 180 a NAS to send specially formed Access-Request packets to a RADIUS 181 server's authentication port. The NAS can then look for a response, 182 and use this information to determine if the server is active or 183 unresponsive. 185 However, the server may see the request as a normal login request for 186 a user, and conclude that a real user has logged onto that NAS. The 187 server may then perform actions that are undesirable for a simple 188 status query. The server may alternatively respond with an Access- 189 Challenge, indicating that it believes an extended authentication 190 conversation is necessary. 192 Another possibility is that the server responds with an Access- 193 Reject, indicating that the user is not authorized to gain access to 194 the network. As above, the server may also perform local site 195 actions, such as warning an administrator of failed login attempts. 196 The server may also delay the Access-Reject response, in the 197 traditional manner of rate-limiting failed authentication attempts. 198 This delay in response means that the querying administrator is 199 unsure as to whether or not the server is down, is slow to respond, 200 or is intentionally delaying its response to the query. 202 In addition, using Access-Request queries may mean that the server 203 may have local users configured whose sole reason for existence is to 204 enable these query requests. Unless the server's policy is designed 205 carefully, it may be possible for an attacker to use those 206 credentials to gain unauthorized network access. 208 We note that some NAS implementations currently use Access-Request 209 packets as described above, with a fixed (and non configurable) user 210 name and password. Implementation issues with that equipment means 211 that if a RADIUS server does not respond to those queries, it may be 212 marked as unresponsive by the NAS. This marking may happen even if 213 the server is actively responding to other Access-Requests from that 214 same NAS. This behavior is confusing to administrators who then need 215 to determine why an active server has been marked as "unresponsive". 217 2.1.1. Recommendation against Access-Request 219 For the reasons outlined above, NAS implementors SHOULD NOT generate 220 Access-Request packets solely to see if a server is alive. 221 Similarly, site administrators SHOULD NOT configure test users whose 222 sole reason for existence is to enable such queries via Access- 223 Request packets. 225 Note that it still may be useful to configure test users for the 226 purpose of performing end-to-end or in-depth testing of a servers 227 policy. While this practice is widespread, we caution administrators 228 to use it with care. 230 2.2. Overloading Accounting-Request 232 A similar solution for the problem of querying server status may be 233 for a NAS to send specially formed Accounting-Request packets to a 234 RADIUS servers accounting port. The NAS can then look for a 235 response, and use this information to determine if the server is 236 active or unresponsive. 238 As seen above with Access-Request, the server may then conclude that 239 a real user has logged onto a NAS, and perform local site actions 240 that are undesirable for a simple status query. 242 Another consideration is that some attributes are mandatory to 243 include in an Accounting-Request. This requirement forces the 244 administrator to query an accounting server with fake values for 245 those attributes in a test packet. These fake values increase the 246 work required to perform a simple query, and may pollute the server's 247 accounting database with incorrect data. 249 2.2.1. Recommendation against Accounting-Request 251 For the reasons outlined above, NAS implementors SHOULD NOT generate 252 Accounting-Request packets solely to see if a server is alive. 253 Similarly, site administrators SHOULD NOT configure accounting 254 policies whose sole reason for existence is to enable such queries 255 via Accounting-Request packets. 257 Note that it still may be useful to configure test users for the 258 purpose of performing end-to-end or in-depth testing of a servers 259 policy. While this practice is widespread, we caution administrators 260 to use it with care. 262 2.3. Status-Server as a Solution 264 A better solution to the above problems is to use the Status-Server 265 packet code. The name of the code leads us to conclude that it was 266 intended for packets that query the status of a server. Since the 267 packet is otherwise undefined, it does not cause interoperability 268 issues to create implementation-specific definitions for it. The 269 difficulty until now has been defining an interoperable method of 270 performing these queries. 272 This document addresses that need. 274 2.3.1. Status-Server to the RADIUS Authentication port 276 Status-Server SHOULD be used instead of Access-Request to query the 277 responsiveness of a server. In this use case, the protocol exchange 278 between client and server is similar to the usual exchange of Access- 279 Request and Access-Accept, as shown below. 281 NAS RADIUS server 282 --- ------------- 283 Status-Server/ 284 Message-Authenticator -> 285 <- Access-Accept/ 286 Reply-Message 288 The Status-Server packet MUST contain a Message-Authenticator 289 attribute for security. The response (if any) to a Status-Server 290 packet sent to an authentication port SHOULD be an Access-Accept 291 packet. Other response packet codes are NOT RECOMMENDED. The list 292 of attributes that are permitted in the Access-Accept packet is given 293 in the Table of Attributes in Section 6, below. 295 2.3.2. Status-Server to the RADIUS Accounting port 297 Status-Server MAY be used instead of Accounting-Request to query the 298 responsiveness of a server. In this use case, the protocol exchange 299 between client and server is similar to the usual exchange of 300 Accounting-Request and Accounting-Response, as shown below. 302 NAS RADIUS server 303 --- ------------- 304 Status-Server/ 305 Message-Authenticator -> 306 <- Accounting-Response 308 The Status-Server packet MUST contain a Message-Authenticator 309 attribute for security. The response (if any) to a Status-Server 310 packet sent to an accounting port SHOULD be an Accounting-Response 311 packet. Other response packet codes are NOT RECOMMENDED. The list 312 of attributes that are permitted in the Accounting-Response packet is 313 given in the Table of Attributes in Section 6, below. 315 3. Packet Format 317 Status-Server packets reuse the RADIUS packet format, with the fields 318 and values for those fields as defined [RFC2865] Section 3. We do 319 not include all of the text or diagrams of that section here, but 320 instead explain the differences required to implement Status-Server. 322 The Authenticator field of Status-Server packets MUST be generated 323 using the same method as that used for the Request Authenticator 324 field of Access-Request packets, as given below. 326 The role of the Identifier field is the same for Status-Server as for 327 other packets. However, as Status-Server is taking the role of 328 Access-Request or Accounting-Request packets, there is the potential 329 for Status-Server requests to be in conflict with Access-Request or 330 Accounting-Request packets with the same Identifier. In Section 4.2, 331 below, we describe a method for avoiding these problems. This method 332 MUST be used to avoid conflicts between Status-Server and other 333 packet types. 335 Request Authenticator 337 In Status-Server Packets, the Authenticator value is a 16 octet 338 random number, called the Request Authenticator. The value 339 SHOULD be unpredictable and unique over the lifetime of a 340 secret (the password shared between the client and the RADIUS 341 server), since repetition of a request value in conjunction 342 with the same secret would permit an attacker to reply with a 343 previously intercepted response. Since it is expected that the 344 same secret MAY be used to authenticate with servers in 345 disparate geographic regions, the Request Authenticator field 346 SHOULD exhibit global and temporal uniqueness. 348 The Request Authenticator value in a Status-Server packet 349 SHOULD also be unpredictable, lest an attacker trick a server 350 into responding to a predicted future request, and then use the 351 response to masquerade as that server to a future Status-Server 352 request from a client. 354 Similarly, the Response Authenticator field of an Access-Accept 355 packet sent in response to Status-Server queries MUST be generated 356 using the same method as used for for calculating the Response 357 Authenticator of the Access-Accept sent in response to an Access- 358 Request, with the Status-Server Request Authenticator taking the 359 place of the Access-Request Request Authenticator. 361 The Response Authenticator field of an Accounting-Response packet 362 sent in response to Status-Server queries MUST be generated using the 363 same method as used for for calculating the Response Authenticator of 364 the Accounting-Response sent in response to an Accounting-Request, 365 with the Status-Server Request Authenticator taking the place of the 366 Accounting-Request Request Authenticator. 368 Note that when a server responds to a Status-Server request, it MUST 369 NOT send more than one response packet. 371 Response Authenticator 373 The value of the Authenticator field in Access-Accept, or 374 Accounting-Response packets is called the Response 375 Authenticator, and contains a one-way MD5 hash calculated over 376 a stream of octets consisting of: the RADIUS packet, beginning 377 with the Code field, including the Identifier, the Length, the 378 Request Authenticator field from the Status-Server packet, and 379 the response Attributes (if any), followed by the shared 380 secret. That is, ResponseAuth = 381 MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where + 382 denotes concatenation. 384 In addition to the above requirements, all Status-Server packets MUST 385 include a Message-Authenticator attribute. Failure to do so would 386 mean that the packets could be trivially spoofed. 388 Status-Server packets MAY include NAS-Identifier, and one of NAS-IP- 389 Address or NAS-IPv6-Address. These attributes are not necessary for 390 the operation of Status-Server, but may be useful information to a 391 server that receives those packets. 393 Other attributes SHOULD NOT be included in a Status-Server packet. 394 User authentication credentials such as User-Password, CHAP-Password, 395 EAP-Message, etc. MUST NOT appear in a Status-Server packet sent to a 396 RADIUS authentication port. User or NAS accounting attributes such 397 as Acct-Session-Id, Acct-Status-Type, Acct-Input-Octets, etc. MUST 398 NOT appear in a Status-Server packet sent to a RADIUS accounting 399 port. 401 The Access-Accept MAY contain a Reply-Message or Message- 402 Authenticator attribute. It SHOULD NOT contain other attributes. 403 The Accounting-Response packets sent in response to a Status-Server 404 query SHOULD NOT contain any attributes. As the intent is to 405 implement a simple query instead of user authentication or 406 accounting, there is little reason to include other attributes in 407 either the query or the corresponding response. 409 Examples of Status-Server packet flows are given below in Section 7. 411 3.1. Single definition for Status-Server 413 When sent to a RADIUS accounting port, contents of the Status-Server 414 packets are calculated as described above. That is, even though the 415 packets are being sent to an accounting port, they are not created 416 using the same method as for Accounting-Requests. This difference 417 has a number of benefits. 419 Having a single definition for Status-Server packets is simpler than 420 having different definitions for different destination ports. In 421 addition, if we were to define Status-Server as being similar to 422 Accounting-Request but containing no attributes, then those packets 423 could be trivially forged. 425 We therefore define Status-Server consistently, and vary the response 426 packets depending on the port to which the request is sent. When 427 sent to an authentication port, the response to a Status-Server query 428 is an Access-Accept packet. When sent to an accounting port, the 429 response to a Status-Server query is an Accounting-Response packet. 431 4. Implementation notes 433 There are a number of considerations to take into account when 434 implementing support for Status-Server. This section describes 435 implementation details and requirements for RADIUS clients and 436 servers that support Status-Server. 438 The following text applies to the authentication and accounting 439 ports. We use the generic terms below to simplify the discussion: 441 * Request packet 443 An Access-Request packet sent to an authentication port, or 444 an Accounting-Request packet sent to an accounting port 446 * Response packet 448 An Access-Accept, Access-Challenge, or Access-Reject packet sent 449 from an authentication port, or an Accounting-Response packet 450 sent from an accounting port. 452 We also refer to "client" as the originator of the Status-Server 453 packet, and "server" as the receiver of that packet, and the 454 originator of the Response packet. 456 Using generic terms to describe the Status-Server conversations is 457 simpler than duplicating the text for authentication, and accounting 458 packets. 460 4.1. Client Requirements 462 Clients SHOULD permit administrators to globally enable or disable 463 the generation of Status-Server packets. The default SHOULD be that 464 it is disabled. As it is undesirable to send queries to servers that 465 do not support Status-Server, clients SHOULD also have a per-server 466 configuration indicating whether or not to enable Status-Server for a 467 particular destination. The default SHOULD be that it is disabled. 469 The client SHOULD also have a configurable global timer (Tw) that is 470 used when sending periodic Status-Server queries during server fail- 471 over. The default value SHOULD be 30 seconds, and the value MUST NOT 472 be permitted to be set below 6 seconds. If a response has not been 473 received within the timeout period, the Status-Server packet is 474 deemed to have received no corresponding Response packet, and MUST be 475 discarded. 477 Clients SHOULD use a jitter of +/- 2 seconds when sending periodic 478 Status-Server packets, in order to avoid synchronization. 480 When Status-Server packets are sent from a client, they MUST NOT be 481 retransmitted. Instead, the Identity field MUST be changed every 482 time a packet is transmitted. The old packet should be discarded, 483 and a new Status-Server packet should be generated and sent, with new 484 Identity and Authenticator fields. 486 Clients MUST include the Message-Authenticator attribute in all 487 Status-Server packets. Failure to do so would mean that the packets 488 could be trivially spoofed, leading to potential denial of service 489 (DoS) attacks. Other attributes SHOULD NOT appear in a Status-Server 490 packet, except as outlined below in Section 6. As the intent of the 491 packet is a simple status query, there is little reason for any 492 additional attributes to appear in Status-Server packets. 494 The client MAY increment packet counters as a result of sending a 495 Status-Server request, or receiving a Response packet. The client 496 MUST NOT perform any other action that is normally performed when it 497 receives a Response packet, such as permitting a user to have login 498 access to a port. 500 Clients MAY send Status-Server requests to the RADIUS destination 501 ports from the same source port used to send normal Request packets. 502 Other clients MAY choose to send Status-Server requests from a unique 503 source port, that is not used to send Request packets. 505 The above suggestion for a unique source port for Status-Server 506 packets aids in matching responses to requests. Since the response 507 to a Status-Server packet is an Access-Accept or Accounting-Response 508 packet, those responses are indistinguishable from other packets sent 509 in response to a Request packet. Therefore, the best way to 510 distinguish them from other traffic is to have a unique port. 512 A client MAY send a Status-Server packet from a source port also used 513 to send Request packets. In that case, the Identifer field MUST be 514 unique across all outstanding Request packets for that source port, 515 independent of the value of the RADIUS Code field for those 516 outstanding requests. Once the client has either received a response 517 to the Status-Server packet, or has determined that the Status-Server 518 packet has timed out, it may reuse that Identifier in another packet. 520 Robust implementations SHOULD accept any Response packet as a valid 521 response to a Status-Server packet, subject to the validation 522 requirements defined above for the Response Authenticator. The code 523 field of the packet matters less than the fact that a valid, signed, 524 response has been received. 526 That is, prior to accepting the response as valid, the client should 527 check that the Response packet Code field is either Access-Accept (2) 528 or Accounting-Response (5). If the code does not match any of these 529 values, the packet MUST be silently discarded. The client MUST then 530 validate the Response Authenticator via the algorithm given above in 531 Section 3. If the Response Authenticator is not valid, the packet 532 MUST be silently discarded. If the Response Authenticator is valid, 533 then the packet MUST be deemed to be a valid response from the 534 server. 536 If the client instead discarded the response because the packet code 537 did not match what it expected, then it could erroneously discard 538 valid responses from a server, and mark that server as unresponsive. 539 This behavior would affect the stability of a RADIUS network, as 540 responsive servers would erroneously be marked as unresponsive. We 541 therefore recommend that clients should be liberal in what they 542 accept as responses to Status-Server queries. 544 4.2. Server Requirements 546 Servers SHOULD permit administrators to globally enable or disable 547 the acceptance of Status-Server packets. The default SHOULD be that 548 it is enabled. Servers SHOULD also permit adminstrators to enable or 549 disable acceptance of Status-Server packets on a per-client basis. 550 The default SHOULD be that it is enabled. 552 Status-Server packets originating from clients that are not permitted 553 to send the server Request packets MUST be silently discarded. If a 554 server does not support Status-Server packets, or is configured to 555 not respond to them, then it MUST silently discard the packet. 557 We note that [RFC2865] Section 3 defines a number of RADIUS Codes, 558 but does not make statements about which Codes are valid for port 559 1812. In contrast, [RFC2866] Section 3 specifies that only RADIUS 560 Accounting packets are to be sent to port 1813. This specification 561 is compatible with [RFC2865], as it uses a known Code for packets to 562 port 1812. This specification is not compatible with [RFC2866], as 563 it adds a new code (Status-Server) that is valid for port 1812. 564 However, as the category of [RFC2866] is Informational, this conflict 565 is acceptable. 567 Servers SHOULD silently discard Status-Server packets if they 568 determine that a client is sending too many Status-Server requests in 569 a particular time period. The method used by a server to make this 570 determination is implementation-specific, and out of scope for this 571 specification. 573 If a server supports Status-Server packets, and is configured to 574 respond to them, and receives a packet from a known client, it MUST 575 validate the Message-Authenticator attribute as defined in [RFC3579] 576 Section 3.2. Packets failing that validation MUST be silently 577 discarded. 579 Servers SHOULD NOT otherwise discard Status-Server packets if they 580 have recently sent the client a Response packet. The query may have 581 originated from an administrator who does not have access to the 582 Response packet stream, or who is interested in obtaining additional 583 information about the server. 585 The server MAY prioritize the handling of Status-Server packets over 586 the handling of other requests, subject to the rate limiting 587 described above. 589 The server MAY decide to not respond to a Status-Server, depending on 590 local site policy. For example, a server that is running but is 591 unable to perform its normal activities MAY silently discard Status- 592 Server packets. This situation can happen, for example, when a 593 server requires access to a database for normal operation, but the 594 connection to that database is down. Or, it may happen when the 595 accepted load on the server is lower than the offered load. 597 Some server implementations require that Access-Request packets are 598 accepted only on "authentication" ports, (e.g. 1812/udp), and that 599 Accounting-Request packets are accepted only on "accounting" ports 600 (e.g. 1813/udp). Those implementations SHOULD reply to Status-Server 601 packets sent to an "authentication" port with an Access-Accept 602 packet. Those implementations SHOULD reply to Status-Server packets 603 sent to an "accounting" port with an Accounting-Response packet. 605 Some server implementations accept both Access-Request and 606 Accounting-Request packets on the same port, and do not distinguish 607 between "authentication only" ports, and "accounting only" ports. 608 Those implementations SHOULD reply to Status-Server packets with an 609 Access-Accept packet. 611 The server MAY increment packet counters as a result of receiving a 612 Status-Server, or sending a Response packet. The server SHOULD NOT 613 perform any other action that is normally performed when it receives 614 a Request packet, other than sending a Response packet. 616 4.3. More Robust Fail-over with Status-Server 618 A common problem in RADIUS client implementations is the 619 implementation of a robust fail-over mechanism between servers. A 620 client may have multiple servers configured, with one server marked 621 as primary and another marked as secondary. If the client determines 622 that the primary is unresponsive, it can "fail over" to the 623 secondary, and send requests to the secondary instead of to the 624 primary. 626 However, it is difficult in standard RADIUS for a client to know when 627 it should start sending requests to the primary again. Sending test 628 Access-Requests or Accounting-Requests to see if the server is alive 629 has the issues outlined above in Section 2. Clients could 630 alternately send real traffic to the primary, on the hope that it is 631 responsive. If the server is still unresponsive, however, the result 632 may be user login failures. The Status-Server solution is an ideal 633 way to solve this problem. 635 When a client fails over from one server to another because of a lack 636 of responsiveness, it SHOULD send periodic Status-Server packets to 637 the unresponsive server, using the timer (Tw) defined above. 639 Once three time periods have passed where Status-Server packets have 640 been sent and responded to, the server should be deemed responsive 641 and RADIUS requests may sent to it again. This determination should 642 be made separately for each server that the client has a relationship 643 with. The same algorithm should be used for both authentication and 644 accounting ports. The client MUST treat each destination (ip, port) 645 combination as a unique server for the purposes of this 646 determination. 648 The above behavior is modelled after [RFC3539] Section 3.4.1. We 649 note that if a reliable transport is used for RADIUS, then the 650 algorithms specified in [RFC3539] MUST be used in preference to the 651 ones given here. 653 4.4. Proxy Server handling of Status-Server 655 Many RADIUS servers can act as proxy servers, and can forward 656 requests to home servers. Such servers MUST NOT proxy Status-Server 657 packets. The purpose of Status-Server as specified here is to permit 658 the client to query the responsiveness of a server that it has a 659 direct relationship with. Proxying Status-Server queries would 660 negate any usefulness that may be gained by implementing support for 661 them. 663 Proxy servers MAY be configured to respond to Status-Server queries 664 from clients, and MAY act as clients sending Status-Server queries to 665 other servers. However, those activities MUST be independent of one 666 another. 668 4.5. Realm Routing 670 RADIUS servers are commonly used in an environment where Network 671 Access Identifiers (NAIs) are used as routing identifiers [RFC4282]. 672 In this practice, the User-Name attribute is decorated with realm 673 routing information, commonly in the format of "user@realm". Since a 674 particular RADIUS server may act as a proxy for more than one realm, 675 the mechanism outlined above may be inadequate. 677 The schematic below demonstrates this scenario. 679 /-> Proxy Server P -----> Home Server for Realm A 680 / \ / 682 NAS X 683 \ / \ 684 \-> Proxy Server S -----> Home Server for Realm B 686 That is, the NAS has relationships with two Proxy Servers, P and S. 687 Each Proxy Server has relationships with Home Servers for both Realm 688 A and Realm B. 690 In this scenario, the Proxy Servers can determine if one or both of 691 the Home Servers are dead or unreachable. The NAS can determine if 692 one or both of the Proxy Servers are dead or unreachable. There is 693 an additional case to consider, however. 695 If Proxy Server P cannot reach the Home Server for Realm A, but the 696 Proxy Server S can reach that Home Server, then the NAS cannot 697 discover this information using the Status-Server queries as outlined 698 above. It would therefore be useful for the NAS to know that Realm A 699 is reachable from Proxy Server S, as it can then route all requests 700 for Realm A to that Proxy Server. Without this knowledge, the client 701 may route requests to Proxy Server P, where they may be discarded or 702 rejected. 704 To complicate matters, the behavior of Proxy Servers P and S in this 705 situation is not well defined. Some implementations simply fail to 706 respond to the request, and other implementations respond with an 707 Access-Reject. If the implementation fails to respond, then the NAS 708 cannot distinguish between the Proxy Server being down, or the next 709 server along the proxy chain being unreachable. 711 In the worst case, failures in routing for Realm A may affect users 712 of Realm B. For example, if Proxy Server P can reach Realm B but not 713 Realm A, and Proxy Server S can reach Realm A but not Realm B, then 714 active paths exist to handle all RADIUS requests. However, depending 715 on the NAS and Proxy Server implementation choices, the NAS may not 716 be able to determine which server requests may be sent to in order to 717 maintain network stability. 719 This problem cannot, unfortunately be solved by using Status-Server 720 requests. A robust solution would involve either a RADIUS routing 721 table for the NAI realms, or a RADIUS "destination unreachable" 722 response to authentication requests. Either solution would not fit 723 into the traditional RADIUS model, and both are therefore outside of 724 the scope of this specification. 726 The problem is discussed here in order to define how best to use 727 Status-Server in this situation, rather than to define a new 728 solution. 730 When a server has responded recently to a request from a client, that 731 client MUST mark the server as "responsive". In the above case, a 732 Proxy Server may be responding to requests destined for Realm A, but 733 not responding to requests destined for Realm B. The client 734 therefore considers the server to be responsive, as it is receiving 735 responses from the server. 737 The client will then continue to send requests to the Proxy Server 738 for destination Realm B, even though the Proxy Server cannot route 739 the requests to that destination. This failure is a known limitation 740 of RADIUS, and can be partially addressed through the use of failover 741 in the Proxy Servers. 743 A more realistic situation than the one outlined above is where each 744 Proxy Server also has multiple choices of Home Servers for a realm, 745 as outlined below. 747 /-> Proxy Server P -----> Home Server P 748 / \ / 749 NAS X 750 \ / \ 751 \-> Proxy Server S -----> Home Server S 753 In this situation, if all participants implement Status-Server as 754 defined herein, any one link may be broken, and all requests from the 755 NAS will still reach a home server. If two links are broken at 756 different places, (i.e. not both links from the NAS), then all 757 requests from the NAS will still reach a home server. In many 758 situations where three or more links are broken, then requests from 759 the NAS may still reach a home server. 761 It is RECOMMENDED, therefore, that implementations desiring the most 762 benefit from Status-Server also implement server failover. The 763 combination of these two practices will maximize network reliability 764 and stability. 766 4.6. Management Information Base (MIB) Considerations 768 4.6.1. Interaction with RADIUS Server MIB modules 770 Since Status-Server packets are sent to the defined RADIUS ports, 771 they can affect the [RFC4669] and [RFC4671] RADIUS server MIB 772 modules. [RFC4669] defines a counter named 773 radiusAuthServTotalUnknownTypes, that counts "The number of RADIUS 774 packets of unknown type that were received". [RFC4671] defines a 775 similar counter named radiusAcctServTotalUnknownTypes. 776 Implementations not supporting Status-Server, or implementations that 777 are configured to not respond to Status-Server packets MUST use these 778 counters to track received Status-Server packets. 780 If, however, Status-Server is supported and the server is configured 781 to respond as described above, then the counters defined in [RFC4669] 782 and [RFC4671] MUST NOT be used to track Status-Server requests or 783 responses to those requests. That is, when a server fully implements 784 Status-Server, the counters defined in [RFC4669] and [RFC4671] MUST 785 be unaffected by the transmission or reception of packets relating to 786 Status-Server. 788 If a server supports Status-Server and the [RFC4669] or [RFC4671] MIB 789 Modules, then it SHOULD also support vendor-specific MIB extensions 790 dedicated solely to tracking Status-Server requests and responses. 791 Any definition of the server MIB modules for Status-Server is outside 792 of the scope of this document. 794 4.6.2. Interaction with RADIUS Client MIB modules 796 Clients implementing Status-Server MUST NOT increment [RFC4668] or 797 [RFC4670] counters upon reception of Response packets to Status- 798 Server queries. That is, when a server fully implements Status- 799 Server, the counters defined in [RFC4668] and [RFC4670] MUST be 800 unaffected by the transmission or reception of packets relating to 801 Status-Server. 803 If an implementation supports Status-Server and the [RFC4668] or 804 [RFC4670] MIB modules, then it SHOULD also support vendor-specific 805 MIB extensions containing similar information as those MIB modules, 806 but which are instead dedicated solely to tracking Status-Server 807 requests and responses. Any definition of the client MIB module 808 extensions for Status-Server is outside of the scope of this 809 document. 811 5. Additional considerations 813 There are additional topics related to the use of Status-Server that 814 may be covered. As those topics do not fit well into the preceding 815 sections, they are covered herein. 817 5.1. Local site testing 819 There is at least one situation where using Access-Request or 820 Accounting-Request packets may be useful, despite the recommendations 821 above in Section 2.1.1 and Section 2.2.1. That situation is local 822 site testing, where the RADIUS client, server, and user store are 823 under the control of a single administrator or administrative entity. 824 In that situation, administrators MAY configure a well-known "test" 825 user to enable local site testing. 827 The advantage to creating such a local user is that it is now 828 possible for the administrator to send a RADIUS request that performs 829 end-to-end testing of the RADIUS server. As above with Status- 830 Server, this testing includes RADIUS server responsiveness. It may 831 also include querying databases of user authentication credentials, 832 or storing accounting data to a billing database. The information 833 obtained from performing those queries is that the entire RADIUS 834 server infrastructure, including all of its dependencies, is 835 functioning as expected. These queries are most useful in 836 deployments where an administrator has internal RADIUS servers that 837 proxy to other internal RADIUS servers, such as for load balancing or 838 fail over. 840 If used, the names utilized for these test users SHOULD be difficult 841 to guess by an attacker. An Access-Request packet for a test user 842 otherwise should be treated as follows, depending on its origin: 844 o Packets from localhost (127.0.0.1 or ::1): RADIUS servers 845 SHOULD treat the request according to local site policy. 847 o Packets from NASes that normally originate Access-Request 848 packets (i.e. not proxy servers): RADIUS servers SHOULD respond 849 with an Access-Reject packet, as the use of Status-Server is 850 preferred. 852 o Packets from other machines controlled by the administrator: 853 RADIUS servers SHOULD treat the request according to local site 854 policy. 856 o Packets originating from machines not controlled by the 857 administrator: RADIUS servers MUST respond with an Access-Reject 858 packet. 860 If a RADIUS server is configured to support test users for 861 Accounting-Request packets, it MAY respond with an Accounting- 862 Response packet, independent of the origin of the request. However, 863 any subsequent analysis of the accounting data such as billing or 864 usage MUST NOT include the data for the test user. 866 If these recommendations are implemented, then it may be possible in 867 some situations to safely query a RADIUS server for responsiveness 868 using Access-Request or Accounting-Request packets. However, this 869 behavior is still NOT RECOMMENDED. 871 5.2. RADIUS over reliable transports 873 Although RADIUS has been assigned two TCP ports (1812/tcp and 874 1813/tcp) in addition to the commonly used UDP ports, there has been 875 as yet no specification for using TCP as a reliable transport for 876 RADIUS. If such a specification were to be created, then the 877 transport issues discussed in [RFC3539] would apply. 879 Further, when RADIUS is run over reliable transports, the watchdog 880 algorithm described in [RFC3539] Section 3.4 MUST be used rather than 881 the algorithm described above. For the reasons outlined above in 882 Section 2, Status-Server packets SHOULD be used as the watchdog 883 request, in preference to Access-Request or Accounting-Request 884 packets. 886 Clients sending Status-Server over reliable transport MUST ensure 887 that the Identifier field is unique for all requests on a particular 888 connection, independent of the packet code. That is, if a Status- 889 Server with a particular value in the Identifier field is sent to a 890 server, the client MUST NOT simultaneously send an Access-Request or 891 Accounting-Request packet with that same Identifier value, on that 892 connection. Once the client has either received a response to the 893 Status-Server packet, or has determined that the Status-Server packet 894 has timed out, it may reuse that Identifier in another packet. 896 5.3. Other uses for Status-Server 898 While other uses of Status-Server are possible, uses beyond those 899 specified here are beyond the scope of this document. It may be 900 tempting to increase the utility of Status-Server by having the 901 responses carry additional information, but implementors are warned 902 that such uses have not been analyzed for potential security issues 903 or network problems. 905 Specifically, it may seem useful to leverage a combination of Status- 906 Server and CoA ports in order to send realm routing information 907 "upstream" from the home servers to the proxy servers, and finally to 908 the NAS. This use of Status-Server is NOT RECOMMENDED, as there has 909 been insufficient analysis and deployment experience to know if it is 910 useful, or even if it makes the network less reliable. 912 6. Table of Attributes 914 The following table provides a guide to which attributes may be found 915 in Status-Server packets, and in what quantity. Attributes other 916 than the ones listed below SHOULD NOT be found in a Status-Server 917 packet. 919 Status- Access- Accounting- 920 Server Accept Response # Attribute 922 0-1 0 0 4 NAS-IP-Address [Note 1] 923 0 0+ 0 18 Reply-Message 924 0+ 0+ 0+ 26 Vendor-Specific 925 0-1 0 0 32 NAS-Identifier [Note 1] 926 1 0-1 0-1 80 Message-Authenticator 927 0-1 0 0 95 NAS-IPv6-Address [Note 1] 929 [Note 1] A Status-Server SHOULD contain one of (NAS-IP-Address or 930 NAS-IPv6-Address), or NAS-Identifier, or both NAS-Identifier and one 931 of (NAS-IP-Address or NAS-IPv6-Address). 933 The following table defines the meaning of the above table entries. 935 0 This attribute MUST NOT be present in packet. 936 0+ Zero or more instances of this attribute MAY be present in packet. 937 0-1 Zero or one instance of this attribute MAY be present in packet. 938 1 Exactly one instance of this attribute MUST be present in packet. 940 7. Examples 942 A few examples are presented to illustrate the flow of packets to 943 both the authentication and accounting ports. These examples are not 944 intended to be exhaustive, many others are possible. Hexadecimal 945 dumps of the example packets are given in network byte order, using 946 the shared secret "xyzzy5461". 948 7.1. Minimal Query to Authentication Port 950 The NAS sends a Status-Server UDP packet with minimal content to a 951 RADIUS server on port 1812. 953 The Request Authenticator is a 16 octet random number generated by 954 the NAS. Message-Authenticator is included in order to authenticate 955 that the request came from a known client. 957 0c da 00 26 8a 54 f4 68 6f b3 94 c5 28 66 e3 02 958 18 5d 06 23 50 12 5a 66 5e 2e 1e 84 11 f3 e2 43 959 82 20 97 c8 4f a3 961 1 Code = Status-Server (12) 962 1 ID = 218 963 2 Length = 38 964 16 Request Authenticator 965 Attributes: 966 18 Message-Authenticator (80) = 5a665e2e1e8411f3e243822097c84fa3 968 The Response Authenticator is a 16 octet MD5 checksum of the code 969 (2), id (218), Length (20), the Request Authenticator from above, and 970 the shared secret. 972 02 da 00 14 ef 0d 55 2a 4b f2 d6 93 ec 2b 6f e8 973 b5 41 1d 66 975 1 Code = Access-Accept (2) 976 1 ID = 218 977 2 Length = 20 978 16 Request Authenticator 980 Attributes: 981 None. 983 7.2. Minimal Query to Accounting Port 985 The NAS sends a Status-Server UDP packet with minimal content to a 986 RADIUS server on port 1813. 988 The Request Authenticator is a 16 octet random number generated by 989 the NAS. Message-Authenticator is included in order to authenticate 990 that the request came from a known client. 992 0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb 1d b7 993 ad 38 82 60 80 12 e8 d6 ea bd a9 10 87 5c d9 1f 994 da de 26 36 78 58 996 1 Code = Status-Server (12) 997 1 ID = 179 998 2 Length = 38 999 16 Request Authenticator 1001 Attributes: 1002 18 Message-Authenticator (80) = e8d6eabda910875cd91fdade26367858 1004 The Response Authenticator is a 16 octet MD5 checksum of the code 1005 (5), id (179), Length (20), the Request Authenticator from above, and 1006 the shared secret. 1008 02 b3 00 1a 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a 1009 48 60 66 9c 1011 1 Code = Accounting-Response (5) 1012 1 ID = 179 1013 2 Length = 20 16 Request Authenticator 1015 Attributes: 1016 None. 1018 7.3. Verbose Query and Response 1020 The NAS at 192.0.2.16 sends a Status-Server UDP packet to the RADIUS 1021 server on port 1812. 1023 The Request Authenticator is a 16 octet random number generated by 1024 the NAS. 1026 0c 47 00 2c bf 58 de 56 ae 40 8a d3 b7 0c 85 13 1027 f9 b0 3f be 04 06 c0 00 02 10 50 12 85 2d 6f ec 1028 61 e7 ed 74 b8 e3 2d ac 2f 2a 5f b2 1030 1 Code = Status-Server (12) 1031 1 ID = 71 1032 2 Length = 44 1033 16 Request Authenticator 1035 Attributes: 1036 6 NAS-IP-Address (4) = 192.0.2.16 1037 18 Message-Authenticator (80) = 852d6fec61e7ed74b8e32dac2f2a5fb2 1039 The Response Authenticator is a 16-octet MD5 checksum of the code 1040 (2), id (71), Length (52), the Request Authenticator from above, the 1041 attributes in this reply, and the shared secret. 1043 The Reply-Message is "RADIUS Server up 2 days, 18:40" 1045 02 47 00 34 46 f4 3e 62 fd 03 54 42 4c bb eb fd 1046 6d 21 4e 06 12 20 52 41 44 49 55 53 20 53 65 72 1047 76 65 72 20 75 70 20 32 20 64 61 79 73 2c 20 31 1048 38 3a 34 30 1050 1 Code = Access-Accept (2) 1051 1 ID = 71 1052 2 Length = 52 1053 16 Request Authenticator 1055 Attributes: 1056 32 Reply-Message (18) 1058 8. IANA Considerations 1060 This specification does not create any new registries, nor does it 1061 require assignment of any protocol parameters. 1063 9. Security Considerations 1065 This document defines the Status-Server packet as being similar in 1066 treatment to the Access-Request packet, and is therefore subject to 1067 the same security considerations as described in [RFC2865], Section 1068 8. Status-Server packets also use the Message-Authenticator 1069 attribute, and are therefore subject to the same security 1070 considerations as [RFC3579], Section 4. 1072 We reiterate that Status-Server packets MUST contain a Message- 1073 Authenticator attribute. Early implementations supporting Status- 1074 Server did not enforce this requirement, and may have been vulnerable 1075 to DoS attacks as a result. 1077 Where this document differs from [RFC2865] is that it defines a new 1078 request/response method in RADIUS; the Status-Server request. As 1079 this use is based on previously described and implemented standards, 1080 we know of no additional security considerations that arise from the 1081 use of Status-Server as defined herein. 1083 10. References 1085 10.1. Normative references 1087 [RFC2865] 1088 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 1089 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 1091 [RFC4282] 1092 Aboba, B., and Beadles, M. at al, "The Network Access Identifier", 1093 RFC 4282, December 2005. 1095 10.2. Informative references 1097 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1098 Requirement Levels", RFC 2119, March, 1997. 1100 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1102 [RFC3539] Aboba, B., Wood, J., "Authentication, Authorization, and 1103 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 1105 [RFC3579] Aboba, B., Calhoun, P., "RADIUS (Remote Authentication Dial In 1106 User Service) Support For Extensible Authentication Protocol 1107 (EAP)", RFC 3579, September 2003. 1109 [RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6", RFC 1110 4668, August 2006. 1112 [RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6", RFC 1113 4669, August 2006. 1115 [RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC 4670, 1116 August 2006. 1118 [RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC 4671, 1119 August 2006. 1121 Acknowledgments 1123 Parts of the text in Section 3 defining the Request and Response 1124 Authenticators were taken with minor edits from [RFC2865] Section 3. 1126 The author would like to thank Mike McCauley of Open Systems 1127 Consultants for making a Radiator server available for 1128 interoperability testing. 1130 Authors' Addresses 1132 Alan DeKok 1133 The FreeRADIUS Server Project 1134 http://freeradius.org 1136 Email: aland@freeradius.org