idnits 2.17.1 draft-ietf-radext-status-server-04.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? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (1 March 2009) is 5534 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Note 1' is mentioned on line 833, but not defined ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: Informational 5 6 Expires: September 1, 2009 7 1 March 2009 9 Use of Status-Server Packets in the 10 Remote Authentication Dial In User Service (RADIUS) Protocol 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 1, 2009. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 RFC 2865 defines a Status-Server code for use in RADIUS, but labels 57 it as "Experimental" without further discussion. This document 58 describes a practical use for the Status-Server packet code, which is 59 to let clients query the status of a RADIUS server. These queries, 60 and responses (if any) enable the client to make more informed 61 decisions. The result is a more stable, and more robust RADIUS 62 architecture. 64 Table of Contents 66 1. Introduction ............................................. 4 67 1.1. Terminology ......................................... 4 68 1.2. Requirements Language ............................... 5 69 2. Problem Statement ........................................ 6 70 2.1. Overloading Access-Request .......................... 6 71 2.1.1. Recommendation against Access-Request .......... 7 72 2.2. Overloading Accounting-Request ...................... 7 73 2.2.1. Recommendation against Accounting-Request ...... 8 74 2.3. Status-Server as a Solution ......................... 8 75 2.3.1. Status-Server to the RADIUS Authentication port 8 76 2.3.2. Status-Server to the RADIUS Accounting port .... 9 77 3. Packet Format ............................................ 9 78 3.1. Single definition for Status-Server ................. 11 79 4. Implementation notes ..................................... 11 80 4.1. Client Requirements ................................. 12 81 4.2. Server Requirements ................................. 14 82 4.3. More Robust Fail-over with Status-Server ............ 15 83 4.4. Proxy Server handling of Status-Server .............. 16 84 4.5. Realm Routing ....................................... 16 85 4.6. Management Information Base (MIB) Considerations .... 18 86 4.6.1. Interaction with RADIUS Server MIB modules ..... 18 87 4.6.2. Interaction with RADIUS Client MIB modules ..... 19 88 5. Table of Attributes ...................................... 19 89 6. Examples ................................................. 20 90 6.1. Minimal Query to Authentication Port ................ 20 91 6.2. Minimal Query to Accounting Port .................... 21 92 6.3. Verbose Query and Response .......................... 22 93 7. IANA Considerations ...................................... 22 94 8. Security Considerations .................................. 23 95 9. References ............................................... 23 96 9.1. Normative references ................................ 23 97 9.2. Informative references .............................. 23 99 1. Introduction 101 The RADIUS Working Group was formed in 1995 to document the protocol 102 of the same name, and created a number of standards surrounding the 103 protocol. It also defined experimental commands within the protocol, 104 without elaborating further on the potential uses of those commands. 105 One of the commands so defined was Status-Server ([RFC2865] Section 106 3.). 108 This document describes how some current implementations are using 109 Status-Server packets as a method for querying the status of a RADIUS 110 server. These queries do not otherwise affect the normal operation 111 of a server, and do not result in any side effects other than perhaps 112 incrementing an internal packet counter. 114 These queries are not intended to implement the application-layer 115 watchdog messages described in [RFC3539] Section 3.4. That document 116 describes Authentication, Authorization, and Accounting (AAA) 117 protocols that run over reliable transports which handle 118 retransmissions internally. Since RADIUS runs over the User Datagram 119 Protocol (UDP) rather than Transport Control Protocol (TCP), the full 120 watchdog mechanism is not applicable here. 122 The rest of this document is laid out as follows. Section 2 contains 123 the problem statement, and explanations as to why some possible 124 solutions can have unwanted side effects. Section 3 defines the 125 Status-Server packet format. Section 4 contains client and server 126 requirements, along with some implementation notes. Section 5 lists 127 additional considerations not covered in the other sections. The 128 remaining text contains a RADIUS table of attributes, and discusses 129 security considerations not covered elsewhere in the document. 131 1.1. Terminology 133 This document uses the following terms: 135 Network Access Server (NAS) 136 The device providing access to the network. Also known as the 137 Authenticator (in IEEE 802.1x terminology) or RADIUS client. 139 Home Server 140 A RADIUS server that is authoritative for user authorization and 141 authentication. 143 Proxy Server 144 A RADIUS server that acts as a Home Server to the NAS, but in turn 145 proxies the request to another Proxy Server, or to a Home Server. 147 silently discard 148 This means the implementation discards the packet without further 149 processing. The implementation MAY provide the capability of 150 logging the error, including the contents of the silently discarded 151 packet, and SHOULD record the event in a statistics counter. 153 1.2. Requirements Language 155 In this document, several words are used to signify the requirements 156 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 157 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 158 and "OPTIONAL" in this document are to be interpreted as described in 159 [RFC2119]. 161 2. Problem Statement 163 It is often useful to know if a RADIUS server is alive and responding 164 to requests. The most accurate way to obtain this information is to 165 query the server via application protocol traffic, as other methods 166 are either less accurate, or cannot be performed remotely. 168 The reasons for wanting to know the status of a server are many. The 169 administrator may simply be curious if the server is responding, and 170 may not have access to NAS or traffic data that would give him that 171 information. The queries may also be performed automatically by a 172 NAS or proxy server, which is configured to send packets to a RADIUS 173 server, and where that server may not be responding. That is, while 174 [RFC2865] Section 2.6 indicates that sending Keep-Alives is harmful, 175 it may be useful to send "Are you Alive" queries to a server once it 176 has been marked "dead" due to prior unresponsiveness. 178 The occasional query to a "dead" server offers little additional load 179 on the network or server, and permits clients to more quickly 180 discover when the server returns to a responsive state. Overall, 181 status queries can be a useful part of the deployment of a RADIUS 182 server. 184 2.1. Overloading Access-Request 186 One possible solution to the problem of querying server status is for 187 a NAS to send specially formed Access-Request packets to a RADIUS 188 server's authentication port. The NAS can then look for a response, 189 and use this information to determine if the server is active or 190 unresponsive. 192 However, the server may see the request as a normal login request for 193 a user, and conclude that a real user has logged onto that NAS. The 194 server may then perform actions that are undesirable for a simple 195 status query. The server may alternatively respond with an Access- 196 Challenge, indicating that it believes an extended authentication 197 conversation is necessary. 199 Another possibility is that the server responds with an Access- 200 Reject, indicating that the user is not authorized to gain access to 201 the network. As above, the server may also perform local site 202 actions, such as warning an administrator of failed login attempts. 203 The server may also delay the Access-Reject response, in the 204 traditional manner of rate-limiting failed authentication attempts. 205 This delay in response means that the querying administrator is 206 unsure as to whether or not the server is down, is slow to respond, 207 or is intentionally delaying its response to the query. 209 In addition, using Access-Request queries may mean that the server 210 may have local users configured whose sole reason for existence is to 211 enable these query requests. Unless the server's policy is designed 212 carefully, it may be possible for an attacker to use those 213 credentials to gain unauthorized network access. 215 We note that some NAS implementations currently use Access-Request 216 packets as described above, with a fixed (and non configurable) user 217 name and password. Implementation issues with that equipment means 218 that if a RADIUS server does not respond to those queries, it may be 219 marked as unresponsive by the NAS. This marking may happen even if 220 the server is actively responding to other Access-Requests from that 221 same NAS. This behavior is confusing to administrators who then need 222 to determine why an active server has been marked as "unresponsive". 224 2.1.1. Recommendation against Access-Request 226 For the reasons outlined above, NAS implementors SHOULD NOT generate 227 Access-Request packets solely to see if a server is alive. 228 Similarly, site administrators SHOULD NOT configure test users whose 229 sole reason for existence is to enable such queries via Access- 230 Request packets. 232 Note that it still may be useful to configure test users for the 233 purpose of performing end-to-end or in-depth testing of a servers 234 policy. While this practice is widespread, we caution administrators 235 to use it with care. 237 2.2. Overloading Accounting-Request 239 A similar solution for the problem of querying server status may be 240 for a NAS to send specially formed Accounting-Request packets to a 241 RADIUS servers accounting port. The NAS can then look for a 242 response, and use this information to determine if the server is 243 active or unresponsive. 245 As seen above with Access-Request, the server may then conclude that 246 a real user has logged onto a NAS, and perform local site actions 247 that are undesirable for a simple status query. 249 Another consideration is that some attributes are mandatory to 250 include in an Accounting-Request. This requirement forces the 251 administrator to query an accounting server with fake values for 252 those attributes in a test packet. These fake values increase the 253 work required to perform a simple query, and may pollute the server's 254 accounting database with incorrect data. 256 2.2.1. Recommendation against Accounting-Request 258 For the reasons outlined above, NAS implementors SHOULD NOT generate 259 Accounting-Request packets solely to see if a server is alive. 260 Similarly, site administrators SHOULD NOT configure accounting 261 policies whose sole reason for existence is to enable such queries 262 via Accounting-Request packets. 264 Note that it still may be useful to configure test users for the 265 purpose of performing end-to-end or in-depth testing of a servers 266 policy. While this practice is widespread, we caution administrators 267 to use it with care. 269 2.3. Status-Server as a Solution 271 A better solution to the above problems is to use the Status-Server 272 packet code. The name of the code leads us to conclude that it was 273 intended for packets that query the status of a server. Since the 274 packet is otherwise undefined, it does not cause interoperability 275 issues to create implementation-specific definitions for it. The 276 difficulty until now has been defining an interoperable method of 277 performing these queries. 279 This document addresses that need. 281 2.3.1. Status-Server to the RADIUS Authentication port 283 Status-Server SHOULD be used instead of Access-Request to query the 284 responsiveness of a server. In this use case, the protocol exchange 285 between client and server is similar to the usual exchange of Access- 286 Request and Access-Accept, as shown below. 288 NAS RADIUS server 289 --- ------------- 290 Status-Server/ 291 Message-Authenticator -> 292 <- Access-Accept/ 293 Reply-Message 295 The Status-Server packet MUST contain a Message-Authenticator 296 attribute for security. The response (if any) to a Status-Server 297 packet sent to an authentication port SHOULD be an Access-Accept 298 packet. Other response packet codes are NOT RECOMMENDED. The list 299 of attributes that are permitted in the Access-Accept packet is given 300 in the Table of Attributes in Section 6, below. 302 2.3.2. Status-Server to the RADIUS Accounting port 304 Status-Server MAY be used instead of Accounting-Request to query the 305 responsiveness of a server. In this use case, the protocol exchange 306 between client and server is similar to the usual exchange of 307 Accounting-Request and Accounting-Response, as shown below. 309 NAS RADIUS server 310 --- ------------- 311 Status-Server/ 312 Message-Authenticator -> 313 <- Accounting-Response 315 The Status-Server packet MUST contain a Message-Authenticator 316 attribute for security. The response (if any) to a Status-Server 317 packet sent to an accounting port SHOULD be an Accounting-Response 318 packet. Other response packet codes are NOT RECOMMENDED. The list 319 of attributes that are permitted in the Accounting-Response packet is 320 given in the Table of Attributes in Section 6, below. 322 3. Packet Format 324 Status-Server packets reuse the RADIUS packet format, with the fields 325 and values for those fields as defined [RFC2865] Section 3. We do 326 not include all of the text or diagrams of that section here, but 327 instead explain the differences required to implement Status-Server. 329 The Authenticator field of Status-Server packets MUST be generated 330 using the same method as that used for the Request Authenticator 331 field of Access-Request packets, as given below. 333 The role of the Identifier field is the same for Status-Server as for 334 other packets. However, as Status-Server is taking the role of 335 Access-Request or Accounting-Request packets, there is the potential 336 for Status-Server requests to be in conflict with Access-Request or 337 Accounting-Request packets with the same Identifier. In Section 4.2, 338 below, we describe a method for avoiding these problems. This method 339 MUST be used to avoid conflicts between Status-Server and other 340 packet types. 342 Request Authenticator 344 In Status-Server Packets, the Authenticator value is a 16 octet 345 random number, called the Request Authenticator. The value 346 SHOULD be unpredictable and unique over the lifetime of a 347 secret (the password shared between the client and the RADIUS 348 server), since repetition of a request value in conjunction 349 with the same secret would permit an attacker to reply with a 350 previously intercepted response. Since it is expected that the 351 same secret MAY be used to authenticate with servers in 352 disparate geographic regions, the Request Authenticator field 353 SHOULD exhibit global and temporal uniqueness. 355 The Request Authenticator value in a Status-Server packet 356 SHOULD also be unpredictable, lest an attacker trick a server 357 into responding to a predicted future request, and then use the 358 response to masquerade as that server to a future Status-Server 359 request from a client. 361 Similarly, the Response Authenticator field of an Access-Accept 362 packet sent in response to Status-Server queries MUST be generated 363 using the same method as used for for calculating the Response 364 Authenticator of the Access-Accept sent in response to an Access- 365 Request, with the Status-Server Request Authenticator taking the 366 place of the Access-Request Request Authenticator. 368 The Response Authenticator field of an Accounting-Response packet 369 sent in response to Status-Server queries MUST be generated using the 370 same method as used for for calculating the Response Authenticator of 371 the Accounting-Response sent in response to an Accounting-Request, 372 with the Status-Server Request Authenticator taking the place of the 373 Accounting-Request Request Authenticator. 375 Note that when a server responds to a Status-Server request, it MUST 376 NOT send more than one response packet. 378 Response Authenticator 380 The value of the Authenticator field in Access-Accept, or 381 Accounting-Response packets is called the Response 382 Authenticator, and contains a one-way MD5 hash calculated over 383 a stream of octets consisting of: the RADIUS packet, beginning 384 with the Code field, including the Identifier, the Length, the 385 Request Authenticator field from the Status-Server packet, and 386 the response Attributes (if any), followed by the shared 387 secret. That is, ResponseAuth = 388 MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where + 389 denotes concatenation. 391 In addition to the above requirements, all Status-Server packets MUST 392 include a Message-Authenticator attribute. Failure to do so would 393 mean that the packets could be trivially spoofed. 395 Status-Server packets MAY include NAS-Identifier, and one of NAS-IP- 396 Address or NAS-IPv6-Address. These attributes are not necessary for 397 the operation of Status-Server, but may be useful information to a 398 server that receives those packets. 400 Other attributes SHOULD NOT be included in a Status-Server packet. 401 User authentication credentials such as User-Password, CHAP-Password, 402 EAP-Message, etc. MUST NOT appear in a Status-Server packet sent to a 403 RADIUS authentication port. User or NAS accounting attributes such 404 as Acct-Session-Id, Acct-Status-Type, Acct-Input-Octets, etc. MUST 405 NOT appear in a Status-Server packet sent to a RADIUS accounting 406 port. 408 The Access-Accept MAY contain a Reply-Message or Message- 409 Authenticator attribute. It SHOULD NOT contain other attributes. 410 The Accounting-Response packets sent in response to a Status-Server 411 query SHOULD NOT contain any attributes. As the intent is to 412 implement a simple query instead of user authentication or 413 accounting, there is little reason to include other attributes in 414 either the query or the corresponding response. 416 Examples of Status-Server packet flows are given below in Section 7. 418 3.1. Single definition for Status-Server 420 When sent to a RADIUS accounting port, contents of the Status-Server 421 packets are calculated as described above. That is, even though the 422 packets are being sent to an accounting port, they are not created 423 using the same method as for Accounting-Requests. This difference 424 has a number of benefits. 426 Having a single definition for Status-Server packets is simpler than 427 having different definitions for different destination ports. In 428 addition, if we were to define Status-Server as being similar to 429 Accounting-Request but containing no attributes, then those packets 430 could be trivially forged. 432 We therefore define Status-Server consistently, and vary the response 433 packets depending on the port to which the request is sent. When 434 sent to an authentication port, the response to a Status-Server query 435 is an Access-Accept packet. When sent to an accounting port, the 436 response to a Status-Server query is an Accounting-Response packet. 438 4. Implementation notes 440 There are a number of considerations to take into account when 441 implementing support for Status-Server. This section describes 442 implementation details and requirements for RADIUS clients and 443 servers that support Status-Server. 445 The following text applies to the authentication and accounting 446 ports. We use the generic terms below to simplify the discussion: 448 * Request packet 450 An Access-Request packet sent to an authentication port, or 451 an Accounting-Request packet sent to an accounting port. 453 * Response packet 455 An Access-Accept, Access-Challenge, or Access-Reject packet sent 456 from an authentication port, or an Accounting-Response packet 457 sent from an accounting port. 459 We also refer to "client" as the originator of the Status-Server 460 packet, and "server" as the receiver of that packet, and the 461 originator of the Response packet. 463 Using generic terms to describe the Status-Server conversations is 464 simpler than duplicating the text for authentication and accounting 465 packets. 467 4.1. Client Requirements 469 Clients SHOULD permit administrators to globally enable or disable 470 the generation of Status-Server packets. The default SHOULD be that 471 it is disabled. As it is undesirable to send queries to servers that 472 do not support Status-Server, clients SHOULD also have a per-server 473 configuration indicating whether or not to enable Status-Server for a 474 particular destination. The default SHOULD be that it is disabled. 476 The client SHOULD also have a configurable global timer (Tw) that is 477 used when sending periodic Status-Server queries during server fail- 478 over. The default value SHOULD be 30 seconds, and the value MUST NOT 479 be permitted to be set below 6 seconds. If a response has not been 480 received within the timeout period, the Status-Server packet is 481 deemed to have received no corresponding Response packet, and MUST be 482 discarded. 484 Clients SHOULD use a jitter of +/- 2 seconds when sending periodic 485 Status-Server packets, in order to avoid synchronization. 487 When Status-Server packets are sent from a client, they MUST NOT be 488 retransmitted. Instead, the Identity field MUST be changed every 489 time a packet is transmitted. The old packet should be discarded, 490 and a new Status-Server packet should be generated and sent, with new 491 Identity and Authenticator fields. 493 Clients MUST include the Message-Authenticator attribute in all 494 Status-Server packets. Failure to do so would mean that the packets 495 could be trivially spoofed, leading to potential denial of service 496 (DoS) attacks. Other attributes SHOULD NOT appear in a Status-Server 497 packet, except as outlined below in Section 6. As the intent of the 498 packet is a simple status query, there is little reason for any 499 additional attributes to appear in Status-Server packets. 501 The client MAY increment packet counters as a result of sending a 502 Status-Server request, or receiving a Response packet. The client 503 MUST NOT perform any other action that is normally performed when it 504 receives a Response packet, such as permitting a user to have login 505 access to a port. 507 Clients MAY send Status-Server requests to the RADIUS destination 508 ports from the same source port used to send normal Request packets. 509 Other clients MAY choose to send Status-Server requests from a unique 510 source port, that is not used to send Request packets. 512 The above suggestion for a unique source port for Status-Server 513 packets aids in matching responses to requests. Since the response 514 to a Status-Server packet is an Access-Accept or Accounting-Response 515 packet, those responses are indistinguishable from other packets sent 516 in response to a Request packet. Therefore, the best way to 517 distinguish them from other traffic is to have a unique port. 519 A client MAY send a Status-Server packet from a source port also used 520 to send Request packets. In that case, the Identifer field MUST be 521 unique across all outstanding Request packets for that source port, 522 independent of the value of the RADIUS Code field for those 523 outstanding requests. Once the client has either received a response 524 to the Status-Server packet, or has determined that the Status-Server 525 packet has timed out, it may reuse that Identifier in another packet. 527 Robust implementations SHOULD accept any Response packet as a valid 528 response to a Status-Server packet, subject to the validation 529 requirements defined above for the Response Authenticator. The code 530 field of the packet matters less than the fact that a valid, signed, 531 response has been received. 533 That is, prior to accepting the response as valid, the client should 534 check that the Response packet Code field is either Access-Accept (2) 535 or Accounting-Response (5). If the code does not match any of these 536 values, the packet MUST be silently discarded. The client MUST then 537 validate the Response Authenticator via the algorithm given above in 538 Section 3. If the Response Authenticator is not valid, the packet 539 MUST be silently discarded. If the Response Authenticator is valid, 540 then the packet MUST be deemed to be a valid response from the 541 server. 543 If the client instead discarded the response because the packet code 544 did not match what it expected, then it could erroneously discard 545 valid responses from a server, and mark that server as unresponsive. 546 This behavior would affect the stability of a RADIUS network, as 547 responsive servers would erroneously be marked as unresponsive. We 548 therefore recommend that clients should be liberal in what they 549 accept as responses to Status-Server queries. 551 4.2. Server Requirements 553 Servers SHOULD permit administrators to globally enable or disable 554 the acceptance of Status-Server packets. The default SHOULD be that 555 it is enabled. Servers SHOULD also permit adminstrators to enable or 556 disable acceptance of Status-Server packets on a per-client basis. 557 The default SHOULD be that it is enabled. 559 Status-Server packets originating from clients that are not permitted 560 to send the server Request packets MUST be silently discarded. If a 561 server does not support Status-Server packets, or is configured to 562 not respond to them, then it MUST silently discard the packet. 564 We note that [RFC2865] Section 3 defines a number of RADIUS Codes, 565 but does not make statements about which Codes are valid for port 566 1812. In contrast, [RFC2866] Section 3 specifies that only RADIUS 567 Accounting packets are to be sent to port 1813. This specification 568 is compatible with [RFC2865], as it uses a known Code for packets to 569 port 1812. This specification is not compatible with [RFC2866], as 570 it adds a new code (Status-Server) that is valid for port 1812. 571 However, as the category of [RFC2866] is Informational, this conflict 572 is acceptable. 574 Servers SHOULD silently discard Status-Server packets if they 575 determine that a client is sending too many Status-Server requests in 576 a particular time period. The method used by a server to make this 577 determination is implementation-specific, and out of scope for this 578 specification. 580 If a server supports Status-Server packets, and is configured to 581 respond to them, and receives a packet from a known client, it MUST 582 validate the Message-Authenticator attribute as defined in [RFC3579] 583 Section 3.2. Packets failing that validation MUST be silently 584 discarded. 586 Servers SHOULD NOT otherwise discard Status-Server packets if they 587 have recently sent the client a Response packet. The query may have 588 originated from an administrator who does not have access to the 589 Response packet stream, or who is interested in obtaining additional 590 information about the server. 592 The server MAY prioritize the handling of Status-Server packets over 593 the handling of other requests, subject to the rate limiting 594 described above. 596 The server MAY decide to not respond to a Status-Server, depending on 597 local site policy. For example, a server that is running but is 598 unable to perform its normal activities MAY silently discard Status- 599 Server packets. This situation can happen, for example, when a 600 server requires access to a database for normal operation, but the 601 connection to that database is down. Or, it may happen when the 602 accepted load on the server is lower than the offered load. 604 Some server implementations require that Access-Request packets are 605 accepted only on "authentication" ports, (e.g. 1812/udp), and that 606 Accounting-Request packets are accepted only on "accounting" ports 607 (e.g. 1813/udp). Those implementations SHOULD reply to Status-Server 608 packets sent to an "authentication" port with an Access-Accept 609 packet. Those implementations SHOULD reply to Status-Server packets 610 sent to an "accounting" port with an Accounting-Response packet. 612 Some server implementations accept both Access-Request and 613 Accounting-Request packets on the same port, and do not distinguish 614 between "authentication only" ports, and "accounting only" ports. 615 Those implementations SHOULD reply to Status-Server packets with an 616 Access-Accept packet. 618 The server MAY increment packet counters as a result of receiving a 619 Status-Server, or sending a Response packet. The server SHOULD NOT 620 perform any other action that is normally performed when it receives 621 a Request packet, other than sending a Response packet. 623 4.3. More Robust Fail-over with Status-Server 625 A common problem in RADIUS client implementations is the 626 implementation of a robust fail-over mechanism between servers. A 627 client may have multiple servers configured, with one server marked 628 as primary and another marked as secondary. If the client determines 629 that the primary is unresponsive, it can "fail over" to the 630 secondary, and send requests to the secondary instead of to the 631 primary. 633 However, it is difficult in standard RADIUS for a client to know when 634 it should start sending requests to the primary again. Sending test 635 Access-Requests or Accounting-Requests to see if the server is alive 636 has the issues outlined above in Section 2. Clients could 637 alternately send real traffic to the primary, on the hope that it is 638 responsive. If the server is still unresponsive, however, the result 639 may be user login failures. The Status-Server solution is an ideal 640 way to solve this problem. 642 When a client fails over from one server to another because of a lack 643 of responsiveness, it SHOULD send periodic Status-Server packets to 644 the unresponsive server, using the timer (Tw) defined above. 646 Once three time periods have passed where Status-Server packets have 647 been sent and responded to, the server should be deemed responsive 648 and RADIUS requests may sent to it again. This determination should 649 be made separately for each server that the client has a relationship 650 with. The same algorithm should be used for both authentication and 651 accounting ports. The client MUST treat each destination (ip, port) 652 combination as a unique server for the purposes of this 653 determination. 655 The above behavior is modelled after [RFC3539] Section 3.4.1. We 656 note that if a reliable transport is used for RADIUS, then the 657 algorithms specified in [RFC3539] MUST be used in preference to the 658 ones given here. 660 4.4. Proxy Server handling of Status-Server 662 Many RADIUS servers can act as proxy servers, and can forward 663 requests to home servers. Such servers MUST NOT proxy Status-Server 664 packets. The purpose of Status-Server as specified here is to permit 665 the client to query the responsiveness of a server that it has a 666 direct relationship with. Proxying Status-Server queries would 667 negate any usefulness that may be gained by implementing support for 668 them. 670 Proxy servers MAY be configured to respond to Status-Server queries 671 from clients, and MAY act as clients sending Status-Server queries to 672 other servers. However, those activities MUST be independent of one 673 another. 675 4.5. Realm Routing 677 RADIUS servers are commonly used in an environment where Network 678 Access Identifiers (NAIs) are used as routing identifiers [RFC4282]. 679 In this practice, the User-Name attribute is decorated with realm 680 routing information, commonly in the format of "user@realm". Since a 681 particular RADIUS server may act as a proxy for more than one realm, 682 the mechanism outlined above may be inadequate. 684 The schematic below demonstrates this scenario. 686 /-> Proxy Server P -----> Home Server for Realm A 687 / \ / 689 NAS X 690 \ / \ 691 \-> Proxy Server S -----> Home Server for Realm B 693 That is, the NAS has relationships with two Proxy Servers, P and S. 694 Each Proxy Server has relationships with Home Servers for both Realm 695 A and Realm B. 697 In this scenario, the Proxy Servers can determine if one or both of 698 the Home Servers are dead or unreachable. The NAS can determine if 699 one or both of the Proxy Servers are dead or unreachable. There is 700 an additional case to consider, however. 702 If Proxy Server P cannot reach the Home Server for Realm A, but the 703 Proxy Server S can reach that Home Server, then the NAS cannot 704 discover this information using the Status-Server queries as outlined 705 above. It would therefore be useful for the NAS to know that Realm A 706 is reachable from Proxy Server S, as it can then route all requests 707 for Realm A to that Proxy Server. Without this knowledge, the client 708 may route requests to Proxy Server P, where they may be discarded or 709 rejected. 711 To complicate matters, the behavior of Proxy Servers P and S in this 712 situation is not well defined. Some implementations simply fail to 713 respond to the request, and other implementations respond with an 714 Access-Reject. If the implementation fails to respond, then the NAS 715 cannot distinguish between the Proxy Server being down, or the next 716 server along the proxy chain being unreachable. 718 In the worst case, failures in routing for Realm A may affect users 719 of Realm B. For example, if Proxy Server P can reach Realm B but not 720 Realm A, and Proxy Server S can reach Realm A but not Realm B, then 721 active paths exist to handle all RADIUS requests. However, depending 722 on the NAS and Proxy Server implementation choices, the NAS may not 723 be able to determine which server requests may be sent to in order to 724 maintain network stability. 726 This problem cannot, unfortunately be solved by using Status-Server 727 requests. A robust solution would involve either a RADIUS routing 728 table for the NAI realms, or a RADIUS "destination unreachable" 729 response to authentication requests. Either solution would not fit 730 into the traditional RADIUS model, and both are therefore outside of 731 the scope of this specification. 733 The problem is discussed here in order to define how best to use 734 Status-Server in this situation, rather than to define a new 735 solution. 737 When a server has responded recently to a request from a client, that 738 client MUST mark the server as "responsive". In the above case, a 739 Proxy Server may be responding to requests destined for Realm A, but 740 not responding to requests destined for Realm B. The client 741 therefore considers the server to be responsive, as it is receiving 742 responses from the server. 744 The client will then continue to send requests to the Proxy Server 745 for destination Realm B, even though the Proxy Server cannot route 746 the requests to that destination. This failure is a known limitation 747 of RADIUS, and can be partially addressed through the use of failover 748 in the Proxy Servers. 750 A more realistic situation than the one outlined above is where each 751 Proxy Server also has multiple choices of Home Servers for a realm, 752 as outlined below. 754 /-> Proxy Server P -----> Home Server P 755 / \ / 756 NAS X 757 \ / \ 758 \-> Proxy Server S -----> Home Server S 760 In this situation, if all participants implement Status-Server as 761 defined herein, any one link may be broken, and all requests from the 762 NAS will still reach a home server. If two links are broken at 763 different places, (i.e. not both links from the NAS), then all 764 requests from the NAS will still reach a home server. In many 765 situations where three or more links are broken, then requests from 766 the NAS may still reach a home server. 768 It is RECOMMENDED, therefore, that implementations desiring the most 769 benefit from Status-Server also implement server failover. The 770 combination of these two practices will maximize network reliability 771 and stability. 773 4.6. Management Information Base (MIB) Considerations 775 4.6.1. Interaction with RADIUS Server MIB modules 777 Since Status-Server packets are sent to the defined RADIUS ports, 778 they can affect the [RFC4669] and [RFC4671] RADIUS server MIB 779 modules. [RFC4669] defines a counter named 780 radiusAuthServTotalUnknownTypes that counts "The number of RADIUS 781 packets of unknown type that were received". [RFC4671] defines a 782 similar counter named radiusAcctServTotalUnknownTypes. 783 Implementations not supporting Status-Server, or implementations that 784 are configured to not respond to Status-Server packets MUST use these 785 counters to track received Status-Server packets. 787 If, however, Status-Server is supported and the server is configured 788 to respond as described above, then the counters defined in [RFC4669] 789 and [RFC4671] MUST NOT be used to track Status-Server requests or 790 responses to those requests. That is, when a server fully implements 791 Status-Server, the counters defined in [RFC4669] and [RFC4671] MUST 792 be unaffected by the transmission or reception of packets relating to 793 Status-Server. 795 If a server supports Status-Server and the [RFC4669] or [RFC4671] MIB 796 Modules, then it SHOULD also support vendor-specific MIB extensions 797 dedicated solely to tracking Status-Server requests and responses. 798 Any definition of the server MIB modules for Status-Server is outside 799 of the scope of this document. 801 4.6.2. Interaction with RADIUS Client MIB modules 803 Clients implementing Status-Server MUST NOT increment [RFC4668] or 804 [RFC4670] counters upon reception of Response packets to Status- 805 Server queries. That is, when a server fully implements Status- 806 Server, the counters defined in [RFC4668] and [RFC4670] MUST be 807 unaffected by the transmission or reception of packets relating to 808 Status-Server. 810 If an implementation supports Status-Server and the [RFC4668] or 811 [RFC4670] MIB modules, then it SHOULD also support vendor-specific 812 MIB extensions dedicated solely to tracking Status-Server requests 813 and responses. Any definition of the client MIB module extensions 814 for Status-Server is outside of the scope of this document. 816 5. Table of Attributes 818 The following table provides a guide to which attributes may be found 819 in Status-Server packets, and in what quantity. Attributes other 820 than the ones listed below SHOULD NOT be found in a Status-Server 821 packet. 823 Status- Access- Accounting- 824 Server Accept Response # Attribute 826 0-1 0 0 4 NAS-IP-Address [Note 1] 827 0 0+ 0 18 Reply-Message 828 0+ 0+ 0+ 26 Vendor-Specific 829 0-1 0 0 32 NAS-Identifier [Note 1] 830 1 0-1 0-1 80 Message-Authenticator 831 0-1 0 0 95 NAS-IPv6-Address [Note 1] 833 [Note 1] A Status-Server SHOULD contain one of (NAS-IP-Address or 834 NAS-IPv6-Address), or NAS-Identifier, or both NAS-Identifier and one 835 of (NAS-IP-Address or NAS-IPv6-Address). 837 The following table defines the meaning of the above table entries. 839 0 This attribute MUST NOT be present in packet. 840 0+ Zero or more instances of this attribute MAY be present in packet. 841 0-1 Zero or one instance of this attribute MAY be present in packet. 842 1 Exactly one instance of this attribute MUST be present in packet. 844 6. Examples 846 A few examples are presented to illustrate the flow of packets to 847 both the authentication and accounting ports. These examples are not 848 intended to be exhaustive, many others are possible. Hexadecimal 849 dumps of the example packets are given in network byte order, using 850 the shared secret "xyzzy5461". 852 6.1. Minimal Query to Authentication Port 854 The NAS sends a Status-Server UDP packet with minimal content to a 855 RADIUS server on port 1812. 857 The Request Authenticator is a 16 octet random number generated by 858 the NAS. Message-Authenticator is included in order to authenticate 859 that the request came from a known client. 861 0c da 00 26 8a 54 f4 68 6f b3 94 c5 28 66 e3 02 862 18 5d 06 23 50 12 5a 66 5e 2e 1e 84 11 f3 e2 43 863 82 20 97 c8 4f a3 865 1 Code = Status-Server (12) 866 1 ID = 218 867 2 Length = 38 868 16 Request Authenticator 870 Attributes: 871 18 Message-Authenticator (80) = 5a665e2e1e8411f3e243822097c84fa3 873 The Response Authenticator is a 16 octet MD5 checksum of the code 874 (2), id (218), Length (20), the Request Authenticator from above, and 875 the shared secret. 877 02 da 00 14 ef 0d 55 2a 4b f2 d6 93 ec 2b 6f e8 878 b5 41 1d 66 879 1 Code = Access-Accept (2) 880 1 ID = 218 881 2 Length = 20 882 16 Request Authenticator 884 Attributes: 885 None. 887 6.2. Minimal Query to Accounting Port 889 The NAS sends a Status-Server UDP packet with minimal content to a 890 RADIUS server on port 1813. 892 The Request Authenticator is a 16 octet random number generated by 893 the NAS. Message-Authenticator is included in order to authenticate 894 that the request came from a known client. 896 0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb 1d b7 897 ad 38 82 60 80 12 e8 d6 ea bd a9 10 87 5c d9 1f 898 da de 26 36 78 58 900 1 Code = Status-Server (12) 901 1 ID = 179 902 2 Length = 38 903 16 Request Authenticator 905 Attributes: 906 18 Message-Authenticator (80) = e8d6eabda910875cd91fdade26367858 908 The Response Authenticator is a 16 octet MD5 checksum of the code 909 (5), id (179), Length (20), the Request Authenticator from above, and 910 the shared secret. 912 02 b3 00 1a 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a 913 48 60 66 9c 915 1 Code = Accounting-Response (5) 916 1 ID = 179 917 2 Length = 20 16 Request Authenticator 919 Attributes: 920 None. 922 6.3. Verbose Query and Response 924 The NAS at 192.0.2.16 sends a Status-Server UDP packet to the RADIUS 925 server on port 1812. 927 The Request Authenticator is a 16 octet random number generated by 928 the NAS. 930 0c 47 00 2c bf 58 de 56 ae 40 8a d3 b7 0c 85 13 931 f9 b0 3f be 04 06 c0 00 02 10 50 12 85 2d 6f ec 932 61 e7 ed 74 b8 e3 2d ac 2f 2a 5f b2 934 1 Code = Status-Server (12) 935 1 ID = 71 936 2 Length = 44 937 16 Request Authenticator 939 Attributes: 940 6 NAS-IP-Address (4) = 192.0.2.16 941 18 Message-Authenticator (80) = 852d6fec61e7ed74b8e32dac2f2a5fb2 943 The Response Authenticator is a 16-octet MD5 checksum of the code 944 (2), id (71), Length (52), the Request Authenticator from above, the 945 attributes in this reply, and the shared secret. 947 The Reply-Message is "RADIUS Server up 2 days, 18:40" 949 02 47 00 34 46 f4 3e 62 fd 03 54 42 4c bb eb fd 950 6d 21 4e 06 12 20 52 41 44 49 55 53 20 53 65 72 951 76 65 72 20 75 70 20 32 20 64 61 79 73 2c 20 31 952 38 3a 34 30 954 1 Code = Access-Accept (2) 955 1 ID = 71 956 2 Length = 52 957 16 Request Authenticator 959 Attributes: 960 32 Reply-Message (18) 962 7. IANA Considerations 964 This specification does not create any new registries, nor does it 965 require assignment of any protocol parameters. 967 8. Security Considerations 969 This document defines the Status-Server packet as being similar in 970 treatment to the Access-Request packet, and is therefore subject to 971 the same security considerations as described in [RFC2865], Section 972 8. Status-Server packets also use the Message-Authenticator 973 attribute, and are therefore subject to the same security 974 considerations as [RFC3579], Section 4. 976 We reiterate that Status-Server packets MUST contain a Message- 977 Authenticator attribute. Early implementations supporting Status- 978 Server did not enforce this requirement, and may have been vulnerable 979 to DoS attacks as a result. 981 Where this document differs from [RFC2865] is that it defines a new 982 request/response method in RADIUS; the Status-Server request. As 983 this use is based on previously described and implemented standards, 984 we know of no additional security considerations that arise from the 985 use of Status-Server as defined herein. 987 9. References 989 9.1. Normative references 991 [RFC2865] 992 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 993 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 995 [RFC4282] 996 Aboba, B., and Beadles, M. at al, "The Network Access Identifier", 997 RFC 4282, December 2005. 999 9.2. Informative references 1001 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1002 Requirement Levels", RFC 2119, March, 1997. 1004 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1006 [RFC3539] Aboba, B., Wood, J., "Authentication, Authorization, and 1007 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 1009 [RFC3579] Aboba, B., Calhoun, P., "RADIUS (Remote Authentication Dial In 1010 User Service) Support For Extensible Authentication Protocol 1011 (EAP)", RFC 3579, September 2003. 1013 [RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6", RFC 1014 4668, August 2006. 1016 [RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6", RFC 1017 4669, August 2006. 1019 [RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC 4670, 1020 August 2006. 1022 [RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC 4671, 1023 August 2006. 1025 Acknowledgments 1027 Parts of the text in Section 3 defining the Request and Response 1028 Authenticators were taken with minor edits from [RFC2865] Section 3. 1030 The author would like to thank Mike McCauley of Open Systems 1031 Consultants for making a Radiator server available for 1032 interoperability testing. 1034 Authors' Addresses 1036 Alan DeKok 1037 The FreeRADIUS Server Project 1038 http://freeradius.org 1040 Email: aland@freeradius.org