[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fwd: Re: COMMENT: draft-ietf-radext-tcp-transport]



--- Begin Message ---
Lars Eggert wrote:
> 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"?

  There is already a RADIUS over TLS document.  The key phrase in the
sentence you quoted is "in the absence of TLS".

  The *previous* sentence says:

    This document defines RADIUS over the Transmission Control
    Protocol (TCP), in order to address handling issues related
    to RADIUS over Transport Layer Security [RTLS].

  So it *is* defining RADIUS over TCP.  It's just suggesting that no one
use it.

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

  Yes.  I suggest a new bullet:

* Lack of congestion control.  Clients can send arbitrary amounts of
traffic with little or no feedback.  This lack of feedback can result
in congestive collapse of the network.

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

  We can just remove the "10+ packets per second" text.

>   Also, how is this at all related to ACK-piggybacking?

  The TCP ACKs can piggy-back on the RADIUS responses, rather than being
sent separately.

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

  I can add some text saying that.

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

  Hmm... nowhere.  That text was left over from earlier edits &&
re-arrangements.

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

  transport protocol.

> 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

  Done.

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

  Maybe.  It's a toss-up between leaving the connection open in order to
reduce setup, *or* closing it because the client obviously doesn't
implement the RADIUS protocol.

  Alan DeKok.


--- End Message ---