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

From: Justin Uberti <[email-masked]>
Date: Wed, 1 Feb 2012 15:42:06 -0800

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?

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Thu, 02 Feb 2012 14:26:19 +0100

On 02/02/12 00:42, Justin Uberti wrote:
>        <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
>        peer reflexive,<rel-addr>  and<rel-port>  are equal to the base
>        relayed,<rel-addr>  and<rel-port>  is equal to the mapped address
>        relayed candidate (seeAppendix 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
> 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?
>
>

Justin,

the TURN Allocate Response from the TURN server should contain
a STUN attribute called XOR-MAPPED-ADDRESS which should contain the
IP/port as seen by the TURN server, i.e. the public WAN address of
your home router.

you should use this IP/port as your rel-addr/rel-port for your Relayed candidate.

/alfred

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Feb 2012 08:57:55 -0800

On 2 February 2012 05:26, Alfred E. Heggestad <[email-masked]> wrote:
>> <rel-addr>
>>       reflexive, and relayed candidates.  >> 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?

I don't see a big problem here.  The text only says that _iff_ you
include a reflexive address, you must include IP+port.  Obviously, if
we are doing TURN only, then omit the candidates you don't want to
reveal.

> a STUN attribute called XOR-MAPPED-ADDRESS

The concern is not whether it is possible, but whether it is
desirable.  Revealing your IP to an as-yet-unaccepted caller has been
deemed not to be desirable.

--Martin

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 2 Feb 2012 17:21:31 +0000

Martin Thomson:
> The concern is not whether it is possible, but whether it is desirable.  Revealing your IP to an as-yet-unaccepted caller has been deemed not to be desirable.

The decision about whether or not to reveal your IP before call accept should be up to the web server.

After all, the web server can already reveal your IP to the other side if it wants to.

Sites that need to provide this protection for calling will do so, by both not revealing what they know from their HTTP logs *and* sending down Javascript that protects the called party's IP until after call accept.

Sites that don't care and want to reduce setup latency will have the option to behave differently... perhaps for different users even.

Matthew Kaufman

---

From: Ted Hardie <[email-masked]>
Date: Thu, 2 Feb 2012 11:55:51 -0800

> After all, the web server can already reveal your IP to the other side if it wants to.

Note that it is not necessarily revealing the same IP as would be used
in the call.  It's common in some SIP deployments for MobileIP to be
used, which results in signaling traffic coming from one address and
media traffic coming from another.  In the similar case here, the web
server may have no idea what IP your media traffic would come through.
 In the case of a web server running plain HTTP, it is also possible
that it only knows the data revealed by any proxies forwarded the
traffic.  That may or may not include a trustable indication of your
real IP.

> Sites that don't care and want to reduce setup latency will have the option to behave differently... perhaps for different users even.

And the clear UI features you propose to distinguish these cases to
end users are?

Ted

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Feb 2012 13:17:22 -0800

> The decision about whether or not to reveal your IP before call accept should be up to the web server.

Since the signalling effectively passes through the server, the server
has this control.  Signing the candidates is the only thing that might
prevent this, but - as we discussed - doing so doesn't buy much for
the cost that it imposes.

> After all, the web server can already reveal your IP to the other side if it wants to.

Assuming of course that there are no HTTP intermediaries.  And that
(as Ted notes), the media is going to follow the same path.

--Martin

---

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:

      relayed candidate (see Appendix B.3<http://tools.ietf.org/html/rfc5245#appendix-B.3> for a discussion of its

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: Randell Jesup <[email-masked]>
Date: Thu, 02 Feb 2012 23:40:56 -0500

> server may have no idea what IP your media traffic would come through.

True, though the security concern is more (though not entirely) that 
your physical location would be (partially) exposed by your IP address, 
as geolocation-by-IP does expose quite a bit of information (and in a 
specific case would expose that you're hiding with your Aunt Matilda in 
Boise, for example).

Right now, if someone gets a disposable cellphone, their location is 
fairly safe against either (former) abusers and against (say) people 
you're hiding from (witness protection, etc).  Allowing IP exposure will 
allow people to be at least roughly located in many cases, and finely 
with access to various databases (I believe) - and as pointed out, just 
knowing the town/city can be a significant information leak.

> traffic.  That may or may not include a trustable indication of your

Yes, though pure-HTTP is advised against - though a proxy might expose 
similar partial-location info.

> And the clear UI features you propose to distinguish these cases to

That's the primary flaw in Matthew's comment in my mind.  And as we 
said, (almost all) users a) don't really understand all the security 
mumbo-jumbo (if they even know it exists), and b) users don't change 
defaults.

IMHO: We can decide we don't care about the location-privacy issue, 
decide we want it by default (and live with limitations), or decide we 
want to make it possible but not the default (even though most people 
who might benefit from it would likely never find/understand it).

-- 
Randell Jesup
[email-masked]

---

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

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.

> 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.

--Martin

---

From: Ted Hardie <[email-masked]>
Date: Fri, 3 Feb 2012 09:00:00 -0800

On Thu, Feb 2, 2012 at 8:40 PM, Randell Jesup <[email-masked]> wrote:
> In the similar case here, the web
> True, though the security concern is more (though not entirely) that your
> physical location would be (partially) exposed by your IP address, as
> geolocation-by-IP does expose quite a bit of information (and in a specific
> case would expose that you're hiding with your Aunt Matilda in Boise, for
> example).
>
> Right now, if someone gets a disposable cellphone, their location is fairly
> safe against either (former) abusers and against (say) people you're hiding
> from (witness protection, etc).  Allowing IP exposure will allow people to
> be at least roughly located in many cases, and finely with access to various
> databases (I believe) - and as pointed out, just knowing the town/city can
> be a significant information leak.
>

This is true, but not the point I was making.  I was pointing out that
the web server having access to *an* IP address does not necessarily
mean it has access to the IP address that would be used for media.  If
both IP addresses are equally revealing of location, then the
distinction for physical location may not be important for some use
cases, but I believe revealing two IP addresses is worse privacy-wise
than one.  More importantly,  it is a reason not to cede control over
the decision to reveal this data to the web server/app writer.  The
information already revealed to them may not be the same.

I think the larger point has already been by Martin, though, in that
what we're trying to do is avoid revealing the media address of a
called party until the call has been accepted.  If we don't do that,
then an unsolicited "call" (invitation to hangout, facebook video chat
request, in-game trash talk attempt) could reveal the IP address of
the party who will ultimately decline.  That's the privacy implication
we *must* deal with.

I personally think that the best way forward may be to provide equal
protection to the party *placing* the call, simply because having a
setting that says "I'm okay/not okay with revealing my media IP to
people I'm trying to talk to before they agree to the call" will get
buried very far down a preference stack and will be confusing to a
large set of folks (at best, they'll understand it by analogy to
Caller-ID blocking, which already has surprising results if you dial
1-800 numbers etc.).   But the trade-offs are a little different
there, and I understand that others may disagree.

regards,

Ted

---

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

> 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.

> 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 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: Randell Jesup <[email-masked]>
Date: Fri, 03 Feb 2012 13:38:04 -0500

On 2/3/2012 12:00 PM, Ted Hardie wrote:
> On Thu, Feb 2, 2012 at 8:40 PM, Randell Jesup<[email-masked]>  wrote:

> the party who will ultimately decline.  That's the privacy implication

Absolutely.

> there, and I understand that others may disagree.

That is the closest commonly-known analog; the problem with that is that 
the analogy breaks down for the callee (people don't expect to have 
information leaked about them if they're called, except maybe that their 
phone is off or out of range).  But it's likely the best we can use to 
help explain it to users.

I'd have no problem with a UI (or API for that matter) that tied the two 
sides (outgoing and incoming location privacy).  The problem in my mind 
is the defaults, and how these options would be visible to the user 
(though that is largely an app issue, but we/W3C may want to give guidance).

-- 
Randell Jesup
[email-masked]

---

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: 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: 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: 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: Stefan Hakansson LK <[email-masked]>
Date: Sun, 5 Feb 2012 17:03:07 +0100

Thinking out loud:

If the server-reflexive/host candidates gives much more info (regarding 
location or anything else) than the IP-address any web server (using 
http) can get hold of now, isn't there a need for some user dialog to 
ack that? (Not that I know how it should be phrased.)

Otherwise, any site you browse to could get to know this data (even if 
it is not a site offering communication of any kind) by setting up a 
PeerConnection object and ask it to gather candidates.

Stefan

On 02/04/2012 12:55 AM, Roman Shpount wrote:
>
> On Fri, Feb 3, 2012 at 6:39 PM, Martin Thomson <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> 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).
>

---

From: "Jim Barnett" <[email-masked]>
Date: Sun, 5 Feb 2012 08:32:50 -0800

If we delay ICE until the call is accepted, almost all these problems go
away - though at the cost of greater set-up time.  What if the default
were that the caller starts gathering ICE candidates immediately, but
the callee does not until the call is accepted?  (In the case that
Stefan is worried about, could  a site start a start a call on the
user's behalf without his  consent?)

- Jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stefan Hakansson LK
Sent: Sunday, February 05, 2012 11:03 AM
To: [email-masked]
Subject: Re: [rtcweb] ICE with only TURN candidates: what should
rel-addr/rel-port be?

Thinking out loud:

Stefan

On 02/04/2012 12:55 AM, Roman Shpount wrote:
>
> On Fri, Feb 3, 2012 at 6:39 PM, Martin Thomson 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> site) and not the end user, or do we plan to provide an interface in 
> web browser settings that allows the overwrite for this?
>

> 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.

> 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).
>

---

From: Matthew Kaufman <[email-masked]>
Date: Sun, 5 Feb 2012 16:34:38 +0000

Jim Barnett:
> If we delay ICE until the call is accepted, almost all these problems go away - though at the cost of greater set-up time.

What is "the call is accepted" for a data-only connection?

Matthew Kaufman

---

From: Stefan Hakansson LK <[email-masked]>
Date: Sun, 5 Feb 2012 17:52:28 +0100

> What is "the call is accepted" for a data-only connection?

Exactly, and my case was that there was even no intention to set up a 
data connection - the (evil) site creates a PeerConnection object and 
asks it to gather candidates with the sole purpose of getting access to 
IP-addresses.

Stefan

---

From: "Jim Barnett" <[email-masked]>
Date: Sun, 5 Feb 2012 09:40:09 -0800

Good question, but I think that if we want the defaults to offer
privacy/security, the "caller" and the "callee" would still have to give
explicit permission to create the data-only connection before ICE could
begin (i.e. once the caller gave consent to create the connection, ICE
could begin on their side, and once the callee gave consent to accept
the connection, ICE could begin on their side.)

For the .01% of the population that changes the defaults, there could be
an 'allow quick connection' option (presumably restricted to specific
addresses), just as there could be an 'always accept connection'
override (also restricted by address.)

- Jim
-----Original Message-----
From: Matthew Kaufman [mailto:[email-masked]] 
Sent: Sunday, February 05, 2012 11:35 AM
To: Jim Barnett; Stefan Hakansson LK; [email-masked]
Subject: RE: [rtcweb] ICE with only TURN candidates: what
shouldrel-addr/rel-port be?

Jim Barnett:
> If we delay ICE until the call is accepted, almost all these problems
go away - though at the cost of greater set-up time.

Matthew Kaufman

---

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 6 Feb 2012 10:56:53 -0800

> browser settings that allows the overwrite for this?

I'm not aware of whether anyone is planning anything at all in particular.

Though I observe that since the browser is the one performing the ICE
parts, including contacting the TURN server, there is nothing stopping
someone from building a browser that has an option for locking down
the TURN negotiation to a single server.

Of course, there is nothing stopping the Javascript from inserting and
removing candidates from the list.  And nor should there be, though
that is just my opinion.  The browser only has control over where it
sends packets.

---

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.