|
Here are my comments: Category: Proposed Standards [BA] My impression was that this document (like RADIUS over TLS and RADIUS over DTLS) was targeted for Experimental status. 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). [BA] It might be worth stating that this specification was developed primarily for addressing the transport issues inherent in RADIUS over TLS, and that it is not intended for use by itself. Section 1 * 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. [BA] Determining when a client or server is down is not automatically solved by choice of a reliable transport. For example, without an application layer watchdog, an application relying on TCP would typically need to wait until the connection timed out before trying another server. This is the problem identified by RFC 2865, which talks about UDP be used for faster failover than would be permitted by TCP without a watchdog. However, failover as envisaged by RFC 2865 does not require deducing that a server is "down" based on lack of a reply; doing so would require a much longer waiting interval than implementations typically provide. RADIUS over UDP implementations typically don't care whether the server is "down" or not; they only care that it hasn't responded after set time interval or number of retries. However, none of this is specified in RFC 2865 (or RFC 5080), so the quality of the failover algorithm will vary between implementations. This I think is the more relevant point -- lack of a standardized failover algorithm. Presumably, this document can address that problem. 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. [BA] I would disagree that the failover problem is necessarily minor; in implementations I'm familiar with, developing a stable and reliable failover algorithm was a major pain. With respect to the reasoning behind the development of RADIUS over TCP, is the issue really the need for a "different set of tradeoffs", or is the issue the different set of needs that manifest themselves in proxy-proxy transport situations? As described in RFC 3539, NAS-proxy scenarios do not really benefit from reliable transport because the connection would be likely to run with the minimum congestion window most of the time. As a result, using reliable transport just generates a lot of ACK traffic without making use of the congestion control/window management benefits of TCP. This is not necessarily the case for proxy-proxy transport where the volume may be quite a bit higher. Section 1.1 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. [BA] I think you might say a bit more about the applicability of RADIUS over "bare" TCP. For example, that it is only useful in proxy-proxy scenarios where the traffic is protected by TLS. The reasons given might include both transport as well as security and interoperability concerns. For example, we have seen interoperability problems result in situations where application layer protocols can be transported in multiple ways (e.g. SIP), and proxy-proxy scenarios can benefit from stronger/more flexible security, as envisaged in RADIUS over TLS. |