Subject: REMINDER: Call for adoption of "DTLS as a Transport Layer for RADIUS" as a RADEXT WG Work Item

From: Bernard Aboba <[email-masked]>
Date: Wed, 2 Sep 2009 17:18:15 -0700

This is a reminder of the ongoing call for review of the document "DTLS as a Transport Layer
for RADIUS" for adoption as a RADEXT WG work item.  This document is
being targeted at Experimental
status. 

The document is available for review here:
http://tools.ietf.org/html/draft-dekok-radext-dtls

The original call for review expired August 7, 2009, but no comments were received.  This call for input will last until October 2, 2009.  Please send email to
the RADEXT WG mailing list indicating whether you support adoption of
this document as a RADEXT WG work item.  If you have comments on the
document, please also send these to the list in the format described on
the RADEXT WG Issues list:
http://www.drizzle.com/~aboba/RADEXT/

---

From: Stig Venaas <[email-masked]>
Date: Tue, 08 Sep 2009 13:38:10 -0700

Bernard Aboba wrote:
> This is a reminder of the ongoing call for review of the document "DTLS 
> as a Transport Layer for RADIUS" for adoption as a RADEXT WG work item.  
> This document is being targeted at Experimental status.
>  
> The original call for review expired August 7, 2009, but no comments 
> were received.  This call for input will last until October 2, 2009.  

I'm in favour of adoption,

Stig

> Please send email to the RADEXT WG mailing list indicating whether you 
> support adoption of this document as a RADEXT WG work item.  If you have 
> comments on the document, please also send these to the list in the 
> format described on the RADEXT WG Issues list:
> <http://www.drizzle.com/%7Eaboba/RADEXT/>
> 
> <http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 16 Sep 2009 10:53:40 -0700

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.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 17 Sep 2009 11:43:26 +0200

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.

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

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 17 Sep 2009 08:45:07 -0700

> no need for data integrity or privacy.

How about this? 

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