Subject: Re: [tram] Need to be fixed! Discuss on draft-ietf-tram-turn-server-discovery-10: (with DISCUSS)

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Tue, 18 Oct 2016 02:38:15 +0000

On 10/17/16, 1:15 AM, "Karl Stahl" <[email-masked]<mailto:[email-masked]>> wrote:

Spencer,

Can the authors of this discovery draft “be ordered” to address the two points below?

:-)

Point 2) was (unnecessarily) introduced during the DISCUSS
(I just highlighted to the WG list that it is NOT addressed, in spite of what is said by an author.)

Point 1) has repeatedly been pointed out on this WG list since version -06 of the draft, but ignored by the authors.

We intend to add the following to explain server behavior a little better:
“A TURN anycast server performs checks 1 to 7 discussed in Section 6.2 of RFC5766. If all checks pass, the TURN anycast server MUST respond with a 300 (Try Alternate) error as described in [RFC5766];”

As the text is in this version -10 of the draft now is, it does NOT fulfill its purpose to discover a network provided TURN server to allow real-time communication, in situations where it otherwise is not possible or bad.
- It does not provide a method suitable for draft-ietf-rtcweb-return-01
- It does not meet the autoconfiguration of RFC 7478 (Web Real-Time Communication Use Cases and Requirements) 2.3.5.1.

More generally (regarding the mandating of (D)TLS, suddenly introduced during the DISCUSS):
We should be able to use WebRTC everywhere we can and do surf, and for firewall/NAT traversal and quality it is in many cases necessary to parallel the local firewall/access router/default gateway with a TURN server, to get a good media path. The automatic discovery of such network provided turn server should be given by this draft, but it should NOT set up restrictions for it usage (especially when it is unnecessary and blocks the general usage e.g. such as specified in draft-ietf-rtcweb-return-01).

Not mandating DTLS opens up the client/server to a host of attacks such as an attacker sending fake requests/responses. The draft is meant for general purpose TURN server discovery, not specific to WebRTC, and hence, security considerations have to be broad.

-Prashanth

The authors of this draft seem to have some other use case in mind, but that must not block the usage for which this discovery specification was required.
As written in this version -10 of the draft, it is a showstopper.

/Karl

---

From: Karl Stahl <[email-masked]>
Date: Tue, 18 Oct 2016 15:20:04 +0200

Spencer (and authors),

We need the long awaited discovery draft and the anycast method, and don’t want an “appeal (which gets us right back here, after wasting time).” 

It must work for discovery of a network provided turn server, that the provider of the local network (LAN) has made available for all his users to run real-time traffic through (rather than through a data crowded or blocked default gateway path). 

This draft cannot/must not (thrown in during the DISCUSS!) block such general usage by under 9 mandating (D)TLS, requiring a new infrastructure to be established by:

A TURN client MUST use (D)TLS …

   one of the following techniques with (D)TLS to validate the TURN

   server:

   o  For certificate-based authentication, a pre-populated trust anchor

      store…

   o  Certification authorities that issue TURN server certificates…

especially when the release of authentication of such turn servers have been specified in the draft.

Ben Campebell did not clear his DISCUSS unconditionally, he said:

“-9, third paragraph:
I saw a comment on my DISCUSS email thread from Karl Stahl, stating that DTLS could not be mandated. Has that input been considered? (I don't have an opinion; I just want to make sure people noticed the comment.)”

That input has NOT been considered.

>From below it seems like the authors will issue a version -11 of the draft

Prashanth,

Please, then remove the (D)TLS mandating.

Your comment:

is irrelevant for turn server allocations on the LAN, where everything is as open as it is: You cannot/should not expect the real-time traffic to have better security by sending it through the turn server path than through the default gateway path. In addition, WebRTC has DTLS-SRTP of the real-time traffic mandated in itself!

And regarding:

> The draft is meant for general purpose TURN server discovery, not specific to WebRTC

Network provided turn servers for WebRTC usage was actually the main purpose: Specifically that must not be blocked now (thrown in during discuss phase)!

SEE FURTHER INLINE BELOW, regarding the issue repeatedly ignored/unanswered during the WG stage (since highlighted in version -06 of this draft).

/Karl

Från: Prashanth Patil (praspati) [mailto:[email-masked]] 
Skickat: den 18 oktober 2016 04:38
Till: Karl Stahl; 'Spencer Dawkins at IETF'; 'The IESG'; [email-masked]
Kopia: [email-masked]; 'Alexey Melnikov'; [email-masked]; 'Simon Perreault'; Tirumaleswar Reddy (tireddy)
Ämne: Re: SV: [tram] Need to be fixed! Discuss on draft-ietf-tram-turn-server-discovery-10: (with DISCUSS)

On 10/17/16, 1:15 AM, "Karl Stahl" < <mailto:[email-masked]> [email-masked]> wrote:

Spencer,

:-)

[Karl] That must be an update of RFC5766. Or does “TURN anycast server” imply that there ALSO is a “TURN unicast server” at the same interface accepting the Allocate request?  

My proposal is better (in several aspects) and don’t need to update RFC5766 turn server behavior.

-Prashanth

/Karl