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

["Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@xxxxxxxxxx>]

Hi Joe,

 

I have added the following line to address your other comment:

 

Note that the server does not perform per-packet translation for TCP-to-UDP relaying and vice-versa. For TCP-to-UDP relaying from client to peer, the TURN server sets the DF field in the outgoing UDP packet based on the presence of DONT-FRAGMENT attribute in the TURN message. For UDP-to-TCP relaying from peer to client, the TURN server sets IP header fields in the TCP packets on a per-connection basis for the TCP connection.

 

Cheers,

-Tiru

 

From: Joe Touch <touch@xxxxxxxxxxxxxx>
Sent: Wednesday, June 19, 2019 7:51 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@xxxxxxxxxx>
Cc: Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx>; tsv-art@xxxxxxxx; draft-ietf-tram-turnbis.all@xxxxxxxx; ietf@xxxxxxxx; Brandon Williams <brandon.williams@xxxxxxxxxx>; tram@xxxxxxxx
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.

---

Hi, Tiru,

 

You still appear to be ignoring the issue about implying per-packet adjustment of IP options and parameters during a TCP connection, in specific.

 

Joe

On Jun 19, 2019, at 6:24 AM, Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@xxxxxxxxxx> 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

   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 <touch@xxxxxxxxxxxxxx> 
Sent: Tuesday, June 18, 2019 8:03 PM
To: Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx>
Cc: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@xxxxxxxxxx>; tsv-art@xxxxxxxx; draft-ietf-tram-turnbis.all@xxxxxxxx; ietf@xxxxxxxx; Brandon Williams <brandon.williams@xxxxxxxxxx>; tram@xxxxxxxx
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 <magnus.westerlund@xxxxxxxxxxxx> 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