Subject: [tram] last call on this draft: draft-ietf-tram-turn-server-discovery-03

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

I don’t think draft-ietf-tram-turn-server-discovery-03 draft is not clear
enough yet.

Hopefully the my suggestions below are non-controversial, only improvements,
so we can make this draft an RFC as soon as possible.

The following should be read in the context of the email below to the RTCWEB
WG.

1) The result of the valid discussion/concerns 

Ending at:
https://mailarchive.ietf.org/arch/msg/tram/W49pCoOHQu2mE-RxokMbq1FmpOg 

about how to achieve auto-configuration (e.g. necessary for good and secure
use of WebRTC on mobile devices) and the consequent necessity to be able to
use the auto discovered TURN server without credentials, and further that a
locally placed turn can achieve this by being available only from a trusted
network,

should be clarified and for which discovery methods it is achieved.  

2) Tiru, you and I have had some discussion a year ago or so about (From 1.
Introduction): 

“The reason for providing multiple mechanisms is to maximize the opportunity
for discovery, based on the network in which the TURN client finds itself.” 

I questioned whether that goal really can be achieved unless we mandate
(MUST implement) common methods, and whether it is up to this draft or some
RTCWEB draft to be responsible for that. With the appearance of 

draft-ietf-rtcweb-return-00

draft-jennings-behave-rtcweb-firewall-00

we now have a chance to clarify this.

I fully agree with the goal and necessity of this draft, but suggest some
rephrasing of the Introduction:

“To allow TURN applications operate real-time traffic seamlessly across
different types of networks and encourage by the use of TURN without the
need for manual configuration, it is important that there exists an auto
discovery mechanism for TURN services. Real-time applications and
specifically Web Real-Time Communication (WebRTC)[I-D.ietf-rtcweb-overview]
usages and related extensions, which are mostly based on web applications,
need this immediately.

And that the “multiple mechanism” sentence is replaced by:

“This document recommends multiple discovery mechanism, and advices about
security such as trust and privacy as well as deployment efforts. It is up
to the specific real-time application recommendation and its use case to
select from these recommendations and advices.” 

draft-ietf-rtcweb-return-00 can then specify how the browser shall implement
auto discovery for WebRTC

and draft-jennings-behave-rtcweb-firewall-00 can then advice firewall
vendors how to achieve the goals of this draft 

3) The concept of “sealed”, “leaky” and “exo-leaky” (see discussion below),
the Recursively Encapsulated method and Border TURN server should be
mentioned and conform with draft-ietf-rtcweb-return-00.

4) Explain that the leakiness for a discovered local TURN server can be auto
configured. E.g.:

“The default gateway router/firewall can block STUN packets by looking for
the magic STUN cookie, by closing port 3478 or by closing all UDP traffic,
to enforce an exo-sealed configuration for a TURN client having a leaky
default configuration, thus improving security, while avoiding the overhead
of sending the real-time traffic through the TURN server (twice) with sealed
a TURN client configuration (as explained in draft-ietf-rtcweb-return-00).

5) After “6.  Discovery using Anycast” section, add a variant:

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 TURN server pinpointed by a default gateway shall always be trusted
and used and the security methods under 9.3 will not have to be applied.

[Some of these features should be repeated under the Deployment and Security
sections]

6) Under “7. Deployment Considerations”, the ease of the Anycast method and
suggested variant could be pointed out. Those methods can be used over any
network and by TURN clients under common operating systems.

It should be adviced to configure discovered TURN servers to be allowed to
be used without credentials for the users that they are intended to serve,
to achieve the goal of this draft (simply by make the TURN server available
to allocate from, only on the network it is supposed to serve, thus no
credentials are needed to protect the TURN server resource as with the
application provided TURN servers).

The DHCP method may also be easy to deploy where used (e.g. Enterprise, Home
and WiFi). However, with IPV6, RA (Router Advertisement) is often used
instead of DHCP to hand out ip addresses. The important mobile world
(3G/4G/LTE) has its own methods, and there are still PPoE and PPoA in use,
where DHCP cannot be used. If a network service provides announces a TURN
server using DHCP, the following firewall needs to pick that up and advice
that to the users on the LAN. DHCP may not be available on some operating
systems where the TURN client, specifically the WebRTC device, should be
able to be implemented on. 

7)I don’t understand the sentences under “9.  Security Considerations”

“In general, it is recommended that a TURN client authenticate with the TURN
server to identify a rouge server. [RFC7350] can be potentially used by a
client to validate a previously unknown server.”

It must be explained and detailed, how and what is authenticated or
validated, for what purpose and how this may help to achieve the goals of
this recommendation, or these sentences should simply be deleted.

I hope this improves this necessary and good draft and that it quickly can
be adopted.

/Karl

Från: tram [mailto:[email-masked]] För Karl Stahl
Skickat: den 19 juli 2015 20:23
Till: 'Benjamin Schwartz'; 'Cullen Jennings (fluffy)'
Kopia: [email-masked]; [email-masked]
Ämne: Re: [tram] [rtcweb] draft-ietf-rtcweb-return-00.txt; Sealed,
Configuration and TURN discovery:

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:

On Mon, Jul 13, 2015 at 6:19 PM, Karl Stahl <
<mailto:[email-masked]> [email-masked]> wrote:

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

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

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

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

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: <mailto:[email-masked]>
[email-masked]] För  <mailto:[email-masked]>
[email-masked]
Skickat: den 14 maj 2015 00:29
Till:  <mailto:[email-masked]> [email-masked]
Kopia:  <mailto:[email-masked]> [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/>
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>
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
<http://tools.ietf.org> tools.ietf.org.

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

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