Re: [tram] TURN server discovery (please discuss!)

["Karl Stahl" <[e-mail]>]

1) I want to emphasize Simon's view in the authentication discussion:
" If the TURN server is provided by the network, couldn't we assume that
authentication is network-based? That is, if you succeed in talking to the
server, then that means you're good. TURN servers would effectively have "no
authentication" in the protocol."

The need for this milestone mechanism/RFC is for an enterprise or a an ISP
to announce a TURN server for their users of their network. The DHCP method
directly reflects this by responding:
"Here are your IP address, your default gateway, your DNS servers and now
the suggested TURN server to use". (The TURN deployed is a networks resource
only available on the local connection - it only has the allocated public
port available to the WAN-side. That is TURN server/router/firewall
combination more or less integrated.) 

So the auto discovered turn-server should only be available and offered to
those allowed to use it - rather than being authenticated (like an
application provided TURN server is). The browser should use the auto
discovered TURN server without authentication.


2) The opposite - Can the browser trust the TURN server offered (also raised
here)? - is not a problem with the DHCP method (If we get network resources
like our IP address, default gateway via DHCP, we should of course also
trust and the same DHCP server with giving us the TURN server address to
place our real-time traffic at.)

However, that may not be the case with the AnyCast method. Simon previously
raised:
"> Suppose we define well-known anycast TURN server addresses. How would 
> this not be subject to the same service quality issues that plagued 
> 6to4? That is, anyone could set up a badly-maintained, 
> under-provisioned TURN server and announce it over BGP to the world, 
> as it was done for
> 6to4 relays. Or just bad BGP outbound filter configuration. And how 
> can we prevent triangle routing? There is nothing guaranteeing that 
> the anycast server you see is being provided to you by your ISP, 
> rather than a server sitting on the other side of the planet

I got an "network-way idea" to address this from a developer of ours that I
have not considered/presented yet and I will also read up on draft
draft-patil-tram-turn-serv-disc-00, and see it I have some educated thoughts
to contribute. It would be good if we can avoid having to introduce
certificates or similar here and just stick to the network level.

A few other points (maybe a better read of
draft-patil-tram-turn-serv-disc-00 obsoletes some of these points and I will
know better on Monday, but anyway):


3) Two methods (DHCP and Anycast) are suggested in the draft. I assume the
thought is that browsers must implement both and the ISP can use any.
Correct? 
- But if one is good enough, shall we then drop the other to make life
easier? 


4) In addition to some doubts raised here against the DHCP discovery, there
were plenty in the discussion at the September-October discussion at the
[rtcweb]-list (summary in
http://www.ietf.org/mail-archive/web/tram/current/msg00132.html), mainly: 

a: concerns whether OSs actually forwards such extended DHCP information for
the browser to use
- If I remember correctly, only Bernard Aboba from MS confirmed that is was
available in Windows.

b: I withdrew my own(!) suggestion to use DHCP to find a network provider
offered TURN server because DHCP is NOT used in many networks, which instead
use (for handing out IP address etc): RA - Router Advertisement - in IPv6,
the IPCP protocol for PPPoE and something else for the mobile OTT channel.


I tend to focus on the Anycast method only (but will read up on
draft-patil-tram-turn-serv-disc-00 until Monday and may be more educated
then...)

/Karl   


-----Ursprungligt meddelande-----
Från: tram [mailto:[e-mail]] För Tirumaleswar Reddy (tireddy)
Skickat: den 21 mars 2014 17:51
Till: Simon Perreault; Brandon Williams; Prashanth Patil (praspati);
[e-mail]
Ämne: Re: [tram] TURN server discovery (please discuss!)

> -----Original Message-----
> From: Simon Perreault [mailto:[e-mail]]
> Sent: Friday, March 21, 2014 9:41 PM
> To: Tirumaleswar Reddy (tireddy); Brandon Williams; Prashanth Patil 
> (praspati); [e-mail]
> Subject: Re: [tram] TURN server discovery (please discuss!)
> 
> Le 2014-03-21 12:07, Tirumaleswar Reddy (tireddy) a écrit :
> >> I think that some type of authentication is necessary, even if all 
> >> it provides is the ability to verify that the two ends of the 
> >> tunnel remain consistent throughout the life of the allocation. 
> >> Without at least that, then the service is open to DOS attacks via
message injection.
> >
> > Agreed, some type of authentication is necessary.
> 
> That's not what I would call authentication. [D]TLS without 
> authentication protects against message injection AFAIK.

DTLS without authentication won't protect the TURN server from clients
sending huge number of Allocate requests and taking up all the resources in
the TURN server. 
I think both D{TLS} and authentication is required.

-Tiru

> 
> Simon
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca

_______________________________________________
tram mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tram