idnits 2.17.1 draft-ietf-radext-status-server-05.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 (12 October 2009) is 5308 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Note 1' is mentioned on line 828, 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: April 12, 2009 7 12 October 2009 9 Use of Status-Server Packets in the 10 Remote Authentication Dial In User Service (RADIUS) Protocol 11 draft-ietf-radext-status-server-05 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on April 12, 2009. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This document describes a deployed extension to the Remote 58 Authentication Dial In User Service (RADIUS) protocol, enabling 59 clients to query the status of a RADIUS server. This extension 60 utilizes the Status-Server (12) Code, which was reserved for 61 experimental use in RFC 2865. 63 Table of Contents 65 1. Introduction ............................................. 4 66 1.1. Applicability ....................................... 4 67 1.2. Terminology ......................................... 5 68 1.3. Requirements Language ............................... 5 69 2. Problem Statement ........................................ 6 70 2.1. Why Access-Request cannot be used ................... 6 71 2.1.1. Recommendation against Access-Request .......... 7 72 2.2. Why Accounting-Request cannot be used ............... 7 73 2.2.1. Recommendation against Accounting-Request ...... 8 74 2.3. Why Status-Server is appropriate .................... 8 75 2.3.1. Status-Server Exchange ......................... 8 76 3. Packet Format ............................................ 9 77 3.1. Single definition for Status-Server ................. 11 78 4. Implementation notes ..................................... 11 79 4.1. Client Requirements ................................. 12 80 4.2. Server Requirements ................................. 13 81 4.3. More Robust Fail-over with Status-Server ............ 15 82 4.4. Proxy Server handling of Status-Server .............. 15 83 4.5. Limitations of Status-Server ........................ 16 84 4.6. Management Information Base (MIB) Considerations .... 18 85 4.6.1. Interaction with RADIUS Server MIB modules ..... 18 86 4.6.2. Interaction with RADIUS Client MIB modules ..... 18 87 5. Table of Attributes ...................................... 19 88 6. Examples ................................................. 19 89 6.1. Minimal Query to Authentication Port ................ 19 90 6.2. Minimal Query to Accounting Port .................... 20 91 6.3. Verbose Query and Response .......................... 21 92 7. IANA Considerations ...................................... 22 93 8. Security Considerations .................................. 22 94 9. References ............................................... 22 95 9.1. Normative references ................................ 22 96 9.2. Informative references .............................. 23 98 1. Introduction 100 This document specifies a deployed extension to the Remote 101 Authentication Dial In User Service (RADIUS) protocol, enabling 102 clients to query the status of a RADIUS server. While the Status- 103 Server Code (12) was defined as experimental in [RFC2865] Section 3, 104 details of the operation and potential uses of the Code were not 105 provided. 107 As with the core RADIUS protocol, the Status-Server extension is 108 stateless, and queries do not otherwise affect the normal operation 109 of a server, nor do they result in any side effects, other than 110 perhaps incrementing of an internal packet counter. Most of the 111 implementations of this extension have utilized it alongside 112 implementations of RADIUS as defined in [RFC2865], so that this 113 document focuses solely on the use of this extension with UDP 114 transport. 116 The rest of this document is laid out as follows. Section 2 contains 117 the problem statement, and explanations as to why some possible 118 solutions can have unwanted side effects. Section 3 defines the 119 Status-Server packet format. Section 4 contains client and server 120 requirements, along with some implementation notes. Section 5 lists 121 additional considerations not covered in the other sections. The 122 remaining text contains a RADIUS table of attributes, and discusses 123 security considerations not covered elsewhere in the document. 125 1.1. Applicability 127 This protocol is being recommended for publication as an 128 Informational RFC rather than as a standards-track RFC because of 129 problems with deployed implementations. This includes security 130 vulnerabilities. The fixes recommended here are compatible with 131 existing servers that receive Status-Server packets, but impose new 132 security requirements on clients that send Status-Server packets. 134 Some existing implementations of this protocol do not support the 135 Message-Authenticator attribute. This enables spoofing of Status- 136 Server packets. In order to remedy this problem, this specification 137 recommends the use of the Message-Authenticator attribute to provide 138 per-packet authentication and integrity protection. 140 With existing implementations of this protocol, the potential exists 141 for Status-Server requests to be in conflict with Access-Request or 142 Accounting-Requests packets using the same Identifier. This 143 specification recommends techniques to avoid this problem. 145 This specification is also limited to being a "hop by hop" query. 147 When RADIUS packets transition one or more RADIUS Proxies, any 148 information about the status of downstreamservers is unavailable to 149 the client. In addition, it queries only the status of a RADIUS 150 server, cannot carry information about specific realms. 152 These limitations are discussed in more detail below. 154 1.2. Terminology 156 This document uses the following terms: 158 Network Access Server (NAS) 159 The device providing access to the network. Also known as the 160 Authenticator (in IEEE 802.1X terminology) or RADIUS client. 162 RADIUS Proxy 163 In order to provide for the routing of RADIUS authentication and 164 accounting requests, a RADIUS proxy can be employed. To the NAS, 165 the RADIUS proxy appears to act as a RADIUS server, and to the 166 RADIUS server, the proxy appears to act as a RADIUS client. 168 silently discard 169 This means the implementation discards the packet without further 170 processing. The implementation MAY provide the capability of 171 logging the error, including the contents of the silently discarded 172 packet, and SHOULD record the event in a statistics counter. 174 1.3. Requirements Language 176 In this document, several words are used to signify the requirements 177 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 178 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 179 and "OPTIONAL" in this document are to be interpreted as described in 180 [RFC2119]. 182 2. Problem Statement 184 A common problem in RADIUS client implementations is the 185 implementation of a robust fail-over mechanism between servers. A 186 client may have multiple servers configured, with one server marked 187 as primary and another marked as secondary. If the client does not 188 receive a response to a request sent to the primary server, it can 189 "fail over" to the secondary, and send requests to the secondary 190 instead of to the primary server. 192 However, it is possible that the lack of a response to requests sent 193 to the primary server was due not to a failure within the the 194 primary, but to alternative causes such as a failed link along the 195 path to the destination server, or the failure of a downstream proxy 196 or server. In such a situation, it may be useful for the client to 197 be able to distinguish between failure causes. For example, if the 198 primary server is down, then quick failover to the secondary server 199 would be prudent, whereas if a downstream failure is the cause, then 200 the value of failing over to a secondary server will depend on 201 whether packets forwarded by the secondary will utilize independent 202 links, intermediaries or destination servers. 204 Since the Status-Server packet is non-forwardable, lack of a response 205 may only be due to packet loss or the failure of the server in the 206 destination IP address, not due to faults in downstream links, 207 proxies or servers. It therefore provides an unambiguous indication 208 of the status of a server. 210 We note that this packet is not a "Keep-Alive" as discussed in 211 [RFC2865] Section 2.6. "Keep-Alives" are sent when an downstream 212 server is known to be responsive. These packets are sent only when a 213 server is suspected to be down, and stop being sent as soon as the 214 server returns to availability. 216 2.1. Why Access-Request cannot be used 218 One possible solution to the problem of querying server status is for 219 a NAS to send specially formed Access-Request packets to a RADIUS 220 server's authentication port. The NAS can then look for a response, 221 and use this information to determine if the server is active or 222 unresponsive. 224 However, the server may see the request as a normal login request for 225 a user, and conclude that a real user has logged onto that NAS. The 226 server may then perform actions that are undesirable for a simple 227 status query. The server may alternatively respond with an Access- 228 Challenge, indicating that it believes an extended authentication 229 conversation is necessary. 231 Another possibility is that the server responds with an Access- 232 Reject, indicating that the user is not authorized to gain access to 233 the network. As above, the server may also perform local site 234 actions, such as warning an administrator of failed login attempts. 235 The server may also delay the Access-Reject response, in the 236 traditional manner of rate-limiting failed authentication attempts. 237 This delay in response means that the querying administrator is 238 unsure as to whether or not the server is down, is slow to respond, 239 or is intentionally delaying its response to the query. 241 In addition, using Access-Request queries may mean that the server 242 may have local users configured whose sole reason for existence is to 243 enable these query requests. Unless the server's policy is designed 244 carefully, it may be possible for an attacker to use those 245 credentials to gain unauthorized network access. 247 We note that some NAS implementations currently use Access-Request 248 packets as described above, with a fixed (and non configurable) user 249 name and password. Implementation issues with that equipment means 250 that if a RADIUS server does not respond to those queries, it may be 251 marked as unresponsive by the NAS. This marking may happen even if 252 the server is actively responding to other Access-Requests from that 253 same NAS. This behavior is confusing to administrators who then need 254 to determine why an active server has been marked as "unresponsive". 256 2.1.1. Recommendation against Access-Request 258 For the reasons outlined above, NAS implementors SHOULD NOT generate 259 Access-Request packets solely to see if a server is alive. 260 Similarly, site administrators SHOULD NOT configure test users whose 261 sole reason for existence is to enable such queries via Access- 262 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.2. Why Accounting-Request cannot be used 271 A similar solution for the problem of querying server status may be 272 for a NAS to send specially formed Accounting-Request packets to a 273 RADIUS servers accounting port. The NAS can then look for a 274 response, and use this information to determine if the server is 275 active or unresponsive. 277 As seen above with Access-Request, the server may then conclude that 278 a real user has logged onto a NAS, and perform local site actions 279 that are undesirable for a simple status query. 281 Another consideration is that some attributes are mandatory to 282 include in an Accounting-Request. This requirement forces the 283 administrator to query an accounting server with fake values for 284 those attributes in a test packet. These fake values increase the 285 work required to perform a simple query, and may pollute the server's 286 accounting database with incorrect data. 288 2.2.1. Recommendation against Accounting-Request 290 For the reasons outlined above, NAS implementors SHOULD NOT generate 291 Accounting-Request packets solely to see if a server is alive. 292 Similarly, site administrators SHOULD NOT configure accounting 293 policies whose sole reason for existence is to enable such queries 294 via Accounting-Request packets. 296 Note that it still may be useful to configure test users for the 297 purpose of performing end-to-end or in-depth testing of a servers 298 policy. While this practice is widespread, we caution administrators 299 to use it with care. 301 2.3. Why Status-Server is appropriate 303 A better solution to the above problems is to use the Status-Server 304 packet code. The name of the code leads us to conclude that it was 305 intended for packets that query the status of a server. Since the 306 packet is officially undefined, but widely used as specified here, 307 this document does not create inter-operability issues. 309 2.3.1. Status-Server Exchange 311 Status-Server packets are typically sent to the destination address 312 and port of a RADIUS server or proxy. A Message-Authenticator 313 attribute MUST be included so as to provide per-packet authentication 314 and integrity protection. A single Status-Server packet MUST be 315 included within a UDP datagram. RADIUS proxies MUST NOT forward 316 Status-Server packets. 318 A RADIUS server or proxy implementing this specification SHOULD 319 respond to a Status-Server packet with an Access-Accept 320 (authentication port) or Accounting-Message (accounting port). Other 321 response packet codes (such as Access-Challenge or Access-Reject) are 322 NOT RECOMMENDED. The list of attributes that are permitted in 323 Status-Server and Access-Accept packets responding to Status-Server 324 packets are provided in the Section 6. 326 3. Packet Format 328 Status-Server packets reuse the RADIUS packet format, with the fields 329 and values for those fields as defined [RFC2865] Section 3. We do 330 not include all of the text or diagrams of that section here, but 331 instead explain the differences required to implement Status-Server. 333 The Authenticator field of Status-Server packets MUST be generated 334 using the same method as that used for the Request Authenticator 335 field of Access-Request packets, as given below. 337 The role of the Identifier field is the same for Status-Server as for 338 other packets. However, as Status-Server is taking the role of 339 Access-Request or Accounting-Request packets, there is the potential 340 for Status-Server requests to be in conflict with Access-Request or 341 Accounting-Request packets with the same Identifier. In Section 4.2, 342 below, we describe a method for avoiding these problems. This method 343 MUST be used to avoid conflicts between Status-Server and other 344 packet types. 346 Request Authenticator 348 In Status-Server Packets, the Authenticator value is a 16 octet 349 random number, called the Request Authenticator. The value 350 SHOULD be unpredictable and unique over the lifetime of a 351 secret (the password shared between the client and the RADIUS 352 server), since repetition of a request value in conjunction 353 with the same secret would permit an attacker to reply with a 354 previously intercepted response. Since it is expected that the 355 same secret MAY be used to authenticate with servers in 356 disparate geographic regions, the Request Authenticator field 357 SHOULD exhibit global and temporal uniqueness. 359 The Request Authenticator value in a Status-Server packet 360 SHOULD also be unpredictable, lest an attacker trick a server 361 into responding to a predicted future request, and then use the 362 response to masquerade as that server to a future Status-Server 363 request from a client. 365 Similarly, the Response Authenticator field of an Access-Accept 366 packet sent in response to Status-Server queries MUST be generated 367 using the same method as used for for calculating the Response 368 Authenticator of the Access-Accept sent in response to an Access- 369 Request, with the Status-Server Request Authenticator taking the 370 place of the Access-Request Request Authenticator. 372 The Response Authenticator field of an Accounting-Response packet 373 sent in response to Status-Server queries MUST be generated using the 374 same method as used for for calculating the Response Authenticator of 375 the Accounting-Response sent in response to an Accounting-Request, 376 with the Status-Server Request Authenticator taking the place of the 377 Accounting-Request Request Authenticator. 379 Note that when a server responds to a Status-Server request, it MUST 380 NOT send more than one response packet. 382 Response Authenticator 384 The value of the Authenticator field in Access-Accept, or 385 Accounting-Response packets is called the Response 386 Authenticator, and contains a one-way MD5 hash calculated over 387 a stream of octets consisting of: the RADIUS packet, beginning 388 with the Code field, including the Identifier, the Length, the 389 Request Authenticator field from the Status-Server packet, and 390 the response Attributes (if any), followed by the shared 391 secret. That is, ResponseAuth = 392 MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where + 393 denotes concatenation. 395 In addition to the above requirements, all Status-Server packets MUST 396 include a Message-Authenticator attribute. Failure to do so would 397 mean that the packets could be trivially spoofed. 399 Status-Server packets MAY include NAS-Identifier, and one of NAS-IP- 400 Address or NAS-IPv6-Address. These attributes are not necessary for 401 the operation of Status-Server, but may be useful information to a 402 server that receives those packets. 404 Other attributes SHOULD NOT be included in a Status-Server packet. 405 User authentication credentials such as User-Password, CHAP-Password, 406 EAP-Message, etc. MUST NOT appear in a Status-Server packet sent to a 407 RADIUS authentication port. User or NAS accounting attributes such 408 as Acct-Session-Id, Acct-Status-Type, Acct-Input-Octets, etc. MUST 409 NOT appear in a Status-Server packet sent to a RADIUS accounting 410 port. 412 The Access-Accept MAY contain a Reply-Message or Message- 413 Authenticator attribute. It SHOULD NOT contain other attributes. 414 The Accounting-Response packets sent in response to a Status-Server 415 query SHOULD NOT contain any attributes. As the intent is to 416 implement a simple query instead of user authentication or 417 accounting, there is little reason to include other attributes in 418 either the query or the corresponding response. 420 Examples of Status-Server packet flows are given below in Section 7. 422 3.1. Single definition for Status-Server 424 When sent to a RADIUS accounting port, contents of the Status-Server 425 packets are calculated as described above. That is, even though the 426 packets are being sent to an accounting port, they are not created 427 using the same method as for Accounting-Requests. This difference 428 has a number of benefits. 430 Having a single definition for Status-Server packets is simpler than 431 having different definitions for different destination ports. In 432 addition, if we were to define Status-Server as being similar to 433 Accounting-Request but containing no attributes, then those packets 434 could be trivially forged. 436 We therefore define Status-Server consistently, and vary the response 437 packets depending on the port to which the request is sent. When 438 sent to an authentication port, the response to a Status-Server query 439 is an Access-Accept packet. When sent to an accounting port, the 440 response to a Status-Server query is an Accounting-Response packet. 442 4. Implementation notes 444 There are a number of considerations to take into account when 445 implementing support for Status-Server. This section describes 446 implementation details and requirements for RADIUS clients and 447 servers that support Status-Server. 449 The following text applies to the authentication and accounting 450 ports. We use the generic terms below to simplify the discussion: 452 * Request packet 454 An Access-Request packet sent to an authentication port, or 455 an Accounting-Request packet sent to an accounting port. 457 * Response packet 459 An Access-Accept, Access-Challenge, or Access-Reject packet sent 460 from an authentication port, or an Accounting-Response packet 461 sent from an accounting port. 463 We also refer to "client" as the originator of the Status-Server 464 packet, and "server" as the receiver of that packet, and the 465 originator of the Response packet. 467 Using generic terms to describe the Status-Server conversations is 468 simpler than duplicating the text for authentication and accounting 469 packets. 471 4.1. Client Requirements 473 Clients SHOULD permit administrators to globally enable or disable 474 the generation of Status-Server packets. The default SHOULD be that 475 it is disabled. As it is undesirable to send queries to servers that 476 do not support Status-Server, clients SHOULD also have a per-server 477 configuration indicating whether or not to enable Status-Server for a 478 particular destination. The default SHOULD be that it is disabled. 480 The client SHOULD also have a configurable global timer (Tw) that is 481 used when sending periodic Status-Server queries during server fail- 482 over. The default value SHOULD be 30 seconds, and the value MUST NOT 483 be permitted to be set below 6 seconds. If a response has not been 484 received within the timeout period, the Status-Server packet is 485 deemed to have received no corresponding Response packet, and MUST be 486 discarded. 488 Clients SHOULD use a jitter of +/- 2 seconds when sending periodic 489 Status-Server packets, in order to avoid synchronization. 491 When Status-Server packets are sent from a client, they MUST NOT be 492 retransmitted. Instead, the Identity field MUST be changed every 493 time a packet is transmitted. The old packet should be discarded, 494 and a new Status-Server packet should be generated and sent, with new 495 Identity and Authenticator fields. 497 Clients MUST include the Message-Authenticator attribute in all 498 Status-Server packets. Failure to do so would mean that the packets 499 could be trivially spoofed, leading to potential denial of service 500 (DoS) attacks. Other attributes SHOULD NOT appear in a Status-Server 501 packet, except as outlined below in Section 6. As the intent of the 502 packet is a simple status query, there is little reason for any 503 additional attributes to appear in Status-Server packets. 505 The client MAY increment packet counters as a result of sending a 506 Status-Server request, or receiving a Response packet. The client 507 MUST NOT perform any other action that is normally performed when it 508 receives a Response packet, such as permitting a user to have login 509 access to a port. 511 Clients MAY send Status-Server requests to the RADIUS destination 512 ports from the same source port used to send normal Request packets. 513 Other clients MAY choose to send Status-Server requests from a unique 514 source port, that is not used to send Request packets. 516 The above suggestion for a unique source port for Status-Server 517 packets aids in matching responses to requests. Since the response 518 to a Status-Server packet is an Access-Accept or Accounting-Response 519 packet, those responses are indistinguishable from other packets sent 520 in response to a Request packet. Therefore, the best way to 521 distinguish them from other traffic is to have a unique port. 523 A client MAY send a Status-Server packet from a source port also used 524 to send Request packets. In that case, the Identifer field MUST be 525 unique across all outstanding Request packets for that source port, 526 independent of the value of the RADIUS Code field for those 527 outstanding requests. Once the client has either received a response 528 to the Status-Server packet, or has determined that the Status-Server 529 packet has timed out, it may reuse that Identifier in another packet. 531 Robust implementations SHOULD accept any Response packet as a valid 532 response to a Status-Server packet, subject to the validation 533 requirements defined above for the Response Authenticator. The code 534 field of the packet matters less than the fact that a valid, signed, 535 response has been received. 537 That is, prior to accepting the response as valid, the client should 538 check that the Response packet Code field is either Access-Accept (2) 539 or Accounting-Response (5). If the code does not match any of these 540 values, the packet MUST be silently discarded. The client MUST then 541 validate the Response Authenticator via the algorithm given above in 542 Section 3. If the Response Authenticator is not valid, the packet 543 MUST be silently discarded. If the Response Authenticator is valid, 544 then the packet MUST be deemed to be a valid response from the 545 server. 547 If the client instead discarded the response because the packet code 548 did not match what it expected, then it could erroneously discard 549 valid responses from a server, and mark that server as unresponsive. 550 This behavior would affect the stability of a RADIUS network, as 551 responsive servers would erroneously be marked as unresponsive. We 552 therefore recommend that clients should be liberal in what they 553 accept as responses to Status-Server queries. 555 4.2. Server Requirements 557 Servers SHOULD permit administrators to globally enable or disable 558 the acceptance of Status-Server packets. The default SHOULD be that 559 it is enabled. Servers SHOULD also permit adminstrators to enable or 560 disable acceptance of Status-Server packets on a per-client basis. 561 The default SHOULD be that it is enabled. 563 Status-Server packets originating from clients that are not permitted 564 to send the server Request packets MUST be silently discarded. If a 565 server does not support Status-Server packets, or is configured to 566 not respond to them, then it MUST silently discard the packet. 568 We note that [RFC2865] Section 3 defines a number of RADIUS Codes, 569 but does not make statements about which Codes are valid for port 570 1812. In contrast, [RFC2866] Section 3 specifies that only RADIUS 571 Accounting packets are to be sent to port 1813. This specification 572 is compatible with [RFC2865], as it uses a known Code for packets to 573 port 1812. This specification is not compatible with [RFC2866], as 574 it adds a new code (Status-Server) that is valid for port 1812. 575 However, as the category of [RFC2866] is Informational, this conflict 576 is acceptable. 578 Servers SHOULD silently discard Status-Server packets if they 579 determine that a client is sending too many Status-Server requests in 580 a particular time period. The method used by a server to make this 581 determination is implementation-specific, and out of scope for this 582 specification. 584 If a server supports Status-Server packets, and is configured to 585 respond to them, and receives a packet from a known client, it MUST 586 validate the Message-Authenticator attribute as defined in [RFC3579] 587 Section 3.2. Packets failing that validation MUST be silently 588 discarded. 590 Servers SHOULD NOT otherwise discard Status-Server packets if they 591 have recently sent the client a Response packet. The query may have 592 originated from an administrator who does not have access to the 593 Response packet stream, or who is interested in obtaining additional 594 information about the server. 596 The server MAY prioritize the handling of Status-Server packets over 597 the handling of other requests, subject to the rate limiting 598 described above. 600 The server MAY decide to not respond to a Status-Server, depending on 601 local site policy. For example, a server that is running but is 602 unable to perform its normal activities MAY silently discard Status- 603 Server packets. This situation can happen, for example, when a 604 server requires access to a database for normal operation, but the 605 connection to that database is down. Or, it may happen when the 606 accepted load on the server is lower than the offered load. 608 Some server implementations require that Access-Request packets are 609 accepted only on "authentication" ports, (e.g. 1812/udp), and that 610 Accounting-Request packets are accepted only on "accounting" ports 611 (e.g. 1813/udp). Those implementations SHOULD reply to Status-Server 612 packets sent to an "authentication" port with an Access-Accept 613 packet. Those implementations SHOULD reply to Status-Server packets 614 sent to an "accounting" port with an Accounting-Response packet. 616 Some server implementations accept both Access-Request and 617 Accounting-Request packets on the same port, and do not distinguish 618 between "authentication only" ports, and "accounting only" ports. 619 Those implementations SHOULD reply to Status-Server packets with an 620 Access-Accept packet. 622 The server MAY increment packet counters as a result of receiving a 623 Status-Server, or sending a Response packet. The server SHOULD NOT 624 perform any other action that is normally performed when it receives 625 a Request packet, other than sending a Response packet. 627 4.3. More Robust Fail-over with Status-Server 629 A client will typically fail over from one server to another because 630 of a lack of responsiveness to normal RADIUS traffic. However, the 631 client has few reasons to mark the server as responsive, as it is not 632 being sent any packets. 634 The solution is that the client SHOULD begin to send periodic Status- 635 Server packets as soon as a server is determined to be unresponsive. 636 The inter-packet period is Tw, as defined above in Section 4.1. 637 These packets will help the client determine if the failure was due 638 to the server being unresponsive, or if the problem is due to an 639 downstream server being unresponsive. 641 Once three time periods have passed where Status-Server packets have 642 been sent and responded to, the server should be deemed responsive 643 and RADIUS requests may sent to it again. This determination should 644 be made separately for each server that the client has a relationship 645 with. The same algorithm should be used for both authentication and 646 accounting ports. The client MUST treat each destination (ip, port) 647 combination as a unique server for the purposes of this 648 determination. 650 The above behavior is modelled after [RFC3539] Section 3.4.1. We 651 note that if a reliable transport is used for RADIUS, then the 652 algorithms specified in [RFC3539] MUST be used in preference to the 653 ones given here. 655 4.4. Proxy Server handling of Status-Server 657 Many RADIUS servers can act as proxy servers, and can forward 658 requests to another RADIUS server. Such servers MUST NOT proxy 659 Status-Server packets. The purpose of Status-Server as specified 660 here is to permit the client to query the responsiveness of a server 661 that it has a direct relationship with. Proxying Status-Server 662 queries would negate any usefulness that may be gained by 663 implementing support for them. 665 Proxy servers MAY be configured to respond to Status-Server queries 666 from clients, and MAY act as clients sending Status-Server queries to 667 other servers. However, those activities MUST be independent of one 668 another. 670 4.5. Limitations of Status-Server 672 RADIUS servers are commonly used in an environment where Network 673 Access Identifiers (NAIs) are used as routing identifiers [RFC4282]. 674 In this practice, the User-Name attribute is decorated with realm 675 routing information, commonly in the format of "user@realm". Since a 676 particular RADIUS server may act as a proxy for more than one realm, 677 we need to explain how the behavior defined above in Section 4.3, 678 above, affects realm routing. 680 The schematic below demonstrates this scenario. 682 /-> RADIUS Proxy P -----> RADIUS Server for Realm A 683 / \ / 684 NAS X 685 \ / \ 686 \-> RADIUS Proxy S -----> RADIUS Server for Realm B 688 That is, the NAS has relationships with two RADIUS Proxies, P and S. 689 Each RADIUS Proxyhas relationships with RADIUS Servers for both Realm 690 A and Realm B. 692 In this scenario, the RADIUS Proxies can determine if one or both of 693 the RADIUS Servers are dead or unreachable. The NAS can determine if 694 one or both of the RADIUS Proxies are dead or unreachable. There is 695 an additional case to consider, however. 697 If RADIUS Proxy P cannot reach the RADIUS Server for Realm A, but the 698 RADIUS Proxy S can reach that RADIUS Server, then the NAS cannot 699 discover this information using the Status-Server queries as outlined 700 above. It would therefore be useful for the NAS to know that Realm A 701 is reachable from RADIUS Proxy S, as it can then route all requests 702 for Realm A to that RADIUS Proxy. Without this knowledge, the client 703 may route requests to RADIUS Proxy P, where they may be discarded or 704 rejected. 706 To complicate matters, the behavior of RADIUS Proxies P and S in this 707 situation is not well defined. Some implementations simply fail to 708 respond to the request, and other implementations respond with an 709 Access-Reject. If the implementation fails to respond, then the NAS 710 cannot distinguish between the RADIUS Proxy being down, or the next 711 server along the proxy chain being unreachable. 713 In the worst case, failures in routing for Realm A may affect users 714 of Realm B. For example, if RADIUS Proxy P can reach Realm B but not 715 Realm A, and RADIUS Proxy S can reach Realm A but not Realm B, then 716 active paths exist to handle all RADIUS requests. However, depending 717 on the NAS and RADIUS Proxy implementation choices, the NAS may not 718 be able to determine which server requests may be sent to in order to 719 maintain network stability. 721 This problem cannot, unfortunately be solved by using Status-Server 722 requests. A robust solution would involve either a RADIUS routing 723 table for the NAI realms, or a RADIUS "destination unreachable" 724 response to authentication requests. Either solution would not fit 725 into the traditional RADIUS model, and both are therefore outside of 726 the scope of this specification. 728 The problem is discussed here in order to define how best to use 729 Status-Server in this situation, rather than to define a new 730 solution. 732 When a server has responded recently to a request from a client, that 733 client MUST mark the server as "responsive". In the above case, a 734 RADIUS Proxy may be responding to requests destined for Realm A, but 735 not responding to requests destined for Realm B. The client 736 therefore considers the server to be responsive, as it is receiving 737 responses from the server. 739 The client will then continue to send requests to the RADIUS Proxy 740 for destination Realm B, even though the RADIUS Proxy cannot route 741 the requests to that destination. This failure is a known limitation 742 of RADIUS, and can be partially addressed through the use of failover 743 in the RADIUS Proxies. 745 A more realistic situation than the one outlined above is where each 746 RADIUS Proxy also has multiple choices of RADIUS Servers for a realm, 747 as outlined below. 749 /-> RADIUS Proxy P -----> RADIUS Server P 750 / \ / 751 NAS X 752 \ / \ 753 \-> RADIUS Proxy S -----> RADIUS Server S 755 In this situation, if all participants implement Status-Server as 756 defined herein, any one link may be broken, and all requests from the 757 NAS will still reach a RADIUS Server. If two links are broken at 758 different places, (i.e. not both links from the NAS), then all 759 requests from the NAS will still reach a RADIUS Server. In many 760 situations where three or more links are broken, then requests from 761 the NAS may still reach a RADIUS Server. 763 It is RECOMMENDED, therefore, that implementations desiring the most 764 benefit from Status-Server also implement server failover. The 765 combination of these two practices will maximize network reliability 766 and stability. 768 4.6. Management Information Base (MIB) Considerations 770 4.6.1. Interaction with RADIUS Server MIB modules 772 Since Status-Server packets are sent to the defined RADIUS ports, 773 they can affect the [RFC4669] and [RFC4671] RADIUS server MIB 774 modules. [RFC4669] defines a counter named 775 radiusAuthServTotalUnknownTypes that counts "The number of RADIUS 776 packets of unknown type that were received". [RFC4671] defines a 777 similar counter named radiusAcctServTotalUnknownTypes. 778 Implementations not supporting Status-Server, or implementations that 779 are configured to not respond to Status-Server packets MUST use these 780 counters to track received Status-Server packets. 782 If, however, Status-Server is supported and the server is configured 783 to respond as described above, then the counters defined in [RFC4669] 784 and [RFC4671] MUST NOT be used to track Status-Server requests or 785 responses to those requests. That is, when a server fully implements 786 Status-Server, the counters defined in [RFC4669] and [RFC4671] MUST 787 be unaffected by the transmission or reception of packets relating to 788 Status-Server. 790 If a server supports Status-Server and the [RFC4669] or [RFC4671] MIB 791 Modules, then it SHOULD also support vendor-specific MIB extensions 792 dedicated solely to tracking Status-Server requests and responses. 793 Any definition of the server MIB modules for Status-Server is outside 794 of the scope of this document. 796 4.6.2. Interaction with RADIUS Client MIB modules 798 Clients implementing Status-Server MUST NOT increment [RFC4668] or 799 [RFC4670] counters upon reception of Response packets to Status- 800 Server queries. That is, when a server fully implements Status- 801 Server, the counters defined in [RFC4668] and [RFC4670] MUST be 802 unaffected by the transmission or reception of packets relating to 803 Status-Server. 805 If an implementation supports Status-Server and the [RFC4668] or 806 [RFC4670] MIB modules, then it SHOULD also support vendor-specific 807 MIB extensions dedicated solely to tracking Status-Server requests 808 and responses. Any definition of the client MIB module extensions 809 for Status-Server is outside of the scope of this document. 811 5. Table of Attributes 813 The following table provides a guide to which attributes may be found 814 in Status-Server packets, and in what quantity. Attributes other 815 than the ones listed below SHOULD NOT be found in a Status-Server 816 packet. 818 Status- Access- Accounting- 819 Server Accept Response # Attribute 821 0-1 0 0 4 NAS-IP-Address [Note 1] 822 0 0+ 0 18 Reply-Message 823 0+ 0+ 0+ 26 Vendor-Specific 824 0-1 0 0 32 NAS-Identifier [Note 1] 825 1 0-1 0-1 80 Message-Authenticator 826 0-1 0 0 95 NAS-IPv6-Address [Note 1] 828 [Note 1] A Status-Server SHOULD contain one of (NAS-IP-Address or 829 NAS-IPv6-Address), or NAS-Identifier, or both NAS-Identifier and one 830 of (NAS-IP-Address or NAS-IPv6-Address). 832 The following table defines the meaning of the above table entries. 834 0 This attribute MUST NOT be present in packet. 835 0+ Zero or more instances of this attribute MAY be present in packet. 836 0-1 Zero or one instance of this attribute MAY be present in packet. 837 1 Exactly one instance of this attribute MUST be present in packet. 839 6. Examples 841 A few examples are presented to illustrate the flow of packets to 842 both the authentication and accounting ports. These examples are not 843 intended to be exhaustive, many others are possible. Hexadecimal 844 dumps of the example packets are given in network byte order, using 845 the shared secret "xyzzy5461". 847 6.1. Minimal Query to Authentication Port 849 The NAS sends a Status-Server UDP packet with minimal content to a 850 RADIUS server on port 1812. 852 The Request Authenticator is a 16 octet random number generated by 853 the NAS. Message-Authenticator is included in order to authenticate 854 that the request came from a known client. 856 0c da 00 26 8a 54 f4 68 6f b3 94 c5 28 66 e3 02 857 18 5d 06 23 50 12 5a 66 5e 2e 1e 84 11 f3 e2 43 858 82 20 97 c8 4f a3 860 1 Code = Status-Server (12) 861 1 ID = 218 862 2 Length = 38 863 16 Request Authenticator 865 Attributes: 866 18 Message-Authenticator (80) = 5a665e2e1e8411f3e243822097c84fa3 868 The Response Authenticator is a 16 octet MD5 checksum of the code 869 (2), id (218), Length (20), the Request Authenticator from above, and 870 the shared secret. 872 02 da 00 14 ef 0d 55 2a 4b f2 d6 93 ec 2b 6f e8 873 b5 41 1d 66 875 1 Code = Access-Accept (2) 876 1 ID = 218 877 2 Length = 20 878 16 Request Authenticator 880 Attributes: 881 None. 883 6.2. Minimal Query to Accounting Port 885 The NAS sends a Status-Server UDP packet with minimal content to a 886 RADIUS server on port 1813. 888 The Request Authenticator is a 16 octet random number generated by 889 the NAS. Message-Authenticator is included in order to authenticate 890 that the request came from a known client. 892 0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb 1d b7 893 ad 38 82 60 80 12 e8 d6 ea bd a9 10 87 5c d9 1f 894 da de 26 36 78 58 896 1 Code = Status-Server (12) 897 1 ID = 179 898 2 Length = 38 899 16 Request Authenticator 901 Attributes: 902 18 Message-Authenticator (80) = e8d6eabda910875cd91fdade26367858 904 The Response Authenticator is a 16 octet MD5 checksum of the code 905 (5), id (179), Length (20), the Request Authenticator from above, and 906 the shared secret. 908 02 b3 00 1a 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a 909 48 60 66 9c 911 1 Code = Accounting-Response (5) 912 1 ID = 179 913 2 Length = 20 16 Request Authenticator 915 Attributes: 916 None. 918 6.3. Verbose Query and Response 920 The NAS at 192.0.2.16 sends a Status-Server UDP packet to the RADIUS 921 server on port 1812. 923 The Request Authenticator is a 16 octet random number generated by 924 the NAS. 926 0c 47 00 2c bf 58 de 56 ae 40 8a d3 b7 0c 85 13 927 f9 b0 3f be 04 06 c0 00 02 10 50 12 85 2d 6f ec 928 61 e7 ed 74 b8 e3 2d ac 2f 2a 5f b2 930 1 Code = Status-Server (12) 931 1 ID = 71 932 2 Length = 44 933 16 Request Authenticator 935 Attributes: 936 6 NAS-IP-Address (4) = 192.0.2.16 937 18 Message-Authenticator (80) = 852d6fec61e7ed74b8e32dac2f2a5fb2 939 The Response Authenticator is a 16-octet MD5 checksum of the code 940 (2), id (71), Length (52), the Request Authenticator from above, the 941 attributes in this reply, and the shared secret. 943 The Reply-Message is "RADIUS Server up 2 days, 18:40" 945 02 47 00 34 46 f4 3e 62 fd 03 54 42 4c bb eb fd 946 6d 21 4e 06 12 20 52 41 44 49 55 53 20 53 65 72 947 76 65 72 20 75 70 20 32 20 64 61 79 73 2c 20 31 948 38 3a 34 30 950 1 Code = Access-Accept (2) 951 1 ID = 71 952 2 Length = 52 953 16 Request Authenticator 955 Attributes: 956 32 Reply-Message (18) 958 7. IANA Considerations 960 This specification does not create any new registries, nor does it 961 require assignment of any protocol parameters. 963 8. Security Considerations 965 This document defines the Status-Server packet as being similar in 966 treatment to the Access-Request packet, and is therefore subject to 967 the same security considerations as described in [RFC2865], Section 968 8. Status-Server packets also use the Message-Authenticator 969 attribute, and are therefore subject to the same security 970 considerations as [RFC3579], Section 4. 972 We reiterate that Status-Server packets MUST contain a Message- 973 Authenticator attribute. Early implementations supporting Status- 974 Server did not enforce this requirement, and may have been vulnerable 975 to DoS attacks as a result. 977 Where this document differs from [RFC2865] is that it defines a new 978 request/response method in RADIUS; the Status-Server request. As 979 this use is based on previously described and implemented standards, 980 we know of no additional security considerations that arise from the 981 use of Status-Server as defined herein. 983 9. References 985 9.1. Normative references 987 [RFC2865] 988 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 989 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 991 [RFC4282] 992 Aboba, B., and Beadles, M. at al, "The Network Access Identifier", 993 RFC 4282, December 2005. 995 9.2. Informative references 997 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 998 Requirement Levels", RFC 2119, March, 1997. 1000 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1002 [RFC3539] Aboba, B., Wood, J., "Authentication, Authorization, and 1003 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 1005 [RFC3579] Aboba, B., Calhoun, P., "RADIUS (Remote Authentication Dial In 1006 User Service) Support For Extensible Authentication Protocol 1007 (EAP)", RFC 3579, September 2003. 1009 [RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6", RFC 1010 4668, August 2006. 1012 [RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6", RFC 1013 4669, August 2006. 1015 [RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC 4670, 1016 August 2006. 1018 [RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC 4671, 1019 August 2006. 1021 Acknowledgments 1023 Parts of the text in Section 3 defining the Request and Response 1024 Authenticators were taken with minor edits from [RFC2865] Section 3. 1026 The author would like to thank Mike McCauley of Open Systems 1027 Consultants for making a Radiator server available for 1028 interoperability testing. 1030 Authors' Addresses 1032 Alan DeKok 1033 The FreeRADIUS Server Project 1034 http://freeradius.org 1036 Email: aland@freeradius.org