idnits 2.17.1 draft-ietf-radext-tcp-transport-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RTLS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 date (19 February 2010) is 5181 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-radext-status-server-06 == Outdated reference: A later version (-12) exists of draft-ietf-radext-radsec-05 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. DeKok 3 INTERNET-DRAFT FreeRADIUS 4 Category: Experimental 5 6 Expires: April 12,2009 7 19 February 2010 9 RADIUS Over TCP 10 draft-ietf-radext-tcp-transport-05 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and 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 April 12, 2009. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info/) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Abstract 52 The Remote Authentication Dial In User Server (RADIUS) Protocol has 53 traditionally used the User Datagram Protocol (UDP) as its underlying 54 transport layer. This document defines RADIUS over the Transmission 55 Control Protocol (TCP), in order to address handling issues related 56 to RADIUS over TLS [RTLS]. It is not intended to define TCP as a 57 transport protocol for RADIUS in the absence of TLS. 59 Table of Contents 61 1. Introduction ............................................. 4 62 1.1. Applicability of Reliable Transport ................. 4 63 1.2. Terminology ......................................... 6 64 1.3. Requirements Language ............................... 7 65 2. Changes to RADIUS ........................................ 7 66 2.1. Packet Format ....................................... 7 67 2.2. Assigned Ports for RADIUS Over TCP .................. 8 68 2.3. Management Information Base (MIB) ................... 8 69 2.4. Detecting Live Servers .............................. 9 70 2.5. Congestion Control Issues ........................... 10 71 2.6. TCP Specific Issues ................................. 10 72 2.6.1. Duplicates and Retransmissions ................. 11 73 2.6.2. Head of Line Blocking .......................... 12 74 2.6.3. Shared Secrets ................................. 12 75 2.6.4. Malformed Packets and Unknown Clients .......... 13 76 2.6.5. Limitations of the ID Field .................... 14 77 2.6.6. EAP Sessions ................................... 14 78 2.6.7. TCP Applications are not UDP Applications ...... 15 79 3. Diameter Considerations .................................. 15 80 4. IANA Considerations ...................................... 15 81 5. Security Considerations .................................. 15 82 6. References ............................................... 16 83 6.1. Normative References ................................ 16 84 6.2. Informative References .............................. 16 86 1. Introduction 88 The RADIUS Protocol has been defined in [RFC2865] as using the User 89 Datagram Protocol (UDP) for the underlying transport layer. While 90 there are a number of benefits to using UDP as outlined in [RFC2865] 91 Section 2.4, there are also some limitations: 93 * Unreliable transport. As a result, systems using RADIUS have to 94 implement application-layer timers and re-transmissions, as 95 described in [RFC5080] Section 2.2.1. 97 * Packet fragmentation. [RFC2865] Section 3 permits RADIUS 98 packets up to 4096 octets in length. These packets are larger 99 than the default Internet MTU (576), resulting in fragmentation of 100 the packets at the IP layer. Transport of fragmented UDP packets 101 appears to be a poorly tested code path on network devices. Some 102 devices appear to be incapable of transporting fragmented UDP 103 packets, making it difficult to deploy RADIUS in a network where 104 those devices are deployed. 106 * Connectionless transport. Neither clients nor servers receive 107 positive statements that a "connection" is down. This information 108 has to be deduced instead from the absence of a reply to a 109 request. 111 As RADIUS is widely deployed, and has been widely deployed for well 112 over a decade, these issues have been minor in some use-cases, and 113 problematic in others. For use-cases such as inter-server proxying, 114 [RTLS] suggests an alternative transport and security model -- RADIUS 115 over TLS. This document describes the transport implications of 116 running RADIUS over TLS/TCP. 118 1.1. Applicability of Reliable Transport 120 The intent of this document is to address transport issues related to 121 RADIUS over TLS [RTLS] in inter-server communications scenarios, such 122 as inter-domain communication between proxies. These situations 123 benefit from the confidentiality and ciphersuite negotiation that can 124 be provided by TLS. Since TLS is already widely available within the 125 operating systems used by proxies, implementation barriers are low. 127 In scenarios where RADIUS proxies exchange a large volume of packets 128 (10+ packets per second), it is likely that there will be sufficient 129 traffic to enable the congestion window to be widened beyond the 130 minimum value on a long-term basis, enabling ACK piggy-backing. 131 Through use of an application-layer watchdog as described in 132 [RFC3539], it is possible to address the objections to reliable 133 transport described in [RFC2865] Section 2.4 without substantial 134 watchdog traffic, since regular traffic is expected in both 135 directions. 137 In addition, use of RADIUS over TLS/TCP has been found to improve 138 operational performance when used with multi-round trip 139 authentication mechanisms such as RADIUS over EAP [RFC3579]. In such 140 exchanges, it is typical for EAP fragmentation to increase the number 141 of round-trips required. For example, where EAP-TLS authentication 142 [RFC5216] is attempted and both the EAP peer and server utilize 143 certificate chains of 8KB, as many as 15 round-trips can be required 144 if RADIUS packets are restricted to 1500 octets in size. 145 Fragmentation of RADIUS over UDP packets is generally inadvisable due 146 to lack of fragmentation support within intermediate devices such as 147 filtering routers, firewalls and NATs. However, since RADIUS over 148 UDP implementations typically do not support MTU discovery, 149 fragmentation can occur even when the maximum RADIUS over UDP packet 150 size is restricted to 1500 octets. 152 These problems disappear if a 4096 application-layer payload can be 153 used alongside RADIUS over TLS/TCP. Since most TCP implementations 154 support MTU discovery, the TCP MSS is automatically adjusted to 155 account for the MTU, and the larger congestion window supported by 156 TCP may allow multiple TCP segments to be sent within a single 157 window. 159 Where the MTU for EAP packets is large, RADIUS/EAP traffic required 160 for an EAP-TLS authentication with 8KB certificate chains may be 161 reduced to 7 round-trips or less, resulting in substantially reduced 162 authentication times. 164 In addition, experience indicates that EAP sessions transported over 165 RTLS are less likely to abort unsuccessfully. Historically, RADIUS 166 over UDP implementations have exhibited poor retransmission behavior. 167 Some implementations retransmit packets, others do not, and others 168 send new packets rather then performing retransmission. Some 169 implementations are incapable of detecting EAP retransmissions, and 170 will instead treat the retransmitted packet as an error. As a 171 result, within RADIUS over UDP implementations, retransmissions have 172 a high likeilhood of causing an EAP authentication session to fail. 173 For a system with a million logins a day running EAP-TLS mutual 174 authentication with 15 round-trips, and having a packet loss 175 probability of P=0.01%, we expect that 0.3% of connections will 176 experience at least one lost packet. That is, 3,000 user sessions 177 each day will experience authentication failure. This is an 178 unacceptable failure rate for a mass-market network service. 180 Using a reliable transport method such as TCP means that RADIUS 181 implementations can remove all application-layer retransmissions, and 182 instead rely on the Operating System (OS) kernel's well-tested TCP 183 transport to ensure Path MTU discovery and reliable delivery. Modern 184 TCP implementations also implement anti-spoofing provisions, which is 185 more difficult to do in a UDP application. 187 In contrast, use of TCP as a transport between a NAS and a RADIUS 188 server is usually a poor fit. As noted in [RFC3539] Section 2.1, for 189 systems originating low numbers of RADIUS request packets, inter- 190 packet spacing is often larger than the packet RTT, meaning that, the 191 congestion window will typically stay below the minimum value on a 192 long-term basis. The result is an increase in packets due to ACKs as 193 compared to UDP, without a corresponding set of benefits. In 194 addition, the lack of substantial traffic implies the need for 195 additional watchdog traffic to confirm reachability. 197 As a result, the objections to reliable transport indicated in 198 [RFC2865] Section 2.4 continue to apply to NAS-RADIUS server 199 communications and UDP SHOULD continue to be used as the transport 200 protocol in this scenario. In addition, it is recommended that 201 implementations of "RADIUS Dynamic AUthorization Extensions" 202 [RFC5176] SHOULD continue to utilize UDP transport, since the volume 203 of dynamic authorization traffic is usually expected to be small. 205 Since "bare" TCP does not provide for confidentiality or enable 206 negotiation of credible ciphersuites, its use is not appropriate for 207 inter-server communications where strong security is required. As a 208 result the use of "bare" TCP transport (i.e. without additional 209 confidentiality and security) is NOT RECOMMENDED for use in any 210 situation, and there has been little or no operational experience 211 with it. 213 1.2. Terminology 215 This document uses the following terms: 217 RADIUS client 218 A device that provides an access service for a user to a network. 219 Also referred to as a Network Access Server, or NAS. 221 RADIUS server 222 A RADIUS authentication, authorization, and/or accounting (AAA) 223 server is an entity that provides one or more AAA services to a 224 NAS. 226 RADIUS proxy 227 A RADIUS proxy acts as a RADIUS server to the NAS, and a RADIUS 228 client to the RADIUS server. 230 RADIUS request packet 231 A packet originated by a RADIUS client to a RADIUS server. e.g. 232 Access-Request, Accounting-Request, CoA-Request, or Disconnect- 233 Request. 235 RADIUS response packet 236 A packet sent by a RADIUS server to a RADIUS client, in response to 237 a RADIUS request packet. e.g. Access-Accept, Access-Reject, 238 Access-Challenge, Accounting-Response, CoA-ACK, etc. 240 1.3. Requirements Language 242 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 243 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 244 document are to be interpreted as described in [RFC2119]. 246 2. Changes to RADIUS 248 RADIUS over TCP involves sending RADIUS application messages over a 249 TCP connection. In the sections that follow, we discuss the 250 implications for the RADIUS packet format (Section 2.1), port usage 251 (Section 2.2), RADIUS MIBs (Section 2.3) and RADIUS proxies (Section 252 2.5). TCP-specific issues are discussed in Section 2.6. 254 2.1. Packet Format 256 The RADIUS packet format is unchanged from [RFC2865], [RFC2866], and 257 [RFC5176]. Specifically, all of the following portions of RADIUS 258 MUST be unchanged when using RADIUS over TCP: 260 * Packet format 261 * Permitted codes 262 * Request Authenticator calculation 263 * Response Authenticator calculation 264 * Minimum packet length 265 * Maximum packet length 266 * Attribute format 267 * Vendor-Specific Attribute (VSA) format 268 * Permitted data types 269 * Calculations of dynamic attributes such as CHAP-Challenge, 270 or Message-Authenticator. 271 * Calculation of "encrypted" attributes such as Tunnel-Password. 273 The use of TLS/TCP transport does not change the calculation of 274 security-related fields (such as the Response-Authenticator) in 275 RADIUS [RFC2865] or RADIUS Dynamic Authorization [RFC5176]. 276 Calculation of attributes such as User-Password [RFC2865] or Message- 277 Authenticator [RFC3579] also does not change. 279 Clients and servers MUST be able to store and manage shared secrets 280 based on the key described above, of (IP address, port, transport 281 protocol). 283 The changes to RADIUS implementations required to implement this 284 specification are largely limited to the portions that send and 285 receive packets on the network. 287 2.2. Assigned Ports for RADIUS Over TCP 289 IANA has already assigned TCP ports for RADIUS and RTLS transport, as 290 outlined below: 292 * radius 1812/tcp 293 * radius-acct 1813/tcp 294 * radius-dynauth 3799/tcp 295 * radsec 2083/tcp 297 Since these ports are unused by existing RADIUS implementations, the 298 assigned values SHOULD be used as the default ports for RADIUS over 299 TCP. 301 The early deployment of RADIUS was done using UDP port number 1645, 302 which conflicts with the "datametrics" service. Implementations 303 using RADIUS over TCP MUST NOT use TCP ports 1645 or 1646 as the 304 default ports for this specification. 306 The "radsec" port (2083/tcp) SHOULD be used as the default port for 307 RTLS. The "radius" port (1812/tcp) SHOULD NOT be used for RTLS. 309 2.3. Management Information Base (MIB) 311 The MIB Module definitions in [RFC4668], [RFC4669], [RFC4670], 312 [RFC4671], [RFC4672], and [RFC4673] each contain only one reference 313 to UDP. These references are in the DESCRIPTION field of the MIB 314 Module definition, and are in the form of "The UDP port" or "the UDP 315 destination port". 317 Implementations of RADIUS over TCP SHOULD re-use these MIB Modules to 318 perform statistics counting for RADIUS over TCP connections. 319 However, implementors are warned that there is no way for these MIB 320 Modules to distinguish between packets sent over UDP or over TCP 321 transport. Similarly, there is no requirement in RADIUS that the 322 RADIUS services offered over UDP on a particular IP address and port 323 are identical to the RADIUS services offered over TCP on a particular 324 IP address and the same (numerical) port. 326 Implementations of RADIUS over TCP SHOULD include the protocol (UDP) 327 or (TCP) in the radiusAuthServIdent, radiusAuthClientID, 328 radiusAuthClientIdentifier, radiusAccServIdent, radiusAccClientID, or 329 radiusAccClientIdentifier fields of the MIB Module. This information 330 can help the administrator distinguish capabilities of systems in the 331 network. 333 2.4. Detecting Live Servers 335 As RADIUS is a "hop by hop" protocol, a RADIUS proxy effectively 336 shields the client from any information about downstream servers. 337 While the client may be able to deduce the operational state of the 338 local server (i.e. proxy), it cannot make any determination about the 339 operational state of the downstream servers. 341 Within RADIUS as defined in [RFC2865], proxies typically only forward 342 traffic between the NAS and RADIUS server, and do not generate their 343 own responses. As a result, when a NAS does not receive a response 344 to a request, this could be the result of packet loss between the NAS 345 and proxy, a problem on the proxy, loss between the RADIUS proxy and 346 server, or a problem with the server. 348 When UDP was used as a transport protocol, the absence of a reply can 349 cause a client to deduce (incorrectly) that the proxy is unavailable. 350 The client could then fail over to another server, or conclude that 351 no "live" servers are available (OKAY state in [RFC3539] Appendix A). 352 This situation is made even worse when requests are sent through a 353 proxy to multiple destinations. Failures in one destination may 354 result in service outages for other destinations, if the client 355 erroneously believes that the proxy is unresponsive. 357 For RADIUS over TLS/TCP, it is RECOMMENDED that implementations 358 utilize the existence of a TCP connection along with the application 359 layer watchdog defined in [RFC3539] Section 3.4 to determine that the 360 server is "live". 362 RADIUS clients using RADIUS over TCP MUST mark a connection DOWN if 363 the network stack indicates that the connection is no longer active. 364 If the network stack indicates that connection is still active, 365 Clients MUST NOT decide that it is down until the application layer 366 watchdog algorithm has marked it DOWN ([RFC3539] Appendix A). RADIUS 367 clients using RADIUS over TCP MUST NOT decide that a RADIUS server is 368 unresponsive until all TCP connections to it have been marked DOWN. 370 The above requirements do not forbid the practice of a client pro- 371 actively closing connections, or marking a server as DOWN due to an 372 administrative decision. 374 2.5. Congestion Control Issues 376 Additional issues with RADIUS proxies involve transport protocol 377 changes where the proxy receives packets on one transport protocol, 378 and forwards them on a different transport protocol. There are 379 several situations in which the law of "conservation of packets" 380 could be violated on an end-to-end basis (e.g. where more packets 381 could enter the system than could leave it on a short-term basis): 383 * Where TCP is used between proxies, it is possible that the 384 bandwidth consumed by incoming UDP packets destined to a given 385 upstream server could exceed the sending rate of a single TCP 386 connection to that server, based on the window size/RTT estimate. 388 * It is possible for the incoming rate of TCP packets destined to 389 a given realm to exceed the UDP throughput achievable using the 390 transport guidelines established in [RFC5080]. This could happen, 391 for example, where the TCP window between proxies has opened, but 392 packet loss is being experienced on the UDP leg, so that the 393 effective congestion window on the UDP side is 1. 395 Intrinsically, proxy systems operate with multiple control loops 396 instead of one end-to-end loop, and so are less stable. This is true 397 even for TCP-TCP proxies. As discussed in [RFC3539], the only way to 398 achieve stability equivalent to a single TCP connection is to mimic 399 the end-to-end behavior of a single TCP connection. This typically 400 is not achievable with an application-layer RADIUS implementation, 401 regardless of transport. 403 2.6. TCP Specific Issues 405 The guidelines defined in [RFC3539] for implementing a AAA protocol 406 over reliable transport are applicable to RADIUS over TLS/TCP. 408 The Application Layer Watchdog defined in [RFC3539] Section 3.4 MUST 409 be used. The Status-Server packet [STATUS] MUST be used as the 410 application layer watchdog message. Implementations MUST reserve one 411 RADIUS ID per connection for the application layer watchdog message. 412 This restriction is described further below in Section 2.6.4. 414 RADIUS over TLS/TCP Implementations MUST support receiving RADIUS 415 packets over both UDP and TLS/TCP transports originating from the 416 same endpoint. RADIUS packets received over UDP MUST be replied to 417 over UDP; RADIUS packets received over TLS/TCP MUST be replied to 418 over TLS/TCP. That is, RADIUS clients and servers MUST be treated as 419 unique based on a key of the three-tuple (IP address, port, transport 420 protocol). Implementations MUST permit different shared secrets to 421 be used for UDP and TCP connections to the same destination IP 422 address and numerical port. 424 This requirement does not forbid the traditional practice of using 425 primary and secondary servers in a fail-over relationship. Instead, 426 it requires that two services sharing an IP address and numerical 427 port, but differing in transport protocol, MUST be treated as 428 independent services for the purpose of fail-over, load-balancing, 429 etc. 431 Whenever the underlying network stack permits the use of TCP 432 keepalive socket options, their use is RECOMMENDED. 434 2.6.1. Duplicates and Retransmissions 436 As TCP is a reliable transport, implementations MUST NOT retransmit 437 RADIUS request packets over a given TCP connection. Similarly, if 438 there is no response to a RADIUS packet over one TCP connection, 439 implementations MUST NOT retransmit that packet over a different TCP 440 connection to the same destination IP address and port, while the 441 first connection is in the OKAY state ([RFC3539] Appendix A). 443 However, if the TCP connection is broken or closed, retransmissions 444 over new connections are permissible. RADIUS request packets that 445 have not yet received a response MAY be transmitted by a RADIUS 446 client over a new TCP connection. As this procedure involves using a 447 new source port, the ID of the packet MAY change. If the ID changes, 448 any security attributes such as Message-Authenticator MUST be 449 recalculated. 451 If a TCP connection is broken or closed, any cached RADIUS response 452 packets ([RFC5080] Section 2.2.2) associated with that connection 453 MUST be discarded. A RADIUS server SHOULD stop processing of any 454 requests associated with that TCP connection. No response to these 455 requests can be sent over the TCP connection, so any further 456 processing is pointless. This requirement applies not only to RADIUS 457 servers, but also to proxies. When a client's connection to a proxy 458 server is closed, there may be responses from a home server that were 459 supposed to be sent by the proxy back over that connection to the 460 client. Since the client connection is closed, those responses from 461 the home server to the proxy server SHOULD be silently discarded by 462 the proxy. 464 Despite the above discussion, RADIUS servers SHOULD still perform 465 duplicate detection on received packets, as described in [RFC5080] 466 Section 2.2.2. This detection can prevent duplicate processing of 467 packets from non-conformant clients. 469 As noted previously, RADIUS packets SHOULD NOT be re-transmitted to 470 the same destination IP and numerical port, but over a different 471 transport layer. There is no guarantee in RADIUS that the two ports 472 are in any way related. This requirement does not, however, forbid 473 the practice of putting multiple servers into a fail-over or load- 474 balance pool. 476 Much of the discussion in this section can be summarized by the 477 following requirement. RADIUS requests MAY be re-transmitted 478 verbatim only if the following 5-tuple (Client IP address, Client 479 port, Transport Protocol, Server IP address, Server port) remains the 480 same. If any field of that 5-tuple changes, the packet MUST NOT be 481 considered to be a re-transmission. Instead, the packet MUST be 482 considered to be a new request, and be treated accordingly. This 483 involves updating header calculations, packet signatures, associated 484 timers and counters, etc. 486 The above requirement is necessary, but not sufficient in all cases. 487 Other specifications give additional situations where the packet is 488 to be considered as a new request. Those recommendations MUST also 489 be followed. 491 2.6.2. Head of Line Blocking 493 When using UDP as a transport for RADIUS, there is no ordering of 494 packets. If a packet sent by a client is lost, that loss has no 495 effect on subsequent packets sent by that client. 497 Unlike UDP, TLS/TCP is subject to issues related to Head of Line 498 (HoL) blocking. This occurs when when a TLS/TCP segment is lost and 499 a subsequent TLS/TCP segment arrives out of order. While the RADIUS 500 server can process RADIUS packets out of order, the semantics of 501 TLS/TCP makes this impossible. This limitation can lower the maximum 502 packet processing rate of RADIUS over TLS/TCP. 504 2.6.3. Shared Secrets 506 The use of TLS/TCP transport does not change the calculation of 507 security-related fields (such as the Response-Authenticator) in 508 RADIUS [RFC2865] or RADIUS Dynamic Authorization [RFC5176]. 509 Calculation of attributes such as User-Password [RFC2865] or Message- 510 Authenticator [RFC3579] also does not change. 512 Clients and servers MUST be able to store and manage shared secrets 513 based on the key described above, of (IP address, port, transport 514 protocol). 516 2.6.4. Malformed Packets and Unknown Clients 518 The RADIUS specifications ([RFC2865], etc.) say that an 519 implementation should "silently discard" a packet in a number of 520 circumstances. This action has no further consequences for UDP 521 transport, as the "next" packet is completely independent of the 522 previous one. 524 When TCP is used as a transport, decoding the "next" packet on a 525 connection depends on the proper decoding of the previous packet. As 526 a result, the behavior with respect to discarded packets has to 527 change. 529 Implementations of this specification SHOULD treat the "silently 530 discard" texts referenced above as "silently discard and close the 531 connection." That is, the TCP connection MUST be closed if any of 532 the following circumstances are seen: 534 * Connection from an unknown client 535 * Packet where the RADIUS "length" field is less than the minimum 536 RADIUS packet length 537 * Packet where the RADIUS "length" field is more than the maximum 538 RADIUS packet length 539 * Packet that has an Attribute "length" field has value of zero 540 or one (0 or 1). 541 * Packet where the attributes do not exactly fill the packet 542 * Packet where the Request Authenticator fails validation 543 (where validation is required). 544 * Packet where the Response Authenticator fails validation 545 (where validation is required). 546 * Packet where the Message-Authenticator attribute fails 547 validation (when it occurs in a packet). 549 After applying the above rules, there are still situations where the 550 previous specifications allow a packet to be "silently discarded". 551 In these situations, the TCP connections MAY remain open, or MAY be 552 closed, as an implementation choice. However, the invalid packet 553 MUST be silently discarded. 555 * Packet with an invalid code field 556 * Response packets that do not match any outstanding request 558 These requirements minimize the possibility for a misbehaving client 559 or server to wreak havoc on the network. 561 2.6.5. Limitations of the ID Field 563 The RADIUS ID field is one octet in size. As a result, any one TCP 564 connection can have only 256 "in flight" RADIUS packets at a time. 565 If more than 256 simultaneous "in flight" packets are required, 566 additional TCP connections will need to be opened. This limitation 567 is also noted in [RFC3539] Section 2.4. 569 An additional limit is the requirement to send a Status-Server packet 570 over the same TCP connection as is used for normal requests. As 571 noted in [STATUS], the response to a Status-Server packet is either 572 an Access-Accept or an Accounting-Response. If all IDs were 573 allocated to normal requests, then there would be no free Id to use 574 for the Status-Server packet, and it could not be sent over the 575 connection. 577 Implementations SHOULD reserve ID zero on each TCP connection for 578 Status-Server packets. This value was picked arbitrarily, as there 579 is no reason to choose any one value over another for this use. 581 Implementors may be tempted to extend RADIUS to permit more than 256 582 outstanding packets on one connection. However, doing so will likely 583 require fundamental changes to the RADIUS protocol, and as such, is 584 outside of the scope of this specification. 586 2.6.6. EAP Sessions 588 When RADIUS clients send EAP requests using RADIUS over TCP, they 589 SHOULD choose the same TCP connection for all packets related to one 590 EAP session. This practice ensures that EAP packets are transmitted 591 in order, and that problems with any one TCP connection do affect the 592 minimum number of EAP sessions. 594 A simple method that may work in many situations is to hash the 595 contents of the Calling-Station-Id attribute, which normally contains 596 the MAC address. The output of that hash can be used to select a 597 particular TCP connection. 599 However, EAP packets for one EAP session can still be transported 600 from client to server over multiple paths. Therefore, when a server 601 receives a RADIUS request containing an EAP request, it MUST be 602 processed without considering the transport protocol. For TCP 603 transport, it MUST be processed without considering the source port. 604 The algorithm suggested in [RFC5080] Section 2.1.1 SHOULD be used to 605 track EAP sessions, as it is independent of source port and transport 606 protocol. 608 The retransmission requirements of Section 2.6.1, above, MUST be 609 applied to RADIUS encapsulated EAP packets. That is, EAP 610 retransmissions MUST NOT result in retransmissions of RADIUS packets 611 over a particular TCP connection. EAP retransmissions MAY result in 612 retransmission of RADIUS packets over a different TCP connection, but 613 only when the previous TCP connection is marked DOWN. 615 2.6.7. TCP Applications are not UDP Applications 617 Implementors should be aware that programming a robust TCP 618 application can be very different from programming a robust UDP 619 application. We RECOMMEND that implementors of this specification 620 familiarize themselves with TCP application programming concepts. We 621 RECOMMEND also that existing TCP applications be examined with an eye 622 to robustness, performance, scalability, etc. 624 Clients and servers SHOULD implement configurable connection limits. 625 Clients and servers SHOULD implement configurable rate limiting on 626 new connections. Allowing an unbounded number or rate of TCP 627 connections may result in resource exhaustion. 629 Further discussion of implementation issues is outside of the scope 630 of this document. 632 3. Diameter Considerations 634 This document defines TCP as a transport layer for RADIUS. It 635 defines no new RADIUS attributes or codes. The only interaction with 636 Diameter is in a RADIUS to Diameter, or in a Diameter to RADIUS 637 gateway. The RADIUS side of such a gateway MAY implement RADIUS over 638 TCP, but this change has no effect on Diameter. 640 4. IANA Considerations 642 This document requires no action by IANA. 644 5. Security Considerations 646 As the RADIUS packet format, signing, and client verification are 647 unchanged from prior specifications, all of the security issues 648 outlined in previous specifications for RADIUS over UDP are also 649 applicable here. 651 As noted above, clients and servers SHOULD support configurable 652 connection limits. Allowing an unlimited number of connections may 653 result in resource exhaustion. 655 There are no (at this time) other known security issues for RADIUS 656 over TCP transport. 658 6. References 660 6.1. Normative References 662 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 663 Requirement Levels", BCP 14, RFC 2119, March 1997. 665 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 666 Authentication Dial In User Service (RADIUS)", RFC 2865, June 667 2000. 669 [RFC3539] Aboba, B. et al., "Authentication, Authorization and 670 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 672 6.2. Informative References 674 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 676 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 677 In User Service) Support For Extensible Authentication 678 Protocol (EAP)", RFC 3579, September 2003. 680 [RFC4668] Nelson, D, "RADIUS Authentication Client MIB for IPv6", RFC 681 4668, August 2006. 683 [RFC4669] Nelson, D, "RADIUS Authentication Server MIB for IPv6", RFC 684 4669, August 2006. 686 [RFC4670] Nelson, D, "RADIUS Accounting Client MIB for IPv6", RFC 4670, 687 August 2006. 689 [RFC4671] Nelson, D, "RADIUS Accounting Server MIB for IPv6", RFC 4671, 690 August 2006. 692 [RFC4672] Nelson, D, "RADIUS Dynamic Authorization Client MIB", RFC 693 4672, August 2006. 695 [RFC4673] Nelson, D, "RADIUS Dynamic Authorization Server MIB", RFC 696 4673, August 2006. 698 [RFC5080] Nelson, D. and DeKok, A, "Common Remote Authentication Dial In 699 User Service (RADIUS) Implementation Issues and Suggested 700 Fixes", RFC 5080, December 2007. 702 [RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote 703 Authentication Dial In User Service (RADIUS)", RFC 5176, 704 January 2008. 706 [RFC5216] Simon, D., etc al., "The EAP-TLS Authentication Protocol", RFC 707 5216, March 2008. 709 [STATUS] DeKok, A., "Use of Status-Server Packets in the Remote 710 Authentication Dial In User Service (RADIUS) Protocol", draft- 711 ietf-radext-status-server-06.txt, February 2010 (work in 712 progress). 714 [RTLS] Winter, S. et. al., "TLS encryption for RADIUS over TCP 715 (RadSec)", draft-ietf-radext-radsec-05.txt, July 2009 (work in 716 progress). 718 Acknowledgments 720 None at this time. 722 Authors' Addresses 724 Alan DeKok 725 The FreeRADIUS Server Project 726 http://freeradius.org/ 728 Email: aland@freeradius.org 730 Open issues 732 Open issues relating to this document are tracked on the following 733 web site: 735 http://www.drizzle.com/~aboba/RADEXT/