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

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Fri, 14 Aug 2015 00:06:39 +0000

Hi Karl,
Appreciate the review. Responses inline.

On 7/19/15, 11:34 AM, "tram on behalf of Karl Stahl" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

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.

Sure, we could add some text around this, but I don’t think we should get into too much this. You could discover other TURN servers that may not require credentials, from your ISP, perhaps.

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.

The latest draft states that a client SHOULD implement all methods for best results. It is up to the client, really. And as you point out, based on application requirements, a client could implement all or prioritize one over the others.

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

Sure, we'll add your recommended text in the draft.

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

Could you please comment on each draft separately? Tracking and following up becomes much simpler.

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.

Not really, you’re intercepting traffic not meant for you. Why can’t the gateway router just listen on the designated anycast address instead?

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

What about the following text?

NEW:

Clients can use TURN servers provided by the local network or by the access network without authenticating with the TURN server. It is recommended that clients use (D)TLS with network provided TURN servers to authenticate and prevent man-in-middle attacks.

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.

If DHCP cannot be used in a specific network then other discovery mechanisms discussed in the draft should be used.

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.

Sure, we’ll add more text around authentication.

-Prashanth

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

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

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

---

From: "Karl Stahl" <[email-masked]>
Date: Mon, 17 Aug 2015 14:52:10 +0200

Hi Prashanth,

See comments /explainations inline below.

Thanks,

Karl

Från: Prashanth Patil (praspati) [mailto:[email-masked]] 
Skickat: den 14 augusti 2015 02:07
Till: Karl Stahl; Tirumaleswar Reddy (tireddy); 'Simon Perreault'; 'Benjamin
Schwartz'; Cullen Jennings (fluffy); 'Adam Roach'
Kopia: [email-masked]
Ämne: Re: [tram] last call on this draft:
draft-ietf-tram-turn-server-discovery-03

Hi Karl,

On 7/19/15, 11:34 AM, "tram on behalf of Karl Stahl" <
<mailto:[email-masked]> [email-masked] on behalf of
<mailto:[email-masked]> [email-masked]> wrote:

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.

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,

Sure, we could add some text around this, but I don’t think we should get
into too much this. 

[Karl] Did you also read:
http://www.ietf.org/mail-archive/web/tram/current/msg01742.html and 

http://www.ietf.org/mail-archive/web/tram/current/msg01747.html ?

I think this discovery draft should get into this “much enough” to minimize
confusions that came to light there.

You could discover other TURN servers that may not require credentials, from
your ISP, perhaps.

[Karl] Yes, of course – that is the intention also – and this draft should
clear enough on that for others to use (e.g. the RETURN draft)

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 

The latest draft states that a client SHOULD implement all methods for best
results. It is up to the client, really. And as you point out, based on
application requirements, a client could implement all or prioritize one
over the others.

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.

“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

Could you please comment on each draft separately? Tracking and following up
becomes much simpler.

[Karl] I have done that, but… – This was just a remark (why I wanted this
little rewrite that you just agreed to)

3) The concept of “sealed”, “leaky” and “exo-leaky” (see discussion below),
the Recursively 

[Karl] Oops – meant “exo sealed” (not “exo-leaky”) above

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

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.

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

(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:

(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

Not really, you’re intercepting traffic not meant for you. 

[Karl] Isn’t that exactly what firewalls do? (and both of us, Cisco and
Ingate/Intertex are making such devices…)

Why can’t the gateway router just listen on the designated anycast address
instead?

[Karl] It does but must even then follow the same procedure of:  open a path
to the TURN server behind the gateway!      

My suggestion to add this variant was because what is explained under 4)
above:

- by blocking STUN packets a gateway router/firewall can enforce an
exo-sealed configuration for a TURN client having a leaky default
configuration. If sealed configuration (by some yet unknown configuration
method) is done just in browser, it will have the unwanted overhead of
sending local real-time traffic twice through the TURN server 

AND because of that the scenario of a the gateway router/firewall in front
of an ISP network provided TURN server, where both want a sealed
configuration where real-time traffic does NOT go through their default
gateways, was not outlined here or in the RETURN draft. 

The longer answer to your question:

> Why can’t the gateway router just listen on the designated anycast address
instead?

is:

If such gateway router/firewall just would advise an OWN TURN server, the
browser would have to add yet another level of recursively encapsulating
(for two network provided plus one application provided TURN server) - a
complication we cannot impose. Instead such gateway, must react to an TURN
allocation (by opening a path to the ISP TURN server) – and *as a
consequence* the specific anycast address is not needed.

The procedure suggested for the browser (and thus for the RETURN draft) is
to handle the situation where the gateway intercepts all TURN allocation
requests – that procedure will *also* work if the firewall instead only
reacts to the anycast address and sets up a path (and allows the next level
to respond to it), while a thinner procedure in the browser may not handle
the case where the gateway answers all TURN allocation requests through its
default gateway.

So, by outlining this implicit discovery anycast variant, the RETURN draft
can recommend a procedure that will work for all cases (that the gateway
router/firewall may choose to implement this “kind of TURN allocation proxy”
needed when in front of an ISP TURN server. 

AND FURTHER, if we know the browser will follow a certain procedure, such
gateway router/firewall in front of an ISP TURN server, can auto configure
itself by following the TURN allocate requests and responses that passes the
gateway router/firewall. I don’t mean it is time to specify such behavior of
such gateway router/firewall in any draft, but if we already now also
outline  the implicit discovery anycast variant  (The method is only 3 lines
of text!) and have the browsers handle it – we have paved the way for easy
deployment of network provided TURN servers.

What about if this is explained in the document after those 3 lines defining
the implicit discovery anycast variant, like this:

“This is outlines a TURN allocate proxy behavior that a gateway
router/firewall in front of an ISP provided TURN server may implement (one
of a few variants). If a real-time application like WebRTC defines the usage
of TURN for such configuration, it should be possible to work generally.”

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

NEW:

Clients can use TURN servers provided by the local network or by the access
network without authenticating with the TURN server. It is recommended that
clients use (D)TLS with network provided TURN servers to authenticate and
prevent man-in-middle attacks.

[Karl] Now I think you hit a confusing point that is a source of the
authenticate/authorize/credential issue popping up now and again relating to
this draft: Here you say “use … without authentication” (meaning that users
need not have credentials) followed by “to authenticate” (meaning checking
that the TURN server has a valid certificate)  

In http://www.ietf.org/mail-archive/web/tram/current/msg01747.html the
question of “authenticate and authorize the discovered TURN server(s)” arose
again.

I think the full story must be spelled out clearly, e.g.:

“The purpose of discovery of a network provided TURN server is to find a
TURN server offered by a network provider or a network admin, to be used for
real-time traffic by the users on that network segment. For WebRTC usage
“everywhere you can surf”, such TURN servers must be used without requiring
users to have credentials for responding to authentication challenges.
Network provided TURN servers must therefore be configured to not challenge
allocation requests from the network segment that they serve and the TURN
server should only be available to and advertised to those users. 

An advertised network provided TURN server, shall simply be interpreted as
an advice to use the TURN server path for real-time traffic, instead of
using the default gateway path. The level of trust is the same for both
paths (since both the default gateway and the TURN server are offered and
arranged by the network provider). A sealed configuration (as outlined in
draft-ietf-rtcweb-return) can be arranged by the network provider by
blocking STUN packets in the default gateway.

For use cases where individual user configuration is wanted and possible,
maybe at an enterprise LAN where not all users should be allowed to use the
TURN server, the TURN server must be configured to authenticate the users,
and credentials then be given to the users. However, for such (unusual) use
cases, it is probably easier and better to also give the IP address of the
TURN server itself to the users, so discovery according to this document
would then not be used.”

I think advice about usage of UPD/TCP/TLS/D(TLS) with the turn server
is/shall be out of scope of this draft and left to ICE and the RETURN draft
procedures.

In the case of WebRTC, encryption and man-in-the-middle-attacks are
end-to-end (P2P) considerations and really not affected by the TURN
transport. And if there was a successful attacker, probably smart enough to
buy a certificate for his “smartattacker.com” domain name, how could
(D)TLS’s verification of that certificate help anything? – It will not even
be displayed to the browser user.

Understanding that the network provided TURN server has the same level of
trust as the default gateway as it effectively parallels, there is no reason
for, and nothing good achieved by checking for certificates or similar (you
don’t do that for using the default gateway) – It is not for this
application. Instead, such statements would risks slow down/stop deployment
of network provided TURN servers (and the encryption would hinder the
scenario above, with a gateway router/firewall in front of an ISP network
provided TURN server).

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.

If DHCP cannot be used in a specific network then other discovery mechanisms
discussed in the draft should be used.

[Karl] Fully agree – my intention was only that this (and where it may
apply) is pointed out more clearly in the document.

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

[Karl] Considering what I just wrote above, here is the place to put usage
of UPD/TCP/TLS/D(TLS) out of scope of this document, and/or clarify that
D(TLS) is NOT for typical WebRTC usage. 

-Prashanth 

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”
! :-) 

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

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

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:

[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?

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.

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

(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:

(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

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

Abstract:

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

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Tue, 25 Aug 2015 01:47:34 +0000

Karl,

On 8/17/15, 5:54 AM, "Karl Stahl" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Prashanth,

Thanks,
Karl

Från: Prashanth Patil (praspati) [mailto:[email-masked]]
Skickat: den 14 augusti 2015 02:07
Till: Karl Stahl; Tirumaleswar Reddy (tireddy); 'Simon Perreault'; 'Benjamin Schwartz'; Cullen Jennings (fluffy); 'Adam Roach'
Kopia: [email-masked]<mailto:[email-masked]>
Ämne: Re: [tram] last call on this draft: draft-ietf-tram-turn-server-discovery-03

Hi Karl,

On 7/19/15, 11:34 AM, "tram on behalf of Karl Stahl" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote

<snip>

Not really, you’re intercepting traffic not meant for you.
[Karl] Isn’t that exactly what firewalls do? (and both of us, Cisco and Ingate/Intertex are making such devices…)
Why can’t the gateway router just listen on the designated anycast address instead?
[Karl] It does but must even then follow the same procedure of:  open a path to the TURN server behind the gateway!

My suggestion to add this variant was because what is explained under 4) above:

- by blocking STUN packets a gateway router/firewall can enforce an exo-sealed configuration for a TURN client having a leaky default configuration. If sealed configuration (by some yet unknown configuration method) is done just in browser, it will have the unwanted overhead of sending local real-time traffic twice through the TURN server

AND because of that the scenario of a the gateway router/firewall in front of an ISP network provided TURN server, where both want a sealed configuration where real-time traffic does NOT go through their default gateways, was not outlined here or in the RETURN draft.

The longer answer to your question:
> Why can’t the gateway router just listen on the designated anycast address instead?
is:

If such gateway router/firewall just would advise an OWN TURN server, the browser would have to add yet another level of recursively encapsulating (for two network provided plus one application provided TURN server) - a complication we cannot impose. Instead such gateway, must react to an TURN allocation (by opening a path to the ISP TURN server) – and *as a consequence* the specific anycast address is not needed.

The procedure suggested for the browser (and thus for the RETURN draft) is to handle the situation where the gateway intercepts all TURN allocation requests – that procedure will *also* work if the firewall instead only reacts to the anycast address and sets up a path (and allows the next level to respond to it), while a thinner procedure in the browser may not handle the case where the gateway answers all TURN allocation requests through its default gateway.

So, by outlining this implicit discovery anycast variant, the RETURN draft can recommend a procedure that will work for all cases (that the gateway router/firewall may choose to implement this “kind of TURN allocation proxy” needed when in front of an ISP TURN server.

AND FURTHER, if we know the browser will follow a certain procedure, such gateway router/firewall in front of an ISP TURN server, can auto configure itself by following the TURN allocate requests and responses that passes the gateway router/firewall. I don’t mean it is time to specify such behavior of such gateway router/firewall in any draft, but if we already now also outline  the implicit discovery anycast variant  (The method is only 3 lines of text!) and have the browsers handle it – we have paved the way for easy deployment of network provided TURN servers.

What about if this is explained in the document after those 3 lines defining the implicit discovery anycast variant, like this:
“This is outlines a TURN allocate proxy behavior that a gateway router/firewall in front of an ISP provided TURN server may implement (one of a few variants). If a real-time application like WebRTC defines the usage of TURN for such configuration, it should be possible to work generally.”

I still don’t understand why a GW cannot listen on anycast and return a 300 Try Alternate – you achieve the same thing as intercepting anycast requests flowing through the device.
In any case, I don’t think this draft should deal with this; we should limit discussion to discovering TURN servers. This seems like something that should go into a use-cases/solution guide draft.

<snip>

NEW:

[Karl] Now I think you hit a confusing point that is a source of the authenticate/authorize/credential issue popping up now and again relating to this draft: Here you say “use … without authentication” (meaning that users need not have credentials) followed by “to authenticate” (meaning checking that the TURN server has a valid certificate)

We’ll reword to “validate the the TURN server”.

In http://www.ietf.org/mail-archive/web/tram/current/msg01747.html the question of “authenticate and authorize the discovered TURN server(s)” arose again.
I think the full story must be spelled out clearly, e.g.:
“The purpose of discovery of a network provided TURN server is to find a TURN server offered by a network provider or a network admin, to be used for real-time traffic by the users on that network segment. For WebRTC usage “everywhere you can surf”, such TURN servers must be used without requiring users to have credentials for responding to authentication challenges. Network provided TURN servers must therefore be configured to not challenge allocation requests from the network segment that they serve and the TURN server should only be available to and advertised to those users.
An advertised network provided TURN server, shall simply be interpreted as an advice to use the TURN server path for real-time traffic, instead of using the default gateway path. The level of trust is the same for both paths (since both the default gateway and the TURN server are offered and arranged by the network provider). A sealed configuration (as outlined in draft-ietf-rtcweb-return) can be arranged by the network provider by blocking STUN packets in the default gateway.
For use cases where individual user configuration is wanted and possible, maybe at an enterprise LAN where not all users should be allowed to use the TURN server, the TURN server must be configured to authenticate the users, and credentials then be given to the users. However, for such (unusual) use cases, it is probably easier and better to also give the IP address of the TURN server itself to the users, so discovery according to this document would then not be used.”
I think advice about usage of UPD/TCP/TLS/D(TLS) with the turn server is/shall be out of scope of this draft and left to ICE and the RETURN draft procedures.

We’re talking of (D)TLS in the context of TURN communication, don’t believe it is out of scope.
If a TURN client and server do not use long-term credentials for authentication or third-party authorization, (D)TLS can to be used to validate the TURN server. It also addresses the problem of MIM modifying TURN messages.

TURN client can use the following techniques to validate a TURN server:

   o  For certificate-based authentication, this
      includes a pre-populated trust anchor store [rfc6024] that allows the
      the TURN client to perform path validation for the server certificate obtained
      during the (D)TLS handshake. The client MUST use the rules and guidelines given in section 6 of
      [RFC6125] to validate the TURN server identity.

   o  For TURN servers that don't have a certificate trust chain
      (e.g., because they are on a home network or a corporate network),
      the configured list of TURN servers can contain the Subject
      Public Key Info (SPKI) fingerprint of the TURN servers. The public key is
      used for the same reasons HTTP pinning [RFC7469] uses the public key.

   o  For raw public key-based authentication as defined in [RFC7250], this
      includes either the TURN server's public key or the hash of the
      server's public key.

In the case of WebRTC, encryption and man-in-the-middle-attacks are end-to-end (P2P) considerations and really not affected by the TURN transport. And if there was a successful attacker, probably smart enough to buy a certificate for his “smartattacker.com” domain name, how could (D)TLS’s verification of that certificate help anything? – It will not even be displayed to the browser user.

That is true with any protocol relying on TLS. Certificate validation (from a trusted CA, or a configured fingerprint) is a legitimate means of determining the authenticity of the server.

Understanding that the network provided TURN server has the same level of trust as the default gateway as it effectively parallels, there is no reason for, and nothing good achieved by checking for certificates or similar (you don’t do that for using the default gateway) – It is not for this application. Instead, such statements would risks slow down/stop deployment of network provided TURN servers (and the encryption would hinder the scenario above, with a gateway router/firewall in front of an ISP network provided TURN server).

No, I don’t think it should be seen as something that hinders deployment. Security and privacy are important considerations. A client, that doesn’t care about these, can choose to ignore server validation or exchange messages over plain text.

-Prashanth

---

From: "Karl Stahl" <[email-masked]>
Date: Fri, 28 Aug 2015 12:24:47 +0200

Hi Prashanth,

Please see inline below and also next email (on the Review of
draft-ietf-tram-turn-server-discovery-04 thread)

Thanks,

Karl

Från: tram [mailto:[email-masked]] För Prashanth Patil (praspati)
Skickat: den 25 augusti 2015 03:48
Till: Karl Stahl; [email-masked]
Ämne: Re: [tram] last call on this draft:
draft-ietf-tram-turn-server-discovery-03

Karl,

On 8/17/15, 5:54 AM, "Karl Stahl" <[email-masked]> wrote:

Hi Prashanth,

Thanks,

Karl

Hi Karl,

On 7/19/15, 11:34 AM, "tram on behalf of Karl Stahl" <
<mailto:[email-masked]> [email-masked] on behalf of
<mailto:[email-masked]> [email-masked]> wrote

<snip>

instead?

is:

I still don’t understand why a GW cannot listen on anycast and return a 300
Try Alternate – you achieve the same thing as intercepting anycast requests
flowing through the device.

In any case, I don’t think this draft should deal with this; we should limit
discussion to discovering TURN servers. This seems like something that
should go into a use-cases/solution guide draft.

[Karl 2] The positive thing you achieve by adding this variant is that it
opens and prepares for an easy and better deployment of network provided
TURN servers (e.g. as part of firewalls products), especially when a sealed
configuration is required (the only good way of achieving this is to impose
such configuration this in the firewall). With this variant outlined in this
draft, recommendations  like the RETURN-draft can get the WebRTC usage of
the network provided TURN server right now. I see no drawback whatsoever of
outlining this variant, and the positive things I have already listed.

I am NOT saying this is required for the anycast method to work (which your
comment seems to imply). It works as described already

<snip>

NEW:

[Karl 2] That does not remove the confusion and you are adding wrong
implications by here suggested texts. See below and next email.

We’re talking of (D)TLS in the context of TURN communication, don’t believe
it is out of scope. 

If a TURN client and server do not use long-term credentials for
authentication or third-party authorization, (D)TLS can to be used to
validate the TURN server. It also addresses the problem of MIM modifying
TURN messages.

[Karl 2] In the text below, you must believe that you can achieve and are
achieving something positive in the direction of “Security and privacy are
important considerations.”

(as you say below), by introducing validation of TURN server’s certificate
or fingerprint for a network provided TURN server in the context of WebRTC
usage.

Your are NOT! See further below and next email.

      the TURN client to perform path validation for the server certificate
obtained

      during the (D)TLS handshake. The client MUST use the rules and
guidelines given in section 6 of

      Public Key Info (SPKI) fingerprint of the TURN servers. The public key
is

      server's public key.

That is true with any protocol relying on TLS. Certificate validation (from
a trusted CA, or a configured fingerprint) is a legitimate means of
determining the authenticity of the server.

[Karl 2] The trusted CA doesn’t know anything about whether a certain TURN
server is good or evil or whether the owner of the domain name (whether it
is goodturnserverprovider.com or evilmimattacker.com) has good or evil
intentions and even less about whether the TURN server fulfills any security
or privacy requirement.

[Karl 2] There is no such regulation, testing, certification, register to
achieve anything like this.

[Karl 2] The security improvement we get by accessing a website with https
rather than with http is (in addition to the encryption) ONLY that the user
can be sure of that when he surfs to www.goodcompany.com, he can be sure
that what he gets in his browser actually comes from the owner of the
goodcompany.com domain name.

No, I don’t think it should be seen as something that hinders deployment.
Security and privacy are important considerations. A client, that doesn’t
care about these, can choose to ignore server validation or exchange
messages over plain text.

[Karl 2] No. 

The security ambition level of this draft must stop at providing a
recommendation that:

> network provided TURN server has the same level of trust as the default
gateway as it effectively parallels

Improvements beyond that is NOT in what you suggest, and I believe also out
of scope for this recommendation.

-Prashanth