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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

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

Cheers,
-Tiru

From: Joe Touch <[e-mail]>
Sent: Tuesday, June 18, 2019 8:03 PM
To: Magnus Westerlund <[e-mail]>
Cc: Konda, Tirumaleswar Reddy <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; Brandon Williams <[e-mail]>; [e-mail]
Subject: Re: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis-25


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________



On Jun 18, 2019, at 6:47 AM, Magnus Westerlund <[e-mail]<mailto:[e-mail]>> wrote:

[TR] The comment from Joe is : if TCP-AO is used, application data is authenticated in the TCP leg but the data can be faked when relayed from the server to the peer using UDP. I tried to address this comment by saying if secure application data (SRTP) is used message authentication is available at the application layer even if UDP does not support authentication option.
Sure, but this is equivalent to the case of TURN over TCP/TLS that also only have the security model to the middle. So pointing that aspect out is fine, but I think TURN is quite clear on that client to peer security are the responsibility of the end-to-end application using TURN. Like the statement in the Third paragraph of 20.1.4:

   These attacks are more properly mitigated by application-layer

   authentication techniques.  In the case of real-time traffic, usage

   of SRTP [RFC3711] prevents these attacks.

FWIW, even with this statement, if you’re going to talk about preserving IP options and settings then it’s equally important to discuss how you preserve or interfere with TCP options and settings - and maybe other layers like TLS too - in the same place in the document.

It’s not just whether this is a security issue; it’s that the semantics are broken in half.

Joe