idnits 2.17.1 draft-ietf-radext-tcp-transport-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The 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 (12 October 2009) is 5282 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-04 == Outdated reference: A later version (-12) exists of draft-ietf-radext-radsec-05 Summary: 2 errors (**), 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 12 October 2009 9 RADIUS Over TCP 10 draft-ietf-radext-tcp-transport-04 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 12, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 The Remote Authentication Dial In User Server (RADIUS) Protocol has 47 traditionally used the User Datagram Protocol (UDP) as it's 48 underlying transport layer. This document defines RADIUS over the 49 Transmission Control Protocol (TCP), in order to address transport 50 issues related to RADIUS over TLS [RTLS]. It is not intended to 51 define TCP as a transport protocol for RADIUS in the absence of TLS. 53 Table of Contents 55 1. Introduction ............................................. 4 56 1.1. Applicability of Reliable Transport ................. 4 57 1.2. Terminology ......................................... 6 58 1.3. Requirements Language ............................... 7 59 2. Changes to RADIUS ........................................ 7 60 2.1. Packet Format ....................................... 7 61 2.2. Assigned Ports for RADIUS Over TCP .................. 8 62 2.3. Management Information Base (MIB) ................... 8 63 2.4. Interaction with RADIUS over TLS .................... 9 64 2.5. RADIUS Proxies ...................................... 9 65 2.6. TCP Specific Issues ................................. 10 66 2.6.1. Duplicates and Retransmissions ................. 11 67 2.6.2. Head of Line Blocking .......................... 12 68 2.6.3. Shared Secrets ................................. 12 69 2.6.4. Malformed Packets and Unknown Clients .......... 13 70 2.6.5. Limitations of the ID Field .................... 13 71 2.6.6. EAP Sessions ................................... 14 72 2.6.7. TCP Applications are not UDP Applications ...... 15 73 3. Diameter Considerations .................................. 15 74 4. IANA Considerations ...................................... 15 75 5. Security Considerations .................................. 15 76 6. References ............................................... 16 77 6.1. Normative References ................................ 16 78 6.2. Informative References .............................. 16 80 1. Introduction 82 The RADIUS Protocol has been defined in [RFC2865] as using the User 83 Datagram Protocol (UDP) for the underlying transport layer. While 84 there are a number of benefits to using UDP as outlined in [RFC2865] 85 Section 2.4, there are also some limitations: 87 * Unreliable transport. As a result, systems using RADIUS have to 88 implement application-layer timers and re-transmissions, as 89 described in [RFC5080] Section 2.2.1. 91 * Packet fragmentation. [RFC2865] Section 3 permits RADIUS 92 packets up to 4096 octets in length. These packets are larger 93 than the default Internet MTU (576), resulting in fragmentation of 94 the packets at the IP layer. Transport of fragmented UDP packets 95 appears to be a poorly tested code path on network devices. Some 96 devices appear to be incapable of transporting fragmented UDP 97 packets, making it difficult to deploy RADIUS in a network where 98 those devices are deployed. 100 * Connectionless transport. Neither clients nor servers receive 101 positive statements that a "connection" is down. This information 102 has to be deduced instead from the absence of a reply to a 103 request. 105 As RADIUS is widely deployed, and has been widely deployed for well 106 over a decade, these issues have been minor in some use-cases, and 107 problematic in others.. New systems may be interested in choosing a 108 different set of trade-offs than those outlined in [RFC2865] Section 109 2.4. New systems may also be interested in choosing a more reliable 110 transport for use-cases such as inter-server proxying. For those 111 systems, we define RADIUS over TCP 113 1.1. Applicability of Reliable Transport 115 The intent of this document is to address transport issues related to 116 RADIUS over TLS [RTLS]. The use of "bare" TCP transport (i.e. 117 without TLS) is NOT RECOMMENDED, as there has been little 118 implementational or operational experience with it. Additionally, 119 [RFC2865] Section 2.4 contains a list of reasons why UDP was 120 originally chosen as the transport protocol for RADIUS. UDP SHOULD 121 be used as transport protocol in all cases where the rationale given 122 in [RFC2865] Section 2.4 applies. 124 Deployment experience with RADIUS over TLS indicates that it is most 125 useful for inter-server communication, such as inter-domain 126 communication between proxies. These situations benefit from the 127 confidentiality and ciphersuite negotiation that can be provided by 128 TLS. Since TLS is already widely available within the operating 129 systems used by proxies, implementation barriers are low. 131 RADIUS over TCP has a similar set of use cases. Use of TCP as a 132 transport between a NAS and RADIUS server is a poor fit, since as 133 noted in [RFC3539], there is likely to be insufficient traffic for 134 the congestion window to remain above the minimum value on a long- 135 term basis. The result is an increase in packets due to ACKs as 136 compared to UDP, without a corresponding set of benefits. 138 In server-server communications the traffic levels in both directions 139 are typically high enough to support a larger congestion window as 140 well as ACK piggy-backing. Through use of an application-layer 141 watchdog as described in [RFC3539], it is possible to address the 142 objections to reliable transport described in [RFC2865] Section 2.4. 143 However, in these scenarios "bare" TCP does not provide for 144 confidentiality or enable negotiation of stronger ciphersuites than 145 are available in RADIUS. 147 As a result of these considerations, use of RADIUS over TCP SHOULD be 148 restricted to situations where RADIUS over TLS is employed. RADIUS 149 over "bare" TCP is NOT RECOMMENDED. 151 There are still a number of benefits to using a reliable transport. 152 For example, when RADIUS is used to carry EAP conversions [RFC3579], 153 the EAP exchanges may involve 5 round trips at the RADIUS application 154 layer. We may assume a probability P of packet loss in each 155 direction (with P having a value of 1% or less). Any one 156 authentication attempt will then have at least one lost packet, with 157 a probability of approximately (10 * P). 159 These lost packets require the supplicant and/or the NAS to re- 160 transmit packets at the application layer. The difficulty with this 161 approach is that retransmission implementations have historically 162 been poor. Some implementations retransmit packets, others do not, 163 and others send new packets rather then performing retransmission. 164 Some implementations are incapable of detecting EAP retransmissions, 165 and will instead treat the retransmitted packet as an error. 167 These retransmissions have a high likelihood of causing the entire 168 authentication session to fail. For a system with a million logins a 169 day, and having a packet loss probability of P=0.01%, we expect that 170 0.1% of connections will experience a lost packet. That is, 1,000 171 user sessions each day will experience authentication failure. 173 In addition, transport of fragmented UDP packets is a poorly tested 174 code path on network devices. Some devices appear to be incapable of 175 transporting fragmented UDP packets, meaning that the packet loss 176 rate for fragmented packets approaches 100 percent. The net effect 177 can be to prevent the deployment of authentication methods such as 178 EAP-TLS that require large RADIUS packets. 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 reliable delivery. In addition, most TCP 184 implementations discover Path MTU better than RADIUS application 185 implementations, resulting in significantly fewer fragmented packets. 186 Modern TCP implementations also implement anti-spoofing provisions, 187 which is more difficult to do in UDP applications. 189 Transporting RADIUS over TCP means that the RADIUS applications can 190 leverage these additional protections offered by TCP. 192 However, there are also some drawbacks to using TCP. RADIUS over TCP 193 has some drawbacks, as noted in [RFC2865] Section 2.4. [RFC3539] 194 Section 2 discusses further issues with using TCP as a transport for 195 Authentication, Authorization, and/or Accounting (AAA) protocols such 196 as RADIUS. 198 Specifically, as noted in [RFC3539] Section 2.1, for systems 199 originating low numbers of RADIUS request packets, inter-packet 200 spacing is often larger than the packet RTT. In those situations, 201 RADIUS over TCP SHOULD NOT be used. 203 In general, RADIUS clients generating small amounts of RADIUS traffic 204 SHOULD NOT use TCP. This suggestion will usually apply to most 205 NASes, and to most clients that originate CoA-Request and Disconnect- 206 Request packets. 208 RADIUS over TCP is most applicable to RADIUS proxies that exchange a 209 large volume of packets with RADIUS clients and servers (10's to 210 1000's of packets per second). In those situations, RADIUS over TCP 211 may be a good fit, and may result in increased network stability and 212 performance. 214 1.2. Terminology 216 This document uses the following terms: 218 RADIUS client 219 A device that provides an access service for a user to a network. 220 Also referred to as a Network Access Server, or NAS. 222 RADIUS server 223 A RADIUS authentication, authorization, and/or accounting (AAA) 224 server is an entity that provides one or more AAA services to a 225 NAS. 227 RADIUS proxy 228 A RADIUS proxy acts as a RADIUS server to the NAS, and a RADIUS 229 client to the RADIUS server. 231 RADIUS request packet 232 A packet originated by a RADIUS client to a RADIUS server. e.g. 233 Access-Request, Accounting-Request, CoA-Request, or Disconnect- 234 Request. 236 RADIUS response packet 237 A packet sent by a RADIUS server to a RADIUS client, in response to 238 a RADIUS request packet. e.g. Access-Accept, Access-Reject, 239 Access-Challenge, Accounting-Response, CoA-ACK, etc. 241 1.3. Requirements Language 243 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 244 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 245 document are to be interpreted as described in [RFC2119]. 247 2. Changes to RADIUS 249 Adding TCP as a RADIUS transport has a number of impacts on the 250 protocol, on applications using the protocol, and on networks that 251 deploy the protocol. In short, RADIUS over TCP is little more than 252 sending RADIUS formatted messages over a TCP connection. 254 As always, there are additional details that need to be discussed. 255 This section outlines the various impacts of using RADIUS over TCP, 256 and the discusses the proposal in more detail. 258 2.1. Packet Format 260 The RADIUS packet format is unchanged from [RFC2865], [RFC2866], and 261 [RFC5176]. Specifically, all of the following portions of RADIUS 262 MUST be unchanged when using RADIUS over TCP: 264 * Packet format 265 * Permitted codes 266 * Request Authenticator calculation 267 * Response Authenticator calculation 268 * Minimum packet length 269 * Maximum packet length 270 * Attribute format 271 * Vendor-Specific Attribute (VSA) format 272 * Permitted data types 273 * Calculations of dynamic attributes such as CHAP-Challenge, 274 or Message-Authenticator. 275 * Calculation of "encrypted" attributes such as Tunnel-Password. 277 The changes to RADIUS implementations required to implement this 278 specification are largely limited to the portions that send and 279 receive packets on the network. 281 2.2. Assigned Ports for RADIUS Over TCP 283 IANA has already assigned TCP ports for RADIUS transport, as outlined 284 below: 286 * radius 1812/tcp 287 * radius-acct 1813/tcp 288 * radius-dynauth 3799/tcp 290 These ports are unused by existing RADIUS applications. 291 Implementations SHOULD use the assigned values as the default ports 292 for RADIUS over TCP. 294 The early deployment of RADIUS was done using UDP port number 1645, 295 which conflicts with the "datametrics" service. Implementations 296 using RADIUS over TCP MUST NOT use TCP ports 1645 or 1646 as the 297 default ports for this specification. 299 2.3. Management Information Base (MIB) 301 The MIB Module definitions in [RFC4668], [RFC4669], [RFC4670], 302 [RFC4671], [RFC4672], and [RFC4673] each contain only one reference 303 to UDP. These references are in the DESCRIPTION field of the MIB 304 Module definition, and are in the form of "The UDP port" or "the UDP 305 destination port". 307 Implementations of RADIUS over TCP SHOULD re-use these MIB Modules to 308 perform statistics counting for RADIUS over TCP connections. 309 However, implementors are warned that there is no way for these MIB 310 Modules to distinguish between packets sent over UDP or over TCP 311 transport. Similarly, there is no requirement in RADIUS that the 312 RADIUS services offered over UDP on a particular IP address and port 313 are identical to the RADIUS services offered over TCP on a particular 314 IP address and the same (numerical) port. 316 Implementations of RADIUS over TCP SHOULD include the protocol (UDP) 317 or (TCP) in the radiusAuthServIdent, radiusAuthClientID, 318 radiusAuthClientIdentifier, radiusAccServIdent, radiusAccClientID, or 319 radiusAccClientIdentifier fields of the MIB Module. This information 320 can help the administrator distinguish capabilities of systems in the 321 network. 323 2.4. Interaction with RADIUS over TLS 325 IANA has already assigned TCP ports for RadSec (i.e. RADIUS over TLS 326 over TCP), as outlined below: 328 * radsec 2083/tcp 330 This value SHOULD be used as the default port for RADIUS over TLS. 331 The "radius" port (1812/tcp) SHOULD NOT be used for RADIUS over TLS. 333 2.5. RADIUS Proxies 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 If a request is proxied through intermediate proxies, it is not 342 possible to detect which of the later hops is responsible for the 343 absence of a reply. An intermediate proxy also cannot signal that 344 the outage lies in a later hop because RADIUS does not have the 345 ability to carry such signalling information. This issue is further 346 exacerbated by some proxy implementations that do not reply to a 347 client if they do not receive a reply to a proxied request. 349 When UDP was used as a transport protocol, the absence of a reply can 350 cause a client to deduce (incorrectly) that the proxy is unavailable. 351 The client could then fail over to another server, or conclude that 352 no "live" servers are available (OKAY state in [RFC3539] Appendix A). 353 This situation is made even worse when requests are sent through a 354 proxy to multiple destinations. Failures in one destination may 355 result in service outages for other destinations, if the client 356 erroneously believes that the proxy is unresponsive. 358 For RADIUS over TCP, the continued existence of the TCP connection 359 SHOULD be used to deduce that the service on the other end of the 360 connection is still responsive. Further, the application layer 361 watchdog defined in [RFC3539] Section 3.4 enables clients to 362 determine that the server is "live", even though it may not have 363 responded recently to non-watchdog requests. 365 RADIUS clients using RADIUS over TCP MUST mark a connection DOWN if 366 the network stack indicates that the connection is no longer active. 367 If the network stack indicates that connection is still active, 368 Clients MUST NOT decide that it is down until the application layer 369 watchdog algorithm has marked it DOWN ([RFC3539] Appendix A). RADIUS 370 clients using RADIUS over TCP MUST NOT decide that a RADIUS server is 371 unresponsive until all TCP connections to it have been marked DOWN. 373 The above requirements do not forbid the practice of a client pro- 374 actively closing connections, or marking a server as DOWN due to an 375 administrative decision. 377 Additional issues with RADIUS proxies involve transport protocol 378 changes where the proxy receives packets on one transport protocol, 379 and forwards them on a different transport protocol. There are 380 several situations in which the law of "conservation of packets" 381 could be violated on an end-to-end basis (e.g. where more packets 382 could enter the system than could leave it on a short-term basis): 384 * Where TCP is used between proxies, it is possible that the 385 bandwidth consumed by incoming UDP packets destined to a given 386 upstream server could exceed the sending rate of a single TCP 387 connection to that server, based on the window size/RTT estimate. 389 * It is possible for the incoming rate of TCP packets destined to 390 a given realm to exceed the UDP throughput achievable using the 391 transport guidelines established in [RFC5080]. This could happen, 392 for example, where the TCP window between proxies has opened, but 393 packet loss is being experienced on the UDP leg, so that the 394 effective congestion window on the UDP side is 1. 396 Intrinsically, proxy systems operate with multiple control loops 397 instead of one end-to-end loop, and so are less stable. This is true 398 even for TCP-TCP proxies. As discussed in [RFC3539], the only way to 399 achieve stability equivalent to a single TCP connection is to mimic 400 the end-to-end behavior of a single TCP connection. This typically 401 is not achievable with an application-layer RADIUS implementation, 402 regardless of transport. 404 2.6. TCP Specific Issues 406 The guidelines defined in [RFC3539] for implementing an AAA protocol 407 operating over a reliable transport MUST be followed by implementors 408 of this specification. 410 The Application Layer Watchdog defined in [RFC3539] Section 3.4 MUST 411 be used. The Status-Server packet [STATUS] MUST be used as the 412 application layer watchdog message. Implementations MUST reserve one 413 RADIUS ID per connection for the application layer watchdog message. 414 This restriction is described further below in Section 2.6.4. 416 Implementations MUST NOT confuse UDP and TCP transport. That is, 417 RADIUS clients and servers MUST be treated as unique based on a key 418 of the three-tuple (IP address, port, transport protocol). 419 Implementations MUST permit different shared secrets to be used for 420 UDP and TCP connections to the same destination IP address and 421 numerical port. 423 This requirement does not forbid the traditional practice of using 424 primary and secondary servers in a fail-over relationship. Instead, 425 it requires that two services sharing an IP address and numerical 426 port, but differing in transport protocol, MUST be treated as 427 independent services for the purpose of fail-over, load-balancing, 428 etc. 430 Whenever the underlying network stack permits the use of TCP 431 keepalive socket options, their use is RECOMMENDED. 433 2.6.1. Duplicates and Retransmissions 435 As TCP is a reliable transport, implementations MUST NOT retransmit 436 RADIUS request packets over a given TCP connection. Similarly, if 437 there is no response to a RADIUS packet over one TCP connection, 438 implementations MUST NOT retransmit that packet over a different TCP 439 connection to the same destination IP address and port, while the 440 first connection is in the OKAY state ([RFC3539] Appendix A). 442 However, if the TCP connection is broken or closed, retransmissions 443 over new connections are permissible. RADIUS request packets that 444 have not yet received a response MAY be transmitted by a RADIUS 445 client over a new TCP connection. As this procedure involves using a 446 new source port, the ID of the packet MAY change. If the ID changes, 447 any security attributes such as Message-Authenticator MUST be 448 recalculated. 450 If a TCP connection is broken or closed, any cached RADIUS response 451 packets ([RFC5080] Section 2.2.2) associated with that connection 452 MUST be discarded. A RADIUS server SHOULD stop processing of any 453 requests associated with that TCP connection. No response to these 454 requests can be sent over the TCP connection, so any further 455 processing is pointless. This requirement applies not only to RADIUS 456 servers, but also to proxies. When a client's connection to a proxy 457 server is closed, there may be responses from a home server that were 458 supposed to be sent by the proxy back over that connection to the 459 client. Since the client connection is closed, those responses from 460 the home server to the proxy server SHOULD be silently discarded by 461 the proxy. 463 Despite the above discussion, RADIUS servers SHOULD still perform 464 duplicate detection on received packets, as described in [RFC5080] 465 Section 2.2.2. This detection can prevent duplicate processing of 466 packets from non-conformant clients. 468 As noted previously, RADIUS packets SHOULD NOT be re-transmitted to 469 the same destination IP and numerical port, but over a different 470 transport layer. There is no guarantee in RADIUS that the two ports 471 are in any way related. This requirement does not, however, forbid 472 the practice of putting multiple servers into a fail-over or load- 473 balance pool. 475 Much of the discussion in this section can be summarized by the 476 following requirement. RADIUS requests MAY be re-transmitted 477 verbatim only if the following 5-tuple (Client IP address, Client 478 port, Transport Protocol, Server IP address, Server port) remains the 479 same. If any field of that 5-tuple changes, the packet MUST NOT be 480 considered to be a re-transmission. Instead, the packet MUST be 481 considered to be a new request, and be treated accordingly. This 482 involves updating header calculations, packet signatures, associated 483 timers and counters, etc. 485 The above requirement is necessary, but not sufficient in all cases. 486 Other specifications give additional situations where the packet is 487 to be considered as a new request. Those recommendations MUST also 488 be followed. 490 2.6.2. Head of Line Blocking 492 When using UDP as a transport for RADIUS, there is no ordering of 493 packets. If a packet sent by a client is lost, that loss has no 494 effect on subsequent packets sent by that client. 496 Unlike UDP, TCP is subject to issues related to Head of Line (HoL) 497 blocking. This occurs when when a TCP segment is lost and a 498 subsequent TCP segment arrives out of order. While the RADIUS server 499 can process RADIUS packets out of order, the semantics of TCP makes 500 this impossible. This limitation can lower the maximum packet 501 processing rate of RADIUS over TCP. 503 2.6.3. Shared Secrets 505 The use of shared secrets in calculating the Response Authenticator, 506 and other attributes such as User-Password or Message-Authenticator 507 [RFC3579] MUST be unchanged from previous specifications. 509 Clients and servers MUST be able to store and manage shared secrets 510 based on the key described above, of (IP address, port, transport 511 protocol). 513 2.6.4. Malformed Packets and Unknown Clients 515 The RADIUS specifications ([RFC2865], etc.) say that an 516 implementation should "silently discard" a packet in a number of 517 circumstances. This action has no further consequences for UDP 518 transport, as the "next" packet is completely independent of the 519 previous one. 521 When TCP is used as a transport, decoding the "next" packet on a 522 connection depends on the proper decoding of the previous packet. As 523 a result, the behavior with respect to discarded packets has to 524 change. 526 Implementations of this specification SHOULD treat the "silently 527 discard" texts referenced above as "silently discard and close the 528 connection." That is, the TCP connection MUST be closed if any of 529 the following circumstances are seen: 531 * Connection from an unknown client 532 * Packet where the RADIUS "length" field is less than the minimum 533 RADIUS packet length 534 * Packet where the RADIUS "length" field is more than the maximum 535 RADIUS packet length 536 * Packet that has an Attribute "length" field has value of zero 537 or one (0 or 1). 538 * Packet where the attributes do not exactly fill the packet 539 * Packet where the Request Authenticator fails validation 540 (where validation is required). 541 * Packet where the Response Authenticator fails validation 542 (where validation is required). 543 * Packet where the Message-Authenticator attribute fails 544 validation (when it occurs in a packet). 546 TCP connections MAY be closed if any of the circumstances outlined 547 below are seen. Alternatively, the TCP connection MAY remain open if 548 any of the following circumstances are seen, but the invalid packet 549 MUST BE silently discarded. 551 * Packet with an invalid code field 552 * Response packets that do not match any outstanding request 554 These requirements minimize the possibility for a misbehaving client 555 or server to wreak havoc on the network. 557 2.6.5. Limitations of the ID Field 559 The RADIUS ID field is one octet in size. As a result, any one TCP 560 connection can have only 256 "in flight" RADIUS packets at a time. 562 If more than 256 simultaneous "in flight" packets are required, 563 additional TCP connections will need to be opened. This limitation 564 is also noted in [RFC3539] Section 2.4. 566 An additional limit is the requirement to send a Status-Server packet 567 over the same TCP connection as is used for normal requests. As 568 noted in [STATUS], the response to a Status-Server packet is either 569 an Access-Accept or an Accounting-Response. If all IDs were 570 allocated to normal requests, then there would be no free Id to use 571 for the Status-Server packet, and it could not be sent over the 572 connection. 574 Implementations SHOULD reserve ID zero on each TCP connection for 575 Status-Server packets. This value was picked arbitrarily, as there 576 is no reason to choose any one value over another for this use. 578 Implementors may be tempted to extend RADIUS to permit more than 256 579 outstanding packets on one connection. However, doing so will likely 580 require fundamental changes to the RADIUS protocol, and as such, is 581 outside of the scope of this specification. 583 2.6.6. EAP Sessions 585 When RADIUS clients send EAP requests using RADIUS over TCP, they 586 SHOULD choose the same TCP connection for all packets related to one 587 EAP session. This practice ensures that EAP packets are transmitted 588 in order, and that problems with any one TCP connection do affect the 589 minimum number of EAP sessions. 591 A simple method that may work in many situations is to hash the 592 contents of the Calling-Station-Id attribute, which normally contains 593 the MAC address. The output of that hash can be used to select a 594 particular TCP connection. 596 However, EAP packets for one EAP session can still be transported 597 from client to server over multiple paths. Therefore, when a server 598 receives a RADIUS request containing an EAP request, it MUST be 599 processed without considering the transport protocol. For TCP 600 transport, it MUST be processed without considering the source port. 601 The algorithm suggested in [RFC5080] Section 2.1.1 SHOULD be used to 602 track EAP sessions, as it is independent of source port and transport 603 protocol. 605 The retransmission requirements of Section 2.6.1, above, MUST be 606 applied to RADIUS encapsulated EAP packets. That is, EAP 607 retransmissions MUST NOT result in retransmissions of RADIUS packets 608 over a particular TCP connection. EAP retransmissions MAY result in 609 retransmission of RADIUS packets over a different TCP connection, but 610 only when the previous TCP connection is marked DOWN. 612 2.6.7. TCP Applications are not UDP Applications 614 Implementors should be aware that programming a robust TCP 615 application can be very different from programming a robust UDP 616 application. We RECOMMEND that implementors of this specification 617 familiarize themselves with TCP application programming concepts. We 618 RECOMMEND also that existing TCP applications be examined with an eye 619 to robustness, performance, scalability, etc. 621 Clients and servers SHOULD implement configurable connection limits. 622 Clients and servers SHOULD implement configurable rate limiting on 623 new connections. Allowing an unbounded number or rate of TCP 624 connections may result in resource exhaustion. 626 Further discussion of implementation issues is outside of the scope 627 of this document. 629 3. Diameter Considerations 631 This document defines TCP as a transport layer for RADIUS. It 632 defines no new RADIUS attributes or codes. The only interaction with 633 Diameter is in a RADIUS to Diameter, or in a Diameter to RADIUS 634 gateway. The RADIUS side of such a gateway MAY implement RADIUS over 635 TCP, but this change has no effect on Diameter. 637 4. IANA Considerations 639 This document requires no action by IANA. 641 5. Security Considerations 643 As the RADIUS packet format, signing, and client verification are 644 unchanged from prior specifications, all of the security issues 645 outlined in previous specifications for RADIUS over UDP are also 646 applicable here. 648 As noted above, clients and servers SHOULD support configurable 649 connection limits. Allowing an unlimited number of connections may 650 result in resource exhaustion. 652 There are no (at this time) other known security issues for RADIUS 653 over TCP transport. 655 6. References 657 6.1. Normative References 659 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 660 Requirement Levels", BCP 14, RFC 2119, March 1997. 662 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 663 Authentication Dial In User Service (RADIUS)", RFC 2865, June 664 2000. 666 [RFC3539] Aboba, B. et al., "Authentication, Authorization and 667 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 669 6.2. Informative References 671 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 673 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 674 In User Service) Support For Extensible Authentication 675 Protocol (EAP)", RFC 3579, September 2003. 677 [RFC4668] Nelson, D, "RADIUS Authentication Client MIB for IPv6", RFC 678 4668, August 2006. 680 [RFC4669] Nelson, D, "RADIUS Authentication Server MIB for IPv6", RFC 681 4669, August 2006. 683 [RFC4670] Nelson, D, "RADIUS Accounting Client MIB for IPv6", RFC 4670, 684 August 2006. 686 [RFC4671] Nelson, D, "RADIUS Accounting Server MIB for IPv6", RFC 4671, 687 August 2006. 689 [RFC4672] Nelson, D, "RADIUS Dynamic Authorization Client MIB", RFC 690 4672, August 2006. 692 [RFC4673] Nelson, D, "RADIUS Dynamic Authorization Server MIB", RFC 693 4673, August 2006. 695 [RFC5080] Nelson, D. and DeKok, A, "Common Remote Authentication Dial In 696 User Service (RADIUS) Implementation Issues and Suggested 697 Fixes", RFC 5080, December 2007. 699 [RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote 700 Authentication Dial In User Service (RADIUS)", RFC 5176, 701 January 2008. 703 [STATUS] DeKok, A., "Use of Status-Server Packets in the Remote 704 Authentication Dial In User Service (RADIUS) Protocol", draft- 705 ietf-radext-status-server-04.txt, October 2009 (work in 706 progress). 708 [RTLS] Winter, S. et. al., "TLS encryption for RADIUS over TCP 709 (RadSec)", draft-ietf-radext-radsec-05.txt, July 2009 (work in 710 progress). 712 Acknowledgments 714 None at this time. 716 Authors' Addresses 718 Alan DeKok 719 The FreeRADIUS Server Project 720 http://freeradius.org/ 722 Email: aland@freeradius.org 724 Open issues 726 Open issues relating to this document are tracked on the following 727 web site: 729 http://www.drizzle.com/~aboba/RADEXT/