RADIUS over TCP
RFC 6613

Agree with Tim's DISCUSS.

Section 27, paragraph 13:
>    It is not intended
>    to define TCP as a transport protocol for RADIUS in the absence of
>    TLS.

  The document title is "RADIUS Over TCP". It's surprising to then see
  that abstract say that it is not intended to define RADIUS over TCP...
  Suggestion: Rename document to "Radius over TLS"?


Section 1., paragraph 1:
>    While
>    there are a number of benefits to using UDP as outlined in [RFC2865]
>    Section 2.4, there are also some limitations:

  Lack of congestion control is surely a limitation?


Section 1.1., paragraph 2:
>    In scenarios where RADIUS proxies exchange a large volume of packets
>    (10+ packets per second), it is likely that there will be sufficient
>    traffic to enable the congestion window to be widened beyond the
>    minimum value on a long-term basis, enabling ACK piggy-backing.

  I don't understand what this paragraph means to say. The TCP
  congestion window opens already at much lower rates than 10+ pps.
  Also, how is this at all related to ACK-piggybacking?


Section 1.1., paragraph 5:
>    These problems disappear if a 4096 application-layer payload can be
>    used alongside RADIUS over TLS.  Since most TCP implementations
>    support MTU discovery, the TCP MSS is automatically adjusted to
>    account for the MTU, and the larger congestion window supported by
>    TCP may allow multiple TCP segments to be sent within a single
>    window.

  Even those few TCP stacks that don't do PMTUD can already support
  arbitrary payloads (just with slightly less efficient packetization).


Section 2.6.1., paragraph 5:
>    As noted previously, RADIUS packets SHOULD NOT be re-transmitted to
>    the same destination IP and numerical port, but over a different
>    transport layer.

  Where does it say that? The second paragraph of Section 2.6 says that
  they MAY be retransmitted over a new connection (which is different
  from a SHOULD NOT). Also, "transport layer" here is unclear - do you
  mean "transport connection" (= use a different TCP connection) or do
  you mean "transport protocol" (= use UDP)?


Section 2.6.2., paragraph 2:
>    Unlike UDP, TLS is subject to issues related to Head of Line (HoL)
>    blocking.  This occurs when when a TLS segment is lost and a
>    subsequent TLS segment arrives out of order.  While the RADIUS server
>    can process RADIUS packets out of order, the semantics of TLS makes
>    this impossible.  This limitation can lower the maximum packet
>    processing rate of RADIUS over TLS.

  s/TLS/TCP/ in this paragraph


Section 2.6.4., paragraph 6:
>    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.

  In order to reduce connection-setup overheads, wouldn't it make sense
  to RECOMMEND the connection stay open?

I cleared my DISCUSS, because I think (I hope I have this right) that "this specification"
in this text:

   "Bare" TCP transport MAY, however, be used when another method such
   as IPSec [RFC4301] is used to provide additional confidentiality and
   security.  Should experience show that such deployments are useful,
   this specification could be moved to standards track.
 
refers to a new, to-be-written document describing the use of TCP+IPSEC.

If I don't have it right, then I still don't understand how experience with TCP+IPSEC
would cause draft-ietf-radext-tcp-transport to be moved to standards track.

  Please consider the comments from the Gen-ART Review by Glenn
  Kowack on 18 May 2010.  The review can be found at:

    http://www.softarmor.com/rai/temp-gen-art/
    draft-ietf-radext-tcp-transport-06-kowack.txt