Re: [MMUSIC] [rtcweb] [tram] TURN permissions for private ips

[Justin Uberti <[e-mail]>]

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 <[e-mail]> wrote:

>
> > On Aug 6, 2015, at 7:14 AM, Jonathan Lennox <[e-mail]> wrote:
> >
> >
> >> On Aug 5, 2015, at 5:35 PM, Justin Uberti <[e-mail]> wrote:
> >>
> >> On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault <[e-mail]>
> wrote:
> >> Le 2015-08-05 13:46, Philipp Hancke a écrit :
> >> > 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.
> >>
> >> 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.
> >>
> >> 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.
> >
>
> 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 ....
>
>
>
>
>