Subject: Review of draft-ietf-radext-tcp-transport (Part II)

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 3 Feb 2010 17:03:15 -0800

Section 2

   Adding TCP as a RADIUS transport has a number of impacts on the

   protocol, on applications using the protocol, and on networks that

   deploy the protocol.  In short, RADIUS over TCP is little more than

   sending RADIUS formatted messages over a TCP connection.

   As always, there are additional details that need to be discussed.

   This section outlines the various impacts of using RADIUS over TCP,

   and the discusses the proposal in more detail.

[BA] How about this? 

RADIUS over TCP involves sending RADIUS formatted messages over a TCP
connection.  

In the sections that follow, we discuss the implications for the RADIUS
packet format

(Section 2.1),  port usage (Section 2.2), RADIUS MIBs (Section 2.3) and
RADIUS proxies

(Section 2.5).  TCP-specific issues are discussed in Section 2.6. 

Section 2.1

   The changes to RADIUS implementations required to implement this

   specification are largely limited to the portions that send and

   receive packets on the network.

[BA] Is this sentence necessary?  What portions of a RADIUS implementation
*don't* relate

To sending and receiving packets?   I'd recommend that it be deleted. 

Section 2.2

   These ports are unused by existing RADIUS applications.

   Implementations SHOULD use the assigned values as the default ports

   for RADIUS over TCP.

[BA] You might say "Since these ports are unused by existing RADIUS
implementations,

the assigned values SHOULD be used as the default ports for RADIUS over
TCP."

I would merge section 2.4 into this section so that one section can cover
ports

for both RADIUS over TCP and RADIUS over TLS. 

Section 2.3

You might revise this section to make it clear that the advice for use of
MIBs 

with RADIUS over TCP also applies to RADIUS over TLS. 

Section 2.4

I'd merge this with Section 2.2. 

Section 2.5

[BA] Suggest this section be renamed "Liveness Detection". 

   If a request is proxied through intermediate proxies, it is not

   possible to detect which of the later hops is responsible for the

   absence of a reply.  An intermediate proxy also cannot signal that

   the outage lies in a later hop because RADIUS does not have the

   ability to carry such signalling information.  This issue is further

   exacerbated by some proxy implementations that do not reply to a

   client if they do not receive a reply to a proxied request.

[BA] This paragraph makes it seem that absence of a response by a proxy is
incorrect behavior. 

Suggest:

   "Within RADIUS as defined in [RFC2865], proxies typically only forward

   traffic between the NAS and RADIUS server, and do not generate their

   own responses.  As a result, when a NAS does not receive a response to

   a request, this could be the result of packet loss between the NAS

   and proxy, a problem on the proxy, loss between the RADIUS proxy and

   server, or a problem with the server."  

   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
<http://tools.ietf.org/html/rfc3539#section-3.4>  3.4 enables clients to

   determine that the server is "live", even though it may not have

   responded recently to non-watchdog requests.

[BA] Suggest the following:

   "For RADIUS over TLS/TCP, it is RECOMMENDED that implementations

   utilize the existence of a TCP connection along with the 

   application layer watchdog defined in [RFC3539] Section
<http://tools.ietf.org/html/rfc3539#section-3.4>  3.4 to

   determine that the server is "live"."

   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

      upstream server could exceed the sending rate of a single TCP

      connection to that server, based on the window size/RTT estimate.

      * It is possible for the incoming rate of TCP packets destined to

      a given realm to exceed the UDP throughput achievable using the

      transport guidelines established in [RFC5080
<http://tools.ietf.org/html/rfc5080> ].  This could happen,

      for example, where the TCP window between proxies has opened, but

      packet loss is being experienced on the UDP leg, so that the

      effective congestion window on the UDP side is 1.

   Intrinsically, proxy systems operate with multiple control loops

   instead of one end-to-end loop, and so are less stable.  This is true

   even for TCP-TCP proxies.  As discussed in [RFC3539
<http://tools.ietf.org/html/rfc3539> ], the only way to

   achieve stability equivalent to a single TCP connection is to mimic

   the end-to-end behavior of a single TCP connection.  This typically

   is not achievable with an application-layer RADIUS implementation,

   regardless of transport.

[BA] I suggest this material be put into a different section entitled

"Congestion Control Issues", since it doesn't relate to liveness detection

(the subject of the rest of the section). 

Section 2.6

   The guidelines defined in [RFC3539 <http://tools.ietf.org/html/rfc3539> ]
for implementing an AAA protocol

   operating over a reliable transport MUST be followed by implementors

   of this specification.

[BA] Not sure the MUST adds value here.  I suggest:

"The guidelines defined in [RFC3539] for implementing a AAA protocol over

reliable transport are applicable to RADIUS over TLS/TCP."

   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 permit different shared secrets to be used for

   UDP and TCP connections to the same destination IP address and

   numerical port.

[BA] I'd suggest "RADIUS over TLS/TCP Implementations MUST support receiving
RADIUS packets over both UDP and TLS/TCP transports originating from the
same  endpoint. 

RADIUS packets received over UDP MUST be replied to over UDP;   RADIUS
packets received over TLS/TCP MUST be replied to over TLS/TCP.  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 permit different shared secrets to be used for

   UDP and TLS/TCP connections to the same destination IP address and

   numerical port.

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.

[BA] Suggest:

   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, TLS/TCP is subject to issues related to Head of Line (HoL)
   blocking.  This occurs when when a TLS/TCP segment is lost and a
   subsequent TLS/TCP segment arrives out of order.  While the RADIUS server
   can process RADIUS packets out of order, the semantics of TLS/TCP makes
   this impossible.  This limitation can lower the maximum packet
   processing rate of RADIUS over TLS/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 <http://tools.ietf.org/html/rfc3579> ] MUST be unchanged from
previous specifications
 
[BA] I'd suggest that this text be merged with Section 2.1, and that the
above paragraph be changed to the following:
 
"The use of TLS/TCP transport does not change the calculation of
security-related
fields (such as the Response-Authenticator) in RADIUS [RFC2865] or RADIUS
Dynamic 
Authorization [RFC5176].  Calculation of attributes such as
User-Password [RFC2865] or Message-Authenticator [RFC3579] also does not
change." 

Section 2.6.4

   Implementations of this specification SHOULD treat the "silently

   discard" texts referenced above as "silently discard and close the

   connection."  

[BA] What is the alternative to this behavior?  Could this be a MUST?

   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.

[BA] Not sure how you can do this in practice.  Are you assuming that the

Length field remains valid? 

Section 2.6.6

Given the discussion in Section 1.1, I'm wondering if this section (or some
other section)

shouldn't make a recommendation on the maximum RADIUS message size
applicable to use with 

RADIUS/EAP.  It seems to me that using a larger RADIUS message size would
make a lot of 

sense.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 19 Feb 2010 11:40:03 +0100

> [BA] How about this?

  OK.

> [BA] Is this sentence necessary?  What portions of a RADIUS
> implementation **don’t** relate
> To sending and receiving packets?   I’d recommend that it be deleted.

  Implementations have re-tranmission timers for UDP sockets.  These
timers need to be disabled for TCP sockets.

  The timers are usually "internal" to an implementation, and don't
directly involve recv() or send() calls.

> [BA] You might say “Since these ports are unused by existing RADIUS
> implementations, 
> TCP.”

  OK.

> I would merge section 2.4 into this section so that one section can
> cover ports 

  OK.

> You might revise this section to make it clear that the advice for use
> of MIBs 

  I thought I'd leave that to the RTLS document.

> [BA] Suggest this section be renamed “Liveness Detection”.

  How about "detecting live servers" ?

> [BA] What is the alternative to this behavior?  Could this be a MUST?

  There are some cases where "silently discard" is OK for TCP.  I don't
recall right now, but I do remember auditing the previous documents.

  The text following that sentence outlines the situations where closing
the connection is a MUST.

> Length field remains valid?

  Yes.  The previous MUST requirement are applied first.

  How about the clarifications to the text:

 After applying the above rules, there are still situations where the
 previous specifications allow a packet to be "silently discarded".  In
 these situations, the TCP connections MAY remain open, or MAY be
 closed, as an implementation choice.  However, the invalid packet MUST
 be silently discarded.

> Section 2.6.6
>
> Given the discussion in Section 1.1, I’m wondering if this section (or
> some other section) 
> shouldn’t make a recommendation on the maximum RADIUS message size
> applicable to use with
> RADIUS/EAP.  It seems to me that using a larger RADIUS message size
> would make a lot of sense. 

  Only when the transport protocol to the supplicant allows large EAP
packets.

  If the NAS sends a Framed-MTU, most RADIUS servers will honor it.
This works today when large packets are allowed.

  Alan DeKok.

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