--- 1/draft-ietf-radext-tcp-transport-03.txt 2009-10-12 18:12:10.000000000 +0200 +++ 2/draft-ietf-radext-tcp-transport-04.txt 2009-10-12 18:12:10.000000000 +0200 @@ -1,95 +1,88 @@ Network Working Group A. DeKok INTERNET-DRAFT FreeRADIUS -Category: Proposed Standard - -Expires: September 1, 2009 -1 March 2009 +Category: Experimental + +Expires: April 12,2009 +12 October 2009 RADIUS Over TCP - draft-ietf-radext-tcp-transport-03 + draft-ietf-radext-tcp-transport-04 This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. This document may contain material - from IETF Documents or IETF Contributions published or made publicly - available before November 10, 2008. The person(s) controlling the - copyright in some of this material may not have granted the IETF - Trust the right to allow modifications of such material outside the - IETF Standards Process. Without obtaining an adequate license from - the person(s) controlling the copyright in such materials, this - document may not be modified outside the IETF Standards Process, and - derivative works of it may not be created outside the IETF Standards - Process, except to format it for publication as an RFC or to - translate it into languages other than English. + provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on September 1, 2009. + This Internet-Draft will expire on April 12, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract The Remote Authentication Dial In User Server (RADIUS) Protocol has traditionally used the User Datagram Protocol (UDP) as it's underlying transport layer. This document defines RADIUS over the - Transmission Control Protocol (TCP). + Transmission Control Protocol (TCP), in order to address transport + issues related to RADIUS over TLS [RTLS]. It is not intended to + define TCP as a transport protocol for RADIUS in the absence of TLS. Table of Contents 1. Introduction ............................................. 4 1.1. Applicability of Reliable Transport ................. 4 1.2. Terminology ......................................... 6 - 1.3. Requirements Language ............................... 6 -2. Changes to RADIUS ........................................ 6 + 1.3. Requirements Language ............................... 7 +2. Changes to RADIUS ........................................ 7 2.1. Packet Format ....................................... 7 - 2.2. Assigned Ports for RADIUS Over TCP .................. 7 - 2.3. Management Information Base (MIB) ................... 7 - 2.4. Interaction with RadSec ............................. 8 - 2.5. RADIUS Proxies ...................................... 8 + 2.2. Assigned Ports for RADIUS Over TCP .................. 8 + 2.3. Management Information Base (MIB) ................... 8 + 2.4. Interaction with RADIUS over TLS .................... 9 + 2.5. RADIUS Proxies ...................................... 9 2.6. TCP Specific Issues ................................. 10 - 2.6.1. Duplicates and Retransmissions ................. 10 - 2.6.2. Shared Secrets ................................. 11 - 2.6.3. Malformed Packets and Unknown Clients .......... 12 - 2.6.4. Limitations of the ID Field .................... 12 - 2.6.5. EAP Sessions ................................... 13 - 2.6.6. TCP Applications are not UDP Applications ...... 13 -3. Diameter Considerations .................................. 14 -4. IANA Considerations ...................................... 14 -5. Security Considerations .................................. 14 -6. References ............................................... 14 - 6.1. Normative References ................................ 14 - 6.2. Informative References .............................. 15 + 2.6.1. Duplicates and Retransmissions ................. 11 + 2.6.2. Head of Line Blocking .......................... 12 + 2.6.3. Shared Secrets ................................. 12 + 2.6.4. Malformed Packets and Unknown Clients .......... 13 + 2.6.5. Limitations of the ID Field .................... 13 + 2.6.6. EAP Sessions ................................... 14 + 2.6.7. TCP Applications are not UDP Applications ...... 15 +3. Diameter Considerations .................................. 15 +4. IANA Considerations ...................................... 15 +5. Security Considerations .................................. 15 +6. References ............................................... 16 + 6.1. Normative References ................................ 16 + 6.2. Informative References .............................. 16 1. Introduction The RADIUS Protocol has been defined in [RFC2865] as using the User Datagram Protocol (UDP) for the underlying transport layer. While there are a number of benefits to using UDP as outlined in [RFC2865] Section 2.4, there are also some limitations: * Unreliable transport. As a result, systems using RADIUS have to implement application-layer timers and re-transmissions, as @@ -97,43 +90,74 @@ * Packet fragmentation. [RFC2865] Section 3 permits RADIUS packets up to 4096 octets in length. These packets are larger than the default Internet MTU (576), resulting in fragmentation of the packets at the IP layer. Transport of fragmented UDP packets appears to be a poorly tested code path on network devices. Some devices appear to be incapable of transporting fragmented UDP packets, making it difficult to deploy RADIUS in a network where those devices are deployed. - * Connectionless transport. Neither clients nor servers can - reliably detect when the other is down. This information has to - be deduced instead from the absence of a reply to a request. + * Connectionless transport. Neither clients nor servers receive + positive statements that a "connection" is down. This information + has to be deduced instead from the absence of a reply to a + request. As RADIUS is widely deployed, and has been widely deployed for well - over a decade, these issues are relatively minor. However, new - systems may be interested in choosing a different set of trade-offs - than those outlined in [RFC2865] Section 2.4. For those systems, we - define RADIUS over TCP. + over a decade, these issues have been minor in some use-cases, and + problematic in others.. New systems may be interested in choosing a + different set of trade-offs than those outlined in [RFC2865] Section + 2.4. New systems may also be interested in choosing a more reliable + transport for use-cases such as inter-server proxying. For those + systems, we define RADIUS over TCP 1.1. Applicability of Reliable Transport The intent of this document is to address transport issues related to - RadSec [RADSEC]. The use of "bare" TCP transport is NOT RECOMMENDED, - as there has been little implementational or operational experience - with it. Additionally, [RFC2865] Section 2.4 contains a list of - reasons why UDP was originally chosen as the transport protocol for - RADIUS. UDP SHOULD be used as transport protocol in all cases where - the rationale given in [RFC2865] Section 2.4 applies. + RADIUS over TLS [RTLS]. The use of "bare" TCP transport (i.e. + without TLS) is NOT RECOMMENDED, as there has been little + implementational or operational experience with it. Additionally, + [RFC2865] Section 2.4 contains a list of reasons why UDP was + originally chosen as the transport protocol for RADIUS. UDP SHOULD + be used as transport protocol in all cases where the rationale given + in [RFC2865] Section 2.4 applies. - There are a number of benefits to using a reliable transport. For - example, when RADIUS is used to carry EAP conversions [RFC3579], the - EAP exchanges may involve 5 round trips at the RADIUS application + Deployment experience with RADIUS over TLS indicates that it is most + useful for inter-server communication, such as inter-domain + communication between proxies. These situations benefit from the + confidentiality and ciphersuite negotiation that can be provided by + TLS. Since TLS is already widely available within the operating + systems used by proxies, implementation barriers are low. + + RADIUS over TCP has a similar set of use cases. Use of TCP as a + transport between a NAS and RADIUS server is a poor fit, since as + noted in [RFC3539], there is likely to be insufficient traffic for + the congestion window to remain above the minimum value on a long- + term basis. The result is an increase in packets due to ACKs as + compared to UDP, without a corresponding set of benefits. + + In server-server communications the traffic levels in both directions + are typically high enough to support a larger congestion window as + well as ACK piggy-backing. Through use of an application-layer + watchdog as described in [RFC3539], it is possible to address the + objections to reliable transport described in [RFC2865] Section 2.4. + However, in these scenarios "bare" TCP does not provide for + confidentiality or enable negotiation of stronger ciphersuites than + are available in RADIUS. + + As a result of these considerations, use of RADIUS over TCP SHOULD be + restricted to situations where RADIUS over TLS is employed. RADIUS + over "bare" TCP is NOT RECOMMENDED. + + There are still a number of benefits to using a reliable transport. + For example, when RADIUS is used to carry EAP conversions [RFC3579], + the EAP exchanges may involve 5 round trips at the RADIUS application layer. We may assume a probability P of packet loss in each direction (with P having a value of 1% or less). Any one authentication attempt will then have at least one lost packet, with a probability of approximately (10 * P). These lost packets require the supplicant and/or the NAS to re- transmit packets at the application layer. The difficulty with this approach is that retransmission implementations have historically been poor. Some implementations retransmit packets, others do not, and others send new packets rather then performing retransmission. @@ -289,30 +313,29 @@ are identical to the RADIUS services offered over TCP on a particular IP address and the same (numerical) port. Implementations of RADIUS over TCP SHOULD include the protocol (UDP) or (TCP) in the radiusAuthServIdent, radiusAuthClientID, radiusAuthClientIdentifier, radiusAccServIdent, radiusAccClientID, or radiusAccClientIdentifier fields of the MIB Module. This information can help the administrator distinguish capabilities of systems in the network. -2.4. Interaction with RadSec +2.4. Interaction with RADIUS over TLS IANA has already assigned TCP ports for RadSec (i.e. RADIUS over TLS over TCP), as outlined below: * radsec 2083/tcp - This value SHOULD be used as the default port for RADIUS over TLS - (i.e. RadSec). The "radius" port (1812/tcp) SHOULD NOT be used for - RadSec. + This value SHOULD be used as the default port for RADIUS over TLS. + The "radius" port (1812/tcp) SHOULD NOT be used for RADIUS over TLS. 2.5. RADIUS Proxies As RADIUS is a "hop by hop" protocol, a RADIUS proxy effectively shields the client from any information about downstream servers. While the client may be able to deduce the operational state of the local server (i.e. proxy), it cannot make any determination about the operational state of the downstream servers. If a request is proxied through intermediate proxies, it is not @@ -331,27 +353,33 @@ This situation is made even worse when requests are sent through a proxy to multiple destinations. Failures in one destination may result in service outages for other destinations, if the client erroneously believes that the proxy is unresponsive. For RADIUS over TCP, the continued existence of the TCP connection SHOULD be used to deduce that the service on the other end of the connection is still responsive. Further, the application layer watchdog defined in [RFC3539] Section 3.4 enables clients to determine that the server is "live", even though it may not have - responded recently to other, non-watchdog requests. + responded recently to non-watchdog requests. - RADIUS clients using RADIUS over TCP MUST NOT decide that a - connection is down until the application layer watchdog algorithm has - marked it DOWN ([RFC3539] Appendix A). RADIUS clients using RADIUS - over TCP MUST NOT decide that a RADIUS server is unresponsive until - all TCP connections to it have been marked DOWN. + RADIUS clients using RADIUS over TCP MUST mark a connection DOWN if + the network stack indicates that the connection is no longer active. + If the network stack indicates that connection is still active, + Clients MUST NOT decide that it is down until the application layer + watchdog algorithm has marked it DOWN ([RFC3539] Appendix A). RADIUS + clients using RADIUS over TCP MUST NOT decide that a RADIUS server is + unresponsive until all TCP connections to it have been marked DOWN. + + The above requirements do not forbid the practice of a client pro- + actively closing connections, or marking a server as DOWN due to an + administrative decision. Additional issues with RADIUS proxies involve transport protocol changes where the proxy receives packets on one transport protocol, and forwards them on a different transport protocol. There are several situations in which the law of "conservation of packets" could be violated on an end-to-end basis (e.g. where more packets could enter the system than could leave it on a short-term basis): * Where TCP is used between proxies, it is possible that the bandwidth consumed by incoming UDP packets destined to a given @@ -376,48 +404,47 @@ 2.6. TCP Specific Issues The guidelines defined in [RFC3539] for implementing an AAA protocol operating over a reliable transport MUST be followed by implementors of this specification. The Application Layer Watchdog defined in [RFC3539] Section 3.4 MUST be used. The Status-Server packet [STATUS] MUST be used as the application layer watchdog message. Implementations MUST reserve one RADIUS ID per connection for the application layer watchdog message. - This restriction is described further below. + This restriction is described further below in Section 2.6.4. Implementations MUST NOT confuse UDP and TCP transport. That is, RADIUS clients and servers MUST be treated as unique based on a key of the three-tuple (IP address, port, transport protocol). - Implementations MUST be configurable to have different shared secrets - for UDP and TCP to the same destination IP address and numerical - port. + Implementations MUST permit different shared secrets to be used for + UDP and TCP connections to the same destination IP address and + numerical port. This requirement does not forbid the traditional practice of using primary and secondary servers in a fail-over relationship. Instead, it requires that two services sharing an IP address and numerical port, but differing in transport protocol, MUST be treated as independent services for the purpose of fail-over, load-balancing, etc. - Whenever the underlying operating system permits the use of TCP + Whenever the underlying network stack permits the use of TCP keepalive socket options, their use is RECOMMENDED. 2.6.1. Duplicates and Retransmissions - As TCP is a reliable transport, implementors of this specification - MUST NOT retransmit RADIUS request packets over the same TCP - connection. Similarly, if there is no response to a RADIUS packet - over one TCP connection, implementations MUST NOT retransmit that - packet over a different TCP connection to the same destination IP - address and port, while the first connection is in the OKAY state - ([RFC3539] Appendix A). + As TCP is a reliable transport, implementations MUST NOT retransmit + RADIUS request packets over a given TCP connection. Similarly, if + there is no response to a RADIUS packet over one TCP connection, + implementations MUST NOT retransmit that packet over a different TCP + connection to the same destination IP address and port, while the + first connection is in the OKAY state ([RFC3539] Appendix A). However, if the TCP connection is broken or closed, retransmissions over new connections are permissible. RADIUS request packets that have not yet received a response MAY be transmitted by a RADIUS client over a new TCP connection. As this procedure involves using a new source port, the ID of the packet MAY change. If the ID changes, any security attributes such as Message-Authenticator MUST be recalculated. If a TCP connection is broken or closed, any cached RADIUS response @@ -434,94 +461,107 @@ the proxy. Despite the above discussion, RADIUS servers SHOULD still perform duplicate detection on received packets, as described in [RFC5080] Section 2.2.2. This detection can prevent duplicate processing of packets from non-conformant clients. As noted previously, RADIUS packets SHOULD NOT be re-transmitted to the same destination IP and numerical port, but over a different transport layer. There is no guarantee in RADIUS that the two ports - are in any way related. This requirement does not forbid the - practice of putting multiple servers into a fail-over or load-balance - pool. + are in any way related. This requirement does not, however, forbid + the practice of putting multiple servers into a fail-over or load- + balance pool. Much of the discussion in this section can be summarized by the following requirement. RADIUS requests MAY be re-transmitted verbatim only if the following 5-tuple (Client IP address, Client port, Transport Protocol, Server IP address, Server port) remains the same. If any field of that 5-tuple changes, the packet MUST NOT be considered to be a re-transmission. Instead, the packet MUST be considered to be a new request, and be treated accordingly. This involves updating header calculations, packet signatures, associated timers and counters, etc. The above requirement is necessary, but not sufficient in all cases. Other specifications give additional situations where the packet is to be considered as a new request. Those recommendations MUST also be followed. -2.6.2. Shared Secrets +2.6.2. Head of Line Blocking + + When using UDP as a transport for RADIUS, there is no ordering of + packets. If a packet sent by a client is lost, that loss has no + effect on subsequent packets sent by that client. + + Unlike UDP, TCP is subject to issues related to Head of Line (HoL) + blocking. This occurs when when a TCP segment is lost and a + subsequent TCP segment arrives out of order. While the RADIUS server + can process RADIUS packets out of order, the semantics of TCP makes + this impossible. This limitation can lower the maximum packet + processing rate of RADIUS over TCP. + +2.6.3. Shared Secrets The use of shared secrets in calculating the Response Authenticator, and other attributes such as User-Password or Message-Authenticator [RFC3579] MUST be unchanged from previous specifications. Clients and servers MUST be able to store and manage shared secrets based on the key described above, of (IP address, port, transport protocol). -2.6.3. Malformed Packets and Unknown Clients +2.6.4. Malformed Packets and Unknown Clients The RADIUS specifications ([RFC2865], etc.) say that an implementation should "silently discard" a packet in a number of circumstances. This action has no further consequences for UDP transport, as the "next" packet is completely independent of the previous one. When TCP is used as a transport, decoding the "next" packet on a connection depends on the proper decoding of the previous packet. As a result, the behavior with respect to discarded packets has to change. Implementations of this specification SHOULD treat the "silently discard" texts referenced above as "silently discard and close the connection." That is, the TCP connection MUST be closed if any of the following circumstances are seen: - * Packet from an unknown client + * Connection from an unknown client * Packet where the RADIUS "length" field is less than the minimum RADIUS packet length * Packet where the RADIUS "length" field is more than the maximum RADIUS packet length * Packet that has an Attribute "length" field has value of zero or one (0 or 1). * Packet where the attributes do not exactly fill the packet * Packet where the Request Authenticator fails validation - (where applicable). + (where validation is required). * Packet where the Response Authenticator fails validation - (where applicable). + (where validation is required). * Packet where the Message-Authenticator attribute fails - validation (where applicable). + validation (when it occurs in a packet). - TCP connections MAY be closed if any of the following circumstances - are seen. Alternatively, the TCP connection MAY remain open if any - of the following circumstances are seen, but the invalid packet MUST - BE silently discarded. + TCP connections MAY be closed if any of the circumstances outlined + below are seen. Alternatively, the TCP connection MAY remain open if + any of the following circumstances are seen, but the invalid packet + MUST BE silently discarded. * Packet with an invalid code field * Response packets that do not match any outstanding request These requirements minimize the possibility for a misbehaving client or server to wreak havoc on the network. -2.6.4. Limitations of the ID Field +2.6.5. Limitations of the ID Field The RADIUS ID field is one octet in size. As a result, any one TCP connection can have only 256 "in flight" RADIUS packets at a time. If more than 256 simultaneous "in flight" packets are required, additional TCP connections will need to be opened. This limitation is also noted in [RFC3539] Section 2.4. An additional limit is the requirement to send a Status-Server packet over the same TCP connection as is used for normal requests. As @@ -533,41 +573,50 @@ Implementations SHOULD reserve ID zero on each TCP connection for Status-Server packets. This value was picked arbitrarily, as there is no reason to choose any one value over another for this use. Implementors may be tempted to extend RADIUS to permit more than 256 outstanding packets on one connection. However, doing so will likely require fundamental changes to the RADIUS protocol, and as such, is outside of the scope of this specification. -2.6.5. EAP Sessions +2.6.6. EAP Sessions When RADIUS clients send EAP requests using RADIUS over TCP, they SHOULD choose the same TCP connection for all packets related to one - EAP conversation. A simple method that may work in many situations - is to hash the contents of the Calling-Station-Id attribute, which - normally contains the MAC address. The output of that hash can be - used to select a particular TCP connection. + EAP session. This practice ensures that EAP packets are transmitted + in order, and that problems with any one TCP connection do affect the + minimum number of EAP sessions. - If this practice is used, then the client SHOULD also reserve one - RADIUS Id per TCP connection for a particular EAP session. + A simple method that may work in many situations is to hash the + contents of the Calling-Station-Id attribute, which normally contains + the MAC address. The output of that hash can be used to select a + particular TCP connection. + + However, EAP packets for one EAP session can still be transported + from client to server over multiple paths. Therefore, when a server + receives a RADIUS request containing an EAP request, it MUST be + processed without considering the transport protocol. For TCP + transport, it MUST be processed without considering the source port. + The algorithm suggested in [RFC5080] Section 2.1.1 SHOULD be used to + track EAP sessions, as it is independent of source port and transport + protocol. The retransmission requirements of Section 2.6.1, above, MUST be applied to RADIUS encapsulated EAP packets. That is, EAP retransmissions MUST NOT result in retransmissions of RADIUS packets over a particular TCP connection. EAP retransmissions MAY result in retransmission of RADIUS packets over a different TCP connection, but - only when the previous TCP connection is marked DOWN as per the - algorithm in [RFC3539] Appendix A. + only when the previous TCP connection is marked DOWN. -2.6.6. TCP Applications are not UDP Applications +2.6.7. TCP Applications are not UDP Applications Implementors should be aware that programming a robust TCP application can be very different from programming a robust UDP application. We RECOMMEND that implementors of this specification familiarize themselves with TCP application programming concepts. We RECOMMEND also that existing TCP applications be examined with an eye to robustness, performance, scalability, etc. Clients and servers SHOULD implement configurable connection limits. Clients and servers SHOULD implement configurable rate limiting on @@ -646,28 +695,29 @@ [RFC5080] Nelson, D. and DeKok, A, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007. [RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008. [STATUS] DeKok, A., "Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol", draft- - ietf-radext-status-server-03.txt, March 2009 (work in + ietf-radext-status-server-04.txt, October 2009 (work in progress). -[RADSEC] Winter, S. et. al., "TLS encryption for RADIUS over TCP - (RadSec)", draft-ietf-radext-radsec-03.txt, Februrary 2009 - (work in progress). +[RTLS] Winter, S. et. al., "TLS encryption for RADIUS over TCP + (RadSec)", draft-ietf-radext-radsec-05.txt, July 2009 (work in + progress). Acknowledgments + None at this time. Authors' Addresses Alan DeKok The FreeRADIUS Server Project http://freeradius.org/ Email: aland@freeradius.org