Re: Review of draft-ietf-radext-tcp-transport (Part I)

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
> [BA] In particular, filters routers and firewalls often drop UDP
> fragments, since otherwise they would need to reassemble them in order
> to apply the filter rules.
> 
> However, this is not a âtransportâ issue, so much as a
> forwarding/filtering issue.  Instead of âTransportâ you might say
> âhandlingâ.

  OK.

> [BA] Note double periods in first sentence, and no period in the last
> sentence.  As I read the document, it is really only suggesting a
> different set of tradeoffs for inter-server proxying.  So you might say
> âFor use-cases such as inter-server proxying, [RTLS] suggests an
> alternative transport and security model -- RADIUS over TLS.  This
> document describes the transport implications of running RADIUS over
> TLS/TCP.â

  OK.

> [BA]  Suggested rewrite:
> ...the larger congestion
>    window supported by TCP may allow multiple TCP segments to
>    be sent within a single window.  As a result, RADIUS/EAP
>    traffic required for an EAP-TLS authentication with 8KB
>    certificate chains may be reduced to 7 round-trips or less,
>    resulting in substantially reduced authentication times.

  Is that really true?  The common limitation on EAP is the 1022 byte
maximum overhead for EAPoL.  Allowing 4K RADIUS packet sizes helps only
when doing EAP *without* EAPoL.  That's a pretty rare occurance.

...  In addition, most TCP
>    implementations discover Path MTU better than RADIUS application
>    implementations, resulting in significantly fewer fragmented packets.

  This is duplicate text.

  I've done some word-smithing, and updated the doc.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>