Re: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis-25

[Benjamin Kaduk <[e-mail]>]

Sorry to jump in and hijack the middle of a different thread, but...

On Wed, Jun 19, 2019 at 01:24:42PM +0000, Konda, Tirumaleswar Reddy wrote:
> Hi Joe,
> 
> I have added the following lines to address your comment:
> 
>    TCP multi-path [RFC6824] is not supported by this version of TURN
>    because TCP multi-path is not used by both SIP and WebRTC protocols
>    [RFC7478] for media and non-media data.  If the TCP connection
>    between the TURN client and server uses TCP-AO [RFC5925] or TLS, the
>    client must secure application data (e.g. using SRTP) to provide
>    confidentially, message authentication and replay protection to
>    protect the application data relayed from the server to the peer
>    using UDP.  Attacker attempting to spoof in fake data is discussed in

... this kind of cross-layer security requirement ("if you were using
TCP-layer protection, now you have to impose a requirement on the
application protocol (stack) at a higher layer") has been quite problematic
in the past when attempted for other protocols.  Consider this early
warning that it will get a careful security area review during IESG
evaluation, if not sooner.  Being very specific about which component of
the system has what requirements under which conditions would be helpful,
as a start.

-Ben

>    Section 20.1.4.  Note that TCP-AO option obsoletes TCP MD5 option.
>    Unlike UDP, TCP without the TCP Fast Open extension [RFC7413] does
>    not support 0-RTT session resumption.  The TCP user timeout [RFC5482]
>    equivalent for application data relayed by the TURN is the use of RTP
>    control protocol (RTCP).  As a reminder, RTCP is a fundamental and
>    integral part of RTP.