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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 24 Mar 2014 12:27:03 +0000

> -----Original Message-----
> From: Brandon Williams [mailto:[email-masked]]
> Sent: Saturday, March 22, 2014 1:54 AM
> To: Tirumaleswar Reddy (tireddy); Simon Perreault; Prashanth Patil (praspati);
> [email-masked]
> Subject: Re: [tram] TURN server discovery (please discuss!)
> 
> Since it's a service being provided by the network provider, the provider could
> easily apply a policy-based solution to the problem you describe (e.g. rate-
> limiting allocation requests). 

Yes, that will probably solve the problem. But how would the Mobile Node (MN) trust the TURN server provided by the network when let's say MN is using Coffee shop WIFI ?
It could be a malicious TURN server provided to monitor the user activity. If certificate validation is not possible then it becomes opportunistic encryption. Further with this restriction, the network provided TURN server may not be able to offer Mobility unlike the application provided TURN server.

-Tiru

> Are there other specific operations where you think
> lack of authentication could be a problem to which it's not possible to apply a
> policy-enforcement solution ?
> 
> --Brandon
> 
> On 03/21/2014 12:51 PM, Tirumaleswar Reddy (tireddy) wrote:
> >> -----Original Message-----
> >> From: Simon Perreault [mailto:[email-masked]]
> >> Sent: Friday, March 21, 2014 9:41 PM
> >> To: Tirumaleswar Reddy (tireddy); Brandon Williams; Prashanth Patil
> >> (praspati); [email-masked]
> >> 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
> 
> --
> Brandon Williams; Senior Principal Software Engineer Emerging Products
> Engineering; Akamai Technologies Inc.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 24 Mar 2014 08:56:26 -0400

> It could be a malicious TURN server provided to monitor the user activity. If certificate validation is not possible then it becomes opportunistic encryption. Further with this restriction, the net…

Do you trust the default gateway that is provided to you by DHCP when
you log on a coffee shop wi-fi? No, you don't. But you still use it. And
maybe you don't even consider this problematic. IMHO, if we dig deep
enough we'll find that this problem is basically unfixable. There will
always be an untrustworthy infrastructure layer on top of which
trustworthy applications are built.

I think what we need to do is:

0. Consider any network-provided TURN server as untrustworthy. This is
an axiomatic position.

1. Devise a mechanism allowing this piece of untrustworthy
infrastructure to be discovered.

2. Show how trustworthy applications can be built on top of this. (i.e.,
by encrypting media streams using SRTP, DTLS, etc.)

The untrustworthy TURN server will be able to know the 5-tuples between
the client and the peer. An untrustworthy IP router would equally be
able to do it. But with appropriate encryption, it won't be able to
discover anything more. So this would not introduce any new attack
vector IMHO.

Simon

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 24 Mar 2014 14:53:18 +0000

Hi Simon,

Please see inline

> Sent: Monday, March 24, 2014 6:26 PM
> To: Tirumaleswar Reddy (tireddy); Brandon Williams; Prashanth Patil (praspati);
> [email-masked]
> > Yes, that will probably solve the problem. But how would the Mobile Node
> (MN) trust the TURN server provided by the network when let's say MN is using
> Coffee shop WIFI ?
> > It could be a malicious TURN server provided to monitor the user activity. If
> certificate validation is not possible then it becomes opportunistic encryption.
> Further with this restriction, the network provided TURN server may not be able
> to offer Mobility unlike the application provided TURN server.
> 
> Do you trust the default gateway that is provided to you by DHCP when you log
> on a coffee shop wi-fi? No, you don't. But you still use it. And maybe you don't
> even consider this problematic. IMHO, if we dig deep enough we'll find that this
> problem is basically unfixable. There will always be an untrustworthy
> infrastructure layer on top of which trustworthy applications are built.
> 
> 0. Consider any network-provided TURN server as untrustworthy. This is an
> axiomatic position.
> 
> 1. Devise a mechanism allowing this piece of untrustworthy infrastructure to be
> discovered.
> 
> 2. Show how trustworthy applications can be built on top of this. (i.e., by
> encrypting media streams using SRTP, DTLS, etc.)
> 
> The untrustworthy TURN server will be able to know the 5-tuples between the
> client and the peer. 

TURN is useful to provide privacy just like TOR. Using TOR ensures that even if the traffic is subjected to pervasive monitoring, attacker cannot find out the remote server with which the user is communicating. TURN can also be used to solve the same problem. If attacker can act as TURN server then this benefit of providing privacy will be lost.

-Tiru

> An untrustworthy IP router would equally be able to do it.
> But with appropriate encryption, it won't be able to discover anything more. So
> this would not introduce any new attack vector IMHO.
> 
> Simon
> --

---

From: Brandon Williams <[email-masked]>
Date: Mon, 24 Mar 2014 12:40:33 -0400

Hi Tiru,

I'm not sure that it would be reasonable to expect the degree of privacy 
that you are describing from an auto-discovered TURN server. Even with 
certs to authenticate the TURN server, you are still trusting the random 
coffee shop's network provider.

I think that Simon's axiom is entirely correct in this context ... don't 
trust the network provided server, and thus don't rely on it for 
privacy. As long as the TURN client allows the user to select an 
appropriate security policy, I think it's OK.

--Brandon

On 03/24/2014 10:53 AM, Tirumaleswar Reddy (tireddy) wrote:
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: "Karl Stahl" <[email-masked]>
Date: Mon, 31 Mar 2014 08:50:55 +0200

I also agree with Simon's 0, 1, 2 even though I tend to call the
"untrustworthy" turn server trusted... (because we use it, just like we use
the IP address and default gateway we get).

Security/privacy comes in step 2, not in the discovery.

/Karl

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

Hi Tiru,

I'm not sure that it would be reasonable to expect the degree of privacy
that you are describing from an auto-discovered TURN server. Even with certs
to authenticate the TURN server, you are still trusting the random coffee
shop's network provider.

I think that Simon's axiom is entirely correct in this context ... don't
trust the network provided server, and thus don't rely on it for privacy. As
long as the TURN client allows the user to select an appropriate security
policy, I think it's OK.

--Brandon

On 03/24/2014 10:53 AM, Tirumaleswar Reddy (tireddy) wrote:
>> (MN) trust the TURN server provided by the network when let's say MN 
>> is using Coffee shop WIFI ?
>> Further with this restriction, the network provided TURN server may 
>> not be able to offer Mobility unlike the application provided TURN
server.
>> you log on a coffee shop wi-fi? No, you don't. But you still use it. 
>> And maybe you don't even consider this problematic. IMHO, if we dig 
>> deep enough we'll find that this problem is basically unfixable. 
>> There will always be an untrustworthy infrastructure layer on top of
which trustworthy applications are built.
>> 0. Consider any network-provided TURN server as untrustworthy. This 
>> is an axiomatic position.
>>
>> 2. Show how trustworthy applications can be built on top of this. 
>> (i.e., by encrypting media streams using SRTP, DTLS, etc.)
>>
>> The untrustworthy TURN server will be able to know the 5-tuples 
>> between the client and the peer.
>
> TURN is useful to provide privacy just like TOR. Using TOR ensures that
even if the traffic is subjected to pervasive monitoring, attacker cannot
find out the remote server with which the user is communicating. TURN can
also be used to solve the same problem. If attacker can act as TURN server
then this benefit of providing privacy will be lost.
>> But with appropriate encryption, it won't be able to discover 
>> anything more. So this would not introduce any new attack vector IMHO.
>>
>> Simon
>> --