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

[Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx>]

On 2019-06-18 15:11, Konda, Tirumaleswar Reddy wrote:

HI Magnus,

 

Please see inline [TR]

 

From: tram <tram-bounces@xxxxxxxx> On Behalf Of Magnus Westerlund
Sent: Tuesday, June 18, 2019 4:57 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@xxxxxxxxxx>; Joe Touch <touch@xxxxxxxxxxxxxx>
Cc: tsv-art@xxxxxxxx; draft-ietf-tram-turnbis.all@xxxxxxxx; ietf@xxxxxxxx; Brandon Williams <brandon.williams@xxxxxxxxxx>; tram@xxxxxxxx
Subject: Re: [tram] [Tsv-art] 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 2019-06-17 12:44, Konda, Tirumaleswar Reddy wrote:

You need to address these issues - e.g., by a version of the response above.

[TR1] Okay, will add the following lines:

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], 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.  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 TURN is the use of RTP control protocol (RTCP). As a reminder,  RTCP is a fundamental and integral part of RTP.

 

Sorry, I find this very confusing. On the Client to TURN Server leg if that is using a TCP connection, then there are no issues with using either TCP-MP or TCP-AO options on that leg. They will have no impact on the TURN messages carried inside the TCP connection or how its outgoing IP/UDP packet. So from my perspective there are no necessity to discuss these as not supported.

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

What is discussed in this document are the options for the IP/UDP packet being sent or received by the turn server to the peer. Those IP/UDP Fields that can be controlled and have meaning are discussed here. Like the DSCP, where TCP will force the use of a single one, when UDP to UDP can support many as the field value is taken from the packet on the client to server leg, rather than an internal TURN message field.

I guess the issue here is that there is a lack of requirement making clear that for a number of the fields in the IP/UDP handled on the server to peer leg that needs to handling rules for the client to server transport.

I think what Section 14 and 15 talks about should be labeled relaying and not translation. And thus focus on how one avoid information or intent loss in the relay process. I understand why section 13 is called translation, but when we get down to it, it is the same here, but a focus on how the relay process maintain information of the IP layer, especially in the face of address family differences.

[TR] Agreed, replaced translation with relaying in both sections 14 and 15.

If I understand Joe's comments, I think a core part of this discussion is that the introduction to section 14 and 15 don't make it clear the purpose of these section is to define which information that needs to be preserved in the relay, and which doesn't not and in that case what are appropriate behaviors.

Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx
----------------------------------------------------------------------