idnits 2.17.1 draft-dekok-radius-status-server-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1171. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1148. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1155. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1161. 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 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (20 March 2008) is 5880 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 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 20, 2008 7 20 March 2008 9 Use of Status-Server Packets in the 10 Remote Authentication Dial In User Service (RADIUS) Protocol 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 20, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 RFC 2865 defines a Status-Server code for use in RADIUS, but labels 42 it as "Experimental" without further discussion. This document 43 describes a practical use for the Status-Server packet code, which is 44 to let clients query the status of a RADIUS server. These queries, 45 and responses (if any) enable the client to make more informed 46 decisions. The result is a more stable, and more robust RADIUS 47 architecture. 49 Table of Contents 51 1. Introduction ............................................. 3 52 1.1. Terminology ......................................... 3 53 1.2. Requirements Language ............................... 4 54 2. Problem Statement ........................................ 5 55 2.1. Overloading Access-Request .......................... 5 56 2.1.1. Recommendation against Access-Request .......... 6 57 2.2. Overloading Accounting-Request ...................... 6 58 2.2.1. Recommendation against Accounting-Request ...... 7 59 2.3. Status-Server as a Solution ......................... 7 60 2.3.1. Status-Server to the RADIUS Authentication port 7 61 2.3.2. Status-Server to the RADIUS Accounting port .... 8 62 3. Packet Format ............................................ 8 63 3.1. Consistent definition for Status-Server ............. 10 64 4. Implementation notes ..................................... 10 65 4.1. Client Requirements ................................. 11 66 4.2. Server Requirements ................................. 13 67 4.3. More Robust Fail-over with Status-Server ............ 14 68 4.4. Proxy Server handling of Status-Server .............. 15 69 4.5. Realm Routing ....................................... 15 70 4.6. Management Information Base (MIB) Considerations .... 17 71 4.6.1. Interaction with RADIUS Server MIBs ............ 17 72 4.6.2. Interaction with RADIUS Client MIBs ............ 18 73 5. Additional considerations ................................ 18 74 5.1. Local site testing .................................. 18 75 5.2. RADIUS over reliable transports ..................... 19 76 5.3. Other uses for Status-Server ........................ 20 77 5.4. Potential Uses for Status-Client .................... 20 78 6. Table of Attributes ...................................... 20 79 7. Examples ................................................. 21 80 7.1. Minimal Query to Authentication Port ................ 21 81 7.2. Minimal Query to Accounting Port .................... 22 82 7.3. Verbose Query and Response .......................... 23 83 8. IANA Considerations ...................................... 23 84 9. Security Considerations .................................. 24 85 10. References .............................................. 24 86 10.1. Normative references ............................... 24 87 10.2. Informative references ............................. 24 88 Intellectual Property Statement .............................. 25 89 Disclaimer of Validity ....................................... 27 90 Full Copyright Statement ..................................... 27 91 1. Introduction 93 The RADIUS Working Group was formed in 1995 to document the protocol 94 of the same name, and created a number of standards surrounding the 95 protocol. It also defined experimental commands within the protocol, 96 without elaborating further on the potential uses of those commands. 97 One of the commands so defined was Status-Server ([RFC2865] Section 98 3.). 100 This document describes how some current implementations are using 101 Status-Server packets as a method for querying the status of a RADIUS 102 server. These queries do not otherwise affect the normal operation 103 of a server, and do not result in any side effects other than perhaps 104 incrementing an internal packet counter. 106 These queries are not intended to implement the application-layer 107 watchdog messages described in [RFC3539] Section 3.4. That document 108 describes Authentication, Authorization, and Accounting (AAA) 109 protocols that run over reliable transports which handle 110 retransmissions internally. Since RADIUS runs over the User Datagram 111 Protocol (UDP) rather than Transport Control Protocol (TCP), the full 112 watchdog mechanism is not applicable here. 114 The rest of this document is laid out as follows. Section 2 contains 115 the problem statement, and explanations as to why some possible 116 solutions can have unwanted side effects. Section 3 defines the 117 Status-Server packet format. Section 4 contains client and server 118 requirements, along with some implementation notes. Section 5 lists 119 additional considerations not covered in the other sections. The 120 remaining text contains a RADIUS table of attributes, and discussed 121 security considerations not covered elsewhere in the document. 123 1.1. Terminology 125 This document uses the following terms: 127 Network Access Server (NAS) 128 The device providing access to the network. Also known as the 129 Authenticator (in IEEE 802.1x terminology) or RADIUS client. 131 Home Server 132 A RADIUS server that is authoritative for user authorization and 133 authentication. 135 Proxy Server 136 A RADIUS server that acts as a Home Server to the NAS, but in turn 137 proxies the request to another Proxy Server, or to a Home Server. 139 silently discard 140 This means the implementation discards the packet without further 141 processing. The implementation MAY provide the capability of 142 logging the error, including the contents of the silently discarded 143 packet, and SHOULD record the event in a statistics counter. 145 1.2. Requirements Language 147 In this document, several words are used to signify the requirements 148 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 149 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 150 and "OPTIONAL" in this document are to be interpreted as described in 151 [RFC2119]. 153 2. Problem Statement 155 It is often useful to know if a RADIUS server is alive and responding 156 to requests. The most accurate way to obtain this information is to 157 query the server via application protocol traffic, as other methods 158 are either less accurate, or cannot be performed remotely. 160 The reasons for wanting to know the status of a server are many. The 161 administrator may simply be curious if the server is responding, and 162 may not have access to NAS or traffic data that would give him that 163 information. The queries may also be performed automatically by a 164 NAS or proxy server, which is configured to send packets to a RADIUS 165 server, and where that server may not be responding. That is, while 166 [RFC2865] Section 2.6 indicates that sending Keep-Alives is harmful, 167 it may be useful to send "Are you Alive" queries to a server once it 168 has been marked "dead" due to prior unresponsiveness. 170 The occasional query to a "dead" server offers little additional load 171 on the network or server, and permits clients to more quickly 172 discover when the server returns to a responsive state. Overall, 173 status queries can be a useful part of the deployment of a RADIUS 174 server. 176 2.1. Overloading Access-Request 178 One possible solution to the problem of querying server status is for 179 a NAS to send specially formed Access-Request packets to a RADIUS 180 server's authentication port. The NAS can then look for a response, 181 and use this information to determine if the server is active or 182 unresponsive. 184 However, the server may see the request as a normal login request for 185 a user, and conclude that a real user has logged onto that NAS. The 186 server may then perform actions that are undesirable for a simple 187 status query. The server may alternatively respond with an Access- 188 Challenge, indicating that it believes an extended authentication 189 conversation is necessary. 191 Another possibility is that the server responds with an Access- 192 Reject, indicating that the user is not authorized to gain access to 193 the network. As above, the server may also perform local site 194 actions, such as warning an administrator of failed login attempts. 195 The server may also delay the Access-Reject response, in the 196 traditional manner of rate-limiting failed authentication attempts. 197 This delay in response means that the querying administrator is 198 unsure as to whether or not the server is down, is slow to respond, 199 or is intentionally delaying it's response to the query. 201 In addition, using Access-Request queries may mean that the server 202 may have local users configured whose sole reason for existence is to 203 enable these query requests. Unless the server's policy is designed 204 carefully, it may be possible for an attacker to use those 205 credentials to gain unauthorized network access. 207 We note that some NAS implementations currently use Access-Request 208 packets as described above, with a fixed (and non configurable) user 209 name and password. Implementation issues with that equipment means 210 that if a RADIUS server does not respond to those qeuries, it may be 211 marked as unresponsive by the NAS. This marking may happen even if 212 the server is actively responding to other Access-Requests from that 213 same NAS. This behavior is confusing to administrators who then need 214 to determine why an active server has been marked as "unresponsive". 216 2.1.1. Recommendation against Access-Request 218 For the reasons outlined above, NAS implementors SHOULD NOT generate 219 Access-Request packets solely to see if a server is alive. 220 Similarly, site administrators SHOULD NOT configure test users whose 221 sole reason for existence is to enable such queries via Access- 222 Request packets. 224 Note that it still may be useful to configure test users for the 225 purpose of performing end-to-end or in-depth testing of a servers 226 policy. While this practice is wide-spread, we caution 227 administrators to use it with care. 229 2.2. Overloading Accounting-Request 231 A similar solution for the problem of querying server status may be 232 for a NAS to send specially formed Accounting-Request packets to a 233 RADIUS servers authentication port. The NAS can then look for a 234 response, and use this information to determine if the server is 235 active or unresponsive. 237 As seen above with Access-Request, the server may then conclude that 238 a real user has logged onto a NAS, and perform local site actions 239 that are undesirable for a simple status query. 241 Another consideration is that some attributes are mandatory to 242 include in an Accounting-Request. This requirement forces the 243 administrator to query an accounting server with fake values for 244 those attributes in a test packet. These fake values increase the 245 work required to perform a simple query, and may pollute the server's 246 accounting database with incorrect data. 248 2.2.1. Recommendation against Accounting-Request 250 For the reasons outlined above, NAS implementors SHOULD NOT generate 251 Accounting-Request packets solely to see if a server is alive. 252 Similarly, site administrators SHOULD NOT configure accounting 253 policies whose sole reason for existence is to enable such queries 254 via Accounting-Request packets. 256 Note that it still may be useful to configure test users for the 257 purpose of performing end-to-end or in-depth testing of a servers 258 policy. While this practice is wide-spread, we caution 259 administrators to use it with care. 261 2.3. Status-Server as a Solution 263 A better solution to the above problems is to use the Status-Server 264 packet code. The name of the code leads us to conclude that it was 265 intended for packets that query the status of a server. Since the 266 packet is otherwise undefined, it does not cause interoperability 267 issues to create implementation-specific definitions for it. The 268 difficulty until now has been defining an inter-operable method of 269 performing these queries. 271 This document addresses that need. 273 2.3.1. Status-Server to the RADIUS Authentication port 275 Status-Server SHOULD be used instead of Access-Request to query the 276 responsiveness of a server. In this use-case, the protocol exchange 277 between client and server is similar to the usual exchange of Access- 278 Request and Access-Accept, as shown below. 280 NAS RADIUS server 281 --- ------------- 282 Status-Server/ 283 Message-Authenticator -> 284 <- Access-Accept/ 285 Reply-Message 287 The Status-Server packet MUST contain a Message-Authenticator 288 attribute for security. The Access-Accept packet can optionally 289 contain an informational Reply-Message attribute. A list of 290 attributes permitted in each type of packet is given in the Table of 291 attributes in Section 6, below. 293 2.3.2. Status-Server to the RADIUS Accounting port 295 Status-Server may be used instead of Accounting-Request to query the 296 responsiveness of a server. In this use-case, the protocol exchange 297 between client and server is similar to the usual exchange of 298 Accounting-Request and Accounting-Response, as shown below. 300 NAS RADIUS server 301 --- ------------- 302 Status-Server/ 303 Message-Authenticator -> 304 <- Accounting-Response 306 The Status-Server packet MUST contain a Message-Authenticator 307 attribute for security. The Accounting-Response packet is empty. A 308 list of attributes permitted in each type of packet is given in the 309 Table of attributes in Section 6, below. 311 3. Packet Format 313 Status-Server packets re-use the RADIUS packet format, with the 314 fields and values for those fields as defined [RFC2865] Section 3. 315 We do not include all of the text or diagrams of that section here, 316 but instead explain the differences required to implement Status- 317 Server. 319 The Authenticator field of Status-Server packets MUST be generated 320 using the same method as that used for the Request Authenticator 321 field of Access-Request packets, as given below. 323 The role of the Identifier field is the same for Status-Server as for 324 other packets. However, as Status-Server is taking the role of 325 Access-Request or Accounting-Request packets, there is the potential 326 for Status-Server requests to be in conflict with Access-Request or 327 Accounting-Request packets with the same Identifier. In Section 4.2, 328 below, we describe a method for avoiding these problems. This method 329 MUST be used to avoid conflicts between Status-Server and other 330 packet types. 332 Request Authenticator 334 In Status-Server Packets, the Authenticator value is a 16 octet 335 random number, called the Request Authenticator. The value 336 SHOULD be unpredictable and unique over the lifetime of a 337 secret (the password shared between the client and the RADIUS 338 server), since repetition of a request value in conjunction 339 with the same secret would permit an attacker to reply with a 340 previously intercepted response. Since it is expected that the 341 same secret MAY be used to authenticate with servers in 342 disparate geographic regions, the Request Authenticator field 343 SHOULD exhibit global and temporal uniqueness. 345 The Request Authenticator value in a Status-Server packet 346 SHOULD also be unpredictable, lest an attacker trick a server 347 into responding to a predicted future request, and then use the 348 response to masquerade as that server to a future Status-Server 349 request from a client. 351 Similarly, the Response Authenticator field of an Access-Accept 352 packet sent in response to Status-Server queries MUST be generated 353 using the same method as used for for calculating the Response 354 Authenticator of the Access-Accept, with the Status-Server Request 355 Authenticator taking the place of the Access-Request Request 356 Authenticator. 358 The Response Authenticator field of an Accounting-Response packet 359 sent in response to Status-Server queries MUST be generated using the 360 same method as used for for calculating the Response Authenticator of 361 the Accounting-Response, with the Status-Server Request Authenticator 362 taking the place of the Accounting-Request Request Authenticator. 364 Note that when a server responds to a Status-Server request, it MUST 365 NOTE send more than one response packet. 367 Response Authenticator 369 The value of the Authenticator field in Access-Accept, or 370 Accounting-Response packets is called the Response 371 Authenticator, and contains a one-way MD5 hash calculated over 372 a stream of octets consisting of: the RADIUS packet, beginning 373 with the Code field, including the Identifier, the Length, the 374 Request Authenticator field from the Status-Server packet, and 375 the response Attributes (if any), followed by the shared 376 secret. That is, ResponseAuth = 377 MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where + 378 denotes concatenation. 380 In addition to the above requirements, all Status-Server packets MUST 381 include a Message-Authenticator attribute. Failure to do so would 382 mean that the packets could be trivially spoofed. 384 Status-Server packets MAY include NAS-Identifier, one of NAS-IP- 385 Address or NAS-IPv6-Address, and Reply-Message. These attributes are 386 not necessary for the operation of Status-Server, but may be useful 387 information to a server that receives those packets. 389 Other attributes SHOULD NOT be included in a Status-Server packet. 390 User authentication credentials such as User-Password, CHAP-Password, 391 EAP-Message, etc. MUST NOT appear in a Status-Server packet sent to a 392 RADIUS authentication port. User or NAS accounting attributes such 393 as Acct-Session-Id, Acct-Status-Type, Acct-Input-Octets, etc. MUST 394 NOT appear in a Status-Server packet sent to a RADIUS accounting 395 port. 397 The Access-Accept MAY contain a Reply-Message or Message- 398 Authenticator attribute. It SHOULD NOT contain other attributes. 399 The Accounting-Response packets sent in response to a Status-Server 400 query SHOULD NOT contain any attributes. As the intent is to 401 implement a simple query instead of user authentication or 402 accounting, there is little reason to include other attributes in 403 either the query or the corresponding response. 405 Examples of Status-Server packet flows are given below in Section 7. 407 3.1. Consistent definition for Status-Server 409 When sent to a RADIUS accounting port, contents of the Status-Server 410 packets are calculated as described above. That is, even though the 411 packets are being sent to an accounting port, they are not created 412 using the same method as Accounting-Request packets. This difference 413 from the handling of Accounting-Request packets has a number of 414 benefits. 416 Having one definition for Status-Server packets is simpler than 417 having different definitions for different destination ports. In 418 addition, if we were to define Status-Server as being similar to 419 Accounting-Request, but containing no attributes, then the packets 420 could be trivially forged. 422 We therefore define Status-Server consistently, and vary the response 423 packets depending on the port to which the request is sent. When 424 sent to an authentication port, the response to a Status-Server query 425 is an Access-Accept packet. When sent to an accounting port, the 426 response to a Status-Server query is an Accounting-Response packet. 428 4. Implementation notes 430 There are a number of considerations to take into account when 431 implementing support for Status-Server. This section describes 432 implementation details and requirements for RADIUS clients and 433 servers that support Status-Server. 435 The following text applies to both authentication and accounting 436 ports. We use the generic terms below to simplify the discussion: 438 * Request packet 440 An Access-Request packet sent to an authentication port, or 441 an Accounting-Request packet sent to an accounting port. 443 * Response packet 445 An Access-Accept, Access-Challenge, or Access-Reject packet sent 446 from an authentication port, or an Accounting-Response packet 447 sent from an accounting port. 449 Using generic terms to describe the Status-Server conversations is 450 simpler than duplicating the text for both authentication and 451 accounting ports. 453 4.1. Client Requirements 455 Clients SHOULD permit administrators to globally enable or disable 456 the generation of Status-Server packets. The default SHOULD be that 457 it is disabled. As it is undesirable to send queries to servers that 458 do not support Status-Server, clients SHOULD also have a per-server 459 configuration indicating whether or not to enable Status-Server for a 460 particular destination. The default SHOULD be that it is disabled. 462 The client SHOULD also have a configurable global timer (Tw) that is 463 used when sending periodic Status-Server queries during server fail- 464 over. The default value SHOULD be 30 seconds, and the value MUST NOT 465 be permitted to be set below 6 seconds. If a response has not been 466 received within the timeout period, the Status-Server packet is 467 deemed to have received no corresponding Response packet, and MUST be 468 discarded. 470 When Status-Server packets are sent from a client, they MUST NOT be 471 retransmitted. Instead, the Identity field MUST be changed every 472 time a packet is transmitted. The old packet should be discarded, 473 and a new Status-Server packet should be generated and sent, with new 474 Identity and Authenticator fields. 476 Clients MUST include the Message-Authenticator attribute in all 477 Status-Server packets. Failure to do so would mean that the packets 478 could be trivially spoofed, leading to potential denial of service 479 (DoS) attacks. Other attributes SHOULD NOT appear in a Status-Server 480 packet, except as outlined below in Section 6. As the intent of the 481 packet is a simple status query, there is little reason for any 482 additional attributes to appear in Status-Server packets. 484 The client MAY increment packet counters as a result of sending a 485 Status-Server request, or receiving a Response packet. The client 486 MUST NOT perform any other action that is normally performed when it 487 receives a Response packet, such as permitting a user to have login 488 access to a port. 490 When a client sends Status-Server packets, those requests SHOULD NOT 491 be sent from a source port that is used to send Access-Request or 492 Accounting-Request packets. Clients MAY send Status-Server requests 493 to both authentication and accounting destination ports from the same 494 source port. 496 The above suggestion for a unique source port for Status-Server 497 packets aids in matching responses to requests. Since the response 498 to a Status-Server packet is an Access-Accept or Accounting-Response 499 packet, those responses are indistinguishable from other packets sent 500 in response to an Access-Request or Accounting-Request. Therefore, 501 the best way to distinguish them from other traffic is to have a 502 unique port. 504 A client MAY send a Status-Server packet from a source port also used 505 to send Access-Request or Accounting-Request packets. In that case, 506 the Identifer field MUST be unique across all outstanding requests 507 for that source port, independent of the value of the RADIUS Code 508 field for those outstanding requests. Once the client has either 509 received a response to the Status-Server packet, or has determined 510 that the Status-Server packet has timed out, it may re-use that 511 Identifier in another packet. 513 When the client receives a response to a Status-Server query, the 514 response may be either an Access-Accept packet or an Accounting- 515 Response packet, depending both on the behavior of the server, and 516 the port to which the query was sent. It may be difficult for the 517 client to know which Response packet to expect. Therefore, a client 518 SHOULD accept either packet code as an acceptable response to a 519 Status-Server query, subject to the validation requirements defined 520 above for the Response Authenticator. 522 That is, prior to accepting the response as valid, the client should 523 check that the Response packet Code field is either Access-Accept (2) 524 or Accounting-Response (5). If the code does not match one of those 525 two values, the packet MUST be silently discarded. The client MUST 526 then validate the Response Authenticator via the algorithm given 527 above in Section 3. If the Response Authenticator is not valid, the 528 packet MUST be silently discarded. If the Response Authenticator is 529 valid, then the packet MUST be deemed to be a valid response from the 530 server. 532 If the client instead discarded the response because the packet code 533 did not match what it expected, then it could erroneously discard 534 valid responses from a server, and mark that server as unresponsive. 535 This behavior would affect the stability of a RADIUS network, as 536 responsive servers would erroneously be marked as unresponsive. We 537 therefore recommend that clients should be liberal in what they 538 accept as responses to Status-Server queries. 540 4.2. Server Requirements 542 Servers SHOULD permit administrators to globally enable or disable 543 the acceptance of Status-Server packets. The default SHOULD be that 544 it is enabled. Servers SHOULD also permit adminstrators to enable or 545 disable acceptance of Status-Server packets on a per-client basis. 546 The default SHOULD be that it is enabled. 548 Status-Server packets originating from clients that are not permitted 549 to send the server Request packets MUST be silently discarded. If a 550 server does not support Status-Server packets, or is configured to 551 not respond to them, then it MUST silently discard the packet. 553 We note that [RFC2865] Section 3 defines a number of RADIUS Codes, 554 but does not make statements about which Codes are valid for port 555 1812. In contrast, [RFC2866] Section 3 specifies that only RADIUS 556 Accounting packets are to be sent to port 1813. This specification 557 is compatible with [RFC2865], as it uses a known Code for packets to 558 port 1812. This specification is not compatible with [RFC2866], as 559 it adds a new code (Status-Server) that is valid for port 1812. 560 However, as the category of [RFC2866] is Informational, this conflict 561 is acceptable. 563 Servers SHOULD silently discard Status-Server packets if they 564 determine that a client is sending too many Status-Server requests in 565 a particular time period. The method used by a server to make this 566 determination is implementation-specific, and out of scope for this 567 specification. 569 If a server supports Status-Server packets, and is configured to 570 respond to them, and receives a packet from a known client, it MUST 571 validate the Message-Authenticator attribute as defined in [RFC3579] 572 Section 3.2. Packets failing that validation MUST be silently 573 discarded. 575 Servers SHOULD NOT otherwise discard Status-Server packets if they 576 have recently sent the client a Response packet. The query may have 577 originated from an administrator who does not have access to the 578 Response packet stream, or who is interested in obtaining additional 579 information about the server. 581 The server MAY prioritize the handling Status-Server queries over the 582 handling of other requests, subject to the rate limiting described 583 above. 585 The server MAY decide to not respond to a Status-Server, depending on 586 local site policy. For example, a server that is running but is 587 unable to perform it's normal activities MAY silently discard Status- 588 Server packets. This situation can happen, for example, when a 589 server requires access to a database for normal operation, but the 590 connection to that database is down. Or, it may happen when the 591 accept load on the server is lower than the offered load. 593 Some server implementations require that Access-Request packets are 594 accepted only on "authentication" ports, (e.g. 1812/udp), and that 595 Accounting-Request packets are accepted only on "accounting" ports 596 (e.g. 1813/udp). Those implementations SHOULD reply to Status-Server 597 packets sent to an "authentication" port with an Access-Accept 598 packet. Those implementations SHOULD reply to Status-Server packets 599 sent to an "accounting" port with an Accounting-Response packet. 601 Some server implementations accept both Access-Request and 602 Accounting-Request packets on the same port, and do not distinguish 603 between "authentication only" ports, and "accounting only" ports. 604 Those implementations SHOULD reply to Status-Server packets with an 605 Access-Accept packet. 607 The server MAY increment packet counters as a result of receiving a 608 Status-Server, or sending a Response packet. The server SHOULD NOT 609 perform any other action that is normally performed when it receives 610 a Request packet, other than sending a Response packet. 612 4.3. More Robust Fail-over with Status-Server 614 A common problem in RADIUS client implementations is the 615 implementation of a robust fail-over mechanism between servers. A 616 client may have multiple servers configured, with one server marked 617 as primary and another marked as secondary. If the client determines 618 that the primary is unresponsive, it can "fail over" to the 619 secondary, and send requests to the secondary instead of to the 620 primary. 622 However, it is difficult in standard RADIUS for a client to know when 623 it should start sending requests to the primary again. Sending test 624 Access-Requests or Accounting-Requests to see if the server is alive 625 has the issues outlined above in Section 2. Clients could 626 alternately send real traffic to the primary, on the hope that it is 627 responsive. If the server is still unresponsive, however, the result 628 may be user login failures. The Status-Server solution is an ideal 629 one to solve this problem. 631 When a client fails over from one server to another because of a lack 632 of responsiveness, it SHOULD send periodic Status-Server packets to 633 the unresponsive server, using the timer (Tw) defined above. 635 Once three time periods have passed where Status-Server messages have 636 been sent and responded to, the server should be deemed responsive 637 and RADIUS requests may sent to it again. This determination should 638 be made separately for each server that the client has a relationship 639 with. The same algorithm should be used for both authentication and 640 accounting ports. The client MUST treat each destination (ip, port) 641 combination as a unique server for the purposes of this 642 determination. 644 The above behavior is modelled after [RFC3539] Section 3.4.1. We 645 note that if a reliable transport is used for RADIUS, then the 646 algorithms specified in [RFC3539] MUST be used in preference to the 647 ones given here. 649 4.4. Proxy Server handling of Status-Server 651 Many RADIUS servers can act as proxy servers, and can forward 652 requests to home servers. Such servers MUST NOT proxy Status-Server 653 packets. The purpose of Status-Server as specified here is to permit 654 the client to query the responsiveness of a server that it has a 655 direct relationship with. Proxying Status-Server queries would 656 negate any usefulness that may be gained by implementing support for 657 them. 659 Proxy servers MAY be configured to respond to Status-Server queries 660 from clients, and MAY act as clients sending Status-Server queries to 661 other servers. However, those activities MUST be independent of one 662 another. 664 4.5. Realm Routing 666 RADIUS servers are commonly used in an environment where Network 667 Access Identifiers (NAIs) are used as routing identifiers [RFC4282]. 668 In this practice, the User-Name attribute is decorated with realm 669 routing information, commonly in the format of "user@realm". Since a 670 particular RADIUS server may act as a proxy for more than one realm, 671 the mechanism outlined above may be inadequate. 673 The schematic below demonstrates this scenario. 675 /-> Proxy Server P -----> Home Server for Realm A 676 / \ / 677 NAS X 678 \ / \ 679 \-> Proxy Server S -----> Home Server for Realm B 681 That is, the NAS has relationships with two Proxy Servers, P and S. 682 Each Proxy Server has relationships with Home Servers for both Realm 683 A and Realm B. 685 In this scenario, the Proxy Servers can determine if one or both of 686 the Home Servers are dead or unreachable. The NAS can determine if 687 one or both of the Proxy Servers are dead or unreachable. There is 688 an additional case to consider, however. 690 If Proxy Server P cannot reach the Home Server for Realm A, but the 691 Proxy Server S can reach that Home Server, then the NAS cannot 692 discover this information using the Status-Server queries as outlined 693 above. It would therefore be useful for the NAS to know that Realm A 694 is reachable from Proxy Server S, as it can then route all requests 695 for Realm A to that Proxy Server. Without this knowledge, the client 696 may route requests to Proxy Server P, where they may be discarded or 697 rejected. 699 To complicate matters, the behavior of Proxy Servers P and S in this 700 situation is not well defined. Some implementations simply fail to 701 respond to the request, and other implementations respond with an 702 Access-Reject. If the implementation fails to respond, then the NAS 703 cannot distinguish between the Proxy Server being down, or the next 704 server along along the proxy chain is unreachable. 706 In the worst case, failures in routing for Realm A may affect users 707 Realm B. For example, if Proxy Server P can reach Realm B but not 708 Realm A, and Proxy Server S can reach Realm A but not Realm B, then 709 active paths exist to handle all RADIUS requests. However, depending 710 on the NAS and Proxy Server implementation choices, the NAS may not 711 be able to determine which server requests may be sent to in order to 712 maintain network stability. 714 This problem cannot, unfortunately be solved by using Status-Server 715 requests. A robust solution would involve either a RADIUS routing 716 table for the NAI realms, or a RADIUS "destination unreachable" 717 response to authentication requests. Either solution would not fit 718 into the traditional RADIUS model, and both are therefore outside of 719 the scope of this specification. 721 The problem is discussed here in order to define how best to use 722 Status-Server in this situation, rather than to define a new 723 solution. 725 When a server has responded recently to a request from a client, that 726 client MUST mark the server as "responsive". In the above case, a 727 Proxy Server may be responding to requests destined for Realm A, but 728 not responding to requests destined for Realm B. The client 729 therefore considers the server to be responsive, as it is receiving 730 responses from the server. 732 The client will then continue to send requests to the Proxy Server 733 for destination Realm B, even though the Proxy Server cannot route 734 the requests to that destination. This failure is a known limitation 735 of RADIUS, and can be partially addressed through the use of failover 736 in the Proxy Servers. 738 A more realistic situation than the one outlined above is where each 739 Proxy Server also has multiple choices of Home Servers for a realm, 740 as outlined below. 742 /-> Proxy Server P -----> Home Server P 743 / \ / 744 NAS X 745 \ / \ 746 \-> Proxy Server S -----> Home Server S 748 In this situation, if all participants impement Status-Server as 749 defined herein, any one link may be broken, and all requests from the 750 NAS will still reach a home server. If two links are broken at 751 different places, (i.e. not both links from the NAS), then all 752 requests from the NAS will still reach a home server. In many 753 situations where three or more links are broken, then requests from 754 the NAS may still reach a home server. 756 It is RECOMMENDED, therefore, that implementations desiring the most 757 benefit from Status-Server also implement server failover. The 758 combination of these two practices will maximize network reliability 759 and stability. 761 4.6. Management Information Base (MIB) Considerations 763 4.6.1. Interaction with RADIUS Server MIBs 765 Since Status-Server packets are sent to the defined RADIUS ports, 766 they can affect the [RFC4669] and [RFC4671] RADIUS server MIBs. 767 [RFC4669] defines a counter named radiusAuthServTotalUnknownTypes, 768 that counts "The number of RADIUS packets of unknown type that were 769 received". [RFC4671] defines a similar counter named 770 radiusAcctServTotalUnknownTypes. Implementations not supporting 771 Status-Server, or implementations that are configured to not respond 772 to Status-Server packets MUST use these counters to track received 773 Status-Server packets. 775 If, however, Status-Server is supported and the server is configured 776 to respond as described above, then the counters defined in [RFC4669] 777 and [RFC4671] MUST NOT be used to track Status-Server requests or 778 responses to those requests. That is, when a server fully implements 779 Status-Server, the counters defined in [RFC4669] and [RFC4671] MUST 780 be unaffected by the transmission or reception of packets relating to 781 Status-Server. 783 If a server supports Status-Server and the [RFC4669] or [RFC4671] 784 MIBs, then it SHOULD also support vendor-specific MIBs containing 785 similar information as the standard MIBs, but which are instead 786 dedicated solely to tracking Status-Server requests and responses. 787 Any definition of the server MIBs for Status-Server is outside of the 788 scope of this document. 790 4.6.2. Interaction with RADIUS Client MIBs 792 Clients implementing Status-Server MUST NOT increment [RFC4668] or 793 [RFC4670] counters upon reception of Response packets to Status- 794 Server queries. That is, when a server fully implements Status- 795 Server, the counters defined in [RFC4668] and [RFC4670] MUST be 796 unaffected by the transmission or reception of packets relating to 797 Status-Server. 799 If an implementation supports Status-Server and the [RFC4668] or 800 [RFC4670] MIBs, then it SHOULD also support vendor-specific MIBs 801 containing similar information as those MIBs, but which are instead 802 dedicated solely to tracking Status-Server requests and responses. 803 Any definition of the client MIBs for Status-Server is outside of the 804 scope of this document. 806 5. Additional considerations 808 There are additional topics related to the use of Status-Server that 809 may be covered. As those topics do not fit well into the preceding 810 sections, they are covered herein. 812 5.1. Local site testing 814 There is at least one situation where using Access-Request or 815 Accounting-Request packets may be useful, despite the recommendations 816 above in Section 2.1.1 and Section 2.2.1. That situation is local 817 site testing, where the RADIUS client, server, and user store are 818 under the control of a single administrator or administrative entity. 819 In that situation, administrators MAY configure a well-known "test" 820 user to enable local site testing. 822 The advantage to creating such a local user is that it is now 823 possible for the administrator to send a RADIUS request that performs 824 end-to-end testing of the RADIUS server. As above with Status- 825 Server, this testing includes RADIUS server responsiveness. It may 826 also include querying databases of user authentication credentials, 827 or storing accounting data to a billing database. The information 828 obtained from performing those queries is that the entire RADIUS 829 server infrastructure, including all of it's dependencies, is 830 functioning as expected. These queries are most useful in 831 deployments where an administrator has internal RADIUS server that 832 proxy to other internal RADIUS servers, such as for load balancing or 833 fail over. 835 If used, the names used for these test users SHOULD be difficult to 836 guess by an attacker. An Access-Request packet for a test user 837 otherwise should be treated as follows, depending on its origin: 839 o Packets from localhost (127.0.0.1 or ::1): RADIUS servers 840 SHOULD treat the request according to local site policy. 842 o Packets from NASes that normally originate Access-Request 843 packets (i.e. not proxy servers): RADIUS servers SHOULD respond 844 with an Access-Reject packet, as the use of Status-Server is 845 preferred. 847 o Packets from other machines controlled by the administrator: 848 RADIUS servers SHOULD treat the request according to local site 849 policy. 851 o Packets originating from machines not controlled by the 852 administrator: RADIUS servers MUST respond with an Access-Reject 853 packet. 855 If a RADIUS server is configured to support test users for 856 Accounting-Request packets, it MAY respond with an Accounting- 857 Response packet, independent of the origin of the request. However, 858 any subsequent analysis of the accounting data such as billing or 859 usage MUST NOT include the data for the test user. 861 If these recommendations are implemented, then it may be possible in 862 some situations to safely query a RADIUS server for responsiveness 863 using Access-Request or Accounting-Request packets. However, this 864 behavior is still NOT RECOMMENDED. 866 5.2. RADIUS over reliable transports 868 Although RADIUS has been assigned two TCP ports (1812/tcp and 869 1813/tcp) in addition to the commonly used UDP ports, there has been 870 as yet no specification for using TCP as a reliable transport for 871 RADIUS. If such a specification were to be created, then the 872 transport issues discussed in [RFC3539] would apply. 874 Further, when RADIUS is run over reliable transports, the watchdog 875 algorithm described in [RFC3539] Section 3.4 MUST be used rather than 876 the algorithm described above. For the reasons outlined above in 877 Section 2, Status-Server packets SHOULD be used as the watchdog 878 request, in preference to Access-Request or Accounting-Request 879 packets. 881 Clients sending Status-Server over reliable transport MUST ensure 882 that the Identifier field is unique for all requests on a particular 883 connection, independent of the packet code. That is, if a Status- 884 Server with a particular value in the Identifier field is sent to a 885 server, the client MUST NOT simultaneously send an Access-Request or 886 Accounting-Request packet with that same Identifier value, on that 887 connection. Once the client has either received a response to the 888 Status-Server packet, or has determined that the Status-Server packet 889 has timed out, it may re-use that Identifier in another packet. 891 5.3. Other uses for Status-Server 893 While other uses of Status-Server are possible, uses beyond those 894 specified here are beyond the scope of this document. It may be 895 tempting to increase the utility of Status-Server by having the 896 responses carry additional information, implementors are warned that 897 such uses have not been analyzed for potential security issues or 898 network problems. 900 5.4. Potential Uses for Status-Client 902 RADIUS currently defines an experimental Status-Client packet type, 903 in addition to Status-Server. It could be possible to define Status- 904 Client similar to Status-Server, except that it would be applicable 905 to Change of Authorization, and Disconnect-Request packets, currently 906 sent to a NAS on port 3799 [RFC5176]. 908 We do no more than mention the possibility here. Any definition of 909 Status-Client is outside of the scope of this document. 911 6. Table of Attributes 913 The following table provide a guide to which attributes may be found 914 in Status-Server packets, and in what quantity. No attributes other 915 than the ones listed below should be found in a Status-Server packet. 917 Status- Access- Accounting- 918 Server Accept Response # Attribute 919 0-1 0 0 4 NAS-IP-Address 920 0 0+ 0 18 Reply-Message 921 0+ 0+ 0+ 26 Vendor-Specific 922 0+ 0+ 0 31 Calling-Station-Id 923 0-1 0 0 32 NAS-Identifier 924 1 0-1 0-1 80 Message-Authenticator 925 0-1 0 0 95 NAS-IPv6-Address 927 The following table defines the meaning of the above table entries. 929 0 This attribute MUST NOT be present in packet. 930 0+ Zero or more instances of this attribute MAY be present in packet. 931 0-1 Zero or one instance of this attribute MAY be present in packet. 932 1 Exactly one instance of this attribute MUST be present in packet. 934 7. Examples 936 A few examples are presented to illustrate the flow of packets to 937 both the authentication and accounting ports. These examples are not 938 intended to be exhaustive, many others are possible. Hexadecimal 939 dumps of the example packets are given in network byte order, using 940 the shared secret "xyzzy5461". 942 7.1. Minimal Query to Authentication Port 944 The NAS sends a Status-Server UDP packet with minimal content to a 945 RADIUS server on port 1812. 947 The Request Authenticator is a 16 octet random number generated by 948 the NAS. Message-Authenticator is included in order to authenticate 949 that the request came from a known client. 951 0c da 00 26 8a 54 f4 68 6f b3 94 c5 28 66 e3 02 952 18 5d 06 23 50 12 5a 66 5e 2e 1e 84 11 f3 e2 43 953 82 20 97 c8 4f a3 955 1 Code = Status-Server (12) 956 1 ID = 218 957 2 Length = 38 958 16 Request Authenticator 960 Attributes: 961 18 Message-Authenticator (80) = 5a665e2e1e8411f3e243822097c84fa3 963 The Response Authenticator is a 16-octet MD5 checksum of the code 964 (2), id (218), Length (20), the Request Authenticator from above, and 965 the shared secret. 967 02 da 00 14 ef 0d 55 2a 4b f2 d6 93 ec 2b 6f e8 968 b5 41 1d 66 970 1 Code = Access-Accept (2) 971 1 ID = 218 972 2 Length = 20 973 16 Request Authenticator 975 Attributes: 976 None. 978 7.2. Minimal Query to Accounting Port 980 The NAS sends a Status-Server UDP packet with minimal content to a 981 RADIUS server on port 1813. 983 The Request Authenticator is a 16 octet random number generated by 984 the NAS. Message-Authenticator is included in order to authenticate 985 that the request came from a known client. 987 0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb 1d b7 988 ad 38 82 60 80 12 e8 d6 ea bd a9 10 87 5c d9 1f 989 da de 26 36 78 58 991 1 Code = Status-Server (12) 992 1 ID = 179 993 2 Length = 38 994 16 Request Authenticator 996 Attributes: 997 18 Message-Authenticator (80) = e8d6eabda910875cd91fdade26367858 999 The Response Authenticator is a 16-octet MD5 checksum of the code 1000 (5), id (179), Length (20), the Request Authenticator from above, and 1001 the shared secret. 1003 02 b3 00 1a 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a 1004 48 60 66 9c 1006 1 Code = Accounting-Response (5) 1007 1 ID = 179 1008 2 Length = 20 16 Request Authenticator 1010 Attributes: 1011 None. 1013 7.3. Verbose Query and Response 1015 The NAS at 192.0.2.16 sends a Status-Server UDP packet to the RADIUS 1016 server on port 1812. 1018 The Request Authenticator is a 16 octet random number generated by 1019 the NAS. 1021 0c 47 00 2c bf 58 de 56 ae 40 8a d3 b7 0c 85 13 1022 f9 b0 3f be 04 06 c0 00 02 10 50 12 85 2d 6f ec 1023 61 e7 ed 74 b8 e3 2d ac 2f 2a 5f b2 1025 1 Code = Status-Server (12) 1026 1 ID = 71 1027 2 Length = 44 1028 16 Request Authenticator 1030 Attributes: 1031 6 NAS-IP-Address (4) = 192.0.2.16 1032 18 Message-Authenticator (80) = 852d6fec61e7ed74b8e32dac2f2a5fb2 1034 The Response Authenticator is a 16-octet MD5 checksum of the code 1035 (2), id (71), Length (52), the Request Authenticator from above, the 1036 attributes in this reply, and the shared secret. 1038 The Reply-Message is "RADIUS Server up 2 days, 18:40" 1040 02 47 00 34 46 f4 3e 62 fd 03 54 42 4c bb eb fd 1041 6d 21 4e 06 12 20 52 41 44 49 55 53 20 53 65 72 1042 76 65 72 20 75 70 20 32 20 64 61 79 73 2c 20 31 1043 38 3a 34 30 1045 1 Code = Access-Accept (2) 1046 1 ID = 71 1047 2 Length = 52 1048 16 Request Authenticator 1050 Attributes: 1051 32 Reply-Message (18) 1053 8. IANA Considerations 1055 This specification does not create any new registries, nor does it 1056 require assignment of any protocol parameters. 1058 9. Security Considerations 1060 This document defines the Status-Server packet as being similar in 1061 treatment to the Access-Request packet, and is therefore subject to 1062 the same security considerations as described in [RFC2865], Section 1063 8. Status-Server packets also use the Message-Authenticator 1064 attribute, and are therefore subject to the same security 1065 considerations as [RFC3579], Section 4. 1067 We reiterate that Status-Server packets MUST contain a Message- 1068 Authenticator attribute. Early implementations supporting Status- 1069 Server did not enforce this requirement, and may have been vulnerable 1070 to DoS attacks as a result. 1072 Where this document differs from [RFC2865] is that it defines a new 1073 request/response method in RADIUS; the Status-Server request. As 1074 this use is based on previously described and implemented standards, 1075 we know of no additional security considerations that arise from the 1076 use of Status-Server as defined herein. 1078 10. References 1080 10.1. Normative references 1082 [RFC2865] 1083 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 1084 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 1086 [RFC2866] 1087 Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1089 [RFC3579] 1090 Aboba, B., Calhoun, P., "RADIUS (Remote Authentication Dial In User 1091 Service) Support For Extensible Authentication Protocol (EAP)", RFC 1092 3579, September 2003. 1094 [RFC4282] 1095 Aboba, B., and Beadles, M. at al, "The Network Access Identifier", 1096 RFC 4282, December 2005. 1098 10.2. Informative references 1100 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1101 Requirement Levels", RFC 2119, March, 1997. 1103 [RFC3539] Aboba, B., Wood, J., "Authentication, Authorization, and 1104 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 1106 [RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6", RFC 1107 4668, August 2006. 1109 [RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6", RFC 1110 4669, August 2006. 1112 [RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC 4670, 1113 August 2006. 1115 [RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC 4671, 1116 August 2006. 1118 [RFC5176] Chiba, M., Eklund, M., et al, "Dynamic Authorization 1119 Extensions to Remote Authentication Dial In User Service 1120 (RADIUS)", RFC 5176, January 2008. 1122 Acknowledgments 1124 Parts of the text in Section 3 defining the Request and Response 1125 Authenticators were taken with minor edits from [RFC2865] Section 3. 1127 The author would like to thank Mike McCauley of Open Systems 1128 Consultants for making a Radiator server available for inter- 1129 operability testing. 1131 Authors' Addresses 1133 Alan DeKok 1134 The FreeRADIUS Server Project 1135 http://freeradius.org 1137 Email: aland@freeradius.org 1139 Intellectual Property Statement 1141 The IETF takes no position regarding the validity or scope of any 1142 Intellectual Property Rights or other rights that might be claimed to 1143 pertain to the implementation or use of the technology described in 1144 this document or the extent to which any license under such rights 1145 might or might not be available; nor does it represent that it has 1146 made any independent effort to identify any such rights. Information 1147 on the procedures with respect to rights in RFC documents can be 1148 found in BCP 78 and BCP 79. 1150 Copies of IPR disclosures made to the IETF Secretariat and any 1151 assurances of licenses to be made available, or the result of an 1152 attempt made to obtain a general license or permission for the use of 1153 such proprietary rights by implementers or users of this 1154 specification can be obtained from the IETF on-line IPR repository at 1155 http://www.ietf.org/ipr. 1157 The IETF invites any interested party to bring to its attention any 1158 copyrights, patents or patent applications, or other proprietary 1159 rights that may cover technology that may be required to implement 1160 this standard. Please address the information to the IETF at ietf- 1161 ipr@ietf.org. 1163 Disclaimer of Validity 1165 This document and the information contained herein are provided on an 1166 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1167 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1168 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1169 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1170 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1171 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1173 Full Copyright Statement 1175 Copyright (C) The IETF Trust (2008). 1177 This document is subject to the rights, licenses and restrictions 1178 contained in BCP 78, and except as set forth therein, the authors 1179 retain all their rights. 1181 Acknowledgment 1183 Funding for the RFC Editor function is currently provided by the 1184 Internet Society.