[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Fwd: Re: COMMENT: draft-ietf-radext-tcp-transport]
- To: 'radext mailing list' <email@example.com>
- Subject: [Fwd: Re: COMMENT: draft-ietf-radext-tcp-transport]
- From: Alan DeKok <firstname.lastname@example.org>
- Date: Thu, 20 May 2010 13:38:07 +0200
- User-agent: Thunderbird 126.96.36.199 (Macintosh/20100228)
--- 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
> 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
> Section 1., paragraph 1:
>> 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
> 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
> 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 &&
> 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?
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.
--- End Message ---