Subject: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 05 Aug 2015 06:06:07 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-rtcweb-stun-consent-freshness-15: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Apologies that these discuss points are maybe asking
fairly fundamental questions.  That could be that this
is really the first of the new security things required
by rtcweb to get to the IESG.  Or maybe I'm misreading
stuff here, if so, sorry;-)

(1) Why call this "consent?" That term is (ab)used in
many ways on the web, and adding another variation
without a definition that distinguishes this from "click
ok to my 200 page anti-privacy policy" or "remember that
example.com is allowed use my camera/mic" seems like a
terrible idea. I also don't see how this can ever be
something to which a normal person can "consent" (i.e.
consciously agree while fully understanding) so the term
is IMO very misleading, and will I fear be used to
mislead further.  (See also some of the comments below -
I do not think we ought be as fast and loose with this
aleady terribly badly used term.) To summarise: I'd love
if you did s/consent/anything-else/g but if not, please
define consent here in a way that clearly and
unambiguously distinguishes this usage from other abuses
of the term.

(2) WebRTC does not require STUN or TURN servers for
some calls, even if it does for many. Why is it ok to
require such a server be present in all calls (which I
think this means) espcially when that means exposing
additional meta-data (calling parties in a case where
the servers weren't needed and call duration in all
cases) to those servers when that is not always
necessary? 

(3) (end of p5) You have a MUST NOT here that is
depenedent on current browser implementations. Why is
that an IETF thing and not a W3C thing? But more
interestingly, can one securely use this protocol
without the kind of JS vs. browser sandboxing etc that's
needed in the web? If the answer is "no" then don't you
need to say that this protocol can only safely be used
for such implementations? (In section 2, which almost
but not quite says that.)

(4) Section 8: Where are these 96 bits defined? I think
this "requires..." statement needs a precise reference
to the place in some ICE/TURN/STUN RFC where it's
defined. (And I forget where that is, sorry:-) This
should be an easy fix.

(5) Why is it ok to approve this while the
rtcweb-security-arch and rtcweb-security are still
developing? There are section-specific references here
along the lines of: "doing this is ok because of section
x.x" of both of those drafts. Why is it ok to approve
this now, when the underlying architecture and overall
security model on which this depends are still in-flux?
I'm not asking about editorial changes here nor about
timing, but about why it's ok to approve this when the
basic security concepts have yet to undergo IETF last
call, and so could change significantly. I do not think
it would be acceptable for a comment/discuss on the
security documents to be received with "yes, but you
approved consent-freshness and so we implemented and
deployed that so you're too late to make that
comment/discuss and expect some change."

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- abstract: why is only sending "media" mentioned here?
What about data channels?  And the body of the document
in fact says this all applies to any non-ICE data and
not only media.

- intro: "initial consent to send by performing STUN" I
do not find the word consent in either rfc5245 or 3489,
but perhaps it is used somewhere else. Where?  And with
what meaning?

- section 4, 2nd last para - I think the conclusion is
bogus.  An implementation knows when the keying it's
using can not involve >1 (nominally operating) party.

- 5.1, 3rd para: "Explicit consent to send is
obtained..." is misleading. That is not a concept that
an implementation of STUN will embody. 

- 5.1, What is the "Note" about TCP for? Why is this
needed?

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Aug 2015 13:22:02 +0000

Hi Stephen,

>(2) WebRTC does not require STUN or TURN servers for some calls, even if it does for many. Why is it ok to require such a server be present in all calls (which I think this means) espcially 
>when that means exposing additional meta-data (calling parties in a case where the servers weren't needed and call duration in all
>cases) to those servers when that is not always necessary? 

Could you please refer to the text which you think mandates STUN or TURN servers?

If there are no NATs, the STUN requests can be sent between the endpoints, without STUN or TURN servers.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 5 Aug 2015 08:00:53 -0700

> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/

You should probably propose a new term at this point.

> cases) to those servers when that is not always

I'm not sure what you mean by "OK" and "require". The physics of the
situation
is that if you want to do a call between two people not on the same network,
then you minimally need STUN. If you want it to (almost) always work you
need TURN. This isn't a spec requirement but just a result of the network
topology. As far as I know, the specs don't require that the site supply
a STUN/TURN server and the implementations don't either, but I'm not
sure what else you're looking for.

> but not quite says that.)

This is just only relevant in this case. It doesn't apply to non-JS
implementations.

-Ekr

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 05 Aug 2015 17:55:25 +0100

Hiya,

On 05/08/15 14:22, Christer Holmberg wrote:
> Hi Stephen,
> 
>> (2) WebRTC does not require STUN or TURN servers for some calls,
>> even if it does for many. Why is it ok to require such a server be
>> present in all calls (which I think this means) espcially when that
>> means exposing additional meta-data (calling parties in a case
>> where the servers weren't needed and call duration in all cases) to
>> those servers when that is not always necessary?
> 

Sure, I think there were a couple of places, but I'd have to
track 'em down. I'll try update the ballot with that if it
turns out to be needed. (Be tomorrow before I get to that,
sorry.)

> endpoints, without STUN or TURN servers.

Really - so browsers will be able to act like a STUN server or
something? I didn't know that. Where's that described?

S.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 5 Aug 2015 10:01:27 -0700

> something? I didn't know that. Where's that described?

ICE uses STUN in three ways:

1. For address discovery
2. To talk to TURN servers (TURN is based on STUN)
3. For ICE connectivity checks.

Christer is referring to #3.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 05 Aug 2015 18:06:27 +0100

Hiya.

> You should probably propose a new term at this point.

Really? Happy to try (and fail:-) How'd "willing to take
rtcweb traffic" work? I suspect it wouldn't though.

But I'm not clear if you're agreeing that that term
is problematic or just asking me to suggest something in
the hope I realise the futility of what I'm requesting?

> then you minimally need STUN. 

Sure. But if they're on the same n/w? Do we agree that
in that case, there shouldn't be a need for a new STUN
or TURN server in the call? And that if this draft meant
such a server was needed even in that case, then that'd
be an issue?

> If you want it to (almost) always work you

So one non-inevitable consequence of the how this draft
is written is that the STUN/TURN server gets to know the
call duration. That could have been avoided I think if
some other design had been chosen. 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.

> This is just only relevant in this case. It doesn't apply to non-JS

Not sure I'm following. Are you saying that this protocol
would be safe even if there wasn't the split between JS
and non-JS code running on the browser? If so, that's good.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 05 Aug 2015 18:19:54 +0100

> Christer is referring to #3.

Ok, and what happens with this freshness stuff in that
scenario? (Apologies if its in this or some other draft
and I missed it)

S

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 5 Aug 2015 10:22:29 -0700

This freshness stuff is also about #3. Namely, it's about the endpoints
doing continual STUN connectivity checks between each other.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 5 Aug 2015 10:38:57 -0700

On Wed, Aug 5, 2015 at 10:06 AM, Stephen Farrell <[email-masked]>
wrote:

> >> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

Maybe something between the two.

> or TURN server in the call?

Yes.

> And that if this draft meant

Yes, I think it shouldn't require that.

> call duration.

This isn't correct. The STUN server doesn't know and the TURN server only
knows if the relay candidate is slected.

> That could have been avoided I think if

I don't understand what you are concerned about here.

> and non-JS code running on the browser? If so, that's good.

I'm saying that the primary concern of this document is that attackers
will force people's Web browsers to spam other people with RTP traffic
and that that isn't as big an issue in non-Web contexts, which is why
we don't do continuing consent for (say) SIP + ICE.

-Ekr

---

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

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: Alissa Cooper <[email-masked]>
Date: Wed, 5 Aug 2015 12:47:59 -0700

Thanks Stephen, responding to a couple points below where others have not chimed in yet.

> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-stun-consent-freshness/

https://tools.ietf.org/html/rfc5389#section-6 (as referenced in Section 5.1)

> call, and so could change significantly.

I think it’s worth looking at what the cross-references actually point to.

Section 2 says:

"Section 4.4 and Section 5.3 of
   [I-D.ietf-rtcweb-security-arch] further explains the value of
   obtaining and maintaining consent.”

Section 4.4 of draft-ietf-rtcweb-security-arch essentially says that implementations MUST use the mechanism specified in draft-ietf-stun-consent-freshness. Section 5.3 of draft-ietf-rtcweb-security-arch establishes the normative requirement that ICE be used and how it be used and explains the need for consent freshness.

Section 8 says:

"Consent Verification to avoid attacks using a browser as
   an attack platform against machines is discussed in Sections 3.3 and
   4.2 of [I-D.ietf-rtcweb-security].”

Both of these references are about the need to obtain consent in the first place, and as such I think they are provided more to give the broader picture of where stun-consent-freshness fits into the RTCWEB security story. Section 3.3 explains the threat model that motivates the need to obtain communications consent. Section 4.2 explains how this threat is mitigated, namely by using ICE. 

The upshot of this is if the WG or the IETF decides before publishing the security documents that communications consent isn’t actually necessary (seems highly unlikely to me), then maintaining consent freshness won’t make much sense, but having published this draft wouldn’t be particularly harmful either since it will basically be meaningless. Likewise, I guess in theory consensus could emerge not to use ICE. But in either of those cases, we could obsolete draft-ietf-stun-consent-freshness if it had already been published. Furthermore, if consensus does emerge not to use ICE, there will probably be bigger problems with the RTCWEB document suite than the fact that draft-ietf-stun-consent-freshness was published.

If your concern is that the specific section numbers in the security documents might change, I think those could be taken out without issue.

Alissa

> I do not think

---

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: Eric Rescorla <[email-masked]>
Date: Wed, 5 Aug 2015 15:08:16 -0700

I think I too am in favor of this change.

---

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: Stephen Farrell <[email-masked]>
Date: Wed, 05 Aug 2015 23:39:14 +0100

Hiya,

Thanks for that - I've cleared those points. Will
come back to other discuss points tomorrow

Cheers,
S.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Aug 2015 05:46:05 +0000

Hi,

Correct.

From a STUN protocol perspective, consent requests are normal STUN connectivity checks.

So, the browser will be a “server” in the sense that it receives and processes STUN connectivity checks, but it will not be a “STUN server” :)

Regards,

Christer

From: Eric Rescorla [mailto:[email-masked]]
Sent: 5. elokuuta 2015 20:22
To: Stephen Farrell
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; The IESG; Christer Holmberg; [email-masked]
Subject: Re: [rtcweb] Stephen Farrell's Discuss on draft-ietf-rtcweb-stun-consent-freshness-15: (with DISCUSS and COMMENT)

-Ekr

On Wed, Aug 5, 2015 at 10:19 AM, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:

On 05/08/15 18:01, Eric Rescorla wrote:
> On Wed, Aug 5, 2015 at 9:55 AM, Stephen Farrell <[email-masked]<mailto:[email-masked]>>
> wrote:
>
>>
>> Hiya,
>>

S

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

---

From: Xavier Marjou <[email-masked]>
Date: Thu, 6 Aug 2015 10:34:23 +0200

>(2) WebRTC does not require STUN or TURN servers for some calls, even if
it does for many.

In a typical WebRTC communication with A and B as WebRTC endpoints:
1 - Optionally A and/or B can use a STUN server to discover a public IP
address ("server reflexive" address as per rfc5245)
2 - Optionally A and/or B can use a TURN server to tunnel/relay WebRTC
messages with the help of a TURN server (c.f. draft-ietf-tram-turnbis-05)
3 - A and B have to implement ICE (rfc5245) and thus have to exchange STUN
connectivity check messages between their candidates (to try "open" flows",
... and maybe even to transport "consent" information).

Therefore, there can be STUN messages transported in three different
"sectors" :
1 - between the WebRTC endpoint and its STUN server, if used
2 - between the WebRTC endpoint and its TURN server, if used
(draft-ietf-tram-turnbis-05 states that "Most, though not all, TURN
messages are STUN-formatted messages" so there are precisely
"STUN-formatted", not "STUN", but I mention them to be exhaustive with
different sort of messages appearing as STUN messages in tools like
Wireshark).
3 - between the WebRTC endpoints (in this case, the STUN connectivity check
messages are in the same flow that transports SCTP/DTLS and SRTP messages).

Some newcomers think that STUN messages only happen in cases 1 and/or 2,
they forget case 3. Maybe this explains the misunderstanding.

On Wed, Aug 5, 2015 at 3:22 PM, Christer Holmberg <
[email-masked]> wrote:

> Hi Stephen,
>
> >(2) WebRTC does not require STUN or TURN servers for some calls, even if
> it does for many. Why is it ok to require such a server be present in all
> calls (which I think this means) espcially
> >when that means exposing additional meta-data (calling parties in a case
> where the servers weren't needed and call duration in all

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 6 Aug 2015 06:08:08 -0700

Picking up on one more of these ...

> rtcweb traffic" work? I suspect it wouldn't though.

I am sympathetic to the point about “consent” but I’m not sure there is a single better word that connotes a machine agreeing to something rather than a person doing so. I think “permission” would be an even worse choice in this case given that it has a very common usage in WebRTC/browser land related to exactly what you cite above, namely browser permissions to use camera, mic, etc. “Willingness” seems at least as human if not more so than “consent.”

There is already a definition of “consent” in the draft:

Consent:  The mechanism of obtaining permission from the remote
      endpoint to send non-ICE traffic to a remote transport address.
      Consent is obtained using ICE.

I would suggest adding one additional sentence to this:

“Note that this is an application-level consent; no human intervention is involved.”

Alissa

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 06 Aug 2015 14:15:48 +0100

Hiya,

On 06/08/15 14:08, Alissa Cooper wrote:
>>> On Wed, Aug 5, 2015 at 6:06 AM, Stephen Farrell
>>> <[email-masked]> wrote:
>>> 
>>>> When responding, please keep the subject line intact and reply
>>>> to all email addresses included in the To and CC lines. (Feel
>>>> free to cut this introductory paragraph, however.)
>>>> 
>>>> 
>>>> Please refer to
>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for
>>>> more information about IESG DISCUSS and COMMENT positions.
>>>> 
>>>> 
>>>> fairly fundamental questions.  That could be that this is
>>>> really the first of the new security things required by rtcweb
>>>> to get to the IESG.  Or maybe I'm misreading stuff here, if so,
>>>> sorry;-)
>>>> 
>>>> (1) Why call this "consent?" That term is (ab)used in many ways
>>>> on the web, and adding another variation without a definition
>>>> that distinguishes this from "click ok to my 200 page
>>>> anti-privacy policy" or "remember that example.com is allowed
>>>> use my camera/mic" seems like a terrible idea. I also don't see
>>>> how this can ever be something to which a normal person can
>>>> "consent" (i.e. consciously agree while fully understanding) so
>>>> the term is IMO very misleading, and will I fear be used to 
>>>> mislead further.  (See also some of the comments below - I do
>>>> not think we ought be as fast and loose with this aleady
>>>> terribly badly used term.) To summarise: I'd love if you did
>>>> s/consent/anything-else/g but if not, please define consent
>>>> here in a way that clearly and unambiguously distinguishes this
>>>> usage from other abuses of the term.
>>>> 
>>> 
>> Really? Happy to try (and fail:-) How'd "willing to take rtcweb
>> traffic" work? I suspect it wouldn't though.
> 
> I am sympathetic to the point about “consent” but I’m not sure there
> is a single better word that connotes a machine agreeing to something
> rather than a person doing so. 

https://en.wikipedia.org/wiki/Clear_to_Send ?

> I think “permission” would be an even
> worse choice in this case given that it has a very common usage in
> WebRTC/browser land related to exactly what you cite above, namely
> browser permissions to use camera, mic, etc. “Willingness” seems at
> least as human if not more so than “consent.”

IMO anything that doesn't use the word consent is better than
anything that does.

To make a webrtc call a person is forced to consent to a whole
bunch of pseudo-legal crap (by their OS, browser, IdP, and
probably the web site) so entangling the protocol with any of
that is a mistake. Once you stick with the term consent, I
think such entanglement is inevitable and will be regretted.

> intervention is involved.”

That would be good enough for me to clear yes. As a comment,
I think though it'd be better as something more like:

'The only human level "consent" here is that the application
developer (e.g. WebRTC browser implementer) has programmed their
application to adhere to this specification. The actual end users
who are involved in the call have not consented to anything just
because their browser uses this protocol.'

S.

> 
> Alissa
> 
>> 
>> But I'm not clear if you're agreeing that that term is problematic
>> or just asking me to suggest something in the hope I realise the
>> futility of what I'm requesting?
>> 
>> 
>>> 
>>> 
>>>> some calls, even if it does for many. Why is it ok to require
>>>> such a server be present in all calls (which I think this
>>>> means) espcially when that means exposing additional meta-data
>>>> (calling parties in a case where the servers weren't needed and
>>>> call duration in all cases) to those servers when that is not
>>>> always necessary?
>>>> 
>>> 
>>> I'm not sure what you mean by "OK" and "require". The physics of
>>> the situation is that if you want to do a call between two people
>>> not on the same network, then you minimally need STUN.
>> 
>> Sure. But if they're on the same n/w? Do we agree that in that
>> case, there shouldn't be a need for a new STUN or TURN server in
>> the call? And that if this draft meant such a server was needed
>> even in that case, then that'd be an issue?
>> 
>>> If you want it to (almost) always work you need TURN. This isn't
>>> a spec requirement but just a result of the network topology. As
>>> far as I know, the specs don't require that the site supply a
>>> STUN/TURN server and the implementations don't either, but I'm
>>> not sure what else you're looking for.
>> 
>> So one non-inevitable consequence of the how this draft is written
>> is that the STUN/TURN server gets to know the call duration. That
>> could have been avoided I think if some other design had been
>> chosen. 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 
>>>> (3) (end of p5) You have a MUST NOT here that is depenedent on
>>>> current browser implementations. Why is that an IETF thing and
>>>> not a W3C thing? But more interestingly, can one securely use
>>>> this protocol without the kind of JS vs. browser sandboxing etc
>>>> that's needed in the web? If the answer is "no" then don't you 
>>>> need to say that this protocol can only safely be used for such
>>>> implementations? (In section 2, which almost but not quite says
>>>> that.)
>>>> 
>>> 
>>> This is just only relevant in this case. It doesn't apply to
>>> non-JS implementations.
>> 
>> Not sure I'm following. Are you saying that this protocol would be
>> safe even if there wasn't the split between JS and non-JS code
>> running on the browser? If so, that's good.
>> 
>> Cheers, S.
>> 
>>> 
>>> -Ekr
>>> 
>>>> What about data channels?  And the body of the document in fact
>>>> says this all applies to any non-ICE data and not only media.
>>>> 
>>>> - intro: "initial consent to send by performing STUN" I do not
>>>> find the word consent in either rfc5245 or 3489, but perhaps it
>>>> is used somewhere else. Where?  And with what meaning?
>>>> 
>>>> - section 4, 2nd last para - I think the conclusion is bogus.
>>>> An implementation knows when the keying it's using can not
>>>> involve >1 (nominally operating) party.
>>>> 
>>>> - 5.1, 3rd para: "Explicit consent to send is obtained..." is
>>>> misleading. That is not a concept that an implementation of
>>>> STUN will embody.
>>>> 
>>>> - 5.1, What is the "Note" about TCP for? Why is this needed?
>>>> 
>>>> 
>>>> _______________________________________________ rtcweb mailing
>>>> list [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 06 Aug 2015 14:17:34 +0100

> they forget case 3. Maybe this explains the misunderstanding.

Yep. So I think the action is on me to go back and pick out the
bits of text that imply a server is needed, or say I tried and
they're not really there:-)

I'll get to that tomorrow.

S.

---

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: Roman Shpount <[email-masked]>
Date: Thu, 6 Aug 2015 17:16:45 -0400

On Thu, Aug 6, 2015 at 5:08 PM, Jonathan Lennox <[email-masked]> wrote:

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

There are also countries like North Korea (not that a very popular place by
a long shot, but it still exists) which runs their entire country in RFC
1918 address space:
http://www.theregister.co.uk/2015/07/21/north_koreas_internet/
_____________
Roman Shpount

---

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

---

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
>

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