Subject: Re: [tram] Anycast discovery, was: draft-ietf-tram-turn-server-discovery

From: "Karl Stahl" <[email-masked]>
Date: Fri, 2 Dec 2016 09:33:33 +0100

Hi Simon,

Sorry for late reply, I wanted to connect that Linksys router again to see
if I had missed something in the GUI (I actually had - I admit), so detail
argumentation may hide the more general points I am trying to
convey/exemplify.

I also want to avoid confusion that may arise from that I wrote "> resolve
the NAT/Firewall traversal problem
that has plagued real-time communication since SIP was introduced in early
2000" (that was a very general overview comment" which is NOT the same NAT
thing you are commenting as "Why would you want to use port forwarding and
have to deal with NAT issues" (here I think you relate to a "NAT issue" of
getting the anycast Allocate packet to the correct IP address of that
special TWO LAN IP TURN server so it can respond with the 300 error, while
using the anycast Binding request instead, there is no  such "NAT issue" to
resolve - Just get the anycast packet to *the TURN server* (no matter how)
and you will get the unicast address of "the TURN server" to USE in the 300
error response.

I am (trying to) exemplify/clarify the high level (important) points why we
need/want anycast discovery by saying Binding instead of Allocate. These
points are:

(A) We need an anycast discovery method for auto-discovering "a TURN server"
(not some special TURN server or arrangement of TURN servers "invented" for
being discoverable by a certain method)

(B) We need an anycast discovery method for a TURN server that is
setup/installed/configured for its USAGE (which is relaying traffic) - not
requiring a special network configuration just for being discoverable. (And
more widely, it must be the goal of this specification to provide at least
one discovery method that works for ALL network types and configurations,
where a network provided TURN server may be useful - I see only anycast
using Binding for querying *the TURN server's* unicast address fulfilling
this.)  

(C) Robust (tolerant) deployment is highly preferable.

(D) Ease of deployment is highly preferable.

Saying Binding instead Allocate, is nessesary to achieve (A) and (B), and
improves (C) and (D). 

Both the requirements RFC https://tools.ietf.org/html/rfc7478 "straddle" (in
"deploy a TURN server that straddles the boundary between the internal and
the external network. *The firewall* will block all attempts to use STUN
with an external destination unless they go to the enterprise auditing TURN
server." and the return draft's
https://tools.ietf.org/html/draft-ietf-rtcweb-return-01 "firewall
configuration" (in "This TURN server may be placed inside the network, with
*a firewall configuration* allowing it to communicate with the public
internet, or it may be operated by a third party outside the network, with a
firewall configuration that allows hosts inside the network to communicate
with it.") assumes (or at least implies/allows/suggest) network
configurations that should works if we say Binding, but not if we say
Allocate. These are not shoot-yourself-in-the-foot deployment scenarios, but
real ones that this draft shall support: Point (A) and (B) fails when saying
Allocate in the anycast method. 

And generally, saying Binding works in All cases where saying Allocate CAN
work (There are no drawbacks). Saying Binding results in more robust
configuration and more ways how to deploy (never less). In addition,
changing to Binding from Allocate, is the fastest/easiest way to clarify the
draft (in addition to clarify what that TWO LAN IP TURN "anycast server"
actually is, we have the lack of distinction between discovery and usage,
and even the confusion around the authentication/DTLS discussion that has
nothing to do with the discovery method (It only applies to usage).   

Regarding the points below in my exemplification, starting with where we
agree:

> Note however that the preferred deployment scenario here would be to
have the TURN server be embedded on the home router 
[Karl] Fully agree 
so as to have one leg on the LAN and another on the WAN 
[Karl] Fully agree
and thus avoid NAT. 
[Karl] ?? Don't follow
No need for manual routing setup in this case, and the current anycast
discovery
method would work perfectly.
[Karl] Fully agree and understand, and the same applies if you say Binding
instead of Allocate. In addition, by saying Binding, you get the advantage
of an easier implementation with ONE TURN server instead of TWO embedded in
the home router (the second only adds the limited function of responding
with the 300 response to an Allocate request).  
But, yes, BOTH works - and hides the complication from saying Allocate and
having to be concerned about anycast routing setup.

[Karl] Further, an embedded TURN server AT the default gateway address may
be an even more preferred deployment scenario, and easier implementation and
will work is saying Binding but not if saying Allocate... 

Further in-line below --> 

/Karl

-----Ursprungligt meddelande-----
Från: Simon Perreault [mailto:[email-masked]] 
Skickat: den 28 november 2016 14:31
Till: Karl Stahl; 'Tirumaleswar Reddy (tireddy)'; 'Brandon Williams';
'Prashanth Patil (praspati)'; [email-masked]
Kopia: [email-masked]; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: Re: SV: SV: SV: SV: [tram] Anycast discovery, was:
draft-ietf-tram-turn-server-discovery

Le 2016-11-27 à 15:00, Karl Stahl a écrit :
> I just looked into the GUI of a Cisco 14890/Linksys EA2700 WiFi Router
> having a single subnet for wireless and its 4 LAN ports. In a data crowded
> environment it is in need of a paralleled TURN server for a path to the
high
> quality voip pipe in my triple play network access, especially with WebRTC
> voice+video wanting 2.5 mbps through the access for one session.
> 
> Finding "Single Port Forwarding" in the router GUI, it should be able to
> forward all STUN and TURN packets to a TURN server at the LAN,

I'm not following, sorry. Why would you want to use port forwarding and
have to deal with NAT issues, 
[Karl] ?? With the Binding variant, there is no "NAT issue" to deal with!
Port forwarding was just to get the anycast packet to *the TURN server*. 
while there are much simpler mechanisms available to you?
[Karl] What could possibly be simpler? With this port forwarding I assure
that the anycast packet arrives at *the TURN server* and also seals the
network (in a way that the TURN client can detect)

[Karl] And by this trivial UDP port 3478 forwarding to *the TURN server* I
both fix the routing to the TURN server and seal the network (STUN request
don't go out) (which the TURN client can detect and use sealed behavior). 

(Maybe you only have "pure IP routing" in mind, but routing based on port or
application, or quality needs is very common in triple play broadband access
networks that I am familiar with - Here I have one LAN but 4 WAN pipes
(Surf, Voice, IP-TV, TR069-managent) over my copper ADSL phone line and
routing involves even more "obscure" criteria than port-based, e.g. knowing
whether the application is SIP trunking to a certain SP, to enforce usage of
the Priority Voice pipe for a specific SIP service. And you typically have
classifiers, e.g. selecting a port range to have DSCP bits sets AND to route
to a special network. So I would say this kind of routing is not at all
unusual, especially when it comes to real-time communications.) 

> but I could
> not find the routing table for adding a static anycast route, nor could I
> find a way to create an extra subnet on the LAN side (or at all).

http://www.linksys.com/us/support-article?articleNum=135048
Step 5 shows how to configure static routing table entries.
[Karl] You are correct, I missed that under "Advanced Routing" when I looked
in the GUI...

This is a super common feature on home routers. As another example, I'm
currently using an Asus RT-AC66U and it also has that feature:

http://www.asus.com/us/support/FAQ/1011706/
[Karl] Probably fully correct, but IF/WHEN missing, saying Binding will
work, saying Allocate will not work.  

Note however that the preferred deployment scenario here would be to
have the TURN server be embedded on the home router so as to have one
leg on the LAN and another on the WAN and thus avoid NAT. No need for
manual routing setup in this case, and the current anycast discovery
method would work perfectly.
[Karl] Yes correct, but saying Binding give even further advantages, see
above

> The
> Binding anycast discovery method should work, but not the discussed
> separating between TWO TURN addresses.

See above. In addition, your proposed alternative would require NAT,
which is a non-starter.
[Karl] ?? Now I don't follow. The only requirement is that the anycast
Binding request goes to *the TURN server* (NAT or no NAT, however you do
it).

> And thinking further, will we not just delay this highly needed RFC
further
> by more demonstrations?...

(This discussion is not delaying anything. The DTLS one is.)

I will not respond to the paragraphs below because they ask questions
that are premature. Again with my chair hat on, problems with the
current mechanism need to be demonstrated before a solution can be
proposed. This has not yet happened.

Simon

> The more I look into this, and even if I would agree to all your
> comments/answers below, we cannot accept a discovery draft that is highly
> unclear, on what it is we are able to discover (TWO TURN servers or
combined
> into ONE, listening to TWO IP addresses, not described here or in RFC5766
> (TURN protocol not being changed is no excuse)) and with a method
> description that even qualified members of this WG have discussed in terms
> of using DTLS for the anycast-addressed Allocate or Binding request
packets
> (anycast packets *are over UPD*) and similarly confused by the lack of
> distinction between discovery and usage in the draft.
> 
> I understand and share the opinion that it is urgent to now finally get
this
> draft into place, but accepting the anycast method as it is in this
version,
> may add another decade to finally resolve the NAT/Firewall traversal
problem
> that has plagued real-time communication since SIP was introduced in early
> 2000, when we now are about to complete the ICE/STUN/TURN suit into
> something deployable (as we know, instead of ICE, SBCs are still what is
> used for NAT/Firewall traversal - we make them :-) - but SBCs are not
usable
> with WebRTC. 
> 
> The magic of exchanging the anycast addressed Allocate request to a
Binding
> request for getting the IP address of *the TURN server* is a resolution,
and
> the text for that update is already suggested. This method was proposed
> already in October 2013 after detailed discussion on the RTCWEB list after
> which the TRAM WG was formed
> https://www.ietf.org/mail-archive/web/tram/current/msg00132.html
> You Simon, already then, pointed out the two relevant issues/problems, 
> https://www.ietf.org/mail-archive/web/tram/current/msg00138.html 
> which I also in the suggested "Deployment Considerations for TURN Servers
> Provided by the Local or Access Network" to be added, now have spelled out
> the full solutions to (including the "leakage-problem" that is related to
> your second issue raised at that time).
> 
> So, I think we safely and quickly can fix up this draft for becoming the
> long awaited RFC that gets us an anycast method that at least works for
> detecting "a TURN server" (OK, not "ordinary TURN server" and absolutely
not
> un-described "anycast TURN server"). And without having to bother about
how
> the then anycast addressed Binding arrives at *the TURN server*, we can
> remove the "not all TURN servers may support anycast" under section 3 and
> have no worries over that ">Anycast *is* difficult to implement in many
> real-world scenarios,".
> 
> /Karl
> 
> PS: I don't agree to the "you'd be shooting yourself in the foot" comment,
> which you made on a quote from draft-ietf-rtcweb-return-00, which this
> specification should service with a working and deployable discovery
method
> (which I believe will be done by the changes suggested). Then there will
be
> no need to ">NAT to a different UDP port, so that you are able to
> differentiate unicast and anycast traffic". I said something about
"robust"
> in my suggested deployment considerations to add to this draft -
Robustness
> must also be a goal for successful deployment and for this draft.
> 
> And, since the configuration described in draft-ietf-rtcweb-return-00, is
> for USAGE of the TURN server paralleling the default gateway, those
authors
> could/should not foresee that we come up with a DISCOVERY method that will
> complicate deployment configuration by requiring an extra subnet on the
LAN
> side (that may not be supported by the default gateway router). Using DHCP
> for discovery, one would not have thought of this as a
> shoot-yourself-in-the-foot deployment.
> 
> But DHCP is unfortunately not commonly available on many of the access
> networks we use today (LTE.., IPv6) (and the DHCP discovery is also
> unnecessarily complicated by going via domain name + DNS rather than
> defining a new IANA DHCP option (but I not going to request such change
:-)
> since we cannot use DHCP discovery on all networks a WebRTC browser is
> commonly used from anyway). We simply need the anycast discovery method
for
> WebRTC browsers' general usage.
> 
> The anycast discovery method must be clear, well defined and understood by
> readers of the draft, and with the aim to work in all deployment scenarios
> (for USAGE of such TURN server) and to be as robust and tolerant as
> possible.
> 
> Let's do it! That is also faster and simpler than just making current
method
> clearly defined and understood.
> (We are just making a small change to the method: Allocate -> Binding in
the
> DISCOVERY package to get all these advantages.)

-- 
Simon Perreault
Director of Engineering, Platform | Jive Communications, Inc.
https://jive.com | +1 418 478 0989 ext. 1241 | [email-masked]

---

From: "Karl Stahl" <[email-masked]>
Date: Fri, 2 Dec 2016 09:38:07 +0100

Hi Tiru,

I am trying to make the point that there is no option for this draft,
supposed to fulfill:

[tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and
ISPs

to result in: “We forbid usage of such (yellow) network provided TURN
servers (use gray or grayish TURN servers instead)”,  which is the
consequence of mandating (D)TLS.

Simply leave the consensus since version -7 of this draft by removing the
(D)TLS mandating for TURN servers provided by  the local or access network
thrown-in during the discuss.

/Karl

PS: I believe the attack discussion below is already done, and that you are
wrong in thinking that authentication which protects against spoof attacks
can be exchanged for encryption, and that any of these things protects
against DDOS attacks . These security things address different things and
are not interchangeable, nor are they universal means against attacks of
various kinds.

And the outcome of any such discussion doesn’t change the above.  

Please note (sorry to repeat)  that for the purpose of getting a better path
for real-time traffic than through the default gateway path, we cannot
expect to also get a higher security or trust level, nor to resolve every
problem in the world.

Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] 
Skickat: den 28 november 2016 10:53
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati);
[email-masked]
Kopia: [email-masked]; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery

Hi Karl,

Yes, I am discussing TURN servers provided by local or access networks,
referring to inside attacks launched by attackers inside the local or access
network.

a)An inside attacker sends faked permissions to the TURN server to launch
attack (DOS or DDOS) on the victim (TURN client).

b)An inside attacker sends spoofed TURN requests to the TURN server to close
allocations.

Both above attacks can be prevented by using opportunistic encryption with
(D)TLS.

-Tiru

From: tram [mailto:[email-masked]] On Behalf Of Karl Stahl
Sent: Monday, November 28, 2016 2:49 PM
To: Tirumaleswar Reddy (tireddy) <[email-masked]>; 'Brandon Williams'
<[email-masked]>; Prashanth Patil (praspati)
<[email-masked]>; [email-masked]
Cc: [email-masked]; 'Dan Wing' <[email-masked]>; 'Spencer Dawkins at
IETF' <[email-masked]>
Subject: Re: [tram] draft-ietf-tram-turn-server-discovery

Hi Tiru,

Now I don’t know where you are again.

Are you discussing TURN servers provided by the local or access network (the
yellow TURN servers), that are released from authentication (no dispute
there), but for which (D)TLS mandate was thrown in-during the discuss
(making them gray)? That is the showstopper that must go away. 

Some comments below. Hope we agree  the below does not relate to the yellow
TURN server.

/Karl

Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] 
Skickat: den 28 november 2016 04:02
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati);
[email-masked]
Kopia: [email-masked]; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery

Hi Karl,

No, I don’t agree that (D)TLS is not mandatory. Opportunistic encryption is
not new. It’s discussed in RFC7435, and used in TCP increased security
(TCPINC WG) and DNS privacy exchange (DPRIVE WG). 

How do you propose to handle the following passive attacks without (D)TLS or
STUN authentication ?

a) https://tools.ietf.org/html/rfc5766#section-17.2.1, where attacker sends
faked permissions to the TURN server to launch attack (DOS or DDOS) on the
victim (TURN client). 

> Since the TURN server sits outside the firewall, at attacker outside the
firewall can now send a

--- A TURN server provided by local or access network, shall only be
accessible by users inside the firewall.

b) https://tools.ietf.org/html/rfc5766#section-17.3.3, attacker sends
spoofed TURN requests to the TURN server to close allocations.

--- I don’t think (D)TLS helps if you can spoof and have such attackers
inside your network. (that paragraph says:  TURN prevents this by requiring
that the credentials used”) meaning authentication (not certificate
checking, nor encryption).

-Tiru

From: tram [mailto:[email-masked]] On Behalf Of Karl Stahl
Sent: Monday, November 28, 2016 1:39 AM
To: Tirumaleswar Reddy (tireddy) <[email-masked]>; 'Brandon Williams'
<[email-masked]>; Prashanth Patil (praspati)
<[email-masked]>; [email-masked]
Cc: [email-masked]; 'Dan Wing' <[email-masked]>; 'Spencer Dawkins at
IETF' <[email-masked]>
Subject: Re: [tram] draft-ietf-tram-turn-server-discovery

Hi Tiru,

So we agree that the (D)TLS mandate thrown-in during the discuss (making
yellow TURN servers gray) shall go away and we are back to what was
consensus since version -7 of the draft. I think the attacks you are
discussing now have been listed already and for TURN servers in a local or
access network (no change since version -7), we should not expect a higher
security or trust level when sending our real-time traffic through another
path than the through default gateway, both paths are provided by the same
network provider.

If “protects the client from various attacks discussed in previous mails”
related to discovery of TURN servers, really is possible by introducing
something (why reopen that now?), we have to be careful not to make yellow
TURN servers grayish, which I am afraid self signed certificates might do,
and further, does this belong in a discovery draft, risking to pick a fight
with the WebRTC browser makers supposed to use this specification. We know
they don’t fancy self signed certificates…

Isn’t it specifications for some specific usage/application (like the return
draft for WebRTC browsers) that should consider such things (not this
draft), without any recommendation from this specification? 

/Karl

Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] 
Skickat: den 23 november 2016 04:15
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati);
[email-masked]
Kopia: [email-masked]; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery

I am not suggesting that authentication is mandatory for TURN servers
provided by local or access networks using (D)TLS but use of (D)TLS [Karl:
“these become gray not yellow” or are you suggesting certificated signed by
the network provider]

[TR] No, they are yellow and not grey; clients will use (D)TLS but do not
validate the TURN server certificate (referred to as Opportunistic security
in the draft). 

[Karl: Seems like you are suggesting self signed certificates to just get
the encryption (again – also discussed)]

[TR] Yes, that’s one possible option to mandate (D)TLS. Client cannot
validate the TURN server certificate but use encryption-only (D)TLS and
protects the client from various attacks discussed in previous mails.

-Tiru

From: Karl Stahl [mailto:[email-masked]] 
Sent: Tuesday, November 22, 2016 11:12 PM
To: Tirumaleswar Reddy (tireddy) <[email-masked]>; 'Brandon Williams'
<[email-masked]>; Prashanth Patil (praspati)
<[email-masked]>; [email-masked]
Cc: [email-masked]; 'Dan Wing' <[email-masked]>; 'Spencer Dawkins at
IETF' <[email-masked]>
Subject: SV: [tram] draft-ietf-tram-turn-server-discovery

Hi Tiru,

Please understand that in this context:

- Authentication is to only allow certain users to use the TURN server
resource

- Certificate checking as when using (D)TLS is to assure the user is using a
trusted TURN server (and further is sets up an encrypted channel).

These things are not interchangeable or do the same things or achieves the
same, which has been discussed over and over again in this draft already.

Let it rest with that we cannot/should not expect a higher trust or security
level when sending our real-time traffic through the TURN server path, than
trough the default gateway path. You simply have to trust the access from
the network provider you select to connect to, or refrain from using it.

Please also understand that “the gray TURN servers” are provided by others
than the local or access network, and you chose to trust them with your
real-time traffic based on checking their certificate (Who configures which
to allow into the WebRTC browser?).

In a specification which main purpose is to auto discover TURN servers
provided by the local or access network (“the yellow ones”), you CANNOT
LOGICALLY end up with saying you MUST/SHOULD or are RECOMMENDED to use “the
gray ones” instead, provided by some authority or Brandon maybe (which are
meant for other purposes). Then you have not delivered the specification we
need = The showstopper.

/Karl

PS: Some comments below.

Från: Tirumaleswar Reddy (tireddy) [ <mailto:[email-masked]>
mailto:[email-masked]] 
Skickat: den 22 november 2016 04:31
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati);
<mailto:[email-masked]> [email-masked]
Kopia:  <mailto:[email-masked]> [email-masked]; 'Dan Wing';
'Spencer Dawkins at IETF'
Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery

Hi Karl,

I am not suggesting that authentication is mandatory for TURN servers
provided by local or access networks using (D)TLS but use of (D)TLS [Karl:
“these become gray not yellow” or are you suggesting certificated signed by
the network provider] without authenticating the TURN server is mandatory to
avoid various attacks listed in previous mails. 

In short, the TURN servers provided by local or access networks must use
(D)TLS but it’s not mandatory for these TURN servers to get certificates
from CA or any explicit configuration is required on the client to trust the
TURN server. [Karl: Seems like you are suggesting self signed certificates
to just get the encryption (again – also discussed)]

-Tiru

From: Karl Stahl [mailto:[email-masked]] 
Sent: Monday, November 21, 2016 2:10 AM
To: Tirumaleswar Reddy (tireddy) <[email-masked]>; 'Brandon Williams'
<[email-masked]>; Prashanth Patil (praspati)
<[email-masked]>; [email-masked]
Cc: [email-masked]; 'Dan Wing' <[email-masked]>; 'Spencer Dawkins at
IETF' <[email-masked]>
Subject: SV: [tram] draft-ietf-tram-turn-server-discovery

Hi Tiru,

Trying to clarify as you request: I have lost track of in which context you
are when you are "discussing various attacks" and what you mean with the ??
I marked below. 

My concern was whether this may again lead to that WE HAVE NO TURN SERVERS
in the yellow area below resulting from the (D)TLS mandating that was
thrown-in into version -10 during the discuss (=the showstopping), since
TURN servers with certificates are NOT provided by the local or access
network (those are provided by some "trust anchor store [RFC6024] allows a
TURN client ..." or by "Certification authorities that issue TURN server
certificates" etc..)

So, just let me rest with that your discussion does not take away the
allowance to use TURN servers provided by the local or access network
without authentication that was re-introduced in version -7 of the draft
(after long discussions, including with you Tiru). Remember, those yellow
TURN servers were the requirement of this draft to auto discover so they can
be used by the WebRTC browsers – Usage cannot be forbidden (or
un-recommended as Brandon suggests, although Brandon is agreeing to that the
(D)TLS mandate must vanish for the yellow TURN servers). 

FURTHER JUST TO REMIND AUTHORS of what is needed to be addresses in this
draft; it is found in

 <https://www.ietf.org/mail-archive/web/tram/current/msg02216.html>
https://www.ietf.org/mail-archive/web/tram/current/msg02216.html 

and the contradiction in section 7.2 as said in 

 <https://www.ietf.org/mail-archive/web/tram/current/msg02226.html>
https://www.ietf.org/mail-archive/web/tram/current/msg02226.html 

while this discussion with Author Tiru and >“I don't run a local network or
an access network and would not expect to deploy relays meant to function in
that mode“ Brandon*, has been on more or less deviated subjects, or
repeating what we already have been through earlier (PS: Notice that Author
Prashanth already listed/discussed the attack stuff during the discuss. I
feared you were redoing that.)

/Karl

*  <https://www.ietf.org/mail-archive/web/tram/current/msg02217.html>
https://www.ietf.org/mail-archive/web/tram/current/msg02217.html 

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [ <mailto:[email-masked]>
mailto:[email-masked]] 
Skickat: den 18 november 2016 04:00
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati);
<mailto:[email-masked]> [email-masked]
Kopia:  <mailto:[email-masked]> [email-masked]; 'Dan Wing';
'Spencer Dawkins at IETF'
Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery

Hi Karl,

I don't understand your concerns, please clarify. The draft mandates (D)TLS
but does not mandate TURN server validation. 

We are discussing various attacks possbile for the WG to decide if (D)TLS is
a MUST or SHOULD.

-Tiru

> -----Original Message-----

> From: Karl Stahl [ <mailto:[email-masked]>
mailto:[email-masked]]

> Sent: Friday, November 18, 2016 2:11 AM

> To: Tirumaleswar Reddy (tireddy) < <mailto:[email-masked]>
[email-masked]>; 'Brandon Williams'

> < <mailto:[email-masked]> [email-masked]>;
Prashanth Patil (praspati)

> < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]>
[email-masked]

> Cc:  <mailto:[email-masked]> [email-masked]; 'Dan Wing' <
<mailto:[email-masked]> [email-masked]>; 'Spencer Dawkins

> at IETF' < <mailto:[email-masked]>
[email-masked]>

> Subject: SV: [tram] draft-ietf-tram-turn-server-discovery

> Continuing the thread of this subject with the view that it should be
about the

> MUST/SHOULD/RECOMMEND discussion regarding D(TLS) for the USAGE of

> an already discovered TURN server, which must be totally independent of
the

> method used for discovery.

> I can't say I understand where Brandon's/Tiru's discussion fits in and
whether

> are right things are said and are in the right context:

> ?? > > The draft mandates (D)TLS but does not mandate TURN server

> validation.

> ?? (D)TLS helps avoid various attacks, like attacker sending spoofed TURN

> messages ??  We should discuss all such possible attacks, before we decide
to

> go with MUST or SHOULD.

> Where are we know?

> Please, just keep the clearance from authentication as it was from version

> -07 of the draft already, until the D(TLS) mandate was thrown in during
the

> DISCUSS.

> Simply, logically:

> > >> TURN servers *provided by* (and maintained by?) some "trust anchor

> > >> store [RFC6024] allows a TURN client ..." or by "Certification

> > >> authorities that issue TURN server certificates"

> are NOT under the clearance discussed, which is for "TURN servers
*provided

> by* the local network or by the access network".

> so a SHOULD or RECOMMENDED of D(TLS) does not even belong under the

> clearance discussed.

> FURTHER, When I read:

> 7.2.  Recursively Encapsulated TURN

>    WebRTC endpoints SHOULD treat any TURN server discovered through the

>    mechanisms described in this specification as an enterprise/gateway

>    or access network server, in accordance with Recursively Encapsulated

>    TURN [I-D.ietf-rtcweb-return].

> Isn't that "any" in total contradiction to the clearance being discussed?

> I thought: "enterprise/gateway or access network" was the same as your

> "local or access network" and that for OTHER discovered TURN servers

> (outside the local or access network), it must be the application that
instructs

> the TURN client how to use.

> I suggest the 7.2 section is replaced with my:

> > >>> (4) "Deployment Considerations for TURN Servers Provided by the

> > >>> Local or

> > >> Access Network"

> which mentions Recursively Encapsulated TURN [I-D.ietf-rtcweb-return].

> (you can spell it out like that)

> Från: Tirumaleswar Reddy (tireddy) [ <mailto:[email-masked]>
mailto:[email-masked]]

> Skickat: den 15 november 2016 05:01

> Till: Brandon Williams; Karl Stahl; Prashanth Patil (praspati);
<mailto:[email-masked]> [email-masked]

> Kopia:  <mailto:[email-masked]> [email-masked]; 'Dan Wing';
'Spencer Dawkins at IETF'

> Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery

> Hi Brandon,

> I just listed one possible attack, there could be various other attacks
like the

> one discussed in  <https://tools.ietf.org/html/rfc5766#section-17.2.1>
https://tools.ietf.org/html/rfc5766#section-17.2.1,

> where attacker sends faked permissions to the TURN server to launch attack

> (DOS or DDOS) on the victim (TURN client).

> We should discuss all such possible attacks, before we decide to go with

> MUST or SHOULD.

> -Tiru

> > -----Original Message-----

> > From: tram [ <mailto:[email-masked]>
mailto:[email-masked]] On Behalf Of Brandon

> > Williams

> > Sent: Monday, November 14, 2016 7:31 PM

> > To: Tirumaleswar Reddy (tireddy) < <mailto:[email-masked]>
[email-masked]>; Karl Stahl

> > < <mailto:[email-masked]> [email-masked]>; Prashanth Patil
(praspati)

> > < <mailto:[email-masked]> [email-masked]>;
<mailto:[email-masked]> [email-masked]

> > Cc:  <mailto:[email-masked]> [email-masked]; 'Dan Wing' <
<mailto:[email-masked]> [email-masked]>; 'Spencer

> > Dawkins at IETF' < <mailto:[email-masked]>
[email-masked]>

> > Subject: Re: [tram] draft-ietf-tram-turn-server-discovery

> > +1 on the rationale. It makes almost no difference how you secure the

> > local or access network at the border, it's still possible that there

> > are

> on-path

> > adversaries, and using some type of authentication (either (D)TLS or

> > STUN) helps to protect against them.

> > I still agree with Karl on downgrading the MUST back to SHOULD or

> > RECOMMENDED, since I think there's room for disagreement about how

> > critical it is to mitigate against that attack. Ease-of-use might win

> > out

> for some

> > networks provided they have other protection mechanisms at either the

> > network or datalink layer. I don't think it should drop below the

> > recommendation level though, because most network will not have such

> > mechanisms in place.

> > --Brandon

> > On 11/14/2016 06:36 AM, Tirumaleswar Reddy (tireddy) wrote:

> > > There seems to be confusion why (D)TLS is mandated in the draft.

> > > The draft mandates (D)TLS but does not mandate TURN server validation.

> In

> > scenarios where the TURN client cannot validate the TURN server,

> > (D)TLS helps avoid various attacks, like attacker sending spoofed TURN

> > messages

> to

> > TURN client and server. For example, when (D)TLS is not used, attacker

> > can send spoofed TURN requests to the TURN server to close allocations.

> > > The above attack is possible when TURN servers are provided by

> > > either

> local

> > or access networks.

> > > -Tiru

> > >> -----Original Message-----

> > >> From: tram [ <mailto:[email-masked]>
mailto:[email-masked]] On Behalf Of Karl Stahl

> > >> Sent: Monday, November 14, 2016 1:38 PM

> > >> To: 'Brandon Williams' < <mailto:[email-masked]>
[email-masked]>; Prashanth

> > >> Patil

> > >> (praspati) < <mailto:[email-masked]> [email-masked]>;
<mailto:[email-masked]> [email-masked]

> > >> Cc:  <mailto:[email-masked]> [email-masked]; 'Dan Wing' <
<mailto:[email-masked]> [email-masked]>; 'Spencer

> > >> Dawkins at IETF' < <mailto:[email-masked]>
[email-masked]>; Tirumaleswar

> > >> Reddy

> > >> (tireddy) < <mailto:[email-masked]> [email-masked]>

> > >> Subject: Re: [tram] draft-ietf-tram-turn-server-discovery

> > >> Hi Brandon,

> > >> In this draft, you have been pushing for "validation" of the

> > >> discovered TURN server by using DTLS. The use case for that has not

> > >> been spelled out, but the use case of "TURN servers *provided by*

> > >> the local network or by the access network", really needs to be

> > >> clarified in this draft. For this use case, clearance from

> > >> authentication and validation was made in version -07 of the draft

> already.

> > >> Regarding your comment below, it is not clear which use case YOU

> > >> NOW are considering.

> > >> Further, DISCOVERY and USAGE are not the same in this discussion.

> > >> You mix that, especially regarding the anycast method. No one is

> > >> suggesting that the TURN server is USED when addressed by anycast.

> > >> There is only ONE packet addressed by anycast and sent to the

> > >> STUN/TURN server and that is for DISCOVERING it.

> > >> See further inline below.

> > >> Thanks,

> > >> Karl

> > >> Från: Brandon Williams [ <mailto:[email-masked]>
mailto:[email-masked]]

> > >> Skickat: den 11 november 2016 19:08

> > >> Till: Karl Stahl; 'Prashanth Patil (praspati)';
<mailto:[email-masked]> [email-masked]

> > >> Kopia:  <mailto:[email-masked]> [email-masked]; 'Dan
Wing'; 'Spencer Dawkins at IETF';

> > >> 'Tirumaleswar Reddy (tireddy)'

> > >> Ämne: Re: [tram] draft-ietf-tram-turn-server-discovery

> > >> (1) I agree with Karl that the MUST for (D)TLS or STUN auth should

> > >> revert to a SHOULD or a RECOMMENDED, given that network perimeter

> > >> control is called out with MUST (note that there are a few "must"

> > >> to "MUST" edits required in that text). Although I would disagree

> > >> with an enterprise network admin who chooses not to do one of those

> > >> two things (see my comments about (3)/(4) below), I think there's

> > >> room for difference of opinion there, so MUST is unlikely to be

> > >> complied

> with

> > anyway.

> > >> [Karl] Good that you agree the MUST (thrown-in during discuss) must

> > >> go away, but for the use case of "TURN servers *provided by* the

> > >> local network or by the access network." there should not even be

> SHOULD

> > or RECOMMEND.

> > >> Your are relating to TURN servers *provided by* (and maintained

> > >> by?) some "trust anchor store [RFC6024] allows a TURN client ..."

> > >> or by "Certification authorities that issue TURN server

> > >> certificates" that *provide TURN servers with their certificates

> > >> in* that you expect to be discovered and where the TURN client (the

> > >> WebRTC browser) must be equipped to accept those certificates. That

> > >> is NOT FOR "the TURN servers *provided by* the local network or by

> > >> the access network" that

> is

> > being discussed here.

> > >> (2) I disagree with Karl about anycast. A server that properly

> > >> supports anycast [Karl] What is "a server that properly supports

> > >> anycast"? It is certainly NOT A [RFC5766] TURN server that is

> > >> supposed

> to

> > be discovered by this draft.

> > >> Also notice that we are talking about one anycast packet FOR

> > >> DISCOVERY, NOT USAGE (relaying traffic) with anycast adressing.

> > >> (I asked that the confusing "supports anycast" statement is removed

> > >> from the beginning of the draft.)

> > >> will indeed treat incoming requests differently depending upon

> > >> whether they arrive on the anycast address or the unicast address.

> > >> I strongly disagree with the idea of using Try Alternate on the

> > >> binding request, because you want redirect for the long-lived

> > >> allocate request, not for the query-response binding request.

> > >> [Karl] With a TURN server provided by the local or access network,

> > >> STUN is NOT USED for setting up any binding and no subsequent

> > >> traffic. The STUN binding response 300 Try Alternate (statically

> > >> configured) in my proposed text, is only an indication used at

> > >> DISCOVERY, that a network provided TURN server is there and should

> > >> be used at its unicast address revealed in the

> > >> 300 response. The long-lived TURN allocate IS USED for the traffic.

> > >> The STUN server portion of the TURN server paralleling the default

> > >> gateway router is never used for any binding.

> > >> Part of my reason for this is that good (by my definition) TURN

> > >> server distribution is broader than is reasonable for anycast

> > >> address management, and determining a redirect address to be

> > >> delivered increases the cost of handling the STUN bind request. It

> > >> is desirable for that cost to scale with the TURN allocate load,

> > >> not the STUN bind

> load.

> > >> [Karl] You just add a static route in you access router for the

> > >> anycast address to point to your TURN server!

> > >> I don't oppose supporting both in the spec if someone wants to

> > >> propose language for that, but it would add burden to client

> > >> implementations because they would be required to support both even

> > >> though the server could use either. On the other hand, the

> > >> currently defined method shouldn't require changes to clients at all.

> > >> [Karl] ?! But it does not find [RFC5766] TURN servers...

> > >> (3)/(4) I disagree with Karl's assessment of the deployment

> > >> considerations, especially the conclusion that anycast is the

> > >> better path for local/access networks.

> > >> [Karl] If you mean traffic paths (like I did), "paths" are for

> > >> USAGE and no one is suggesting anycast for that.

> > >> Independent of how discovered (by anycast or any of the DNS

> > >> methods) ALL USAGE through paths is by unicast addressing.

> > >> It might be better for the server

> > >> implementer, but not for the the client, because I think it's

> > >> particularly difficult for a client to determine whether it's

> > >> network

> is

> > "sealed".

> > >> [Karl] No, not at all. Blocking STUN packets at the default gateway

> > >> is the way to "network wise" seal the local network (and only allow

> > >> the parallel TURN path)! That is easily detected by a TURN client.

> > >> The client has to trust that the network is properly sealed, since

> > >> it's difficult (at

> > >> least) for the client to verify. Also, I think that the DNS and

> > >> DHCP methods are likely to be easier for enterprise and access

> > >> networks to implement, since they will have the necessary systems

> > >> in place already. Even a home network gateway appliance will

> > >> already have both integrate DNS and integrate DHCP, so I suspect

> > >> that a small local network will have an easier time with these than
you

> suggest as well.

> > >> [Karl] So you agree that for a TURN server in a local network, its

> > >> address shall only be deployed in local DNS - I think the draft

> > >> should

> say

> > that also.

> > >> Despite the fact that I disagree with the assessment, I don't run a

> > >> local network or an access network and would not expect to deploy

> > >> relays meant to function in that mode, so I will not have strong

> > >> objections to including that language if there is broad support

> > >> within

> > WG for Karl's framing.

> > >> --Brandon

> > >> On 11/10/2016 05:48 PM, Karl Stahl wrote:

> > >>> (1) The downgrade of the MUST level requirement for authentication

> > >>> defined

> > >> in [RFC5766] was "rightly" (to use the term from below) introduced

> > >> and made OPTIONAL for TURN servers provided by the local or access

> > network.

> > >>> HOWEVER, Prashanth's: "I think we can mandate (D)TLS *if* STUN

> > >> authentication or third-party authorization is not used." thrown-in

> > >> during the DISCUSS, must be deleted from the -10 version of this

> > >> discovery since it BLOCKs the usage and deployment of network

> > >> provided TURN servers, which was the main purpose of this discovery

> > >> draft. (Also, Authors's did not follow Ben Campbell's: "I saw a

> > >> comment on my DISCUSS email thread from Karl Stahl, stating that

> > >> DTLS could not be mandated. Has that input been

> > >> considered?")

> > >>> The thrown-in addition in version -10 (not shown in full below)

> > >>> highlights

> > >> this:

> > >>>    A TURN client MUST use (D)TLS ... in the absence of STUN
long-term

> > >>>    credential mechanism [RFC5389] or STUN Extension for Third-Party

> > >>>    Authorization [RFC7635].  ...

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

> anchor

> > >>>       store [RFC6024] allows a TURN client ...

> > >>>    o  Certification authorities that issue TURN server certificates

> > >>>       ...

> > >>>    o  For TURN servers that don't have a certificate trust chain

> (e.g.,

> > >>>       because they are on a home network or a corporate network), a

> > >>>       configured list of TURN servers can contain the Subject

> > >>> Public

> Key

> > >>>       Info (SPKI) fingerprint of the TURN servers... etc.

> > >>> What does the Authors have in mind - a regulated network of TURN

> > >>> servers,

> > >> when the purpose was for everyone to be able to use good WebRTC

> > >> everywhere you can surf, including behind your home Best Buy bought

> > >> WiFi router (which we can hope, some day, will include a default

> > >> configured, ready to use, TURN server path paralleling its default

> > >> gateway path (i.e. the NAT/firewall/access router/default gateway)?

> > >>> This specification shall (at least) specify discovery of network

> > >>> provided

> > >> TURN servers to allow real-time communication, in situations where

> > >> it otherwise is not possible or bad:

> > >>> - to meet the auto configuration of RFC 7478 (Web Real-Time

> > >>> Communication

> > >> Use Cases and Requirements) 2.3.5.1.

> > >>> - providing a discovery method suitable for

> > >>> draft-ietf-rtcweb-return-01

> > >>> The above has already been discussed many times in this WG:

> > >>>  <https://www.ietf.org/mail-archive/web/tram/current/msg01319.html>
https://www.ietf.org/mail-archive/web/tram/current/msg01319.html

> > >>>  <https://www.ietf.org/mail-archive/web/tram/current/msg01742.html>
https://www.ietf.org/mail-archive/web/tram/current/msg01742.html

> > >>>  <https://www.ietf.org/mail-archive/web/tram/current/msg02191.html>
https://www.ietf.org/mail-archive/web/tram/current/msg02191.html

> > >>> Just as credentials for authentication cannot be expected to be

> > >>> available

> > >> for this general usage, nor can we impose that certificates should

> used.

> > >> For the network provided TURN server, we should not/must not expect

> > >> some higher level of trust or security when the real-time media

> > >> flows through the TURN server than when it goes through the default

> gateway!

> > >>> The use of (D)TLS has been discussed intensively in the -04

> > >>> version of the

> > >> draft

> > >>>  <https://www.ietf.org/mail-archive/web/tram/current/msg01821.html>
https://www.ietf.org/mail-archive/web/tram/current/msg01821.html

> > >>> and was NOT mandated for the TURN server provided by the local or

> > >>> access

> > >> network. It cannot be thrown-in now again!

> > >>> Any arguments against have been of type: We need security in

> > >>> itself

> > >>> -

> > >> protect this and that - do every authentication/validation in the

> > >> book (whether needed or not) etc., which only leads to responses

> > >> like I had to bring up during the discuss:

> > >>> [Karl] Do you think we need to discover TURN servers for the

> > >>> pleasure of

> > >> doing "security that deal directly with TURN messages" in itself,

> > >> and not for what they are supposed to do (relay "application data")

> > >> and do you also think that is why a network provider will deploy

> > >> such TURN

> > server for his users?

> > >> Please do not stop the purpose (by such phrases)!

> > >>> (Also, encryption and protection against man-in-the-middle

> > >>> attacks, for

> > >> the payload (real-time traffic) are for the endpoints to do - like

> > >> with WebRTC, mandating DTLS-SRTP media - it should not be expected

> > >> to be done by a TURN server, especially when not always used.)

> > >>> (2) Also as pointed out during the DISCUSS

> > >>>  <https://www.ietf.org/mail-archive/web/tram/current/msg02144.html>
https://www.ietf.org/mail-archive/web/tram/current/msg02144.html

> > >>> and two times earlier (during WG discussions, but not addressed or

> > >> responded to by the Authors):

> > >>>  <https://www.ietf.org/mail-archive/web/tram/current/msg02081.htm>
https://www.ietf.org/mail-archive/web/tram/current/msg02081.htm l

> > >>> and  <https://www.ietf.org/mail-> https://www.ietf.org/mail-

> > archive/web/tram/current/msg01976.html

> > >>> The anycast method does not work with RFC5766 TURN servers! That

> > >>> has not

> > >> been addressed at all.

> > >>> A TURN server doesn't react one way (answering 300 Try Alternate)

> > >>> when

> > >> addressed by an anycast address and another way (accepting the

> > >> Allocate

> > >> request) when addressed by its unicast address, does it?

> > >>> Author's (during the DISCUSS): "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];"

> > >>> does not help and I responded: [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?

> > >> What are these things?

> > >>> I have proposed this modification of the anycast method, which is

> > >>> better

> > >> (in several aspects) and doesn't need to update RFC5766:

> > >>> "When a client requires TURN services, it sends a STUN binding

> > >>> request to

> > >> the assigned anycast address.  The STUN server

> > >>> responds with a 300 (Try Alternate) error as described in

> > >>> [RFC5389]; The

> > >> response contains a unicast address in the ALTERNATE-SERVER

> > >> attribute, which the client compares with the source address of the

> > >> response and if the

> > >>> addresses are the same, it is an indication to use the TURN server

> > >>> at that

> > >> address.

> > >>> For subsequent communication with the TURN server, the client uses

> > >>> that

> > >> responding server's unicast address."

> > >>> The sentence in the -10 draft under "3 Discovery Procedure": "not

> > >>> all TURN

> > >> servers may support anycast" can then be removed.

> > >>> (3) I cannot see this -10 draft telling which discovery method

> > >>> that is fit

> > >> for the TURN servers provided by the local or access network (the

> > >> network provided TURN server). However, there are confusing client

> > >> behavior recommendations, like the sentences in the draft under "3

> > >> Discovery

> > >> Procedure": "For best results, a client SHOULD implement all

> > >> discovery mechanisms described above." and under "1 Introduction":

> > >> "three discovery mechanisms, so as to maximize opportunity for

> > >> discovery, based on the network in which the TURN client finds
itself."

> > >>> A network provided TURN server is only meant for the users on the

> > >>> specific

> > >> network - others should not be able to use such TURN server, and it

> > >> would then be preferred that it is only advertized and discovered

> > >> at that local network - which is badly described by "maximize

> > >> opportunity

> > discovery".

> > >>> If a DNS method would be used to discover the network provided

> > >>> TURN

> > >> server, its private address should only be configured in private

> > >> (local) DNS (we don't like to put our private IP addresses in

> > >> public DNS), but I see no such recommendation. Further, the DNS

> > >> methods are complex and expensive to deploy and one of them depends

> > >> on DHCP that is not available on all access networks. That makes (a

> > >> working) anycast discovery method the clear choice for a TURN

> > >> server provided by

> > the local or access network.

> > >>> Network provided TURN servers paralleling a NAT/firewall/access

> > >> router/default gateway is a new concept that came up during WebRTC

> > >> standardization work to deal with traversal and quality problems of

> > >> real-time traffic. However, this draft give little or no guidance

> > >> for deployment and I therefore suggest that a separate section is

> > >> added, that spells out the deployment considerations for TURN

> > >> servers provided by the local or access network (which now is

> > >> missing, but I propose the following

> > >> text):

> > >>> (4) "Deployment Considerations for TURN Servers Provided by the

> > >>> Local or

> > >> Access Network"

> > >>> (Suggested text for an additional section)

> > >>> The concept of paralleling a NAT/firewall/access-router/default

> > >>> gateway at

> > >> the local or access network with a TURN server, to deal with

> > >> traversal and quality problems of real-time traffic, is new and

> > >> came up during the WebRTC standardization work.

> > >>> Such network provided TURN servers, only accessible by the users

> > >>> on the

> > >> local or access network, must be automatically discovered and used,

> > >> without specific configuration or having credentials for

> > >> authentication or certificates for validation, to be useful for e.g.

> > >> a WebRTC browsers to allow quality media traffic "everywhere you

> > >> can

> > surf".

> > >>> Just as for the Internet access itself, the TURN server is offered

> > >>> by the

> > >> network provider and there is no change in the trust or security

> > >> level (which should not be expected) when real-time traffic flows

> > >> through the TURN server path, than through the default gateway path.

> > >> (The purpose of the network provided turn server is to allow

> > >> traversal of real-time media traffic in environments with

> > >> restrictive NAT/firewalls closed for UDP traffic and/or to allow

> > >> better quality through the often data congested router at the

> > >> default

> > >> gateway.)

> > >>> The discovery of the network provided TURN server should meet the

> > >>> auto

> > >> configuration of RFC 7478 (Web Real-Time Communication Use Cases

> > >> Requirements) 2.3.5.1. and draft-ietf-rtcweb-return-01 is defining

> > >> the TURN client behavior for WebRTC browsers.

> > >>> For quality reasons, a sealed network configuration - i.e. the

> > >>> media has

> > >> to go through the TURN server, not through the default gateway (by

> > >> using STUN instead of TURN) - is the typical intention when a TURN

> > >> server is deployed in the local or access network. The sealed

> > >> configuration can be enforced and signaled to the TURN client by

> > >> the network provider blocking STUN packets at the default gateway.

> > >>> A network configuration enforcing sealed behavior, has the good

> > >>> effect of

> > >> allowing the TURN client (e.g. a WebRTC browser) in itself to have

> > >> a

> > >> non- sealed default configuration. (ietf-rtcweb-return-01 explains

> > >> that a sealed default configuration in the browser itself, would

> > >> result in that media between local clients would have to pass the

> > >> TURN server, which is not

> > >> desirable.)

> > >>> The above assumes that the TURN client using a TURN server in the

> > >>> local or

> > >> access network shall use unencrypted STUN/TURN (over UDP for best

> > >> quality) so the STUN cookie can be detected and stopped in the

> > >> default

> > gateway.

> > >>> A TURN server included in the router at the default gateway, that

> > >> intercepts and responds to an allocate request, should   be treated
as

> a

> > >> discovered network provided sealed TURN server configuration by a

> > >> TURN client (without having to review any 300 Try Alternate

> > >> response as outlined in anycast method description) allowing for

> > >> tolerant and

> secure

> > deployment.

> > >>> A web application that wants to try the default gateway path

> > >>> instead of

> > >> the TURN server path (in spite of a sealed network configuration)

> > >> can suggest encrypted (D)TLS STUN and TURN candidates that will not

> > >> be blocked by STUN cookie recognition at the default gateway. It is

> > >> then up to application's TURN client whether to try the default

> > >> gateway

> path.

> > >>> A further advantage of detecting a sealed network configuration,

> > >>> is that a

> > >> TURN client can select to *only in a sealed network configuration*

> > >> look for a TURN server by the anycast method for discovery, thus

> > >> eliminating the leakage risk mentioned under 9.3. Further, there

> > >> will be no risk that a far away TURN server will be discovered and

> > >> used and there will be no need for the TTL limitation suggested under
9.3.

> > >>> The anycast discovery method, combined with the above

> > >>> recommendations,

> > >> allow for an easy and robust deployment of network provided TURN

> > >> servers, fitting all types of local and access networks.

> > >>> The DNS based methods of this specification are more complex and

> > >>> expensive

> > >> to deploy and one of them depends on DHCP that is not available on

> > >> all access networks. If any of the DNS based methods is used to

> > >> advertize and discover a TURN in the local or access network, its

> > >> private addresses should only be configured in private (local) DNS

> > >> and not be published publicly, which adds further to the complexity

> > cost of deployment.

> > >>> (5) Most (all?) of what is considered and summed up under (4) (the

> > >> suggested additional text), has been brought forward on the TRAM WG

> > >> list before, but not brought into the current -10 draft, see:

> > >>>  <https://www.ietf.org/mail-archive/web/tram/current/msg00132.html>

> > >>>  <https://www.ietf.org/mail-archive/web/tram/current/msg00138.html>

> > >>>  <https://www.ietf.org/mail-archive/web/tram/current/msg01721.html>
https://www.ietf.org/mail-archive/web/tram/current/msg01721.html

> > >>>  <https://www.ietf.org/mail-archive/web/tram/current/msg01745.html>
https://www.ietf.org/mail-archive/web/tram/current/msg01745.html

> > >>> The links given under (1) and (2) above

> > >>>  <https://www.ietf.org/mail-archive/web/tram/current/msg02155.html>
https://www.ietf.org/mail-archive/web/tram/current/msg02155.html

> > >>> Från: tram [ <mailto:[email-masked]>
mailto:[email-masked]] För Prashanth Patil

> > >>> (praspati)

> > >>> Skickat: den 2 november 2016 22:18

> > >>> Till:  <mailto:[email-masked]> [email-masked]

> > >>> Kopia:  <mailto:[email-masked]> [email-masked]; Dan
Wing; Spencer Dawkins at IETF;

> > >> Tirumaleswar Reddy (tireddy)

> > >>> Ämne: [tram] draft-ietf-tram-turn-server-discovery

> > >>> The TURN discovery draft originally suggested that STUN

> > >>> authentication be

> > >> relaxed and made OPTIONAL for TURN servers provided by the local or

> > >> access network. The intention was to allow new/guest users (who do

> > >> not necessarily possess long term credentials for STUN

> > >> authentication) in the network to discover and use TURN services

> offered

> > by the network.

> > >>> Ben Campbell raised an objection during IESG evaluation that we

> > >>> clearly

> > >> indicate that this is a downgrade of a MUST level requirement

> > >> defined in [RFC5766] and explain its consequences. It was also

> > >> rightly suggested that we mandate the use of (D)TLS in the absence

> > >> of STUN authentication for protection against a variety of attacks;

> > >> the draft now makes it a MUST that TURN servers use (D)TLS in the

> > >> absence of STUN

> > authentication.

> > >>> To put it simply, the draft mandates that TURN servers in a local

> > >>> or

> > >> access network do at least one of (D)TLS or STUN authentication. If

> > >> you have an opinion about this change, please let the working group

> > >> know on the mailing list before the end of IETF 97.

> > >>> See below for snippets of what changed.

> > >>> Excerpt from Security Considerations of

> > >> draft-ietf-tram-turn-server-discovery-09:

> > >>>    "Use of Session Traversal Utilities for NAT (STUN) [RFC5389]

> > >>>    authentication is OPTIONAL for TURN servers provided by the local

> > >>>    network or by the access network.  A network provided TURN

> > >>> server

> > MAY

> > >>>    be configured to accept Allocation requests without STUN

> > >>>    authentication, and a TURN client MAY be configured to accept

> > >>>    Allocation success responses without STUN authentication from a

> > >>>    network provided TURN server.  In order to protect against
man-in-

> > >>>    the-middle attacks when accepting a TURN allocation response

> without

> > >>>    STUN authentication, it is RECOMMENDED that the TURN client use

> one

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

> server"

> > >>> Updated text in Security Considerations of

> > >> draft-ietf-tram-turn-server-discovery-10:

> > >>>    "Use of Session Traversal Utilities for NAT (STUN) [RFC5389]

> > >>>    authentication is OPTIONAL for TURN servers provided by the local

> > >>>    network or by the access network.  A network provided TURN

> > >>> server

> > MAY

> > >>>    be configured to accept Allocation requests without STUN

> > >>>    authentication, and a TURN client MAY be configured to accept

> > >>>    Allocation success responses without STUN authentication from a

> > >>>    network provided TURN server.

> > >>>    Making STUN authentication OPTIONAL is a downgrade of a MUST

> level

> > >>>    requirement defined in [RFC5766].  The downgrade allows TURN

> servers

> > >>>    provided by local or access network to accept Allocation requests

> > >>>    from new and/or guest users in the network who do not necessarily

> > >>>    possess long term credentials for STUN authentication.  The

> > >>>    intention, in such deployments, being to provide TURN services

> > >>> to

> all

> > >>>    users in the local or access network.  However, this opens up a

> TURN

> > >>>    server to a variety of attacks described in Section 17 of

> [RFC5766].

> > >>>    A TURN server in such cases must be configured to only process
STUN

> > >>>    requests from the trusted local network or subscribers of the

> access

> > >>>    network.  Operational measures must be taken in order protect the

> > >>>    TURN server; some of these measures include, but not limited to,

> > >>>    access control by means of access-lists, firewalls, subscriber

> quota

> > >>>    limits, ingress filtering etc.

> > >>>    A TURN client MUST use (D)TLS in the absence of STUN long-term

> > >>>    credential mechanism [RFC5389] or STUN Extension for Third-Party

> > >>>    Authorization [RFC7635]."

> > >>> Please refer

<https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-1>
https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-1

> > >> 0#

> > >> section

> > >> -9 for more details.

> > >>> Thanks,

> > >>> Authors

> > >>> _______________________________________________

> > >>> tram mailing list

> > >>>  <mailto:[email-masked]> [email-masked]

> > >>>  <https://www.ietf.org/mailman/listinfo/tram>
https://www.ietf.org/mailman/listinfo/tram

> > >>> _______________________________________________

> > >>> tram mailing list

> > >>>  <mailto:[email-masked]> [email-masked]

> > >>>  <https://www.ietf.org/mailman/listinfo/tram>
https://www.ietf.org/mailman/listinfo/tram

> > >> _______________________________________________

> > >> tram mailing list

> > >>  <mailto:[email-masked]> [email-masked]

> > >>  <https://www.ietf.org/mailman/listinfo/tram>
https://www.ietf.org/mailman/listinfo/tram

> > _______________________________________________

> > tram mailing list

> >  <mailto:[email-masked]> [email-masked]

> >  <https://www.ietf.org/mailman/listinfo/tram>
https://www.ietf.org/mailman/listinfo/tram

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Fri, 2 Dec 2016 17:57:16 +0000

Hi Karl (and tramsters),

I am sympathetic to your arguments but they might have been lost somewhere in the email thread (A mix of quoting, repeating and inline commenting have at least made my email client somewhat confused.)

The best thing you can do at this moment is to provide text. I suggest you write up a draft as a counter proposal and submit it. In that way the WG members can read through and comment.

I encourage the WG chairs to give Karl enough time to write this up, before progressing the other draft.

.-.
Pål-Erik

On 2 Dec 2016, at 09:38, Karl Stahl <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tiru,

I am trying to make the point that there is no option for this draft, supposed to fulfill:
[tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs
to result in: “We forbid usage of such (yellow) network provided TURN servers (use gray or grayish TURN servers instead)”,  which is the consequence of mandating (D)TLS.

Simply leave the consensus since version -7 of this draft by removing the (D)TLS mandating for TURN servers provided by  the local or access network thrown-in during the discuss.

/Karl

PS: I believe the attack discussion below is already done, and that you are wrong in thinking that authentication which protects against spoof attacks can be exchanged for encryption, and that any of these things protects against DDOS attacks . These security things address different things and are not interchangeable, nor are they universal means against attacks of various kinds.

Please note (sorry to repeat)  that for the purpose of getting a better path for real-time traffic than through the default gateway path, we cannot expect to also get a higher security or trust level, nor to resolve every problem in the world.

Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Skickat: den 28 november 2016 10:53
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati); [email-masked]<mailto:[email-masked]>
Kopia: [email-masked]<mailto:[email-masked]>; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery

Hi Karl,

Yes, I am discussing TURN servers provided by local or access networks, referring to inside attacks launched by attackers inside the local or access network.
a)An inside attacker sends faked permissions to the TURN server to launch attack (DOS or DDOS) on the victim (TURN client).
b)An inside attacker sends spoofed TURN requests to the TURN server to close allocations.

Both above attacks can be prevented by using opportunistic encryption with (D)TLS.

-Tiru

From: tram [mailto:[email-masked]] On Behalf Of Karl Stahl
Sent: Monday, November 28, 2016 2:49 PM
To: Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>>; 'Brandon Williams' <[email-masked]<mailto:[email-masked]>>; Prashanth Patil (praspati) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; 'Dan Wing' <[email-masked]<mailto:[email-masked]>>; 'Spencer Dawkins at IETF' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [tram] draft-ietf-tram-turn-server-discovery

Hi Tiru,

Are you discussing TURN servers provided by the local or access network (the yellow TURN servers), that are released from authentication (no dispute there), but for which (D)TLS mandate was thrown in-during the discuss (making them gray)? That is the showstopper that must go away.

Some comments below. Hope we agree  the below does not relate to the yellow TURN server.

/Karl

Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Skickat: den 28 november 2016 04:02
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati); [email-masked]<mailto:[email-masked]>
Kopia: [email-masked]<mailto:[email-masked]>; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery

Hi Karl,

No, I don’t agree that (D)TLS is not mandatory. Opportunistic encryption is not new. It’s discussed in RFC7435, and used in TCP increased security (TCPINC WG) and DNS privacy exchange (DPRIVE WG).

How do you propose to handle the following passive attacks without (D)TLS or STUN authentication ?

a) https://tools.ietf.org/html/rfc5766#section-17.2.1, where attacker sends faked permissions to the TURN server to launch attack (DOS or DDOS) on the victim (TURN client).
> Since the TURN server sits outside the firewall, at attacker outside the firewall can now send a
--- A TURN server provided by local or access network, shall only be accessible by users inside the firewall.

b) https://tools.ietf.org/html/rfc5766#section-17.3.3, attacker sends spoofed TURN requests to the TURN server to close allocations.

--- I don’t think (D)TLS helps if you can spoof and have such attackers inside your network. (that paragraph says:  TURN prevents this by requiring that the credentials used”) meaning authentication (not certificate checking, nor encryption).

-Tiru

From: tram [mailto:[email-masked]] On Behalf Of Karl Stahl
Sent: Monday, November 28, 2016 1:39 AM
To: Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>>; 'Brandon Williams' <[email-masked]<mailto:[email-masked]>>; Prashanth Patil (praspati) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; 'Dan Wing' <[email-masked]<mailto:[email-masked]>>; 'Spencer Dawkins at IETF' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [tram] draft-ietf-tram-turn-server-discovery

Hi Tiru,

So we agree that the (D)TLS mandate thrown-in during the discuss (making yellow TURN servers gray) shall go away and we are back to what was consensus since version -7 of the draft. I think the attacks you are discussing now have been listed already and for TURN servers in a local or access network (no change since version -7), we should not expect a higher security or trust level when sending our real-time traffic through another path than the through default gateway, both paths are provided by the same network provider.

If “protects the client from various attacks discussed in previous mails” related to discovery of TURN servers, really is possible by introducing something (why reopen that now?), we have to be careful not to make yellow TURN servers grayish, which I am afraid self signed certificates might do, and further, does this belong in a discovery draft, risking to pick a fight with the WebRTC browser makers supposed to use this specification. We know they don’t fancy self signed certificates…

Isn’t it specifications for some specific usage/application (like the return draft for WebRTC browsers) that should consider such things (not this draft), without any recommendation from this specification?

/Karl

Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Skickat: den 23 november 2016 04:15
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati); [email-masked]<mailto:[email-masked]>
Kopia: [email-masked]<mailto:[email-masked]>; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery

I am not suggesting that authentication is mandatory for TURN servers provided by local or access networks using (D)TLS but use of (D)TLS [Karl: “these become gray not yellow” or are you suggesting certificated signed by the network provider]

[TR] No, they are yellow and not grey; clients will use (D)TLS but do not validate the TURN server certificate (referred to as Opportunistic security in the draft).

[Karl: Seems like you are suggesting self signed certificates to just get the encryption (again – also discussed)]

[TR] Yes, that’s one possible option to mandate (D)TLS. Client cannot validate the TURN server certificate but use encryption-only (D)TLS and protects the client from various attacks discussed in previous mails.

-Tiru

From: Karl Stahl [mailto:[email-masked]]
Sent: Tuesday, November 22, 2016 11:12 PM
To: Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>>; 'Brandon Williams' <[email-masked]<mailto:[email-masked]>>; Prashanth Patil (praspati) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; 'Dan Wing' <[email-masked]<mailto:[email-masked]>>; 'Spencer Dawkins at IETF' <[email-masked]<mailto:[email-masked]>>
Subject: SV: [tram] draft-ietf-tram-turn-server-discovery

Hi Tiru,

Please understand that in this context:
- Authentication is to only allow certain users to use the TURN server resource
- Certificate checking as when using (D)TLS is to assure the user is using a trusted TURN server (and further is sets up an encrypted channel).

These things are not interchangeable or do the same things or achieves the same, which has been discussed over and over again in this draft already.

Let it rest with that we cannot/should not expect a higher trust or security level when sending our real-time traffic through the TURN server path, than trough the default gateway path. You simply have to trust the access from the network provider you select to connect to, or refrain from using it.

Please also understand that “the gray TURN servers” are provided by others than the local or access network, and you chose to trust them with your real-time traffic based on checking their certificate (Who configures which to allow into the WebRTC browser?).

In a specification which main purpose is to auto discover TURN servers provided by the local or access network (“the yellow ones”), you CANNOT LOGICALLY end up with saying you MUST/SHOULD or are RECOMMENDED to use “the gray ones” instead, provided by some authority or Brandon maybe (which are meant for other purposes). Then you have not delivered the specification we need = The showstopper.

/Karl

PS: Some comments below.

Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Skickat: den 22 november 2016 04:31
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati); [email-masked]<mailto:[email-masked]>
Kopia: [email-masked]<mailto:[email-masked]>; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery

Hi Karl,

I am not suggesting that authentication is mandatory for TURN servers provided by local or access networks using (D)TLS but use of (D)TLS [Karl: “these become gray not yellow” or are you suggesting certificated signed by the network provider] without authenticating the TURN server is mandatory to avoid various attacks listed in previous mails.

In short, the TURN servers provided by local or access networks must use (D)TLS but it’s not mandatory for these TURN servers to get certificates from CA or any explicit configuration is required on the client to trust the TURN server. [Karl: Seems like you are suggesting self signed certificates to just get the encryption (again – also discussed)]

-Tiru

From: Karl Stahl [mailto:[email-masked]]
Sent: Monday, November 21, 2016 2:10 AM
To: Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>>; 'Brandon Williams' <[email-masked]<mailto:[email-masked]>>; Prashanth Patil (praspati) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; 'Dan Wing' <[email-masked]<mailto:[email-masked]>>; 'Spencer Dawkins at IETF' <[email-masked]<mailto:[email-masked]>>
Subject: SV: [tram] draft-ietf-tram-turn-server-discovery

Hi Tiru,

Trying to clarify as you request: I have lost track of in which context you are when you are "discussing various attacks" and what you mean with the ?? I marked below.

My concern was whether this may again lead to that WE HAVE NO TURN SERVERS in the yellow area below resulting from the (D)TLS mandating that was thrown-in into version -10 during the discuss (=the showstopping), since TURN servers with certificates are NOT provided by the local or access network (those are provided by some "trust anchor store [RFC6024] allows a TURN client ..." or by "Certification authorities that issue TURN server certificates" etc..)

So, just let me rest with that your discussion does not take away the allowance to use TURN servers provided by the local or access network without authentication that was re-introduced in version -7 of the draft (after long discussions, including with you Tiru). Remember, those yellow TURN servers were the requirement of this draft to auto discover so they can be used by the WebRTC browsers – Usage cannot be forbidden (or un-recommended as Brandon suggests, although Brandon is agreeing to that the (D)TLS mandate must vanish for the yellow TURN servers).

FURTHER JUST TO REMIND AUTHORS of what is needed to be addresses in this draft; it is found in
https://www.ietf.org/mail-archive/web/tram/current/msg02216.html
and the contradiction in section 7.2 as said in
https://www.ietf.org/mail-archive/web/tram/current/msg02226.html
while this discussion with Author Tiru and >“I don't run a local network or an access network and would not expect to deploy relays meant to function in that mode“ Brandon*, has been on more or less deviated subjects, or repeating what we already have been through earlier (PS: Notice that Author Prashanth already listed/discussed the attack stuff during the discuss. I feared you were redoing that.)

/Karl

* https://www.ietf.org/mail-archive/web/tram/current/msg02217.html

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Skickat: den 18 november 2016 04:00
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati); [email-masked]<mailto:[email-masked]>
Kopia: [email-masked]<mailto:[email-masked]>; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery

Hi Karl,

I don't understand your concerns, please clarify. The draft mandates (D)TLS but does not mandate TURN server validation.
We are discussing various attacks possbile for the WG to decide if (D)TLS is a MUST or SHOULD.

-Tiru

> To: Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>>; 'Brandon Williams'
> <[email-masked]<mailto:[email-masked]>>; Prashanth Patil (praspati)
> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>; 'Dan Wing' <[email-masked]<mailto:[email-masked]>>; 'Spencer Dawkins
> at IETF' <[email-masked]<mailto:[email-masked]>>
> Continuing the thread of this subject with the view that it should be about the
> an already discovered TURN server, which must be totally independent of the
> I can't say I understand where Brandon's/Tiru's discussion fits in and whether
> messages ??  We should discuss all such possible attacks, before we decide to
> go with MUST or SHOULD.
>
> Where are we know?
>
> -07 of the draft already, until the D(TLS) mandate was thrown in during the
> DISCUSS.
>
> Simply, logically:
> are NOT under the clearance discussed, which is for "TURN servers *provided
> (outside the local or access network), it must be the application that instructs
> Till: Brandon Williams; Karl Stahl; Prashanth Patil (praspati); [email-masked]<mailto:[email-masked]>
> Kopia: [email-masked]<mailto:[email-masked]>; 'Dan Wing'; 'Spencer Dawkins at IETF'
> I just listed one possible attack, there could be various other attacks like the
> one discussed in https://tools.ietf.org/html/rfc5766#section-17.2.1,
> > From: tram [mailto:[email-masked]] On Behalf Of Brandon
> > Williams
> > To: Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>>; Karl Stahl
> > <[email-masked]<mailto:[email-masked]>>; Prashanth Patil (praspati)
> > <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> > Cc: [email-masked]<mailto:[email-masked]>; 'Dan Wing' <[email-masked]<mailto:[email-masked]>>; 'Spencer
> > Dawkins at IETF' <[email-masked]<mailto:[email-masked]>>
> > >> To: 'Brandon Williams' <[email-masked]<mailto:[email-masked]>>; Prashanth
> > >> Patil
> > >> (praspati) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> > >> Cc: [email-masked]<mailto:[email-masked]>; 'Dan Wing' <[email-masked]<mailto:[email-masked]>>; 'Spencer
> > >> Dawkins at IETF' <[email-masked]<mailto:[email-masked]>>; Tirumaleswar
> > >> Reddy
> > >> (tireddy) <[email-masked]<mailto:[email-masked]>>
> > >> Från: Brandon Williams [mailto:[email-masked]]
> > >> Till: Karl Stahl; 'Prashanth Patil (praspati)'; [email-masked]<mailto:[email-masked]>
> > >> Kopia: [email-masked]<mailto:[email-masked]>; 'Dan Wing'; 'Spencer Dawkins at IETF';
> > >> that a small local network will have an easier time with these than you
> suggest as well.
> > >>
> > >>>    A TURN client MUST use (D)TLS ... in the absence of STUN long-term
> > >>> and https://www.ietf.org/mail-
> > >> discovery, based on the network in which the TURN client finds itself."
> > >>>
> > >> intercepts and responds to an allocate request, should   be treated as
> a
> > >> used and there will be no need for the TTL limitation suggested under 9.3.
> > >>>
> > >>> Från: tram [mailto:[email-masked]] För Prashanth Patil
> > >>> (praspati)
> > >>> Till: [email-masked]<mailto:[email-masked]>
> > >>> Kopia: [email-masked]<mailto:[email-masked]>; Dan Wing; Spencer Dawkins at IETF;
> > >>>    network provided TURN server.  In order to protect against man-in-
> > >>>    A TURN server in such cases must be configured to only process STUN
> > >>> [email-masked]<mailto:[email-masked]>
> > >>> [email-masked]<mailto:[email-masked]>
> > >> [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sun, 4 Dec 2016 06:09:10 +0000

No, Mandating (D)TLS does not mean forbidding TURN server usage in local (Enterprise) and access networks.
Opportunistic encryption protects the TURN client from the attacks I had discussed in the previous mail, attacker cannot see the TURN messages exchanged b/w the TURN client and TURN server, and cannot spoof TURN messages.

-Tiru

From: Karl Stahl [mailto:[email-masked]]
Sent: Friday, December 2, 2016 2:08 PM
To: Tirumaleswar Reddy (tireddy) <[email-masked]>; 'Brandon Williams' <[email-masked]>; Prashanth Patil (praspati) <[email-masked]>; [email-masked]
Cc: [email-masked]; 'Dan Wing' <[email-masked]>; 'Spencer Dawkins at IETF' <[email-masked]>
Subject: SV: [tram] draft-ietf-tram-turn-server-discovery

Hi Tiru,

I am trying to make the point that there is no option for this draft, supposed to fulfill:
[tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs
to result in: "We forbid usage of such (yellow) network provided TURN servers (use gray or grayish TURN servers instead)",  which is the consequence of mandating (D)TLS.

/Karl

And the outcome of any such discussion doesn't change the above.

Hi Karl,

-Tiru

Hi Tiru,

Now I don't know where you are again.

/Karl

Hi Karl,

No, I don't agree that (D)TLS is not mandatory. Opportunistic encryption is not new. It's discussed in RFC7435, and used in TCP increased security (TCPINC WG) and DNS privacy exchange (DPRIVE WG).

--- I don't think (D)TLS helps if you can spoof and have such attackers inside your network. (that paragraph says:  TURN prevents this by requiring that the credentials used") meaning authentication (not certificate checking, nor encryption).

-Tiru

Hi Tiru,

If "protects the client from various attacks discussed in previous mails" related to discovery of TURN servers, really is possible by introducing something (why reopen that now?), we have to be careful not to make yellow TURN servers grayish, which I am afraid self signed certificates might do, and further, does this belong in a discovery draft, risking to pick a fight with the WebRTC browser makers supposed to use this specification. We know they don't fancy self signed certificates...

Isn't it specifications for some specific usage/application (like the return draft for WebRTC browsers) that should consider such things (not this draft), without any recommendation from this specification?

/Karl

I am not suggesting that authentication is mandatory for TURN servers provided by local or access networks using (D)TLS but use of (D)TLS [Karl: "these become gray not yellow" or are you suggesting certificated signed by the network provider]

[Karl: Seems like you are suggesting self signed certificates to just get the encryption (again - also discussed)]

[TR] Yes, that's one possible option to mandate (D)TLS. Client cannot validate the TURN server certificate but use encryption-only (D)TLS and protects the client from various attacks discussed in previous mails.

-Tiru

Hi Tiru,

Please also understand that "the gray TURN servers" are provided by others than the local or access network, and you chose to trust them with your real-time traffic based on checking their certificate (Who configures which to allow into the WebRTC browser?).

In a specification which main purpose is to auto discover TURN servers provided by the local or access network ("the yellow ones"), you CANNOT LOGICALLY end up with saying you MUST/SHOULD or are RECOMMENDED to use "the gray ones" instead, provided by some authority or Brandon maybe (which are meant for other purposes). Then you have not delivered the specification we need = The showstopper.

/Karl

PS: Some comments below.

Hi Karl,

I am not suggesting that authentication is mandatory for TURN servers provided by local or access networks using (D)TLS but use of (D)TLS [Karl: "these become gray not yellow" or are you suggesting certificated signed by the network provider] without authenticating the TURN server is mandatory to avoid various attacks listed in previous mails.

In short, the TURN servers provided by local or access networks must use (D)TLS but it's not mandatory for these TURN servers to get certificates from CA or any explicit configuration is required on the client to trust the TURN server. [Karl: Seems like you are suggesting self signed certificates to just get the encryption (again - also discussed)]

-Tiru

Hi Tiru,

So, just let me rest with that your discussion does not take away the allowance to use TURN servers provided by the local or access network without authentication that was re-introduced in version -7 of the draft (after long discussions, including with you Tiru). Remember, those yellow TURN servers were the requirement of this draft to auto discover so they can be used by the WebRTC browsers - Usage cannot be forbidden (or un-recommended as Brandon suggests, although Brandon is agreeing to that the (D)TLS mandate must vanish for the yellow TURN servers).

while this discussion with Author Tiru and >"I don't run a local network or an access network and would not expect to deploy relays meant to function in that mode" Brandon*, has been on more or less deviated subjects, or repeating what we already have been through earlier (PS: Notice that Author Prashanth already listed/discussed the attack stuff during the discuss. I feared you were redoing that.)

/Karl

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Skickat: den 18 november 2016 04:00
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati); [email-masked]<mailto:[email-masked]>
Kopia: [email-masked]<mailto:[email-masked]>; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery

Hi Karl,

-Tiru

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sun, 4 Dec 2016 07:32:43 +0000

Prashanth has already summarized the changes done to draft during ISEG review in https://mailarchive.ietf.org/arch/msg/tram/3svO9djFxeZyTtNsgqQf8zCTiVY

Karl’s comment is to not mandate (D)TLS, and we don’t agree with him.

Request you, WG members, WG chairs and AD to share their thoughts on mandating the use of (D)TLS when STUN authentication is not used to handle the threats discussed in RFC5766.

-Tiru

From: Pal Martinsen (palmarti)
Sent: Friday, December 2, 2016 11:27 PM
To: Karl Stahl <[email-masked]>; tram mailing list <[email-masked]>
Cc: Tirumaleswar Reddy (tireddy) <[email-masked]>; Brandon Williams <[email-masked]>; Prashanth Patil (praspati) <[email-masked]>; [email-masked]; Dan Wing <[email-masked]>; Spencer Dawkins at IETF <[email-masked]>
Subject: Re: [tram] draft-ietf-tram-turn-server-discovery

Hi Karl (and tramsters),

.-.
Pål-Erik

Hi Tiru,

/Karl

Hi Karl,

-Tiru

Hi Tiru,

/Karl

Hi Karl,

-Tiru

Hi Tiru,

/Karl

-Tiru

Hi Tiru,

/Karl

PS: Some comments below.

Hi Karl,

-Tiru

Hi Tiru,

/Karl

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Skickat: den 18 november 2016 04:00
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati); [email-masked]<mailto:[email-masked]>
Kopia: [email-masked]<mailto:[email-masked]>; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery

Hi Karl,

-Tiru

---

From: "Karl Stahl" <[email-masked]>
Date: Mon, 5 Dec 2016 17:13:32 +0100

Hi Tiru,

See previous:

I think all you bring up, since version -7 of this draft, is already
discussed in Author’s: “Please refer
<https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-10#sectio
n-9>
https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-10#section
-9 for more details.”

/Karl

PS: Yet some comments below

Skickat: den 4 december 2016 07:09

No, Mandating (D)TLS does not mean forbidding TURN server usage in local
(Enterprise) and access networks.

--- See previous

Opportunistic encryption protects the TURN client from the attacks I had
discussed in the previous mail, attacker cannot see the TURN messages
exchanged b/w the TURN client and TURN server, 

--- On local networks, you are among friends (or much worse than TURN server
spoof attacks may happen)

--- On access networks you are hopefully in cafe mode, not being in contact
with the other users (seeing their TURN messages) 

and cannot spoof TURN messages.

--- encryption does not hide source or destination ip addresses as far as I
understand

/Karl

-Tiru

Hi Tiru,

/Karl

 

Hi Karl,

-Tiru

Hi Tiru,

/Karl

Hi Karl,

firewall can now send a

 

-Tiru

Hi Tiru,

 

/Karl

-Tiru

Hi Tiru,

/Karl

PS: Some comments below.

Hi Karl,

-Tiru

Hi Tiru,

 

 

/Karl

 

-----Ursprungligt meddelande-----

Hi Karl,

-Tiru

[email-masked]

about the

the

whether

to

the

*provided

instructs

like the

(praspati)

you

long-term

itself."

as

9.3.

man-in-

STUN

---

From: "Karl Stahl" <[email-masked]>
Date: Mon, 5 Dec 2016 17:17:45 +0100

Hi Pål-Erik and All,

Attached I have hopefully done something better and years quicker, simply red-lined in current version -10 what I find required to be fixed for TURN server provided by local or access network. (A pdf for those of you without Word, but in Word text for all (including Authors) to cut and paste from, so we get this done in few days.)

Almost all red text comes from earlier in this thread. I have tried to maintain most of the current text and made all changes clearly visible.

Thanks,

Karl

Från: Pal Martinsen (palmarti) [mailto:[email-masked]] 
Skickat: den 2 december 2016 18:57
Till: Karl Stahl; tram mailing list
Kopia: Tirumaleswar Reddy (tireddy); Brandon Williams; Prashanth Patil (praspati); [email-masked]; Dan Wing; Spencer Dawkins at IETF
Ämne: Re: [tram] draft-ietf-tram-turn-server-discovery

Hi Karl (and tramsters), 

 

.-.

Pål-Erik

On 2 Dec 2016, at 09:38, Karl Stahl <[email-masked]> wrote:

Hi Tiru,

/Karl

 

Från: Tirumaleswar Reddy (tireddy) [ <mailto:[email-masked]> mailto:[email-masked]] 
Skickat: den 28 november 2016 10:53
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati);  <mailto:[email-masked]> [email-masked]
Kopia:  <mailto:[email-masked]> [email-masked]; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery

Hi Karl,

-Tiru

From: tram [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Karl Stahl
Sent: Monday, November 28, 2016 2:49 PM
To: Tirumaleswar Reddy (tireddy) < <mailto:[email-masked]> [email-masked]>; 'Brandon Williams' < <mailto:[email-masked]> [email-masked]>; Prashanth Patil (praspati) < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]
Cc:  <mailto:[email-masked]> [email-masked]; 'Dan Wing' < <mailto:[email-masked]> [email-masked]>; 'Spencer Dawkins at IETF' < <mailto:[email-masked]> [email-masked]>
Subject: Re: [tram] draft-ietf-tram-turn-server-discovery

Hi Tiru,

/Karl

Från: Tirumaleswar Reddy (tireddy) [ <mailto:[email-masked]> mailto:[email-masked]] 
Skickat: den 28 november 2016 04:02
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati);  <mailto:[email-masked]> [email-masked]
Kopia:  <mailto:[email-masked]> [email-masked]; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery

Hi Karl,

a)  <https://tools.ietf.org/html/rfc5766#section-17.2.1> https://tools.ietf.org/html/rfc5766#section-17.2.1, where attacker sends faked permissions to the TURN server to launch attack (DOS or DDOS) on the victim (TURN client). 

b)  <https://tools.ietf.org/html/rfc5766#section-17.3.3> https://tools.ietf.org/html/rfc5766#section-17.3.3, attacker sends spoofed TURN requests to the TURN server to close allocations.

 

-Tiru

From: tram [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Karl Stahl
Sent: Monday, November 28, 2016 1:39 AM
To: Tirumaleswar Reddy (tireddy) < <mailto:[email-masked]> [email-masked]>; 'Brandon Williams' < <mailto:[email-masked]> [email-masked]>; Prashanth Patil (praspati) < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]
Cc:  <mailto:[email-masked]> [email-masked]; 'Dan Wing' < <mailto:[email-masked]> [email-masked]>; 'Spencer Dawkins at IETF' < <mailto:[email-masked]> [email-masked]>
Subject: Re: [tram] draft-ietf-tram-turn-server-discovery

Hi Tiru,

 

/Karl

Från: Tirumaleswar Reddy (tireddy) [ <mailto:[email-masked]> mailto:[email-masked]] 
Skickat: den 23 november 2016 04:15
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati);  <mailto:[email-masked]> [email-masked]
Kopia:  <mailto:[email-masked]> [email-masked]; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery

-Tiru

From: Karl Stahl [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Tuesday, November 22, 2016 11:12 PM
To: Tirumaleswar Reddy (tireddy) < <mailto:[email-masked]> [email-masked]>; 'Brandon Williams' < <mailto:[email-masked]> [email-masked]>; Prashanth Patil (praspati) < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]
Cc:  <mailto:[email-masked]> [email-masked]; 'Dan Wing' < <mailto:[email-masked]> [email-masked]>; 'Spencer Dawkins at IETF' < <mailto:[email-masked]> [email-masked]>
Subject: SV: [tram] draft-ietf-tram-turn-server-discovery

Hi Tiru,

/Karl

PS: Some comments below.

Från: Tirumaleswar Reddy (tireddy) [ <mailto:[email-masked]> mailto:[email-masked]] 
Skickat: den 22 november 2016 04:31
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati);  <mailto:[email-masked]> [email-masked]
Kopia:  <mailto:[email-masked]> [email-masked]; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery

Hi Karl,

-Tiru

From: Karl Stahl [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: Monday, November 21, 2016 2:10 AM
To: Tirumaleswar Reddy (tireddy) < <mailto:[email-masked]> [email-masked]>; 'Brandon Williams' < <mailto:[email-masked]> [email-masked]>; Prashanth Patil (praspati) < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]
Cc:  <mailto:[email-masked]> [email-masked]; 'Dan Wing' < <mailto:[email-masked]> [email-masked]>; 'Spencer Dawkins at IETF' < <mailto:[email-masked]> [email-masked]>
Subject: SV: [tram] draft-ietf-tram-turn-server-discovery

Hi Tiru,

 

 

 <https://www.ietf.org/mail-archive/web/tram/current/msg02216.html> https://www.ietf.org/mail-archive/web/tram/current/msg02216.html

 <https://www.ietf.org/mail-archive/web/tram/current/msg02226.html> https://www.ietf.org/mail-archive/web/tram/current/msg02226.html

/Karl

*  <https://www.ietf.org/mail-archive/web/tram/current/msg02217.html> https://www.ietf.org/mail-archive/web/tram/current/msg02217.html

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [ <mailto:[email-masked]> mailto:[email-masked]] 
Skickat: den 18 november 2016 04:00
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati);  <mailto:[email-masked]> [email-masked]
Kopia:  <mailto:[email-masked]> [email-masked]; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery

Hi Karl,

-Tiru

> From: Karl Stahl [ <mailto:[email-masked]> mailto:[email-masked]]

> To: Tirumaleswar Reddy (tireddy) < <mailto:[email-masked]> [email-masked]>; 'Brandon Williams'

> < <mailto:[email-masked]> [email-masked]>; Prashanth Patil (praspati)

> < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]

> Cc:  <mailto:[email-masked]> [email-masked]; 'Dan Wing' < <mailto:[email-masked]> [email-masked]>; 'Spencer Dawkins

> at IETF' < <mailto:[email-masked]> [email-masked]>

> Från: Tirumaleswar Reddy (tireddy) [ <mailto:[email-masked]> mailto:[email-masked]]

> Till: Brandon Williams; Karl Stahl; Prashanth Patil (praspati);  <mailto:[email-masked]> [email-masked]

> Kopia:  <mailto:[email-masked]> [email-masked]; 'Dan Wing'; 'Spencer Dawkins at IETF'

> one discussed in  <https://tools.ietf.org/html/rfc5766#section-17.2.1> https://tools.ietf.org/html/rfc5766#section-17.2.1,

> > From: tram [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Brandon

> > To: Tirumaleswar Reddy (tireddy) < <mailto:[email-masked]> [email-masked]>; Karl Stahl

> > < <mailto:[email-masked]> [email-masked]>; Prashanth Patil (praspati)

> > < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]

> > Cc:  <mailto:[email-masked]> [email-masked]; 'Dan Wing' < <mailto:[email-masked]> [email-masked]>; 'Spencer

> > Dawkins at IETF' < <mailto:[email-masked]> [email-masked]>

> > >> From: tram [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Karl Stahl

> > >> To: 'Brandon Williams' < <mailto:[email-masked]> [email-masked]>; Prashanth

> > >> (praspati) < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]

> > >> Cc:  <mailto:[email-masked]> [email-masked]; 'Dan Wing' < <mailto:[email-masked]> [email-masked]>; 'Spencer

> > >> Dawkins at IETF' < <mailto:[email-masked]> [email-masked]>; Tirumaleswar

> > >> Från: Brandon Williams [ <mailto:[email-masked]> mailto:[email-masked]]

> > >> Till: Karl Stahl; 'Prashanth Patil (praspati)';  <mailto:[email-masked]> [email-masked]

> > >> Kopia:  <mailto:[email-masked]> [email-masked]; 'Dan Wing'; 'Spencer Dawkins at IETF';

> > >>>  <https://www.ietf.org/mail-archive/web/tram/current/msg01319.html> https://www.ietf.org/mail-archive/web/tram/current/msg01319.html

> > >>>  <https://www.ietf.org/mail-archive/web/tram/current/msg01742.html> https://www.ietf.org/mail-archive/web/tram/current/msg01742.html

> > >>>  <https://www.ietf.org/mail-archive/web/tram/current/msg02191.html> https://www.ietf.org/mail-archive/web/tram/current/msg02191.html

> > >>>  <https://www.ietf.org/mail-archive/web/tram/current/msg01821.html> https://www.ietf.org/mail-archive/web/tram/current/msg01821.html

> > >>>  <https://www.ietf.org/mail-archive/web/tram/current/msg02144.html> https://www.ietf.org/mail-archive/web/tram/current/msg02144.html

> > >>>  <https://www.ietf.org/mail-archive/web/tram/current/msg02081.htm> https://www.ietf.org/mail-archive/web/tram/current/msg02081.htm l

> > >>>  <https://www.ietf.org/mail-archive/web/tram/current/msg00132.html> https://www.ietf.org/mail-archive/web/tram/current/msg00132.html

> > >>>  <https://www.ietf.org/mail-archive/web/tram/current/msg00138.html> https://www.ietf.org/mail-archive/web/tram/current/msg00138.html

> > >>>  <https://www.ietf.org/mail-archive/web/tram/current/msg01721.html> https://www.ietf.org/mail-archive/web/tram/current/msg01721.html

> > >>>  <https://www.ietf.org/mail-archive/web/tram/current/msg01745.html> https://www.ietf.org/mail-archive/web/tram/current/msg01745.html

> > >>>  <https://www.ietf.org/mail-archive/web/tram/current/msg02155.html> https://www.ietf.org/mail-archive/web/tram/current/msg02155.html

> > >>> Från: tram [ <mailto:[email-masked]> mailto:[email-masked]] För Prashanth Patil

> > >>> Kopia:  <mailto:[email-masked]> [email-masked]; Dan Wing; Spencer Dawkins at IETF;

> > >>  <https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-1> https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-1

> > >>>  <https://www.ietf.org/mailman/listinfo/tram> https://www.ietf.org/mailman/listinfo/tram

> > >>>  <https://www.ietf.org/mailman/listinfo/tram> https://www.ietf.org/mailman/listinfo/tram

> > >>  <https://www.ietf.org/mailman/listinfo/tram> https://www.ietf.org/mailman/listinfo/tram

> >  <https://www.ietf.org/mailman/listinfo/tram> https://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/tram> https://www.ietf.org/mailman/listinfo/tram

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 6 Dec 2016 05:59:18 +0000

Hi Karl,

Inside attacks are possible in local networks (e.g. Enterprise network).

I will elaborate one of the attacks:

a)Inside attacker passively monitors the TURN messages b/w the TURN client and TURN server, and learns the nonce value conveyed by the TURN server in Allocate response.

b)Inside attacker spoofs a TURN request to the TURN server to close the allocation (lifetime set to zero). Attacker spoofs the source IP address of the TURN client and uses the nonce learned previously.

c)TURN server checks if the nonce value is valid and successfully closes the allocation

With opportunistic encryption, attacker will not see the nonce value sent by the TURN server to the TURN client and cannot close the allocation.

-Tiru

From: Karl Stahl [mailto:[email-masked]]
Sent: Monday, December 5, 2016 9:44 PM
To: Tirumaleswar Reddy (tireddy) <[email-masked]>; 'tram mailing list' <[email-masked]>; 'Brandon Williams' <[email-masked]>
Cc: Prashanth Patil (praspati) <[email-masked]>; [email-masked]; 'Dan Wing' <[email-masked]>; 'Spencer Dawkins at IETF' <[email-masked]>
Subject: SV: [tram] to Tiru, WAS:draft-ietf-tram-turn-server-discovery

Hi Tiru,

See previous:
I think all you bring up, since version -7 of this draft, is already discussed in Author's: "Please refer https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-10#section-9 for more details."

/Karl

No, Mandating (D)TLS does not mean forbidding TURN server usage in local (Enterprise) and access networks.
--- See previous
Opportunistic encryption protects the TURN client from the attacks I had discussed in the previous mail, attacker cannot see the TURN messages exchanged b/w the TURN client and TURN server,
--- On local networks, you are among friends (or much worse than TURN server spoof attacks may happen)
--- On access networks you are hopefully in cafe mode, not being in contact with the other users (seeing their TURN messages)
and cannot spoof TURN messages.
--- encryption does not hide source or destination ip addresses as far as I understand
/Karl
-Tiru

Hi Tiru,

/Karl

Hi Karl,

-Tiru

Hi Tiru,

/Karl

Hi Karl,

-Tiru

Hi Tiru,

/Karl

-Tiru

Hi Tiru,

/Karl

PS: Some comments below.

Hi Karl,

-Tiru

Hi Tiru,

/Karl

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Skickat: den 18 november 2016 04:00
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati); [email-masked]<mailto:[email-masked]>
Kopia: [email-masked]<mailto:[email-masked]>; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery

Hi Karl,

-Tiru

---

From: "Karl Stahl" <[email-masked]>
Date: Wed, 7 Dec 2016 03:04:43 +0100

Hi Tiru,

Isn’t all of that in the draft since version -7 and no one has suggested to
remove it:

Author’s: “Please refer

“An auto-discovered TURN server is considered to be only as trusted as

   the path between the client and the TURN server.  In order to safely

   use auto-discovered TURN servers for sessions with 'strict privacy'

   requirements, the user needs to be able to define privacy criteria

   (e.g.  a trusted list of servers, networks, or domains) that are

   considered acceptable for such traffic.  Any discovered TURN server

   outside the criteria is considered untrusted and therefore MUST NOT

   be used for privacy sensitive communication.

   In some auto-discovery scenarios, it might not be possible for the

   TURN client to use (D)TLS authentication to validate the TURN server.

   However, fall-back to clear text in such cases could leave the TURN

   client open to on-path injection of spoofed TURN messages.  Instead,

   with an explicit administrator choice, a TURN client SHOULD fall-back

   to encryption-only (D)TLS when (D)TLS authentication is not

   available.  Another reason to fall-back to encryption-only is for

   privacy, which is analogous to SMTP opportunistic encryption

   [RFC7435 <https://tools.ietf.org/html/rfc7435> ] where one does not
require privacy but one desires privacy

   when possible.

   It is suggested that a TURN client attempt (D)TLS with authentication

   and encryption, falling back to encryption-only if the TURN server

   cannot be authenticated via (D)TLS.  A TURN client could fall back to

   clear text, with an explicit administrator choice, if it does not

   support unauthenticated (D)TLS, but fallback to clear text is NOT

   RECOMMENDED because it makes the client more susceptible to man-in-

   the-middle attacks and on-path packet injection.”

Also, you said you were NOT interested in mandating D(TLS) for validation,
which was the text thrown during  the discuss, and the only thing I have
suggested to be removed.

In addition to “A TURN server in such cases must be configured to only
process STUN

   requests from the trusted local network or subscribers of the access

   access control by means of access-lists, firewalls, subscriber quota

   limits, ingress filtering etc.” as compensation for the authentication
downgrade from MUST, which also no one has suggested to be removed, I
suggested that this sentence thrown in during the discuss, is removed:

   “A TURN client MUST use (D)TLS in the absence of STUN long-term

   credential mechanism [RFC5389 <https://tools.ietf.org/html/rfc5389> ] or
STUN Extension for Third-Party

   Authorization [RFC7635 <https://tools.ietf.org/html/rfc7635> ].”

And  this yellow (that Brandon wanted, but you were not interested in the
validation) is still there in all versions from -7 to suggested -11.

  “It is RECOMMENDED that the TURN client use

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

   server:

So I think we can keep the (D)TLS consensus that has been there since
version -7 and remains in my suggested -11.

/Karl

Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] 
Skickat: den 6 december 2016 06:59
Till: Karl Stahl; 'tram mailing list'; 'Brandon Williams'
Kopia: Prashanth Patil (praspati); [email-masked]; 'Dan Wing';
'Spencer Dawkins at IETF'
Ämne: RE: [tram] to Tiru, WAS:draft-ietf-tram-turn-server-discovery

Hi Karl,

a)Inside attacker passively monitors the TURN messages b/w the TURN client
and TURN server, and learns the nonce value conveyed by the TURN server in
Allocate response.

b)Inside attacker spoofs a TURN request to the TURN server to close the
allocation (lifetime set to zero). Attacker spoofs the source IP address of
the TURN client and uses the nonce learned previously.

c)TURN server checks if the nonce value is valid and successfully closes the
allocation

With opportunistic encryption, attacker will not see the nonce value sent by
the TURN server to the TURN client and cannot close the allocation.

-Tiru 

From: Karl Stahl [mailto:[email-masked]] 
Sent: Monday, December 5, 2016 9:44 PM
To: Tirumaleswar Reddy (tireddy) <[email-masked]>; 'tram mailing list'
<[email-masked]>; 'Brandon Williams' <[email-masked]>
Cc: Prashanth Patil (praspati) <[email-masked]>; [email-masked];
'Dan Wing' <[email-masked]>; 'Spencer Dawkins at IETF'
<[email-masked]>
Subject: SV: [tram] to Tiru, WAS:draft-ietf-tram-turn-server-discovery

Hi Tiru,

See previous:

/Karl

--- See previous

/Karl

-Tiru

Hi Tiru,

/Karl

 

Hi Karl,

-Tiru

Hi Tiru,

/Karl

Hi Karl,

firewall can now send a

 

-Tiru

Hi Tiru,

 

/Karl

-Tiru

Hi Tiru,

/Karl

PS: Some comments below.

Hi Karl,

-Tiru

Hi Tiru,

 

 

/Karl

 

-----Ursprungligt meddelande-----

Hi Karl,

-Tiru

[email-masked]

about the

the

whether

to

the

*provided

instructs

like the

(praspati)

you

long-term

itself."

as

9.3.

man-in-

STUN

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 7 Dec 2016 04:17:12 +0000

Karl Wrote:  Also, you said you were NOT interested in mandating D(TLS) for validation, which was the text thrown during  the discuss, and the only thing I have suggested to be removed.

[Tiru]
I can fix the following text to avoid the confusion that (D)TLS is mandatory but validating the TURN server identity is not mandatory:

OLD:
A TURN client MUST use (D)TLS in the absence of STUN long-term credential mechanism [RFC5389] or STUN Extension for Third-Party Authorization [RFC7635].

NEW:
In the absence of STUN long-term credential mechanism [RFC5389] or STUN Extension for Third-Party Authorization [RFC7635], a TURN client MUST use (D)TLS and if (D)TLS authentication to validate the TURN server identity is not possible then the TURN client MUST fallback to encryption-only (D)TLS.

-Tiru

Sent: Wednesday, December 7, 2016 7:35 AM

Hi Tiru,

Isn't all of that in the draft since version -7 and no one has suggested to remove it:
Author's: "Please refer https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-10#section-9 for more details."

"An auto-discovered TURN server is considered to be only as trusted as

   [RFC7435<https://tools.ietf.org/html/rfc7435>] where one does not require privacy but one desires privacy
   when possible.

   the-middle attacks and on-path packet injection."

Also, you said you were NOT interested in mandating D(TLS) for validation, which was the text thrown during  the discuss, and the only thing I have suggested to be removed.

In addition to "A TURN server in such cases must be configured to only process STUN
   requests from the trusted local network or subscribers of the access
   network.  Operational measures must be taken in order protect the
   TURN server; some of these measures include, but not limited to,
   access control by means of access-lists, firewalls, subscriber quota
   limits, ingress filtering etc." as compensation for the authentication downgrade from MUST, which also no one has suggested to be removed, I suggested that this sentence thrown in during the discuss, is removed:
   "A TURN client MUST use (D)TLS in the absence of STUN long-term
   credential mechanism [RFC5389<https://tools.ietf.org/html/rfc5389>] or STUN Extension for Third-Party
   Authorization [RFC7635<https://tools.ietf.org/html/rfc7635>]."
And  this yellow (that Brandon wanted, but you were not interested in the validation) is still there in all versions from -7 to suggested -11.
  "It is RECOMMENDED that the TURN client use
   one of the following techniques with (D)TLS to validate the TURN
   server:

So I think we can keep the (D)TLS consensus that has been there since version -7 and remains in my suggested -11.

/Karl

Kopia: Prashanth Patil (praspati); [email-masked]<mailto:[email-masked]>; 'Dan Wing'; 'Spencer Dawkins at IETF'

Hi Karl,

-Tiru

From: Karl Stahl [mailto:[email-masked]]
Sent: Monday, December 5, 2016 9:44 PM
To: Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>>; 'tram mailing list' <[email-masked]<mailto:[email-masked]>>; 'Brandon Williams' <[email-masked]<mailto:[email-masked]>>
Cc: Prashanth Patil (praspati) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'Dan Wing' <[email-masked]<mailto:[email-masked]>>; 'Spencer Dawkins at IETF' <[email-masked]<mailto:[email-masked]>>
Subject: SV: [tram] to Tiru, WAS:draft-ietf-tram-turn-server-discovery

Hi Tiru,

See previous:

/Karl

Hi Tiru,

/Karl

Hi Karl,

-Tiru

Hi Tiru,

/Karl

Hi Karl,

-Tiru

Hi Tiru,

/Karl

-Tiru

Hi Tiru,

/Karl

PS: Some comments below.

Hi Karl,

-Tiru

Hi Tiru,

/Karl

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Skickat: den 18 november 2016 04:00
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati); [email-masked]<mailto:[email-masked]>
Kopia: [email-masked]<mailto:[email-masked]>; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery

Hi Karl,

-Tiru

---

From: Brandon Williams <[email-masked]>
Date: Sat, 10 Dec 2016 10:06:44 -0500

+1

On 12/06/2016 11:17 PM, Tirumaleswar Reddy (tireddy) wrote:
> Karl Wrote:  Also, you said you were NOT interested in mandating D(TLS)
> for validation, which was the text thrown during  the discuss, and the
> only thing I have suggested to be removed.
>
>
>
> [Tiru]
>
> I can fix the following text to avoid the confusion that (D)TLS is
> mandatory but validating the TURN server identity is not mandatory:
>
>
>
> OLD:
>
> Authorization [RFC7635].
> In the absence of STUN long-term credential mechanism [RFC5389] or STUN
> Extension for Third-Party Authorization [RFC7635], a TURN client MUST
> use (D)TLS and if (D)TLS authentication to validate the TURN server
> identity is not possible then the TURN client MUST fallback to
> encryption-only (D)TLS.
>
>
>
> -Tiru
>
>
>
> *From:* Karl Stahl [mailto:[email-masked]]
> *Sent:* Wednesday, December 7, 2016 7:35 AM
> *To:* Tirumaleswar Reddy (tireddy) <[email-masked]>; 'tram mailing
> list' <[email-masked]>; 'Brandon Williams' <[email-masked]>
> *Cc:* Prashanth Patil (praspati) <[email-masked]>;
> [email-masked]; 'Dan Wing' <[email-masked]>; 'Spencer Dawkins at
> *Subject:* SV: [tram] to Tiru, WAS:draft-ietf-tram-turn-server-discovery
>
>
>
> Hi Tiru,
>
>
>
> Isn’t all of that in the draft since version -7 and no one has suggested
> to remove it:
>
> Author’s: “Please refer
> https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-10#section-9
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D10-23section-2D9&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=6aJ1JWFxE2YgbNJfXZnnIngnYbMdeK80XioPfnUwks4&e=>
> for more details.”
>
>
>
>    [RFC7435
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7435&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=o-ahnzvSKRMEYO1xIUtpMh0QBXqHdM5jncX_6SLG31k&e=>]
> where one does not require privacy but one desires privacy
>
>    when possible.
>
>
>
> Also, you said you were NOT interested in mandating D(TLS) for
> validation, which was the text thrown during  the discuss, and the only
> thing I have suggested to be removed.
>
>
>
>    limits, ingress filtering etc.” as compensation for the
> authentication downgrade from MUST, which also no one has suggested to
> be removed, I suggested that this sentence thrown in during the discuss,
> is removed:
>
>    credential mechanism [RFC5389
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5389&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=F4YughE0J_rmP7Ulo5T9IJB4Fu3W-JNMyoheE6iyek8&e=>]
> or STUN Extension for Third-Party
>
>    Authorization [RFC7635
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7635&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=MIL4juxvOv918XY6KGHPmqDeE7OJsySEhai5dbBIXMo&e=>].”
>
> And  this yellow (that Brandon wanted, but you were not interested in
> the validation) is still there in all versions from -7 to suggested -11.
>
> So I think we can keep the *(D)TLS consensus* that has been there since
> *Från:*Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
> *Skickat:* den 6 december 2016 06:59
> *Till:* Karl Stahl; 'tram mailing list'; 'Brandon Williams'
> *Kopia:* Prashanth Patil (praspati); [email-masked]
> <mailto:[email-masked]>; 'Dan Wing'; 'Spencer Dawkins at IETF'
> *Ämne:* RE: [tram] to Tiru, WAS:draft-ietf-tram-turn-server-discovery
>
>
>
> Hi Karl,
>
>
>
> a)Inside attacker passively monitors the TURN messages b/w the TURN
> client and TURN server, and learns the nonce value conveyed by the TURN
> server in Allocate response.
>
>
>
> allocation (lifetime set to zero). Attacker spoofs the source IP address
> of the TURN client and uses the nonce learned previously.
>
>
>
> With opportunistic encryption, attacker will not see the nonce value
> sent by the TURN server to the TURN client and cannot close the allocation.
>
>
>
> -Tiru
>
>
>
> *From:* Karl Stahl [mailto:[email-masked]]
> *Sent:* Monday, December 5, 2016 9:44 PM
> *To:* Tirumaleswar Reddy (tireddy) <[email-masked]
> <mailto:[email-masked]>>; 'tram mailing list' <[email-masked]
> <mailto:[email-masked]>>; 'Brandon Williams' <[email-masked]
> <mailto:[email-masked]>>
> *Cc:* Prashanth Patil (praspati) <[email-masked]
> <mailto:[email-masked]>>; [email-masked]
> <mailto:[email-masked]>; 'Dan Wing' <[email-masked]
> <mailto:[email-masked]>>; 'Spencer Dawkins at IETF'
> <[email-masked] <mailto:[email-masked]>>
> *Subject:* SV: [tram] to Tiru, WAS:draft-ietf-tram-turn-server-discovery
>
>
>
> Hi Tiru,
>
>
>
> See previous:
>
> https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-10#section-9
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D10-23section-2D9&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=6aJ1JWFxE2YgbNJfXZnnIngnYbMdeK80XioPfnUwks4&e=>
> for more details.”
>
>
>
> /Karl
>
>
>
> *Från:*Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
> *Skickat:* den 4 december 2016 07:09
> *Till:* Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati);
> [email-masked] <mailto:[email-masked]>
> *Kopia:* [email-masked] <mailto:[email-masked]>; 'Dan Wing';
> *Ämne:* RE: [tram] draft-ietf-tram-turn-server-discovery
>
>
>
> --- On access networks you are hopefully in cafe mode, not being in
> contact with the other users (seeing their TURN messages)
>
> *From:* Karl Stahl [mailto:[email-masked]]
> *Sent:* Friday, December 2, 2016 2:08 PM
> *To:* Tirumaleswar Reddy (tireddy) <[email-masked]
> <mailto:[email-masked]>>; 'Brandon Williams'
> <[email-masked] <mailto:[email-masked]>>;
> Prashanth Patil (praspati) <[email-masked]
> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>; 'Dan Wing'
> <[email-masked] <mailto:[email-masked]>>; 'Spencer Dawkins at IETF'
> <[email-masked] <mailto:[email-masked]>>
> *Subject:* SV: [tram] draft-ietf-tram-turn-server-discovery
>
>
>
> Hi Tiru,
>
>
>
> *[tram] Milestone 3: TURN server auto-discovery mechanism for enterprise
> and ISPs***
>
> Simply leave the consensus since version -7 of this draft by removing
> the (D)TLS mandating for TURN servers provided by  the local or access
> network thrown-in during the discuss.
>
>
>
> /Karl
>
>
>
> PS: I believe the attack discussion below is already done, and that you
> are wrong in thinking that authentication which protects against spoof
> attacks can be exchanged for encryption, and that any of these things
> protects against DDOS attacks . These security things address different
> things and are not interchangeable, nor are they universal means against
> attacks of various kinds.
>
>
>
> Please note (sorry to repeat)  that for the purpose of getting a better
> path for real-time traffic than through the default gateway path, we
> cannot expect to also get a higher security or trust level, nor to
> resolve every problem in the world.
>
>
>
>
>
> *Från:*Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
> *Skickat:* den 28 november 2016 10:53
> *Till:* Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati);
> [email-masked] <mailto:[email-masked]>
> *Kopia:* [email-masked] <mailto:[email-masked]>; 'Dan Wing';
> *Ämne:* RE: [tram] draft-ietf-tram-turn-server-discovery
>
>
>
> Hi Karl,
>
>
>
> referring to inside attacks launched by attackers inside the local or
> access network.
>
> a)An inside attacker sends faked permissions to the TURN server to
> launch attack (DOS or DDOS) on the victim (TURN client).
>
> *From:* tram [mailto:[email-masked]] *On Behalf Of *Karl Stahl
> *Sent:* Monday, November 28, 2016 2:49 PM
> *To:* Tirumaleswar Reddy (tireddy) <[email-masked]
> <mailto:[email-masked]>>; 'Brandon Williams'
> <[email-masked] <mailto:[email-masked]>>;
> Prashanth Patil (praspati) <[email-masked]
> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>; 'Dan Wing'
> <[email-masked] <mailto:[email-masked]>>; 'Spencer Dawkins at IETF'
> <[email-masked] <mailto:[email-masked]>>
> *Subject:* Re: [tram] draft-ietf-tram-turn-server-discovery
>
>
>
> Hi Tiru,
>
>
>
> Are you discussing TURN servers provided by the local or access network
> (the yellow TURN servers), that are released from authentication (no
> dispute there), but for which (D)TLS mandate was thrown in-during the
> discuss (making them gray)? That is the showstopper that must go away.
>
>
>
> *Från:*Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
> *Skickat:* den 28 november 2016 04:02
> *Till:* Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati);
> [email-masked] <mailto:[email-masked]>
> *Kopia:* [email-masked] <mailto:[email-masked]>; 'Dan Wing';
> *Ämne:* RE: [tram] draft-ietf-tram-turn-server-discovery
>
>
>
> Hi Karl,
>
>
>
> No, I don’t agree that (D)TLS is not mandatory. Opportunistic encryption
> is not new. It’s discussed in RFC7435, and used in TCP increased
> security (TCPINC WG) and DNS privacy exchange (DPRIVE WG).
>
>
>
> a) https://tools.ietf.org/html/rfc5766#section-17.2.1
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5766-23section-2D17.2.1&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=ZZ-_SMjOP8Ki9gZ6wzPjBywDoWtHtOREkDxWQHt0hA4&e=>,
> where attacker sends faked permissions to the TURN server to launch
>> Since the _TURN server sits outside_ the firewall, at attacker outside the
> firewall can now send a
>
> b) https://tools.ietf.org/html/rfc5766#section-17.3.3
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5766-23section-2D17.3.3&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=-mVAbbScCntQIQqG27WQgiJYDUnDrwrv3TooeaeW9WQ&e=>,
> attacker sends spoofed TURN requests to the TURN server to close
> allocations.
>
> inside your network. (that paragraph says:  TURN prevents this by
> requiring that the credentials used”) meaning authentication (not
> certificate checking, nor encryption).
>
>
>
>
>
> -Tiru
>
>
>
> *From:* tram [mailto:[email-masked]] *On Behalf Of *Karl Stahl
> *Sent:* Monday, November 28, 2016 1:39 AM
> *To:* Tirumaleswar Reddy (tireddy) <[email-masked]
> <mailto:[email-masked]>>; 'Brandon Williams'
> <[email-masked] <mailto:[email-masked]>>;
> Prashanth Patil (praspati) <[email-masked]
> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>; 'Dan Wing'
> <[email-masked] <mailto:[email-masked]>>; 'Spencer Dawkins at IETF'
> <[email-masked] <mailto:[email-masked]>>
> *Subject:* Re: [tram] draft-ietf-tram-turn-server-discovery
>
>
>
> Hi Tiru,
>
>
>
> discussing now have been listed already and for TURN servers in a local
> or access network (no change since version -7), we should not expect a
> higher security or trust level when sending our real-time traffic
> through another path than the through default gateway, both paths are
> provided by the same network provider.
>
> * *
>
> If “protects the client from various attacks discussed in previous
> mails” related to discovery of TURN servers, really is possible by
> introducing something (why reopen that now?), we have to be careful not
> to make yellow TURN servers grayish, which I am afraid self signed
> certificates might do, and further, does this belong in a discovery
> draft, risking to pick a fight with the WebRTC browser makers supposed
> to use this specification. We know they don’t fancy self signed
> certificates…
>
>
>
> Isn’t it specifications for some specific usage/application (like the
> return draft for WebRTC browsers) that should consider such things (not
> this draft), without any recommendation from this specification?
>
>
>
> /Karl
>
>
>
> *Från:*Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
> *Skickat:* den 23 november 2016 04:15
> *Till:* Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati);
> [email-masked] <mailto:[email-masked]>
> *Kopia:* [email-masked] <mailto:[email-masked]>; 'Dan Wing';
> *Ämne:* RE: [tram] draft-ietf-tram-turn-server-discovery
>
>
>
> provided by local or access networks using (D)TLS but use of
> (D)TLS[Karl: “these become gray not yellow” or are you suggesting
> certificated signed by the network provider]
>
>
>
> [TR] No, they are yellow and not grey; clients will use (D)TLS but do
> not validate the TURN server certificate (referred to as Opportunistic
> security in the draft).
>
>
>
> [Karl: Seems like you are suggesting self signed certificates to just
> get the encryption (again – also discussed)]
>
>
>
> *From:* Karl Stahl [mailto:[email-masked]]
> *Sent:* Tuesday, November 22, 2016 11:12 PM
> *To:* Tirumaleswar Reddy (tireddy) <[email-masked]
> <mailto:[email-masked]>>; 'Brandon Williams'
> <[email-masked] <mailto:[email-masked]>>;
> Prashanth Patil (praspati) <[email-masked]
> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>; 'Dan Wing'
> <[email-masked] <mailto:[email-masked]>>; 'Spencer Dawkins at IETF'
> <[email-masked] <mailto:[email-masked]>>
> *Subject:* SV: [tram] draft-ietf-tram-turn-server-discovery
>
>
>
> Hi Tiru,
>
>
>
> - Certificate checking as when using (D)TLS is to assure the user is
> using a trusted TURN server (and further is sets up an encrypted channel).
>
>
>
> These things are not interchangeable or do the same things or achieves
> the same, which has been discussed over and over again in this draft
> already.
>
>
>
> Let it rest with that we cannot/should not expect a higher trust or
> security level when sending our real-time traffic through the TURN
> server path, than trough the default gateway path. You simply have to
> trust the access from the network provider you select to connect to, or
> refrain from using it.
>
>
>
> Please also understand that “the gray TURN servers” are provided by
> others than the local or access network, and you chose to trust them
> with your real-time traffic based on checking their certificate (Who
> configures which to allow into the WebRTC browser?).
>
>
>
> LOGICALLY end up with saying you MUST/SHOULD or are RECOMMENDED to use
> “the gray ones” instead, provided by some authority or Brandon maybe
> (which are meant for other purposes). Then you have not delivered the
> specification we need = The showstopper.
>
>
>
> /Karl
>
>
>
> PS: Some comments below.
>
>
>
> *Från:*Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
> *Skickat:* den 22 november 2016 04:31
> *Till:* Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati);
> [email-masked] <mailto:[email-masked]>
> *Kopia:* [email-masked] <mailto:[email-masked]>; 'Dan Wing';
> *Ämne:* RE: [tram] draft-ietf-tram-turn-server-discovery
>
>
>
> Hi Karl,
>
>
>
> provided by local or access networks using (D)TLS but use of
> (D)TLS[Karl: “these become gray not yellow” or are you suggesting
> certificated signed by the network provider]without authenticating the
> TURN server is mandatory to avoid various attacks listed in previous mails.
>
>
>
> from CA or any explicit configuration is required on the client to trust
> the TURN server.[Karl: Seems like you are suggesting self signed
> certificates to just get the encryption (again – also discussed)]
>
>
>
> -Tiru
>
>
>
> *From:* Karl Stahl [mailto:[email-masked]]
> *Sent:* Monday, November 21, 2016 2:10 AM
> *To:* Tirumaleswar Reddy (tireddy) <[email-masked]
> <mailto:[email-masked]>>; 'Brandon Williams'
> <[email-masked] <mailto:[email-masked]>>;
> Prashanth Patil (praspati) <[email-masked]
> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>; 'Dan Wing'
> <[email-masked] <mailto:[email-masked]>>; 'Spencer Dawkins at IETF'
> <[email-masked] <mailto:[email-masked]>>
> *Subject:* SV: [tram] draft-ietf-tram-turn-server-discovery
>
>
>
> Hi Tiru,
>
>
>
> Trying to clarify as you request: I have lost track of in which context
> you are when you are "discussing various attacks" and what you mean with
> the ?? I marked below.
>
>
>
> My concern was whether this may again lead to that WE HAVE *_NO_* TURN
> SERVERS in the yellow area below resulting from the (D)TLS mandating
> that was thrown-in into version -10 during the discuss (=the
> showstopping), since TURN servers with certificates are NOT provided by
> the local or access network (those are provided by some "trust anchor
> authorities that issue TURN server certificates" etc..)
>
>
>
>
>
>
> (after long discussions, including with you Tiru). Remember, _those
> yellow TURN servers were the requirement of this draft to auto discover_
> so they can be used by the WebRTC browsers – Usage cannot be forbidden
> (or un-recommended as Brandon suggests, although Brandon is agreeing to
> that the (D)TLS mandate must vanish for the yellow TURN servers).
>
>
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02216.html&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=RoQksDYwTif8WcC7pu9mSw93lTpGv0PpvAVrBJmOqBE&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02226.html&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=HlFe94mDcpEMQcstYO_MnhU7YzYVgNNLj_zA6fKbQsw&e=>
>
> while this discussion with Author Tiru and >“I don't run a local network
> or an access network and would not expect to deploy relays meant to
> function in that mode“ Brandon*, has been on more or less deviated
> subjects, or repeating what we already have been through earlier (PS:
> Notice that Author Prashanth already listed/discussed the attack stuff
> during the discuss. I feared you were redoing that.)
>
>
>
> /Karl
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02217.html&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=MDJEF8Fm0L5d86VeSQoKznG8WMvrLGyL37ZlVoK7RbE&e=>
>
>
>
>
>
> [email-masked] <mailto:[email-masked]>
> Kopia: [email-masked] <mailto:[email-masked]>; 'Dan Wing';
> I don't understand your concerns, please clarify. The draft mandates
> (D)TLS but does not mandate TURN server validation.
>
>> To: Tirumaleswar Reddy (tireddy) <[email-masked] <mailto:[email-masked]>>; 'Brandon Williams'
>
>> <[email-masked] <mailto:[email-masked]>>;
>> <[email-masked] <mailto:[email-masked]>>; [email-masked]
> <mailto:[email-masked]>
>
>> Cc: [email-masked] <mailto:[email-masked]>; 'Dan Wing'
> <[email-masked] <mailto:[email-masked]>>; 'Spencer Dawkins
>
>> at IETF' <[email-masked] <mailto:[email-masked]>>
>
>> Till: Brandon Williams; Karl Stahl; Prashanth Patil (praspati); [email-masked] <mailto:[email-masked]>
>
>> Kopia: [email-masked] <mailto:[email-masked]>; 'Dan Wing';
>> one discussed in https://tools.ietf.org/html/rfc5766#section-17.2.1
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5766-23section-2D17.2.1&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=ZZ-_SMjOP8Ki9gZ6wzPjBywDoWtHtOREkDxWQHt0hA4&e=>,
>
>> > To: Tirumaleswar Reddy (tireddy) <[email-masked] <mailto:[email-masked]>>; Karl Stahl
>
>> > <[email-masked] <mailto:[email-masked]>>; Prashanth Patil
> (praspati)
>
>> > <[email-masked] <mailto:[email-masked]>>; [email-masked]
> <mailto:[email-masked]>
>
>> > Cc: [email-masked] <mailto:[email-masked]>; 'Dan Wing'
> <[email-masked] <mailto:[email-masked]>>; 'Spencer
>
>> > Dawkins at IETF' <[email-masked] <mailto:[email-masked]>>
>
>> > >> To: 'Brandon Williams' <[email-masked] <mailto:[email-masked]>>; Prashanth
>
>> > >> Patil
>
>> > >> (praspati) <[email-masked] <mailto:[email-masked]>>; [email-masked]
> <mailto:[email-masked]>
>
>> > >> Cc: [email-masked] <mailto:[email-masked]>; 'Dan Wing'
> <[email-masked] <mailto:[email-masked]>>; 'Spencer
>
>> > >> Dawkins at IETF' <[email-masked] <mailto:[email-masked]>>;
> Tirumaleswar
>
>> > >> Reddy
>
>> > >> (tireddy) <[email-masked] <mailto:[email-masked]>>
>
>> > >> Till: Karl Stahl; 'Prashanth Patil (praspati)'; [email-masked] <mailto:[email-masked]>
>
>> > >> Kopia: [email-masked] <mailto:[email-masked]>; 'Dan Wing';
> 'Spencer Dawkins at IETF';
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg01319.html&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=UQ8nxZHjChRSQF3sc2tbr82Vo2rwqxib6C1flqSTj0M&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg01742.html&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=bEWAC26Xp-ZCCpWasI9Az-CSOA7wvnm9eja0udVuZrk&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02191.html&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=TR1caTM9QwgFaASc71-diTPehw0IpmP3MWC-Kv3ECEA&e=>
>
>> > >>>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg01821.html&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=1K6T0yYhF7wHe5ZWa8i_FgptKRnKJPCrjulsFhA7ZiU&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02144.html&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=rAmhwLM0wIIegwZIGibns7sX1UArUnQPAKVg1lac1IM&e=>
>
>> > >>> https://www.ietf.org/mail-archive/web/tram/current/msg02081.htm
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02081.htm&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=n5wv4T-Romjuscl7TckqrB8HlLTNQQT2hhkbVLdC0nw&e=>l
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2D&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=ngvMj_FO-lqDILKiWc_vhnRwu9uGvez69CcN3WT7tZk&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg00132.html&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=RYHSesfqj7o8Z-N2Cf-bzialwIHWlsyrSz0xRmHzY4c&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg00138.html&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=KHA3cB1EXSI0iHSKZJ2M35wFeNJlswYbPCeUR0bsAA8&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg01721.html&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=_tS_buEDXuCbIC40GFNswK2X9uWoL1Whf5szrHEJDO4&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg01745.html&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=O11Dc68fLCzyFKwE5uk4gGITttt8x4swXSiI2Rq1t-I&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02155.html&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=Z3119bHFcte36WxImltxLO6FN_1UkgzYWpoPYZDVzt4&e=>
>
>> > >>>
>
>> > >>> /Karl
>
>> > >>>
>
>> > >>>
>
>> > >>> Till: [email-masked] <mailto:[email-masked]>
>
>> > >>> Kopia: [email-masked] <mailto:[email-masked]>; Dan Wing; Spencer
> Dawkins at IETF;
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D1&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=DVGS9E_SiopOIRk_em6JrGzQfeEIFTKDaFuOyMBN88Y&e=>
>
>> > >> 0#
>
>> > >> section
>
>> > >> -9 for more details.
>
>> > >>>
>
>> > >>> Thanks,
>
>> > >>> Authors
>
>> > >>>
>
>> > >>> [email-masked] <mailto:[email-masked]>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=m-0KDgh3LnSwNkYBXRZEvmD-6KbIBecTW_LVyOtpxKw&e=>
>
>> > >>>
>
>> > >>> [email-masked] <mailto:[email-masked]>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=m-0KDgh3LnSwNkYBXRZEvmD-6KbIBecTW_LVyOtpxKw&e=>
>
>> > >>>
>
>> > >>
>
>> > >> [email-masked] <mailto:[email-masked]>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=m-0KDgh3LnSwNkYBXRZEvmD-6KbIBecTW_LVyOtpxKw&e=>
>
>> >
>
>> > [email-masked] <mailto:[email-masked]>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=DgMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=7_NPCCssr1qNc9mpIa2KGK9mZALgQpov0FRi9DO1LVs&s=m-0KDgh3LnSwNkYBXRZEvmD-6KbIBecTW_LVyOtpxKw&e=>
>

-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.

---

From: Brandon Williams <[email-masked]>
Date: Sat, 10 Dec 2016 10:14:11 -0500

Wait ... I take back my +1 here ...

As I was writing a separate response to the server-side requirement 
thread, I changed my thinking about this one (or rather remembered my 
earlier thinking). Keeping track of this discussion has become really 
difficult at this point.

Sorry about my confusion. I'll send a separate e-mail that describes my 
thinking about (D)TLS, since I've already got it started in a separate 
window.

--Brandon

On 12/10/2016 10:06 AM, Brandon Williams wrote:
>>> To: Tirumaleswar Reddy (tireddy) <[email-masked]
>>> attack
>>> > >> To: 'Brandon Williams' <[email-masked]
>>> <mailto:[email-masked]>>; Prashanth
>>
>>> > >> Patil
>>

---

From: Brandon Williams <[email-masked]>
Date: Sat, 10 Dec 2016 12:12:25 -0500

Hi Karl,

Thanks for writing down your proposed changes to the anycast mechanism. 
That is at least a start.

However, I think we need agreement on the justification for such a 
change. There are good reasons to prefer the mechanism as defined in the 
current -10 text, especially backward compatibility with existing 
RFC5389 TURN clients. There has to be a compelling argument to move away 
from backward compatibility.

Regarding your proposed deployment considerations text, I don't think 
the mechanism for detecting whether the network is sealed is clearly 
enough defined for us to assess whether it actually works, let alone for 
someone to implement the mechanism. On a separate note, you appear to be 
describing transparent interception as an alternative discovery method; 
I strongly disagree with injecting that element into the discussion at 
this stage.

--Brandon

On 12/05/2016 11:17 AM, Karl Stahl wrote:
> Hi Pål-Erik and All,
>
>
>
> Attached I have hopefully done something better and years quicker,
> simply red-lined in current version -10 what I find required to be fixed
> for TURN server provided by local or access network. (A pdf for those of
> you without Word, but in Word text for all (including Authors) to cut
> and paste from, so we get this done in few days.)
>
>
>
> Almost all red text comes from earlier in this thread. I have tried to
> maintain most of the current text and made all changes clearly visible.
>
>
>
> Thanks,
>
> Karl
>
>
>
>
>
> *Från:*Pal Martinsen (palmarti) [mailto:[email-masked]]
> *Skickat:* den 2 december 2016 18:57
> *Till:* Karl Stahl; tram mailing list
> *Kopia:* Tirumaleswar Reddy (tireddy); Brandon Williams; Prashanth Patil
> (praspati); [email-masked]; Dan Wing; Spencer Dawkins at IETF
> *Ämne:* Re: [tram] draft-ietf-tram-turn-server-discovery
>
>
>
> Hi Karl (and tramsters),
>
>
>
> I am sympathetic to your arguments but they might have been lost
> somewhere in the email thread (A mix of quoting, repeating and inline
> commenting have at least made my email client somewhat confused.)
>
>
>
> The best thing you can do at this moment is to provide text. I suggest
> you write up a draft as a counter proposal and submit it. In that way
> the WG members can read through and comment.
>
>
>
>     *[tram] Milestone 3: TURN server auto-discovery mechanism for
>     enterprise and ISPs*
>
>     to result in: “We forbid usage of such (yellow) network provided
>     TURN servers (use gray or grayish TURN servers instead)”,  which is
>     the consequence of mandating (D)TLS.
>
>
>
>     Simply leave the consensus since version -7 of this draft by
>     removing the (D)TLS mandating for TURN servers provided by  the
>     local or access network thrown-in during the discuss.
>
>
>
>     /Karl
>
>
>
>     PS: I believe the attack discussion below is already done, and that
>     you are wrong in thinking that authentication which protects against
>     spoof attacks can be exchanged for encryption, and that any of these
>     things protects against DDOS attacks . These security things address
>     different things and are not interchangeable, nor are they universal
>     means against attacks of various kinds.
>
>
>
>     Please note (sorry to repeat)  that for the purpose of getting a
>     better path for real-time traffic than through the default gateway
>     path, we cannot expect to also get a higher security or trust level,
>     nor to resolve every problem in the world.
>
>
>
>
>
>     *Från:* Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
>     *Till:* Karl Stahl; 'Brandon Williams'; Prashanth Patil
>     (praspati); [email-masked] <mailto:[email-masked]>
>     *Kopia:* [email-masked] <mailto:[email-masked]>; 'Dan
>     Wing'; 'Spencer Dawkins at IETF'
>     Yes, I am discussing TURN servers provided by local or access
>     networks, referring to inside attacks launched by attackers inside
>     <[email-masked] <mailto:[email-masked]>>; 'Spencer Dawkins at
>     IETF' <[email-masked]
>     <mailto:[email-masked]>>
>     Are you discussing TURN servers provided by the local or access
>     network (the yellow TURN servers), that are released from
>     authentication (no dispute there), but for which (D)TLS mandate was
>     thrown in-during the discuss (making them gray)? That is the
>     showstopper that must go away.
>
>
>
>     *Från:* Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
>     *Till:* Karl Stahl; 'Brandon Williams'; Prashanth Patil
>     (praspati); [email-masked] <mailto:[email-masked]>
>     *Kopia:* [email-masked] <mailto:[email-masked]>; 'Dan
>     Wing'; 'Spencer Dawkins at IETF'
>     No, I don’t agree that (D)TLS is not mandatory. Opportunistic
>     encryption is not new. It’s discussed in RFC7435, and used in TCP
>     increased security (TCPINC WG) and DNS privacy exchange (DPRIVE WG).
>
>
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5766-23section-2D17.2.1&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=8m7Kq7XF7RXOJUURoHPp08xL_gPwEqvUKMZmhnZRYsA&s=iHw9pxq3PC-AIu_fbfWkcf9kklknr7GFVaB2rtdccnU&e=>,
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5766-23section-2D17.3.3&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=8m7Kq7XF7RXOJUURoHPp08xL_gPwEqvUKMZmhnZRYsA&s=2dDgXn_BcLJNa1sckXttm3c6HFMMqg3qYYFhy7EmsA0&e=>,
>     --- I don’t think (D)TLS helps if you can spoof and have such
>     attackers inside your network. (that paragraph says:  TURN prevents
>     this by requiring that the credentials used”) meaning authentication
>     (not certificate checking, nor encryption).
>
>
>
>
>
>     -Tiru
>
>
>
>     <[email-masked] <mailto:[email-masked]>>; 'Spencer Dawkins at
>     IETF' <[email-masked]
>     <mailto:[email-masked]>>
>     So we agree that the (D)TLS mandate thrown-in during the discuss
>     (making yellow TURN servers gray) shall go away and we are back to
>     what was consensus since version -7 of the draft. I think the
>     attacks you are discussing now have been listed already and for TURN
>     servers in a local or access network (no change since version -7),
>     we should not expect a higher security or trust level when sending
>     our real-time traffic through another path than the through default
>     gateway, both paths are provided by the same network provider.
>
>     * *
>
>     introducing something (why reopen that now?), we have to be careful
>     not to make yellow TURN servers grayish, which I am afraid self
>     signed certificates might do, and further, does this belong in a
>     discovery draft, risking to pick a fight with the WebRTC browser
>     makers supposed to use this specification. We know they don’t fancy
>     self signed certificates…
>
>
>
>
>     Isn’t it specifications for some specific usage/application (like
>     the return draft for WebRTC browsers) that should consider such
>     things (not this draft), without any recommendation from this
>     specification?
>
>
>
>     /Karl
>
>
>
>     *Från:* Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
>     *Till:* Karl Stahl; 'Brandon Williams'; Prashanth Patil
>     (praspati); [email-masked] <mailto:[email-masked]>
>     *Kopia:* [email-masked] <mailto:[email-masked]>; 'Dan
>     Wing'; 'Spencer Dawkins at IETF'
>     I am not suggesting that authentication is mandatory for TURN
>     servers provided by local or access networks using (D)TLS but use of
>     (D)TLS [Karl: “these become gray not yellow” or are you suggesting
>     [TR] No, they are yellow and not grey; clients will use (D)TLS but
>     do not validate the TURN server certificate (referred to as
>     Opportunistic security in the draft).
>
>
>
>     [Karl: Seems like you are suggesting self signed certificates to
>     just get the encryption (again – also discussed)]
>
>
>
>     [TR] Yes, that’s one possible option to mandate (D)TLS. Client
>     cannot validate the TURN server certificate but use encryption-only
>     (D)TLS and protects the client from various attacks discussed in
>     previous mails.
>
>
>
>     -Tiru
>
>
>
>     <[email-masked] <mailto:[email-masked]>>; 'Spencer Dawkins at
>     IETF' <[email-masked]
>     <mailto:[email-masked]>>
>     These things are not interchangeable or do the same things or
>     achieves the same, which has been discussed over and over again in
>     this draft already.
>
>
>
>     server path, than trough the default gateway path. You simply have
>     to trust the access from the network provider you select to connect
>     to, or refrain from using it.
>
>
>
>     In a specification which main purpose is to auto discover TURN
>     servers provided by the local or access network (“the yellow ones”),
>     you CANNOT LOGICALLY end up with saying you MUST/SHOULD or are
>     RECOMMENDED to use “the gray ones” instead, provided by some
>     authority or Brandon maybe (which are meant for other purposes).
>     Then you have not delivered the specification we need = The showstopper.
>
>
>
>     /Karl
>
>
>
>     PS: Some comments below.
>
>
>
>     *Från:* Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
>     *Till:* Karl Stahl; 'Brandon Williams'; Prashanth Patil
>     (praspati); [email-masked] <mailto:[email-masked]>
>     *Kopia:* [email-masked] <mailto:[email-masked]>; 'Dan
>     Wing'; 'Spencer Dawkins at IETF'
>     I am not suggesting that authentication is mandatory for TURN
>     servers provided by local or access networks using (D)TLS but use of
>     (D)TLS [Karl: “these become gray not yellow” or are you suggesting
>     certificated signed by the network provider] without authenticating
>     the TURN server is mandatory to avoid various attacks listed in
>     previous mails.
>
>
>
>     In short, the TURN servers provided by local or access networks must
>     use (D)TLS but it’s not mandatory for these TURN servers to get
>     certificates from CA or any explicit configuration is required on
>     the client to trust the TURN server. [Karl: Seems like you are
>     suggesting self signed certificates to just get the encryption
>     (again – also discussed)]
>
>
>
>     -Tiru
>
>
>
>     <[email-masked] <mailto:[email-masked]>>; 'Spencer Dawkins at
>     IETF' <[email-masked]
>     <mailto:[email-masked]>>
>     Trying to clarify as you request: I have lost track of in which
>     context you are when you are "discussing various attacks" and what
>     you mean with the ?? I marked below.
>
>
>
>     My concern was whether this may again lead to that WE
>     HAVE *_NO_* TURN SERVERS in the yellow area below resulting from the
>     (D)TLS mandating that was thrown-in into version -10 during the
>     discuss (=the showstopping), since
>

---

From: Brandon Williams <[email-masked]>
Date: Sat, 10 Dec 2016 12:18:18 -0500

Looks like the list was dropped off an earlier part of the thread. 
Resending with the list included. Apologies to those who are getting 
this a second time.

--

I'm not sure we're quite at consensus yet Karl, but I think we're close.

I agree that the text you quote from the doc covers the client side 
considerations, and that framing it as recommendations rather than 
requirements still makes sense. It's up to the client to decide which 
security elements are required for the application use case, and that 
text was intended to provide guidance without trying to force a security 
posture that is more complicated than the use case requires.

For the server side, in order to allow the client to fall back to 
(D)TLS, the TURN server MUST support (D)TLS at least for opportunistic 
privacy. This doesn't mean that the server has to require (D)TLS. It can 
still allow fallback to cleartext if the client so chooses.

So, I agree with you on reverting the MUST for the client, as long as we 
continue to strongly recommend (D)TLS as the fallback. If we do that 
though, I think we need to make it clear that a TURN server configured 
to allow sessions without STUN auth MUST support (D)TLS so that the 
client has the option of (D)TLS fallback.

I think we are agreeing to this change.

OLD:

"A TURN client MUST use (D)TLS in the absence of ..."

NEW:

"A TURN client SHOULD use (D)TLS in the absence of ..."

And I am proposing the addition of this paragraph at the end of the 
section 9, just before section 9.1.

"In order to allow the TURN client to select fallback to (D)TLS as 
described above, a TURN server that does not require either STUN long 
term authentication [RFC5389] or STUN Extension for Third Party 
Authorization [RFC7635] MUST support (D)TLS. Such a TURN server MAY also 
allow fallback to clear text."

--Brandon

On 12/05/2016 11:59 AM, Karl Stahl wrote:
> All I want to do in the (D)TLS discussion is to delete the sentence “A
> TURN client MUST use (D)TLS in the absence of STUN long-term credential
> mechanism [RFC5389] or STUN Extension for Third-Party Authorization
> [RFC7635].” under 9.  Security Considerationsthat was thrown-into
> version -10 during the discuss.
>
>
>
> **We leave all the rest regarding (D)TLS as it has been since version -7
> of this draft.**
>
>
>
>
>
> Brandon,
>
>
>
> I see there already are the (general) SHOULD or RECOMMEND that you
> wanted (I did not suggest to change those – they are there since version
> -7 I believe): “It is RECOMMENDED that the TURN client use one of the
> following techniques with (D)TLS to validate the TURN server:” and further…
>
>
>
>
>
> for Tiru, this is already in the draft since -7 and I am not suggesting
> to change that:
>
>
>
> “   An auto-discovered TURN server is considered to be only as trusted as
>
>    [RFC7435] where one does not require privacy but one desires privacy
>
>    when possible.
>
>
>
>    the-middle attacks and on-path packet injection.
>
> ”
>
>
>
>
>
> **Tiru – Below you are pointing at the -10 version changes that WE ARE
> discussing here.**
>
>
>
> Praspanth put them on the table again and I brought up that the
>
> Authorization [RFC7635].”
>
> must go away (leave the rest), since it effectively forbids TURN servers
> provided by the local and access network.
>
>
>
> Brandon had agreed that MUST should go away, when you jumped in with the
> attacks arguments, when we were discussing whether there should still be
> a SHOULD or RECOMMEND. – Then you got me (and others?) lost, and….
>
>
>
> So catch up from point (1) of my:
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02216.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=NtRZwrmn2K-WUI_QN5k_yHlAN-uzhoQU8bs2yA_RBP8&e=>
>
>
>
>
> And you may notice that in
>  https://mailarchive.ietf.org/arch/msg/tram/3svO9djFxeZyTtNsgqQf8zCTiVY
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_tram_3svO9djFxeZyTtNsgqQf8zCTiVY&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=SLjyswdn-oZ_aev0pRxD3h6c4aKbEQZ3c_kL9_ccHGM&e=>
> that you referred to
>
> “Making STUN authentication OPTIONAL”
>
> is ALREADY COMPENSATED for by “IP address authentication” (the
> foundation of today’s IP telephony authentication):
>
> “A TURN server in such cases must be configured to only process STUN
>
>    limits, ingress filtering etc.”
>
> where ”firewalls” specifically applies to TURN servers that local or
> access network providers allow only their own users to access.
>
>
>
> And Author’s: “Please refer
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D10-23section-2D9&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=b0fJ1ANqhE8C2BrlnGY3iWCwVEr2OhYyFlE__oOHtSE&e=>for
> more details.”
>
> already (since version -7 I think) in detail discusses the (D)TLS
> implications in this context (that you are redoing).
>
>
>
> Please, again, let us stay with the consensus since version -7 of this
> draft: No (D)TLS mandate.
>
>
>
> Thanks,
>
> Karl
>
>
>
> *Skickat:* den 4 december 2016 08:33
> *Till:* Pal Martinsen (palmarti); Karl Stahl; tram mailing list
> *Kopia:* Brandon Williams; Prashanth Patil (praspati);
> [email-masked] <mailto:[email-masked]>; Dan Wing; Spencer
> Dawkins at IETF
> Prashanth has already summarized the changes done to draft during ISEG
> review in
> https://mailarchive.ietf.org/arch/msg/tram/3svO9djFxeZyTtNsgqQf8zCTiVY
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_tram_3svO9djFxeZyTtNsgqQf8zCTiVY&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=SLjyswdn-oZ_aev0pRxD3h6c4aKbEQZ3c_kL9_ccHGM&e=>
>
>
>
>
> Request you, WG members, WG chairs and AD to share their thoughts on
> mandating the use of (D)TLS when STUN authentication is not used to
> handle the threats discussed in RFC5766.
>
>
>
> -Tiru
>
>
>
> *From:*Pal Martinsen (palmarti)
> *Sent:* Friday, December 2, 2016 11:27 PM
> *To:* Karl Stahl <[email-masked] <mailto:[email-masked]>>;
> tram mailing list <[email-masked] <mailto:[email-masked]>>
> *Cc:* Tirumaleswar Reddy (tireddy) <[email-masked]
> <mailto:[email-masked]>>; Brandon Williams
> <mailto:[email-masked]>; Dan Wing <[email-masked]
> <mailto:[email-masked]>>; Spencer Dawkins at IETF
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5766-23section-2D17.2.1&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=yTTYKgor2_ajHe7KP_4BznlG1EamuIy_K7ak0U40RbM&e=>,
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5766-23section-2D17.3.3&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=eH-u5a6yq0GxTqHFJMTssCJefcXLrMGLQdz-7MK_l7c&e=>,
>     discuss (=the showstopping), since TURN servers with
>     certificates are NOT provided by the local or access network (those
>     are provided by some "trust anchor store [RFC6024] allows a TURN
>     client ..." or by "Certification authorities that issue TURN server
>     certificates" etc..)
>
>
>
>
>
>
>     So, just let me rest with that your discussion does not take away
>     the allowance to use TURN servers provided by the local or access
>     network without authentication that was re-introduced in version -7
>     of the draft (after long discussions, including with you Tiru).
>     Remember, _those yellow TURN servers were the requirement of this
>     draft to auto discover_ so they can be used by the WebRTC browsers –
>     Usage cannot be forbidden (or un-recommended as Brandon suggests,
>     although Brandon is agreeing to that the (D)TLS mandate must vanish
>     for the yellow TURN servers).
>
>
>
>
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02216.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=NtRZwrmn2K-WUI_QN5k_yHlAN-uzhoQU8bs2yA_RBP8&e=>
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02226.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=EtiuiVt5Mnjbw9WsDtmjiu2l-dv1RoHVpdAlTXtgZIQ&e=>
>
>     while this discussion with Author Tiru and >“I don't run a local
>     network or an access network and would not expect to deploy relays
>     meant to function in that mode“ Brandon*, has been on more or less
>     deviated subjects, or repeating what we already have been through
>     earlier (PS: Notice that Author Prashanth already listed/discussed
>     the attack stuff during the discuss. I feared you were redoing that.)
>
>
>
>     /Karl
>
>
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02217.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=glxP3ovYX7Cd4f12zIILJhbTcEJ0ViqVgJQySQkJHYQ&e=>
>
>
>
>
>
>     Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil
>     Kopia: [email-masked] <mailto:[email-masked]>; 'Dan
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5766-23section-2D17.2.1&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=yTTYKgor2_ajHe7KP_4BznlG1EamuIy_K7ak0U40RbM&e=>,
>
>     > > <[email-masked] <mailto:[email-masked]>>; Prashanth
>     Patil (praspati)
>
>     > > >> Dawkins at IETF' <[email-masked]
>     <mailto:[email-masked]>>; Tirumaleswar
>
>     > > >> Reddy
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg01319.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=Osl0dTxisM85YhdJ__0idlmEuHZDO94zeETh0KuWOUg&e=>
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg01742.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=ovkKpAFtadl_tW-sGE9lKBidFiJ9DwAxrKyC-KgdC6w&e=>
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02191.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=6qTmzqnEW5fWRDNt6JT9RWtnkKecOUYG8OyPtBVY9Ek&e=>
>
>     > > >>>
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg01821.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=JJm49cE6V10iisqHp3jNeSnqE7wHzDtSrIhsQU8Sx3A&e=>
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02144.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=hti885FH0I_-3z7dolfYCAia4FX3i12sUCWsGesND6s&e=>
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02081.htm&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=f-GzOTsPm86NUqzFXyjAgPz6x-BiA-buLhIFPt9QfEg&e=> l
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2D&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=Sa3jwtA2TFtNAIAnfTem32vW9jIfcBlsUwxIBelblDs&e=>
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg00132.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=I4tX_vQd-ANV8cBjPGlHlFIVEUZ-3lYmVI6GbGtjxvc&e=>
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg00138.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=JJWVyPhhTbhTpkcOmQRdB49hx2gOMNKOL7qMT3bq630&e=>
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg01721.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=QnbJOsYAvuDWr9YyEGsxUOv8S1ha8ow9Do5VDOq6Gs0&e=>
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg01745.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=duED3YRw_gPiLwPnjC7zgW0KbQXqQBjN-BJC4bzmt44&e=>
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tram_current_msg02155.html&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=5fxjtRf2Ndt9R-RDwWpgG0d7mctpUT2lUZrKGaThZ40&e=>
>
>     > > >>>
>
>     > > >>> /Karl
>
>     > > >>>
>
>     > > >>>
>
>     > > >>> Kopia: [email-masked] <mailto:[email-masked]>; Dan Wing;
>     Spencer Dawkins at IETF;
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-2D1&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=--B-kAp9De1f6HhRKLEtD1bVS33BpG2S5MYzWBQ_YDI&e=>
>
>     > > >> 0#
>
>     > > >> section
>
>     > > >> -9 for more details.
>
>     > > >>>
>
>     > > >>> Thanks,
>
>     > > >>> Authors
>
>     > > >>>
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=ahRn1ifxnOACrVFgxJ99086nBuC6-cz9H7GKY_0EV8s&e=>
>
>     > > >>>
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=ahRn1ifxnOACrVFgxJ99086nBuC6-cz9H7GKY_0EV8s&e=>
>
>     > > >>>
>
>     > > >>
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=ahRn1ifxnOACrVFgxJ99086nBuC6-cz9H7GKY_0EV8s&e=>
>
>     > >
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=ahRn1ifxnOACrVFgxJ99086nBuC6-cz9H7GKY_0EV8s&e=>
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=ahRn1ifxnOACrVFgxJ99086nBuC6-cz9H7GKY_0EV8s&e=>
>
>
>

---

From: "Karl Stahl" <[email-masked]>
Date: Mon, 12 Dec 2016 13:44:12 +0100

Authors,

Before I answer any of Brandon’s 5 new entries, I hope Authors now are
synchronized so we can avoid more confusion, which cause became apparent
from Tiru’s:

> Skickat: den 4 december 2016 08:33
> Till: Pal Martinsen (palmarti); Karl Stahl; tram mailing list
> Kopia: Brandon Williams; Prashanth Patil (praspati); [email-masked];
Dan Wing; Spencer Dawkins at IETF

review in

> Request you, WG members, WG chairs and AD to share their thoughts on
mandating the use of (D)TLS when STUN authentication is not used to handle
the threats discussed in RFC5766. 

> -Tiru

pointing to where Prashanth November 2 put the (D)TLS mandate issue back to
the WG after the draft was rejected by the ISEG with such order.

Tiru must have jumped in (with things already done long before version -7 of
this draft and already existing in the version -7 text (which consensus was
broken by the (D)TLS mandate thrown in) and Tiru seems to have *missed the
reason why we are on this thread*; To catch up, please start at my November
12 entry (in response to the reference above): 

https://www.ietf.org/mail-archive/web/tram/current/msg02216.html ,

> 1) The downgrade of the MUST level requirement for authentication defined
in [RFC5766] was "rightly" (to use the term from below) introduced and made
OPTIONAL for TURN servers provided by the local or access network.

HOWEVER, Prashanth's: "I think we can mandate (D)TLS *if* STUN
authentication or third-party authorization is not used." thrown-in during
the DISCUSS, must be deleted from the -10 version of this discovery since it
BLOCKs the usage and deployment of network provided TURN servers, which was
the main purpose of this discovery draft. (Also, Authors's did not follow
Ben Campbell's: "I saw a comment on my DISCUSS email thread from Karl Stahl,
stating that DTLS could not be mandated. Has that input been considered?")

Now hopefully with Author’s aligned, I just want to summarize: 

1) The “version -7 consensus text” missed this text now added to version -10
under “9.  Security Considerations” (which is OK):  
“Making STUN authentication OPTIONAL is a downgrade of a MUST level

   requirement defined in [RFC5766 <https://tools.ietf.org/html/rfc5766> ].
The downgrade allows TURN servers

   intention, in such deployments, being to provide TURN services to all

   users in the local or access network.  However, this opens up a TURN

   server to a variety of attacks described in Section
<https://tools.ietf.org/html/rfc5766#section-17>  17 of [RFC5766].

” and this does not break the consensus since version -7.

2) This is a DISCOVERY draft. It may recommend/advice around USAGE of TURN
servers by TURN clients (which already is done in the “version -7 consensus
text”), but this draft must not mandate how to USE TURN servers. (E.g. it is
up the RETURN how WebRTC TURN servers MUST do). We should NOT MANDATE USAGE
in this DISCOVERY draft.

3) The various aspects of (D)TLS usage are already covered in the “9.
Security Considerations” in the “version -7 consensus text” and should not
be reconsidered/redone now. (PS: I will respond to one of Brandon’s email
here and make a suggestion – Await… )

Simply remove the ”A TURN client MUST use (D)TLS in the absence of STUN
long-term credential mechanism [RFC5389
<https://tools.ietf.org/html/rfc5389> ] or STUN Extension for Third-Party
Authorization [RFC7635 <https://tools.ietf.org/html/rfc7635> ]  thrown into
version -10 to clear the now discussed (D)TLS issue.
 
/Karl
 
PS Tiru, regarding the below:

> NEW…, a TURN client *MUST* use

No MUST about USAGE in this DISCOVERY draft – will break consensus of
version -7 text. Leave such USAGE MUSTs to draft handling usage, such as
RETURN draft for WebBrowser TURN Clients OR other for other TURN Clients.

Skickat: den 7 december 2016 05:17

Karl Wrote:  Also, you said you were NOT interested in mandating D(TLS) for
validation, which was the text thrown during  the discuss, and the only
thing I have suggested to be removed.

[Tiru] 

I can fix the following text to avoid the confusion that (D)TLS is mandatory
but validating the TURN server identity is not mandatory:

OLD: 

A TURN client MUST use (D)TLS in the absence of STUN long-term credential
mechanism [RFC5389] or STUN Extension for Third-Party Authorization
[RFC7635].

NEW: 

In the absence of STUN long-term credential mechanism [RFC5389] or STUN
Extension for Third-Party Authorization [RFC7635], a TURN client MUST use
(D)TLS and if (D)TLS authentication to validate the TURN server identity is
not possible then the TURN client MUST fallback to encryption-only (D)TLS.

-Tiru

Hi Tiru,

Author’s: “Please refer

   when possible.

   server:

/Karl

Hi Karl,

-Tiru 

Hi Tiru,

See previous:

/Karl

--- See previous

/Karl

-Tiru

Hi Tiru,

/Karl

 

Hi Karl,

-Tiru

Hi Tiru,

/Karl

Hi Karl,

firewall can now send a

 

-Tiru

Hi Tiru,

 

/Karl

-Tiru

Hi Tiru,

/Karl

PS: Some comments below.

Hi Karl,

-Tiru

Hi Tiru,

 

 

/Karl

 

-----Ursprungligt meddelande-----

Hi Karl,

-Tiru

[email-masked]

about the

the

whether

to

the

*provided

instructs

like the

(praspati)

you

long-term

itself."

as

9.3.

man-in-

STUN

---

From: "Karl Stahl" <[email-masked]>
Date: Mon, 12 Dec 2016 14:55:07 +0100

(Being hinted to add [email-masked] to my response, I hope this now propagates to the WG list - sorry if you got more than once.)
Hi Brandon,

In view of point 2) of previous email I have suggested a good way get your point in.
(Will enter into red-lined Word document, attached to NEXT email)

/Karl

-----Ursprungligt meddelande-----
Från: Brandon Williams [mailto:[email-masked]] 
Skickat: den 10 december 2016 17:43
Till: Karl Stahl; 'Tirumaleswar Reddy (tireddy)'; 'Pal Martinsen (palmarti)'
Kopia: 'Prashanth Patil (praspati)'; [email-masked]; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: Re: SV: [tram] Maybe we have (D)TLS consensus; WAS: draft-ietf-tram-turn-server-discovery

[Karl] Just want mention (for all to follow) that all this text has been in the draft since version -7

[Karl] Yes, of course - nothing new regarding this has been entered since version -7 of the draft

So, I agree with you on reverting the MUST for the client, as long as we 
continue to strongly recommend (D)TLS as the fallback. 

[Karl] That is where we are with the proposed text, yes.

If we do that 

[Karl] When that is the case, it HOWEVER CANNOT BE THIS DRAFT that imposes a "MUST support (D)TLS" - It should be done by a draft relying on TURN server usage from TURN servers discovered by this draft. E.g. the RETURN draft for WebRTC browsers may come to such MUST for their particular needs (based on recommendations here).

OLD:

NEW:

[Karl] We could instead put in this variant:
"In order to allow the TURN client to select fallback to encryption-only (D)TLS and clear text as described above, the TURN server has to support (D)TLS and clear text. TURN clients that does not use either STUN long term authentication [RFC5389] or STUN Extension for Third Party Authorization [RFC7635] for their particular application, should consider to require TURN servers with such support".

That means the same, but hopefully don't brake consensus of the -7 text now added to, by now and suddenly mandating USAGE from this DISCOVERY draft.

[Karl] I will put in this variant in my red-line Word document for review

--Brandon

---

From: "Karl Stahl" <[email-masked]>
Date: Mon, 12 Dec 2016 15:22:13 +0100

Hi Brandon,

Please see [Karl] comments below and feel free to review the blue highlighted additions to the attached Word or PDFs (for the Authors to cut and paste from).

/Karl

-----Ursprungligt meddelande-----
Från: Brandon Williams [mailto:[email-masked]] 
Skickat: den 10 december 2016 18:12
Till: Karl Stahl; 'Pal Martinsen (palmarti)'; 'tram mailing list'
Kopia: 'Tirumaleswar Reddy (tireddy)'; 'Prashanth Patil (praspati)'; [email-masked]; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: Re: SV: [tram] draft-ietf-tram-turn-server-discovery

Hi Karl,

However, I think we need agreement on the justification for such a 
change. 
[Karl] Justification is in the (A), (B), (C) and (D) of 
https://www.ietf.org/mail-archive/web/tram/current/msg02254.html 
where saying Binding instead Allocate, is necessary to achieve (A) and (B), and improves (C) and (D).

[Karl] And there you also find that only by saying Binding instead of Allocate you can fulfill the expectations of the WebRTC requirements RFC and the RETURN draft.

[Karl] Regarding: "proposed CHANGES to the anycast mechanism"... Since the Author's have not explained or responded to (during several versions of the draft) what kind of TURN server and how it should be installed/deployed for the texted mechanism to actually work with, I think we can regard my proposed text as defining a working anycast mechanism (rather than requesting a change).  

There are good reasons to prefer the mechanism as defined in the 
current -10 text, especially backward compatibility with existing 
RFC5389 TURN clients. There has to be a compelling argument to move away 
from backward compatibility.

[Karl] I have no intentions to cause any backward incompatibility and don't follow you seeing such risk. Searching in RFC5389 for anycast, I only find "STUN may be used with anycast addresses, but only with UDP and in usages where authentication is not used."
In this discovery draft, we use only one UPD anycast packet for the discovery (after DISCOVERY, the USAGE of the TURN server may be with any transport).

[Karl] If you think that we instead should ask IANA for an anycast address for "Session Traversal Utilities for NAT (STUN)" (To be used for STUN as well as for TURN server discovery.) instead of as here for "Traversal Using Relays around NAT Anycast", then my discovery procedure should be modified to as shown highlighted in blue in the attached Word and PDF documents. I leave it to and the Authors to select which Alternative may be preferred.
 
(This blue Alternative was actually the initial idea as described in the 22 October 2013 email you can find a bit down in:
https://www.ietf.org/mail-archive/web/tram/current/msg00132.html 
"Another idea came up; to use anycast to allow a WebRTC browser to find a network provided TURN server (both local on a LAN or provided by a carrier). (There are some discussion around using anycast in the STUN and TURN RFCs.) This anycast-way should work both for a TURN server on a LAN and a TURN server outside the NAT/Firewall (any router in the chain can take care of an anycast address) and by the simple method below, return the available TURN server closest to the client. Finding a TURN server close to the client (the WebRTC browser) will also minimize “the turn” the real-time traffic has to take.  

The suggestion is to define an anycast IP address for STUN servers and:

- The network provider, offering a TURN server on his access, adds a route in his access router (or NAT/Firewall) so that the anycast address routes to his TURN/STUN server (a TURN server is an extension of STUN server, thus included in the same box).

- The TURN/STUN server is configured to respond to a binding request with a “300 Try alternate server”, that points out the same TURN/STUN server (by its real IP address, not the anycast address).

The WebRTC browser client would then:

- Issue a STUN binding request to the anycast address

- Issue another STUN binding request to the ALTERNATE SERVER IP address in the “300 Try alternate” response (as any client should do). 

- Interpret the received “300 Try alternate” response now having the same ALTERNATE SERVER IP address as the source IP address of that response, as an indication to use its TURN server (not the STUN server) at that address. "
) [End Karl]

Regarding your proposed deployment considerations text, I don't think 
the mechanism for detecting whether the network is sealed is clearly 
enough defined for us to assess whether it actually works, let alone for 
someone to implement the mechanism. 
[Karl] I added in blue highlight to the attached documents:
(Blocking STUN/TURN packets at the (default) gateway, has the sealing effect that no STUN bindings or TURN allocates through that gateway can be made, whereby an alternative path has to be established for the media traffic. A missing STUN binding acknowledgment allows the TURN client to detect the sealing of that gateway.)

On a separate note, you appear to be 
describing transparent interception as an alternative discovery method; 
[Karl] I am describing how the TURN client should react (whether that is an error condition or not - it could actually be both).

I strongly disagree with injecting that element into the discussion at 
this stage.
[Karl] That is why I did NOT entered it as "as an alternative discovery method", but the TURN client behavior in such situation must be pointed out.

--Brandon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 13 Dec 2016 05:25:06 +0000

Hi Karl,

No. I have not missed any of the previous discussions, and the authors are in sync w.r.t both the updates to the draft and responses sent by me and Prashanth
to the WG.

-Tiru

Sent: Monday, December 12, 2016 6:14 PM

Authors,

Before I answer any of Brandon's 5 new entries, I hope Authors now are synchronized so we can avoid more confusion, which cause became apparent from Tiru's:
> Kopia: Brandon Williams; Prashanth Patil (praspati); [email-masked]<mailto:[email-masked]>; Dan Wing; Spencer Dawkins at IETF

> Karl's comment is to not mandate (D)TLS, and we don't agree with him.

> -Tiru
pointing to where Prashanth November 2 put the (D)TLS mandate issue back to the WG after the draft was rejected by the ISEG with such order.

Tiru must have jumped in (with things already done long before version -7 of this draft and already existing in the version -7 text (which consensus was broken by the (D)TLS mandate thrown in) and Tiru seems to have *missed the reason why we are on this thread*; To catch up, please start at my November 12 entry (in response to the reference above):
https://www.ietf.org/mail-archive/web/tram/current/msg02216.html ,

> 1) The downgrade of the MUST level requirement for authentication defined in [RFC5766] was "rightly" (to use the term from below) introduced and made OPTIONAL for TURN servers provided by the local or access network.

HOWEVER, Prashanth's: "I think we can mandate (D)TLS *if* STUN authentication or third-party authorization is not used." thrown-in during the DISCUSS, must be deleted from the -10 version of this discovery since it BLOCKs the usage and deployment of network provided TURN servers, which was the main purpose of this discovery draft. (Also, Authors's did not follow Ben Campbell's: "I saw a comment on my DISCUSS email thread from Karl Stahl, stating that DTLS could not be mandated. Has that input been considered?")

Now hopefully with Author's aligned, I just want to summarize:

1) The "version -7 consensus text" missed this text now added to version -10 under "9.  Security Considerations" (which is OK):

"Making STUN authentication OPTIONAL is a downgrade of a MUST level
   requirement defined in [RFC5766<https://tools.ietf.org/html/rfc5766>].  The downgrade allows TURN servers
   provided by local or access network to accept Allocation requests
   from new and/or guest users in the network who do not necessarily
   possess long term credentials for STUN authentication.  The
   intention, in such deployments, being to provide TURN services to all
   users in the local or access network.  However, this opens up a TURN
   server to a variety of attacks described in Section 17 of [RFC5766]<https://tools.ietf.org/html/rfc5766#section-17>.
   A TURN server in such cases must be configured to only process STUN
   requests from the trusted local network or subscribers of the access
   network.  Operational measures must be taken in order protect the
   TURN server; some of these measures include, but not limited to,
   access control by means of access-lists, firewalls, subscriber quota
   limits, ingress filtering etc.
" and this does not break the consensus since version -7.

2) This is a DISCOVERY draft. It may recommend/advice around USAGE of TURN servers by TURN clients (which already is done in the "version -7 consensus text"), but this draft must not mandate how to USE TURN servers. (E.g. it is up the RETURN how WebRTC TURN servers MUST do). We should NOT MANDATE USAGE in this DISCOVERY draft.

3) The various aspects of (D)TLS usage are already covered in the "9.  Security Considerations" in the "version -7 consensus text" and should not be reconsidered/redone now. (PS: I will respond to one of Brandon's email here and make a suggestion - Await... )

Simply remove the "A TURN client MUST use (D)TLS in the absence of STUN long-term credential mechanism [RFC5389<https://tools.ietf.org/html/rfc5389>] or STUN Extension for Third-Party Authorization [RFC7635<https://tools.ietf.org/html/rfc7635>]  thrown into version -10 to clear the now discussed (D)TLS issue.

/Karl

PS Tiru, regarding the below:
> NEW..., a TURN client *MUST* use

No MUST about USAGE in this DISCOVERY draft - will break consensus of version -7 text. Leave such USAGE MUSTs to draft handling usage, such as RETURN draft for WebBrowser TURN Clients OR other for other TURN Clients.

[Tiru]

OLD:

NEW:

-Tiru

Hi Tiru,

/Karl

Hi Karl,

-Tiru

Hi Tiru,

See previous:

/Karl

Hi Tiru,

/Karl

Hi Karl,

-Tiru

Hi Tiru,

/Karl

Hi Karl,

-Tiru

Hi Tiru,

/Karl

-Tiru

Hi Tiru,

/Karl

PS: Some comments below.

Hi Karl,

-Tiru

Hi Tiru,

/Karl

-----Ursprungligt meddelande-----
Från: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Skickat: den 18 november 2016 04:00
Till: Karl Stahl; 'Brandon Williams'; Prashanth Patil (praspati); [email-masked]<mailto:[email-masked]>
Kopia: [email-masked]<mailto:[email-masked]>; 'Dan Wing'; 'Spencer Dawkins at IETF'
Ämne: RE: [tram] draft-ietf-tram-turn-server-discovery

Hi Karl,

-Tiru

---

From: Brandon Williams <[email-masked]>
Date: Thu, 15 Dec 2016 06:04:00 -0500

Hi Karl,

I am not responding to all of your comments, because I would prefer to 
see more engagement in the discussion from the rest of the list. I am 
simply going to make two clarifications to my earlier points.

 > where saying Binding instead Allocate, is necessary to achieve (A) 
and (B), and improves (C) and (D).

It is true that you have provided a justification for the change. My 
point is that the small set of people who have engaged in list 
discussion do not appear to agree with your justification.

 > [Karl] I have no intentions to cause any backward incompatibility and 
don't follow you seeing such risk. Searching in RFC5389 for anycast, I 
only find "STUN may be used with anycast addresses, but only with UDP 
and in usages where authentication is not used."
 > In this discovery draft, we use only one UPD anycast packet for the 
discovery (after DISCOVERY, the USAGE of the TURN server may be with any 
transport).

My point is that an RFC5389 client is unlikely to support Try Alternate 
errors for STUN Binding requests, because the RFC5389 says that a STUN 
server SHOULD NOT send Try Alternate errors for Binding requests. On the 
other hand, an RFC5766 client is likely to support Try Alternate error 
responses as defined in the -10 draft without changes as long as STUN 
auth is in use for the session. It will have trouble with sessions that 
do not use STUN auth, but a server supporting the discovery draft that 
desires backward compatibility with RFC5766 clients can require STUN auth.

--Brandon

> That is at least a start.
c>

---

From: Brandon Williams <[email-masked]>
Date: Thu, 15 Dec 2016 06:13:58 -0500

Hi Karl,

I will not respond to all of your comments here, just to one new point 
that you made in this e-mail that I disagree with.

 > [Karl] When that is the case, it HOWEVER CANNOT BE THIS DRAFT that 
imposes a "MUST support (D)TLS" - It should be done by a draft relying 
on TURN server usage from TURN servers discovered by this draft. E.g. 
the RETURN draft for WebRTC browsers may come to such MUST for their 
particular needs (based on recommendations here).

I disagree with the point you are making here. This draft is already 
changing TURN server usage by allowing TURN without STUN auth. I think 
it is important for this draft to describe that change in detail, and 
what I have proposed is not a significant change in focus from existing 
text in the document.

For this reason, I do not consider your proposed variant a suitable 
replacement for the requirement that I suggested. However, I would like 
to hear opinions from other people on the list about the two proposals 
and the question of whether or not it is reasonable to call out such a 
requirement in this document.

--Brandon

---

From: Brandon Williams <[email-masked]>
Date: Tue, 27 Dec 2016 14:43:51 -0500

The original I responded to didn't have the tram list CCed. Apologies to 
those who receive duplicates.

--

Hi Tiru,

Sorry about the delayed response.

I understand that the requirements you propose are to protect the 
client. My point is that the client might not require such protection in 
all cases and it should be up to the client to make that determination. 
For example, if both the client and the server are on my home network, I 
don't really need the protection that (D)TLS provides. The server must 
support whatever security posture the client requires, but the server 
should not require the client to protect itself in a particular way.

This is the foundation for my proposed edits.

--Brandon

On 12/13/2016 12:14 AM, Tirumaleswar Reddy (tireddy) wrote:
> Hi Brandon,
>
> Thanks for the feedback. Please see inline
>
>> From: Brandon Williams [mailto:[email-masked]]
>> Sent: Saturday, December 10, 2016 10:13 PM
>> To: Karl Stahl <[email-masked]>; Tirumaleswar Reddy (tireddy)
>> <[email-masked]>; Pal Martinsen (palmarti) <[email-masked]>
>> Subject: Re: SV: [tram] Maybe we have (D)TLS consensus; WAS: draft-ietf-
>> tram-turn-server-discovery
>>
> The requirements are to protect the client from various attacks.
>
>>
> [1] I agree with the above text except for the last line in the above paragraph. If the TURN server allows fallback to clear text then the attacker can subject the TURN client to various attacks. For example, attacker sends faked permissions to the TURN server to launch attack (DOS or DDOS) on the TURN client and it nullifies the security benefits offered by CreatePermission. The victim in this mode is the TURN client and not the TURN server, and hence it is more important for the client to use (D)TLS to protect itself from attacks.
>
> When there is a possibility that in clear text mode the TURN clients can be subjected to various attacks, why would an TURN server administrator want to allow fallback to clear text  ?
>
> [2] And what problems do you see with the following new proposed text ?
> "In the absence of STUN long-term credential mechanism [RFC5389] or STUN Extension for Third-Party Authorization [RFC7635], a TURN client MUST use (D)TLS and if (D)TLS authentication to validate the TURN server identity is not possible then the TURN client MUST fallback to encryption-only (D)TLS."
>
> -Tiru
>
>>
>> --Brandon
>>
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-
>> 2Darchive_web_tram_current_msg02216.html&d=DgMFaQ&c=96ZbZZcaMF4
>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=NtRZwrmn2K-
>> WUI_QN5k_yHlAN-uzhoQU8bs2yA_RBP8&e=>
>>>
>>>
>>>
>>>
>>> <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__mailarchive.ietf.org_arch_msg_tram_3svO9djFxeZyTtNsgqQf8zCTiVY&d=
>> DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=SLjyswdn-
>> oZ_aev0pRxD3h6c4aKbEQZ3c_kL9_ccHGM&e=>
>>> that you referred to
>>>
>>> <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__tools.ietf.org_html_draft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-
>> 2D10-23section-2D9&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
>> nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=b0fJ1ANqhE8C2BrlnGY3iW
>> CwVEr2OhYyFlE__oOHtSE&e=>for
>>> more details.”
>>>
>>> <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__mailarchive.ietf.org_arch_msg_tram_3svO9djFxeZyTtNsgqQf8zCTiVY&d=
>> DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=SLjyswdn-
>> oZ_aev0pRxD3h6c4aKbEQZ3c_kL9_ccHGM&e=>
>>>
>>>
>>>
>>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__tools.ietf.org_html_rfc5766-23section-
>> 2D17.2.1&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
>> nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=yTTYKgor2_ajHe7KP_4Bznl
>> G1EamuIy_K7ak0U40RbM&e=>,
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__tools.ietf.org_html_rfc5766-23section-
>> 2D17.3.3&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
>> nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=eH-
>> u5a6yq0GxTqHFJMTssCJefcXLrMGLQdz-7MK_l7c&e=>,
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__www.ietf.org_mail-
>> 2Darchive_web_tram_current_msg02216.html&d=DgMFaQ&c=96ZbZZcaMF4
>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=NtRZwrmn2K-
>> WUI_QN5k_yHlAN-uzhoQU8bs2yA_RBP8&e=>
>>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__www.ietf.org_mail-
>> 2Darchive_web_tram_current_msg02226.html&d=DgMFaQ&c=96ZbZZcaMF4
>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=EtiuiVt5Mnjbw9WsDtmjiu2l
>> -dv1RoHVpdAlTXtgZIQ&e=>
>>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__www.ietf.org_mail-
>> 2Darchive_web_tram_current_msg02217.html&d=DgMFaQ&c=96ZbZZcaMF4
>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=glxP3ovYX7Cd4f12zIILJhbTc
>> EJ0ViqVgJQySQkJHYQ&e=>
>>>
>>>
>>>
>>>
>>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__tools.ietf.org_html_rfc5766-23section-
>> 2D17.2.1&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
>> nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=yTTYKgor2_ajHe7KP_4Bznl
>> G1EamuIy_K7ak0U40RbM&e=>,
>>>
>> <mailto:[email-masked]>>; Karl Stahl
>>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__www.ietf.org_mail-
>> 2Darchive_web_tram_current_msg01319.html&d=DgMFaQ&c=96ZbZZcaMF4
>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=Osl0dTxisM85YhdJ__0idlm
>> EuHZDO94zeETh0KuWOUg&e=>
>>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__www.ietf.org_mail-
>> 2Darchive_web_tram_current_msg01742.html&d=DgMFaQ&c=96ZbZZcaMF4
>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=ovkKpAFtadl_tW-
>> sGE9lKBidFiJ9DwAxrKyC-KgdC6w&e=>
>>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__www.ietf.org_mail-
>> 2Darchive_web_tram_current_msg02191.html&d=DgMFaQ&c=96ZbZZcaMF4
>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=6qTmzqnEW5fWRDNt6JT9R
>> WtnkKecOUYG8OyPtBVY9Ek&e=>
>>>
>>>     > > >>>
>>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__www.ietf.org_mail-
>> 2Darchive_web_tram_current_msg01821.html&d=DgMFaQ&c=96ZbZZcaMF4
>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=JJm49cE6V10iisqHp3jNeSn
>> qE7wHzDtSrIhsQU8Sx3A&e=>
>>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__www.ietf.org_mail-
>> 2Darchive_web_tram_current_msg02144.html&d=DgMFaQ&c=96ZbZZcaMF4
>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=hti885FH0I_-
>> 3z7dolfYCAia4FX3i12sUCWsGesND6s&e=>
>>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__www.ietf.org_mail-
>> 2Darchive_web_tram_current_msg02081.htm&d=DgMFaQ&c=96ZbZZcaMF4w
>> 0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=f-
>> GzOTsPm86NUqzFXyjAgPz6x-BiA-buLhIFPt9QfEg&e=> l
>>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__www.ietf.org_mail-
>> 2D&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=Sa3jwtA2TFtNAIAnfTem32v
>> W9jIfcBlsUwxIBelblDs&e=>
>>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__www.ietf.org_mail-
>> 2Darchive_web_tram_current_msg00132.html&d=DgMFaQ&c=96ZbZZcaMF4
>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=I4tX_vQd-
>> ANV8cBjPGlHlFIVEUZ-3lYmVI6GbGtjxvc&e=>
>>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__www.ietf.org_mail-
>> 2Darchive_web_tram_current_msg00138.html&d=DgMFaQ&c=96ZbZZcaMF4
>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=JJWVyPhhTbhTpkcOmQRdB
>> 49hx2gOMNKOL7qMT3bq630&e=>
>>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__www.ietf.org_mail-
>> 2Darchive_web_tram_current_msg01721.html&d=DgMFaQ&c=96ZbZZcaMF4
>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=QnbJOsYAvuDWr9YyEGsxU
>> Ov8S1ha8ow9Do5VDOq6Gs0&e=>
>>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__www.ietf.org_mail-
>> 2Darchive_web_tram_current_msg01745.html&d=DgMFaQ&c=96ZbZZcaMF4
>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=duED3YRw_gPiLwPnjC7zgW
>> 0KbQXqQBjN-BJC4bzmt44&e=>
>>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__www.ietf.org_mail-
>> 2Darchive_web_tram_current_msg02155.html&d=DgMFaQ&c=96ZbZZcaMF4
>> w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-
>> NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=5fxjtRf2Ndt9R-
>> RDwWpgG0d7mctpUT2lUZrKGaThZ40&e=>
>>>
>>>     > > >>>
>>>
>>>     > > >>> /Karl
>>>
>>>     > > >>>
>>>
>>>     > > >>>
>>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__tools.ietf.org_html_draft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddiscovery-
>> 2D1&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-
>> nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=--B-
>> kAp9De1f6HhRKLEtD1bVS33BpG2S5MYzWBQ_YDI&e=>
>>>
>>>     > > >> 0#
>>>
>>>     > > >> section
>>>
>>>     > > >> -9 for more details.
>>>
>>>     > > >>>
>>>
>>>     > > >>> Thanks,
>>>
>>>     > > >>> Authors
>>>
>>>     > > >>>
>>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__www.ietf.org_mailman_listinfo_tram&d=DgMFaQ&c=96ZbZZcaMF4w0F4j
>> pN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=ahRn1ifxnOACrVFgxJ99086
>> nBuC6-cz9H7GKY_0EV8s&e=>
>>>
>>>     > > >>>
>>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__www.ietf.org_mailman_listinfo_tram&d=DgMFaQ&c=96ZbZZcaMF4w0F4j
>> pN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=ahRn1ifxnOACrVFgxJ99086
>> nBuC6-cz9H7GKY_0EV8s&e=>
>>>
>>>     > > >>>
>>>
>>>     > > >>
>>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__www.ietf.org_mailman_listinfo_tram&d=DgMFaQ&c=96ZbZZcaMF4w0F4j
>> pN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=ahRn1ifxnOACrVFgxJ99086
>> nBuC6-cz9H7GKY_0EV8s&e=>
>>>
>>>     > >
>>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__www.ietf.org_mailman_listinfo_tram&d=DgMFaQ&c=96ZbZZcaMF4w0F4j
>> pN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=ahRn1ifxnOACrVFgxJ99086
>> nBuC6-cz9H7GKY_0EV8s&e=>
>>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__www.ietf.org_mailman_listinfo_tram&d=DgMFaQ&c=96ZbZZcaMF4w0F4j
>> pN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=LXaH-
>> MVQi2lVbE_s4ulx4hnhEomXhQK7xQEikzAupR8&s=ahRn1ifxnOACrVFgxJ99086
>> nBuC6-cz9H7GKY_0EV8s&e=>
>>>
>>>
>>>
>>
>> --