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.
