Subject: [rtcweb] draft-ietf-rtcweb-return-00.txt; Sealed, Configuration and TURN discovery:

From: "Karl Stahl" <[email-masked]>
Date: Tue, 14 Jul 2015 00:19:26 +0200

We need this draft implemented in WebRTC browsers as soon as possible, so we
can get good WebRTC in difficult places (for firewall traversal and for
quality). Is there any implementation e.g. in Chrome that can be tried?

Now having stated that I am positive to this draft, I have some
concerns/questions/suggestions:

1) We need more levels than sealed/leaky

It is not acceptable that WebRTC traffic between parties on a typical LAN is
forced through a TURN server, just because of a sealed configuration
required for good WebRTC traffic over the WAN. This consequence is pointed
out under "5.11.  Reusing the same TURN server", but IS a problem even if it
"work as expected".

Such TURN resource consumption, waste of bandwidth and possible performance
degradation do not happen today, and can easily be avoided.

I realize this consequence of "sealed" is required to meet some of the
requirements under "3.2.  Independent Path Control", but we simply need an
"exo-sealed" level, in addition to the proposed strictly sealed and leaky,
allowing local endpoints to connect media directly, while external traffic
is forced to use the TURN server (rather than STUN through the default
gateway). 

Such "exo-sealed" configuration should be the default configuration if a
network provided TURN server is made available for good (non-evil) purposes.

2) Mobile devices need to work on various networks, without individual
configuration 

I am not clear about the thoughts behind the "configuration" of sealed level
and requirements for authentication of the turn server, but if there are
methods where an enterprise network (LAN) admin can provide credentials and
force a certain sealed level upon the WebRTC-browser when used at that LAN,
or if the user has the possibility to configure manually, I am OK with that
this can and should OVERRIDE any default configuration or other
configuration (on that particular network).

However, for mobile devices - Don't we all happily connect our browsers via
WiFi here and there? - there must be a way for a network provider with a
good intent to offer an exo-sealed TURN server that automatically should be
used, e.g. to achieve the purpose of offering better RTC quality than is
available through the default gateway WAN path on that network. 

A network provided TURN-server can easily be made available ONLY to the
network users that it is serving, so there is no need for authentication and
credentials to protect against illegal usage of a valuable resource, like it
is with the application provided turn server. Network provided TURN servers
are simply deployed for the network users to be use without other
authentication than being granted an IP address and a default gateway to use
on that particular network in itself.

The same goes for trusting the TURN server with our real-time traffic - If
we would trust the same network provider with the same real-time traffic
through the default gateway - we should also use the offered TURN server
without other "authentication" than that it is available on our network:
Data through the default gateway, RTC through the TURN path is why the TURN
server is provided!

But do we know that it is not someone with the evil purpose of stealing our
(encrypted!) real time traffic that is offering the TURN server (instead of
the network provider), which leads us to my point 3). (If we really think
there is a risk of and danger with such attacks...)

3) Is it now good enough to simply use the auto discovered TURN server? Hope
so!

There has been some recent improvements to
draft-ietf-tram-turn-server-discovery-03 and hopefully that is sufficient
for assuming that the auto-discovered TURN server is offered by our network
provider (a service provider or the enterprise itself) that we trust anyway,
and the TURN server then simply shall be used and considered exo-sealed.
(The current RETURN draft says a non configured TURN server should be
leaky.)

Some concerns regarding the DISCOVERY draft and whether these things should
be specified in the RETURN document:

- Is the above the case with all discovery methods proposed? Or shall the
RETURN document make one method mandatory to implement?

- Can that method then be the Anycast method (which by far seems to be the
most convenient to deploy and to implement and should work for all network
types and in all devices operating systems). I think what is said under
"9.3.  Anycast" under "9.  Security Considerations" is sufficient for
trusting such discovered TURN server. What should then go into the RETURN
draft - or should the DISCOVERY draft be more specific?

I don't fully understand the DISCOVERY draft's: "... three discovery
mechanisms. The reason for providing multiple mechanisms is to maximize the
opportunity for discovery,"

- Can we really put the burden upon all WebRTC devices to implement all
methods and I doubt network providers will deploy more than one method. That
seems risking rather than maximizing discovery...

It is high time to get this done - can we?

/Karl

-----Ursprungligt meddelande-----
Från: rtcweb [mailto:[email-masked]] För [email-masked]
Skickat: den 14 maj 2015 00:29
Till: [email-masked]
Kopia: [email-masked]
Ämne: [rtcweb] I-D Action: draft-ietf-rtcweb-return-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
 This draft is a work item of the Real-Time Communication in WEB-browsers
Working Group of the IETF.

        Title           : Recursively Encapsulated TURN (RETURN) for
Connectivity and Privacy in WebRTC
        Authors         : Benjamin M. Schwartz
                          Justin Uberti
	Filename        : draft-ietf-rtcweb-return-00.txt
	Pages           : 18
	Date            : 2015-05-13

Abstract:
   In the context of WebRTC, the concept of a local TURN proxy has been
   suggested, but not reviewed in detail.  WebRTC applications are
   already using TURN to enhance connectivity and privacy.  This
   document explains how local TURN proxies and WebRTC applications can
   work together.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-return/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rtcweb-return-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

---

From: Benjamin Schwartz <[email-masked]>
Date: Mon, 13 Jul 2015 21:16:10 -0400

> is forced to use the TURN server (rather than STUN through the default

How do you propose to tell what is "local"?  I don't know how to define
that procedurally.

I think my main concern here is that it requires us to "lie" to the remote
party, by sending candidates that we may then refuse to use even if they
work.  This seems very strange.

> (The current RETURN draft says a non configured TURN server should be

The security considerations in that document suggest that not all discovery
mechanisms have equal additional exposure to local network interference.  I
would appreciate clearer guidance on that front.  It seems to me that DHCP
is the only listed mechanism that creates minimal additional exposure to
network interference.

---

From: "Karl Stahl" <[email-masked]>
Date: Sun, 19 Jul 2015 20:23:17 +0200

Benjamin – your concern is valid – I thought exo-sealed was easy to do in the browser.

Below I list a firewall configuration assisted method to address the TURN server and bandwidth resource consumption problem for local WebRTC calls when using the sealed configuration. I believe my suggestion also will meet all security/trust/privacy perspectives and give secure auto-configuration, so mobile devices can to be used with high-quality secure WebRTC communication “everywhere you can surf”  through proper use of Border TURN servers - which must be the (almost already achieved) purpose of this RETURN draft.

After some consideration, to achieve the preferred exo-sealed configuration, the RETURN drafts already prescribes the best default configuration: “leaky” ! :-) 

Explanations inline below -->

Below are also some suggestions for inclusion in the drafts:

draft-ietf-tram-turn-server-discovery-03

draft-jennings-behave-rtcweb-firewall-00

/Karl

PS: Regarding the TURN Origin debate, I don’t have a clear view, but am I not right in the understanding that:

* The purpose of the TURN Origin draft  was to reduce the pain of WebRTC service providers having to deploy network hardware (the Application Provided TURN server) to get their services used, by allowing the TURN server to serve many applications (through a third party). 

 - The introduction of Border TURN servers releases WebRTC service providers of that pain (when commonly deployed) (and also put security back in the right place) (Until deployed commonly, yes these SPs unfortunately have this pain to “fool their services” through users security devices – the firewalls (something which the discussed 3 drafts now finally can remedy (without the use of Origin))

* However, the Application Provided TURN server may also be for (from the RETURN draft: 3 Goals, 3.2 independent path control): 

   o  improving quality of service by tunneling packets through a network that is faster than the public internet,

   +  monitoring the usage of UDP services,

   +  troubleshooting and debugging problematic services,

   +  logging connection metadata for legal or auditing reasons,

   +  recording the entire contents of all connections, or

   -  providing partial IP address anonymization (as described in [I-D.ietf-rtcweb-security] Section 4.2.4).

(+ and – indicates the conflicting impact the use Origin will bring for the listed purposes)

The RETURN draft honors the application’s efforts to enforce media through such Application Provided TURN server (without judging the purpose) (by use of the Recursively Encapsulation mechanism).

My advice now is just to not introduce the Origin discussion in these drafts where we finally have to resolve the firewall traversal problem with real-time traffic. We need these RFCs in place as soon as ever possible. I see a risk in that draft-jennings-behave-rtcweb-firewall-00 starts discussing Origin/SNI in an effort to make a pretty secure WebRTC aware firewall somewhat more secure, and think the draft can advice firewall vendors how to build firewalls that are fully secure and allows real-time traffic and should also be able to provide a quality pipe for the real-time traffic. Origin/SNI is not required for that. The Border TURN server and this RETURN-draft will make that possible.

-- > Don’t forget the inline below -- >

Från: Benjamin Schwartz [mailto:[email-masked]] 
Skickat: den 14 juli 2015 03:16
Till: Karl Stahl
Kopia: [email-masked]; [email-masked]
Ämne: Re: [rtcweb] draft-ietf-rtcweb-return-00.txt; Sealed, Configuration and TURN discovery:

[BS] How do you propose to tell what is "local"?  I don't know how to define that procedurally.

[BS] I think my main concern here is that it requires us to "lie" to the remote party, by sending candidates that we may then refuse to use even if they work.  This seems very strange.

[Karl] You are right. I assumed the preferred exo-sealed behavior could be achieved as easily as we do it “hardware wise” today on the inside of our open test-site https://webrtc.ingate.com where we have a border placed TURN server paralleling our firewall/default gateway. Our firewall looks for the magic STUN cookie and discards all STUN packets from the LAN side. TURN is then automatically enforced and today’s leaky WebRTC browsers automatically get the preferred exo-sealed behavior.

(Just not using STUN in the browser, would have the same effect but not fully, if there are more subnets on the LAN side. Crossing those subnets would then take media through the dual trip via the TURN server that I want to avoid.)

So, let’s enforce the preferred exo-sealed configuration by configuration of the firewall/default gateway (Security from this perspective is then also in the right hands - the network admin’s): 

- Today’s RETURN-draft’s leaky default configuration is OK (since the firewalls discarding STUN automatically enforce the preferred exo-sealed behavior)

- Recommend in the RETURN-draft (and in draft-jennings-behave-rtcweb-firewall-00)  that the network admin discards STUN packets from the LAN side through the default gateway (consent STUNs will go OK through the TURN server), by looking for the magic STUN cookie, by closing port 3478 or by closing all UDP (the restrictive enterprise firewall can simply be left as it is) to achieve exo-sealed leakiness. 

- The network admin offers a Border TURN server for its network users (LAN side only) – no need for authentication (free to use from LAN side being a Border TURN server configuration) 

- The Border TURN server is offered by the network you are using – Just use it! (should the network provider have evil intentions, he needs no TURN server, he can simply close or destroy WebRTC in the firewall if he which,  which Cullen just exemplified in draft-jennings-behave-rtcweb-firewall-00)

As you may have noticed, I stress that NO credentials should be needed for using an auto discovered border TURN server. That is also the goal of TRAM’s discovery draft, but I have asked TRAM  to clarify that achievement. If we don’t fix that, we have failed to make WebRTC usable on mobile devices – or can anyone explain where we would get those credentials from when we run around and have Web access here and there and the goal of WebRTC was to use real-time communication, securely and with high quality, everywhere we can surf, wasn’t it? 

If anyone cries that we NEED AUTHENTICATION, they should remember the IP authentication (simply being on a certain network) is the most commonly used “authentication method” today and protecting huge values (almost the whole telco industry) and also achieves privacy (through the use of firewalls). No individual user credentials which are impossible to handle must be required.

I will in next email propose this new variant of the Anycast method  to TRAM. It should work, shouldn’t it?

And does it provide the claimed advantages/features? – please check.

Implicit discovery by interception of TURN allocate requests at a default gateway

An enterprise firewall or a network server provider’s router at a default gateway can intercept a TURN allocate request and respond with a 300 (Try Alternate) just as described in the Anycast method above. The following procedures and advantages are inherited from the anycast method.

This variant adds the following features:

- no separate deployment of discovery mechanism is required

- no ANA allocated anycast address is required (works with any public ip address) 

- the default gateway router/firewall in charge of the local network responds with the ip address of:

(i)   a Border TURN server (paralleling the default gateway), or 

(ii)  a TURN server behind that firewall/default gateway and opens a path to that TURN server  

- if the intercepted allocate request was intended for an application provided TURN server, the TURN client (e.g. WebRTC browser) on behalf of the user, can select to:

(iii) only use the auto discovered TURN server

(iv)  honor an allocation request by really sending the real-time traffic to the Application Provided TURN server, using the Recursively Encapsulated method, unless

(v)   the TURN  server connected in (ii) already is the Application Provided TURN server

Security wise, the right party is in charge in all cases.

A TURN server pinpointed by a firewall/router at the default gateway should always be trusted (no explicit authentication with credentials is needed) and used. (We trust the default gateway with all our traffic anyway, and any evil intent to disturb real-time traffic can in such case be implemented in a default gateway by easier means.)

The security considerations in that document suggest that not all discovery mechanisms have equal additional exposure to local network interference.  I would appreciate clearer guidance on that front.  It seems to me that DHCP is the only listed mechanism that creates minimal additional exposure to network interference.

--- I am addressing TRAM about this and believe that the variant of the Anycast method I suggest to be added, will fully resolve all security concerns. I am also suggesting that it is up to this RTCWEB draft to select from TRAM’s methods and advices for the WebRTC application and its use cases.

--- See my deployment concerns regarding DHCP put in front of TRAM. I think that the Anycast method with a short TTL-limitation is good enough from the privacy aspect, when used to find Border TURN server.

--- Even though the new variant I propose is more secure and even easier to deploy, I suggest that this RETURN draft mandates the use of the both the Anycast method and its new variant. The reason is that already today, all routers/firewalls at a default gateways can add the anycast route required for discovery, while intercepting the TURN  allocate request and responding with the Try Alternate server probably requires a software upgrade of installed  firewalls and routers with default gateways (a firewall in front of the default gateway can also do the interception and response). 

/Karl

-----Ursprungligt meddelande-----
Från: rtcweb [mailto:[email-masked]] För [email-masked]
Skickat: den 14 maj 2015 00:29
Till: [email-masked]
Kopia: [email-masked]
Ämne: [rtcweb] I-D Action: draft-ietf-rtcweb-return-00.txt

Abstract: