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

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

I read the turn server discovery draft more thoroughly now and think it does
the job well, with the following remarks:

A) The problem 2) below (With the anycast method, can we know that it really
is our trusted enterprise or ISP providing the TURN server, i.e. is it
close?). You have the solution (actually same as the "network-way idea" I
mentioned below) in 8.2 already (although spelled out for other reasons):
"Sensitive clients that do not wish to leak information about their presence
can set an IP TTL on their TURN requests that limits how far they can travel
into the public Internet."

I suggest that this TTL limitation with the anycast method is specified
(e.g. Don't look further than 3 steps - local firewall + max 2 ISP routers)
and brought into section 3. Discovery Procedure, step 3 of the draft.

B) Shall we have more than one method (see 3 and 4 below)? If the Anycast
method can be used by everyone, why then also have DHCP?

I have heard more fears that DHCP options are not available in common OSs.
If so, the DHCP method should be skipped. If a service provider deploys DHCP
discovered TURN servers, but some webrtc browser don't find/can use them, it
would just be bad.

C) I saw Patil's advertised change to the Anycast method
http://www.ietf.org/mail-archive/web/tram/current/msg00433.html and agree it
is better:
"The response to an anycast request will be a 300 (try alternate) response.
The response will contain the unicast address in the ALTERNATE_SERVER
attribute. This has been discussed (in another context), and will be
included in the next revision."

/Karl

-----Ursprungligt meddelande-----
Från: Karl Stahl [mailto:[e-mail]]
Skickat: den 21 mars 2014 21:03
Till: 'Tirumaleswar Reddy (tireddy)'; 'Simon Perreault'; 'Brandon Williams';
'Prashanth Patil (praspati)'; '[e-mail]'
Ämne: SV: [tram] TURN server discovery (please discuss!)

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