Subject: Re: [MMUSIC] [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be?

From: Jonathan Lennox <[email-masked]>
Date: Thu, 2 Feb 2012 18:40:46 -0500

I think this should be an issue for the mmusic group, not rtcweb -- it applies to anything that's doing ICE candidates in SDP.  I suggest replies just go to the mmusic mailing list.

On Feb 1, 2012, at 3:42 PM, Justin Uberti wrote:

http://tools.ietf.org/html/rfc5245, section 15.1:

      <rel-addr> and <rel-port>:  convey transport addresses related to the
      candidate, useful for diagnostics and other purposes. <rel-addr>
      and <rel-port> MUST be present for server reflexive, peer
      reflexive, and relayed candidates.  If a candidate is server or
      peer reflexive, <rel-addr> and <rel-port> are equal to the base
      for that server or peer reflexive candidate.  If the candidate is
      relayed, <rel-addr> and <rel-port> is equal to the mapped address
      in the Allocate response that provided the client with that
      relayed candidate (see Appendix B.3<http://tools.ietf.org/html/rfc5245#appendix-B.3> for a discussion of its
      purpose).  If the candidate is a host candidate, <rel-addr> and
      <rel-port> MUST be omitted.

Clearly we don't want to send out the base address when doing TURN-only, but according to the spec, rel-addr/rel-port must be supplied. What's the right way to handle this?

For clarity (since the followups on the RTCWeb mailing list indicated some confusion): the use case is an endpoint which, for location privacy reasons, wants to offer only TURN candidates in its set of ICE candidates, so the remote ICE peer doesn't know its actual network location.  (The standard example is the woman calling from the battered women's shelter.)

The problem is that RFC 5245 says you MUST include your mapped (server-reflexive) address when encoding relayed (TURN) candidates in SDP. If you do this, however, it completely breaks location privacy -- the mapped address is exactly what you're trying to hide.

It wouldn't be too hard to pick a known-invalid IP and port -- 0.0.0.0 0, presumably -- to encode in this situation (so as not to break strict parsers). The question is whether this would break any endpoints that are trying to follow the behavior in Appendix B.3 of RFC 5245, i.e. trying to apply QoS rules for the path between the endpoint and the TURN server.

--
Jonathan Lennox
[email-masked]<mailto:[email-masked]>

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 3 Feb 2012 12:27:13 -0500

On Feb 3, 2012, at 11:36 AM, Martin Thomson wrote:

> On 2 February 2012 15:40, Jonathan Lennox <[email-masked]> wrote:
>> (The standard
>> example is the woman calling from the battered women's shelter.)
> 
> The other way round, actually.  The case is where someone knows how to
> contact the woman (by webrtc) and simply by attempting to make the
> call, they obtain her location.

Right, good point.

But *why* you want location privacy isn't really relevant to the discussion here -- there are lots of use cases and reasons to want it.

>> The problem is that RFC 5245 says you MUST include your mapped
>> (server-reflexive) address when encoding relayed (TURN) candidates in SDP.
> 
> I don't think that's true from reading the text more carefully.  What
> the text says is that if you include a server reflexive address, you
> must include rel-addr and rel-port.  Section 15.1 describes the
> grammar, not the usage.  There is no reason that you can't simply omit
> all candidates other than the "relay" candidates.

Read the next sentence -- if you include a relay candidate, you must include "the mapped address in the Allocate response that provided the client with that relayed candidate" as the rel-addr and rel-port. This is the same as the server-reflexive address.
 
--
Jonathan Lennox
[email-masked]

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Feb 2012 08:36:47 -0800

--Martin

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Feb 2012 09:41:03 -0800

> Read the next sentence -- if you include a relay candidate, you must include "the mapped address in the Allocate response that provided the client with that relayed candidate" as the rel-addr and r…

My bad.  Your suggestion of ":: 0" should do to satisfy syntax checkers.

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 3 Feb 2012 19:21:28 +0000

Martin Thomson:

> other way round, actually.  The case is where someone knows how to contact the woman (by webrtc) and simply by attempting to make the call, they
> obtain her location.

Exactly. So the woman must use a webrtc provider who 1) doesn't reveal her IP address to bad people itself and 2) doesn't set the parameters such that her local or STUN address is sent prior to answer. Requiring the browser to *never* be able to provide the STUN or local address before answering is overkill (and providers who want faster connections will circumvent by building a brief null call and figuring it out that way).

>I don't think that's true from reading the text more carefully.  What the text says is that if you include a server reflexive address, you must include rel-addr
> and rel-port.  Section 15.1 describes the grammar, not the usage.  There is no reason that you can't simply omit all candidates other than the "relay"
> candidates.

That's how I read it too.

Pretty clear you could return *no* candidates, if that's appropriate.

Matthew Kaufman

---

From: Ted Hardie <[email-masked]>
Date: Fri, 3 Feb 2012 14:53:58 -0800

On Fri, Feb 3, 2012 at 11:21 AM, Matthew Kaufman
<[email-masked]> wrote:

> Requiring the browser to *never* be able to provide the STUN or local address before answering is overkill (and providers who want faster connections will circumvent by >building a brief null call and figuring it out that way).
>
Obviously we can disagree about "overkill" when it comes to the
balance between latency and privacy, but before we go there, I want to
make sure I understand what you mean by a null call.  If I understand
the optimization, you're proposing having the downloaded javascript
instantiate a session to the server ("call home on download"), so that
the server can collect the addresses it uses and then hand them out to
any other user who wishes to make a call to the user.

If that is the proposal, I have to say that I think it runs directly
counter to the privacy imperative we just identified.

Let's imagine our vampire friends at deadjournal decide to do this.
If I want to find out where the holder of [email-masked]
is, er, living, I can set up a script that attempts to autocall them
every N minutes and then lookup.  Whenever they sign in, deadjournal
will collect their IPs and send them over to me for use in my call.
sparklyvamp may very well know I am staker, and decide not to answer.
In the mean time, however, I'm on my way with holy water, garlic, and
a sharpened stick.

In order to avoid this fate, sparklyvamp must know whether or not any
particular service they use which *might* embed audio and video in
some parts of the applications they provide or host will or will not
use this.  This includes the services deadjournal hosts for Zomga, the
well-known undead games maker.

Have I misunderstood your optimization?

Ted

---

From: Martin Thomson <[email-masked]>
Date: Fri, 3 Feb 2012 15:39:50 -0800

> any other user who wishes to make a call to the user.

The point is that, at some level, the user has to trust the site they
are visiting before they grant the site access to PeerConnection.

It _is_ possible to keep the server ignorant with a little trickery.
You use this new data bearer to exchange candidates and keep all but
relay candidates from the server, or always use your own TURN server
and always relay.  The exchange of candidates would have to be
standardized though.  Keep in mind that you also need to proxy your
HTTP traffic to the server as well.  That's the trade-off, and maybe
that's an option that should remain on the table, but you can see
where "overkill" comes from.

--Martin

---

From: Justin Uberti <[email-masked]>
Date: Fri, 3 Feb 2012 12:45:33 -0800

On Fri, Feb 3, 2012 at 9:41 AM, Martin Thomson <[email-masked]>wrote:

> > Read the next sentence -- if you include a relay candidate, you must
> include "the mapped address in the Allocate response that provided the
> client with that relayed candidate" as the rel-addr and rel-port. This is
> the same as the server-reflexive address.
>

Thanks for the replies. Since the text in Appendix B.3 that Jonathan
referred to indicates that rel-addr/port is not critical to ICE operation,
0.0.0.0:0 sounds good to me.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 3 Feb 2012 18:55:40 -0500

> where "overkill" comes from.
I thought that TURN servers would be provisioned by the java script (web
site) and not the end user, or do we plan to provide an interface in web
browser settings that allows the overwrite for this?

One more thing that an end user can do to ensure privacy, is to always
require to use a proxy. I am not sure if the decision have been made, if
proxy is required to be used, if specified by the end user. One option is
that if proxy is specified, the only candidate used would be a TURN address
obtained via a TCP or TLS connection established through proxy.
Unfortunately, this exactly the opposite of what you would want to do, if
you were trying to optimize the media for best performance, since in this
case you would try to connect to the TURN server directly even if proxy is
specified (and to use reflective or local IP if possible).

Final consideration is that even if such options are provided in a web
browser, very few users would be educated enough to use them properly.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 6 Feb 2012 05:06:14 +0100

Hi,

For clarification, what do we exactly mean by "answering the call"?

Do we mean:

a) that the called party has accepted the call, and actually "lifted the hook", or 

b) that the called party has been made aware (alterted) about the incoming call, but has not yet accepted it, and may or may not accept it?

We also have to remember that ICE is not the only way to reveal IP addresses. The signalling protocol (depending on which one we use) can also reveal IP addresses/ports in other protocol elements. 

And, taking SIP as an example: if we don't allow revealing of IP addresses before the call has been answered, it would prevent a SIP app from sending provisional responses with Contact header fields.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Ted Hardie [[email-masked]]
Sent: Saturday, February 04, 2012 12:53 AM
To: Matthew Kaufman
Cc: Jonathan Lennox; [email-masked]; [email-masked]
Subject: Re: [rtcweb] ICE with only TURN candidates: what should rel-addr/rel-port be?

On Fri, Feb 3, 2012 at 11:21 AM, Matthew Kaufman
<[email-masked]> wrote:

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

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 7 Feb 2012 06:22:52 -0700

On Feb 3, 2012, at 4:55 PM, Roman Shpount wrote:

> I thought that TURN servers would be provisioned by the java script (web site) and not the end user, or do we plan to provide an interface in web browser settings that allows the overwrite for this?

Yes, both - in the previous conversations we have agreed to be able to provide TURN servers both of these ways. We have not yet nailed down which one takes precedence if both the browser has one configured and the JS provides one but it seems to me that we need the one the browser provided TURN server to be higher priority than the JS provided one.