Subject: [tram] TURN permissions for private ips (was: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT))

From: Philipp Hancke <[email-masked]>
Date: Wed, 05 Aug 2015 10:46:49 -0700

Am 05.08.2015 um 10:06 schrieb Stephen Farrell:
[...]
> Part of my question
> then is why exposing that additional meta-data to a server
> that most users won't know exists, and that is likely
> controlled by some entity the user has no clue is even
> involved in their calls, is acceptable.

There is an issue with TURN here, but it's not related to the consent 
freshness draft.

If a peer sends candidates with IP addresses from the private space, 
permissions for those are created at the TURN server. Potentially not 
utilising transport encryption even.

I doubt those candidates ever work, so from a privacy point of view it 
seems that clients should not create those permissions in the first 
place. And ICE should probably not try to create pairs.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 05 Aug 2015 14:32:40 -0400

> place. And ICE should probably not try to create pairs.

It's not up to the client to determine what addresses might not might
not work for a given TURN server. There are lots of weird NAT
configurations out there that play games with RFC1918 addresses and can
easily trick clients into doing the wrong thing.

Instead, the server should be the one doing that check because it only
has access to reliable information. It should use the existing mechanism
and return 403 Forbidden for addresses it doesn't like. See RFC 5766
section "9.2. Receiving a CreatePermission Request":

   The server MAY impose restrictions on the IP address allowed in the
   XOR-PEER-ADDRESS attribute -- if a value is not allowed, the server
   rejects the request with a 403 (Forbidden) error.

Simon

---

From: Justin Uberti <[email-masked]>
Date: Wed, 5 Aug 2015 14:35:52 -0700

> easily trick clients into doing the wrong thing.

I am somewhat sympathetic to that, but given that there is measurable
downside here - extra candidate pairs that take time to check - can you
supply a concrete example of where the client choosing not to pair a TURN
candidate with a RFC1918 address would cause a problem?

---

From: Simon Perreault <[email-masked]>
Date: Wed, 05 Aug 2015 18:01:08 -0400

Le 2015-08-05 17:35, Justin Uberti a écrit :
> supply a concrete example of where the client choosing not to pair a
> TURN candidate with a RFC1918 address would cause a problem?

I can't!

Philipp's proposal certainly does make practical sense when you consider
it as an ugly optimization hack rather than something that is necessary
to make things work. Phrase it so that this is clear and I'll be all for
it. :)

Simon

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 05 Aug 2015 15:19:49 -0700

> to make things work. Phrase it so that this is clear and I'll be all for

incidentally, that's how I came up with it a while back:
https://code.google.com/p/webrtc/issues/detail?id=4634
:-)

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Thu, 6 Aug 2015 11:58:28 +0200

On 05/08/15 23:35, Justin Uberti wrote:
>
>
> On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault <[email-masked] <mailto:[email-masked]>> wrote:
>
> I am somewhat sympathetic to that, but given that there is measurable downside here - extra candidate pairs that take time to check - can you supply a concrete
> example of where the client choosing not to pair a TURN candidate with a RFC1918 address would cause a problem?
>

adding a TURN Permission to a private IP-address does not make sense.

in some code I have this pseudo C-code:

	if (!ipv4_address_is_private(addr)) {

		turnc_add_perm(turnc, addr);
	}

/alfred

---

From: Emil Ivov <[email-masked]>
Date: Thu, 6 Aug 2015 06:35:56 -0700

On Wednesday, August 5, 2015, Justin Uberti <[email-masked]> wrote:

>
>
> On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>

Isn't it enough to just have a route on the TURN server to a 1918 network?
I don't know why someone would do this and what sort of DMZed configuration
it would be but if they could then I don't think clients should try to make
assumptions about the practicality of such a configuration.

It is clearly much easier for the TURN server to check whether or not it
has such a route and refuse to add the permission.

Emil

-- 
sent from my mobile

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 6 Aug 2015 14:14:59 +0000

On Aug 5, 2015, at 5:35 PM, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault <[email-masked]<mailto:[email-masked]>> wrote:

I am somewhat sympathetic to that, but given that there is measurable downside here - extra candidate pairs that take time to check - can you supply a concrete example of where the client choosing not to pair a TURN candidate with a RFC1918 address would cause a problem?

This is really an ICE question, not a TURN question, so adding MMUSIC.

Clearly, if your TURN server is actually on the public internet, pairing RFC1918 address with its candidates won’t do any good.  However, there can be scenarios where you have a TURN server sitting in a DMZ or the like, where it can actually route to RFC 1918 addresses.  I suspect this will be relevant in the various scenarios where the TURN server is topologically equivalent to a web proxy.

As I recall from the discussions around the development of ICE, there are actually a fair number of networks out there which have public IPv4 and RFC1918 addresses directly routable to each other. The examples I remember came about as a result of corporate mergers, where one of the pre-merger companies was using their public address space internally, and the other wasn’t.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 6 Aug 2015 13:08:23 -0700

Agree regarding "proxy-like" border TURN servers. I think that a candidate
obtained from this sort of TURN server should be paired with RFC 1918
addresses, but I think that we should be able to avoid pairing candidates
obtained from application TURN servers with RFC 1918 addresses. The
app/browser clearly knows which is which.

On Thu, Aug 6, 2015 at 7:14 AM, Jonathan Lennox <[email-masked]> wrote:

>
> On Aug 5, 2015, at 5:35 PM, Justin Uberti <[email-masked]> wrote:
>
> Clearly, if your TURN server is actually on the public internet, pairing
> RFC1918 address with its candidates won’t do any good.  However, there can
> be scenarios where you have a TURN server sitting in a DMZ or the like,
> where it can actually route to RFC 1918 addresses.  I suspect this will be
> relevant in the various scenarios where the TURN server is topologically
> equivalent to a web proxy.
>
> As I recall from the discussions around the development of ICE, there are
> actually a fair number of networks out there which have public IPv4 and
> RFC1918 addresses directly routable to each other. The examples I remember
> came about as a result of corporate mergers, where one of the pre-merger
> companies was using their public address space internally, and the other
> wasn’t.
>
>
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 6 Aug 2015 13:51:50 -0700

On 6 August 2015 at 13:08, Justin Uberti <[email-masked]> wrote:
> I think that we should be able to avoid pairing candidates obtained from
> application TURN servers with RFC 1918 addresses. The app/browser clearly
> knows which is which.

I'm concerned here that if we let the application choose, we lose the
defence we were looking to gain.  I think that perhaps 1918 pairing
could be restricted to TURN servers that are configured/discovered,
"proxy"-style.

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 6 Aug 2015 21:08:55 +0000

> On Aug 6, 2015, at 4:51 PM, Martin Thomson <[email-masked]> wrote:
> 

What is the threat model/concern here?  Are you trying to save 20 ms for the connectivity check, or are you concerned that the remote candidates are visible on the wire and to the turn server?

Obviously, local and remote candidates are always visible to an application, so this isn’t a circumstance where worrying about hostile applications is particularly relevant.

I can certainly imagine corporate WebRTC applications with an application-configured TURN server in a DMZ.  Another example might be a cloud service which wants all its traffic to come in through a single port, so it configures all applications to connect to it through a TURN port and uses RFC 1918 addresses internally.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 6 Aug 2015 14:36:29 -0700

> What is the threat model/concern here?  Are you trying to save 20 ms for the connectivity check, or are you concerned that the remote candidates are visible on the wire and to the turn server?

Well, perhaps I'd missed the point of the thread, but my understanding
was that attempting to pair TURN candidates with private address
ranges had several negative characteristics:

1. they are unlikely to work
2. they expose the 1918 address to the TURN server
3. they expose the 1918 address to others (depending on whether DTLS
is used to the TURN server and how far a check toward that address
actually makes it through the network)
4. they consume a check slot

Obviously, a lot of this hinges on the first point. If there is a
reasonable chance that the pairing works, then maybe the other costs
can be borne.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 6 Aug 2015 17:01:03 -0700

> could be restricted to TURN servers that are configured/discovered,

Sorry, that is what I was trying to say. The browser knows which turn
servers are "proxies" vs app servers, and can apply the 1918 filtering on
the pairings from the candidates from the app TURN server.

Agree with your enumeration of concerns as well. Also #5, they consume
bandwidth (at least from client to TURN server), which affects maximum
check rate in some cases.

---

From: Emil Ivov <[email-masked]>
Date: Thu, 6 Aug 2015 17:11:52 -0700

> the pairings from the candidates from the app TURN server.

I don't think Jonathan's concerns only apply to proxies though. You
can just as well have apps developed for specific networks and there
is no reason to prevent those from working.

> bandwidth (at least from client to TURN server), which affects maximum check
> rate in some cases.

Why can't we address this by TURN servers simply refusing to create
permissions for candidates they know they won't be able to reach?

Emil

-- 
https://jitsi.org

---

From: Justin Uberti <[email-masked]>
Date: Thu, 6 Aug 2015 17:46:08 -0700

On Thu, Aug 6, 2015 at 5:11 PM, Emil Ivov <[email-masked]> wrote:

> > On Thu, Aug 6, 2015 at 1:51 PM, Martin Thomson <[email-masked]
> >
> > wrote:
> >>
> check

That is one potential solution, which would solve #1/#4/#5.

---

From: Emil Ivov <[email-masked]>
Date: Thu, 6 Aug 2015 19:24:57 -0700

> That is one potential solution, which would solve #1/#4/#5.

So, let's say that Alice calls Bob using SuperApp.

Alice sends her 10.0.0.1 address to SuperApp's server, which then
sends it to Bob.

So Bob and SuperApp now know about Alice's 10.0.0.1 but there's no way
around this. Bob, could be in the same network as Alice so it has to
try her private address.

Next, Bob installs 10.0.0.1 on the TURN server provided by SuperApp,
which also now learns about 10.0.0.1. As long as that server is hosted
by the same people as SuperApp (which we can probably consider as the
common case) then we haven't leaked anything.

If the TURN server is hosted by a third party (SuperTURN) then
SuperTURN do get to learn a little bit of extra information, namely
that Alice's public address has a private network in the 10.0.0.0
range behind it and that 10.0.0.1 is being used by someone.

That's all though.

SuperTURN should have no other information regarding Alice and what
little it just learned was not hard to guess any way.

So I am not sure exactly what we are trying to solve here.

Emil

-- 
https://jitsi.org

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Fri, 7 Aug 2015 07:47:33 +0000

On 07 Aug 2015, at 02:11, Emil Ivov <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Aug 6, 2015 at 5:01 PM, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Aug 6, 2015 at 1:51 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>>
wrote:

On 6 August 2015 at 13:08, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:
I think that we should be able to avoid pairing candidates obtained from
application TURN servers with RFC 1918 addresses. The app/browser
clearly
knows which is which.

How do you reliably and simply do that without a connectivity check?

If the main concern is information leakage, isn’t that up to the client to decide what it want to reveal to the TURN server and the remote client?

Guess what I am saying is that I think it is a good thing to have a “thick” client and relatively simple network components.

.-.
Pål-Erik

Emil

--
https://jitsi.org<https://jitsi.org/>

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

---

From: Emil Ivov <[email-masked]>
Date: Tue, 11 Aug 2015 08:32:10 -0500

Hey Pal,

On Fri, Aug 7, 2015 at 2:47 AM, Pal Martinsen (palmarti)
<[email-masked]> wrote:
>
> On 07 Aug 2015, at 02:11, Emil Ivov <[email-masked]> wrote:
>

There are a few ways a TURN server could be smart about this (e.g.
checking the routing table for local interfaces for example, or
looking into ARP tables) but ultimately they should allow for this to
be configured.

> If the main concern is information leakage, isn’t that up to the client to
> decide what it want to reveal to the TURN server and the remote client?

I don't know that the main concern is leakage (see my previous mail).
I don't see how an application can be worried that the TURN server it
chose is going to find out that there's one of three NATed ranged
behind a certain IP. The TURN server had a 1 in 4 chance of guessing
that even without the app.

That said, I am not opposed to giving JavaScript apps a way to
explicitly signal the stack not to pair certain addresses with TURN.

I just don't want the stack to assume this.

Emil

> Guess what I am saying is that I think it is a good thing to have a “thick”
> client and relatively simple network components.
>
> .-.
> Pål-Erik
>
>
> Emil
>
> --
> https://jitsi.org
>
> [email-masked]

-- 
https://jitsi.org

---

From: Justin Uberti <[email-masked]>
Date: Thu, 13 Aug 2015 16:22:34 -0700

For now I think we will follow the suggestion of letting the server enforce
this policy, and return 403 in the case where the target IP would be
considered unreachable by the server.

Chrome will also need to be updated to actually do the right thing on this
403...

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 14 Aug 2015 08:39:37 -0700

> On Aug 6, 2015, at 7:14 AM, Jonathan Lennox <[email-masked]> wrote:
> 
> 
>> On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault <[email-masked]> wrote:

Some SPs are putting all their customers behind CGN (carrier grade NAT) and then looking at running cloud data centers where other people can rent servers (AWS style) where those servers have public IPs and at the same time they are directly routable to the all the NATed clients. That allows you to run media servers (STUN, TURN, Conferences MCU / Switches, caches etc) that have a low latency connectivity to the SP's customers endpoints. Note the customers's themselves often deploy an additional layer of residential NAT. 

So scenarios like this might be getting more common ....

---

From: Justin Uberti <[email-masked]>
Date: Fri, 14 Aug 2015 13:41:00 -0700

Makes sense, although not sure that the apps will want to disclose the
private IPs of the media servers to endpoints.

Overall I think enough arguments have been made that it is safer for the
server to enforce this policy than clients, since the TURN server should be
more aware of the application topology.

On Fri, Aug 14, 2015 at 8:39 AM, Cullen Jennings <[email-masked]> wrote:

> > As I recall from the discussions around the development of ICE, there
> are actually a fair number of networks out there which have public IPv4 and
> Some SPs are putting all their customers behind CGN (carrier grade NAT)
> and then looking at running cloud data centers where other people can rent
> servers (AWS style) where those servers have public IPs and at the same
> time they are directly routable to the all the NATed clients. That allows
> you to run media servers (STUN, TURN, Conferences MCU / Switches, caches
> etc) that have a low latency connectivity to the SP's customers endpoints.
> Note the customers's themselves often deploy an additional layer of
> residential NAT.
>