Re: REMINDER: Call for adoption of "RADIUS over TCP" as a RADEXT WG Work Item

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
> [BA] My impression was that this document (like RADIUS over TLS and
> RADIUS over DTLS) was targeted for Experimental status.

  Fixed.

> Abstract
...
> [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.   

  That text is also in Section 1.1, but it doesn't hurt to emphasize it
here.

> [BA] Determining when a client or server is down is not automatically
> solved by choice of a reliable transport.

  TCP can provide a positive statement when a connection is down.

> 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.

  Yes.  Or, receiving a FIN when a connection is closed.

>  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.

  For robust proxying, a number of implementations track server state.
They can implement simple checks such as "no response to any packet in
the last 60 seconds".  They can then mark a server as "down", remove it
from any pool of active servers, and refuse to forward *new* packets to it.

>  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.

 Hmm... I'm not so sure.  Failover algorithms are hard to get right.
And I don't think that the TCP document is the best place to discuss
general RADIUS failover.

  Defining a TCP watchdog is OK, but that's just referencing RFC 3539.

  Maybe the text should say instead:

* 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.

> [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.

  Agreed.

>  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?

  Both, I think.  Suggested rewording:

As RADIUS is widely deployed, and has been widely deployed for well
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.

> [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. 

  How about this text:

Deployment experience with RADIUS over TLS indicates that is useful
for inter-server communication, such as inter-domain proxying across
the Internet.  The large amounts of traffic, and long-lived
connections are a good fit for TCP transport.  These situations
commonly also require complete data privacy that can be supplied by
TLS.

The use of "bare" TCP has fewer use-cases.  Using TCP for NAS to
server communication is a bad fit, as there is usually insufficient
traffic to warrant the use of TCP.  Using "bare" TCP for inter-server
communication is a bad fit, as it provides for no data privacy.  The
only valid use-case for "bare" TCP, therefore, is on private, secured
networks where there is simultaneously a large amount of traffic, and
no need for data integrity or privacy.

  Alan DeKok.


  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>