Subject: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-considerations

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 20 Sep 2013 17:06:58 +0000

Hi All,

We have submitted draft-hutton-rtcweb-nat-firewall-considerations-02 in which we have tried to take account of the feedback we have received over the last couple of months.

Please review and send comments to this list I really hope we can make some progress towards adopting this now.

Regards
Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 20 September 2013 15:33
To: [email-masked]
Subject: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : RTCWEB Considerations for NATs, Firewalls and HTTP proxies
	Author(s)       : Thomas Stach
                          Andrew Hutton
                          Justin Uberti
	Filename        : draft-hutton-rtcweb-nat-firewall-considerations-02.txt
	Pages           : 12
	Date            : 2013-09-20

Abstract:
   This document describes mechanism to enable media stream
   establishment for Real-Time Communication in WEB-browsers (WebRTC) in
   the presence of network address translators, firewalls and HTTP
   proxies.  HTTP proxy and firewall deployed in many private network
   domains introduce obstacles to the successful establishment of media
   stream via WebRTC.  This document examines some of these deployment
   scenarios and develops requirements on the web browsers designed to
   provide the best possible chance of media connectivity between WebRTC
   peers.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-hutton-rtcweb-nat-firewall-considerations

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-hutton-rtcweb-nat-firewall-considerations-02

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/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 20 Sep 2013 10:42:26 -0700

Thanks.  The new version is quite a bit more clear.   A question about
Section 2.3: 

      Open issue: Although
      [draft-ietf-rtcweb-use-cases-and-requirements] considers only a
      restriction to HTTP(S) similar consideration apply to other ports as
well.
      or port ranges.  A change to req F37 to "The browser must be able
      to send streams and data to a peer in the presence of FWs that
      only allows traffic via a HTTP Proxy." has been agreed and will be
      in the next update does this solve the issue.

[BA] I found the above somewhat hard to parse.  Is this referring to an
issue with this document, or with the use-case document? 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hutton, Andrew
Sent: Friday, September 20, 2013 10:07 AM
To: [email-masked]
Subject: [pntaw] New version of
draft-hutton-rtcweb-nat-firewall-considerations

Hi All,

We have submitted draft-hutton-rtcweb-nat-firewall-considerations-02 in
which we have tried to take account of the feedback we have received over
the last couple of months.

Please review and send comments to this list I really hope we can make some
progress towards adopting this now.

Regards
Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: 20 September 2013 15:33
To: [email-masked]
Subject: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : RTCWEB Considerations for NATs, Firewalls and HTTP
proxies
	Author(s)       : Thomas Stach
                          Andrew Hutton
                          Justin Uberti
	Filename        :
draft-hutton-rtcweb-nat-firewall-considerations-02.txt
	Pages           : 12
	Date            : 2013-09-20

Abstract:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-hutton-rtcweb-nat-firewall-considerat
ions

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-0
2

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-hutton-rtcweb-nat-firewall-considerat
ions-02

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
pntaw mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pntaw

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 20 Sep 2013 18:11:53 +0000

Hi Bernard,

I agree this is confusing I think it is meant to refer to the use-case document in which the requirement F37 needs to be changed to cater for the case when a HTTP Proxy is deployed and the firewall allows traffic from the proxy. I believe we have already agreed that change to the use-case draft.

Regards
Andy 

> From: Bernard Aboba [mailto:[email-masked]]
> Sent: 20 September 2013 18:42
> To: Hutton, Andrew; [email-masked]
> Subject: RE: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-
> considerations
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sat, 21 Sep 2013 00:32:38 +0200

HI Andrew

Why are you leaving out of scope the case when the WebRTC service is not 
deployed by the corporate organization and/or the HTTP proxy has DPI 
validation?

    When WebRTC is deployed by the corporate IT department one can assume
    that the corporate IT configures the corporate NATs, Firewalls, DPI
    units, TURN servers accordingly.  If so desired by the organization
    WebRTC media streams can then be established to WebRTC peers outside
    of the organization subject to the applied policies.  In order to
    cater for NAT/FWs with address and port dependent mapping
    characteristics [RFC4787  <http://tools.ietf.org/html/rfc4787>], the peers will introduce a TURN server
    [RFC5766  <http://tools.ietf.org/html/rfc5766>] in the public internet as a media relay.  Such a TURN
    server could be deployed by the organization wanting to assert policy
    on WebRTC traffic.

	[...]

    This section considers a scenario where all HTTP(S) traffic is routed
    via an HTTP proxy.  We assume that the HTTP proxy is tranparent and
    just tunnels traffic after e.g. enforcing an acceptable use policy
    with respect to domains that are allowed to be reached.  We don't
    consider cases where the HTTP proxy is used to deploy HTTP traffic
    validation.  This includes DPI validation that the traffic is, in
    fact, HTTP or HTTPS-looking or a HTTP proxy that breaks into the TLS
    exchange and looks for HTTP in the traffic.

In my point of view that is not fullfilling WebRTC requirement:

    F37     The browser must be able to send streams and
            data to a peer in the presence of FWs that only
            allows http(s) traffic.

Best regards
Sergio

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 20 Sep 2013 15:48:30 -0700

Sergio said: 

      "Why are you leaving out of scope the case when the WebRTC service
      is not deployed by the corporate organization and/or the HTTP
      proxy has DPI validation? "
 
[BA ]  My reading of the document is that it is attempting to respect the restrictions set by the firewall administrator.   If UDP and TCP to ports other than 80/443 is denied, and in addition DPI is deployed, then you often will only have a subset of HTTP functionality available to speak to port 80 and maybe a subset of TLS which you can speak to port 443. 
 
This can significantly restrict the choices available.  In my experience, customers denying UDP in/out and only allowing TCP destined to selected ports (e.g. 80/443) as well as deploying DPI validation typically will not allow HTTP CONNECT (or even WebSockets).  
 
We are sometimes successful in making TURN allocation requests over TCP to port 80 or over TLS to port 443 in these scenarios, but TURN over TCP/TLS requests to other ports can fail.  Similarly, one should not expect TURN over WebSockets to work in these kind of installations; the DPI box probably hasn't been updated to handle WebSockets, or if it was, is configured to prevent WebSocket use.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sat, 21 Sep 2013 01:03:10 +0200

El 21/09/2013 0:48, Bernard Aboba escribió:
> Sergio said:
>
> "Why are you leaving out of scope the case when the WebRTC service is 
> not deployed by the corporate organization and/or the HTTP proxy has 
> DPI validation? "
>
> [BA ]  My reading of the document is that it is attempting to respect 
> the restrictions set by the firewall administrator.   If UDP and TCP 
> to ports other than 80/443 is denied, and in addition DPI is deployed, 
> then you often will only have a subset of HTTP functionality available 
> to speak to port 80 and maybe a subset of TLS which you can speak 
> to port 443.

I am not against providing firewall administrators with tools for 
applying corporate policies to outbound connections, in fact I am all 
for it. But in my point of view, if the web part of my service is 
allowed by the company policies (either because it is no black listed, 
or it is whitelisted) then the webrtc part should work also.

>
> This can significantly restrict the choices available.  In my 
> experience, customers denying UDP in/out and only allowing TCP 
> destined to selected ports (e.g. 80/443) as well as deploying DPI 
> validation typically will not allow HTTP CONNECT (or even WebSockets).
>
> We are sometimes successful in making TURN allocation requests over 
> TCP to port 80 or over TLS to port 443 in these scenarios, but TURN 
> over TCP/TLS requests to other ports can fail. Similarly, one should 
> not expect TURN over WebSockets to work in these kind of 
> installations; the DPI box probably hasn't been updated to handle 
> WebSockets, or if it was, is configured to prevent WebSocket use.

Most of webrtc services I have seen so far are using websockets for 
signaling already, so if websockets are not supported by the firewall 
you have bigger problem.
Also, if TURN over TLS on port 443 works (i.e. no DPI in place), secure 
websockets works. So in 100% cases that TURN over TLS works, TURN over 
websocket works too. The other way round is not true.

Best regards
Sergio

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 20 Sep 2013 17:58:04 -0700

Sergio said: 
"Also, if TURN over TLS on port 443 works (i.e. no DPI in place), 
    secure websockets works."
[BA] I have seen DPI boxes that look at the TLS to make sure it is *really* TLS, but if it passes muster (which it might not if you're using extensions or something new like TLS 1.2) then they'll let you through.  So I wouldn't assume that DPI == no TLS.  And yes, if they do let TLS through, then you can do TURN over TLS or secure websockets just as well. 
"So in 100% cases that TURN over TLS works,
    TURN over (secure) websockets works too."
[BA] Agree they would both traverse that firewall equally well, but TURN over (secure) websockets only works if the TURN server supports it, which most won't.   This makes mandating TURN over Webosckets support in the browser a hard sell.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sat, 21 Sep 2013 09:47:35 +0200

>
> "So in 100% cases that TURN over TLS works, TURN over (secure) 
> websockets works too."
>
> [BA] Agree they would both traverse that firewall equally well, but 
> TURN over (secure) websockets only works if the TURN server supports 
> it, which most won't.   This makes mandating TURN over Webosckets 
> support in the browser a hard sell.

We are already working on providing a working prototype of TURN over 
websocket that will show how easy would be to add it to both browser and 
server. In fact, on first phase, we will not change the TURN server at 
all but use a websockify proxy https://github.com/kanaka/websockify to 
the WS to TCP conversion.

Best regards
Sergio

---

From: "Hutton, Andrew" <[email-masked]>
Date: Sat, 21 Sep 2013 22:40:35 +0000

We don't believe that discussing issues around DPI inspection is within scope or desirable and we are not trying to work around it.  However all scenarios that involve accessing WebRTC services from behind a firewall are within scope whether it is a service deployed by an enterprise or not.

Regarding requirement F37 I already raised an issue with this some time ago and a change will be made in the next update to the use case draft. The issue is that this should not refer to a firewall "that only allows HTTP(S) traffic" but should include the case of HTTP Proxy being deployed and the fw allowing traffic from the proxy even if it is not HTTP(S). Once this change gets in to the use case draft I think we are aligned with it.

Regards
Andy

________________________________
From: [email-masked] [[email-masked]] on behalf of Sergio Garcia Murillo [[email-masked]]
Sent: Friday, September 20, 2013 11:32 PM
To: [email-masked]
Subject: Re: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-considerations

HI Andrew

Why are you leaving out of scope the case when the WebRTC service is not deployed by the corporate organization and/or the HTTP proxy has DPI validation?

   When WebRTC is deployed by the corporate IT department one can assume
   that the corporate IT configures the corporate NATs, Firewalls, DPI
   units, TURN servers accordingly.  If so desired by the organization
   WebRTC media streams can then be established to WebRTC peers outside
   of the organization subject to the applied policies.  In order to
   cater for NAT/FWs with address and port dependent mapping
   characteristics [RFC4787<http://tools.ietf.org/html/rfc4787>], the peers will introduce a TURN server
   [RFC5766<http://tools.ietf.org/html/rfc5766>] in the public internet as a media relay.  Such a TURN
   server could be deployed by the organization wanting to assert policy
   on WebRTC traffic.

        [...]

Best regards
Sergio

Hi All,

Regards
Andy

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 20 September 2013 15:33
To: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-02.txt

Abstract:

_______________________________________________
I-D-Announce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
pntaw mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pntaw

---

From: "Hutton, Andrew" <[email-masked]>
Date: Sat, 21 Sep 2013 22:48:08 +0000

I just don't see any advantage in the TURN over Websockets approach over the HTTP Connect initiated tunnel which works without any new protocol and therefore works with existing TURN servers.

Andy

________________________________________
From: [email-masked] [[email-masked]] on behalf of Sergio Garcia Murillo [[email-masked]]
Sent: Saturday, September 21, 2013 8:47 AM
To: Bernard Aboba
Cc: [email-masked]
Subject: Re: [pntaw] New version of     draft-hutton-rtcweb-nat-firewall-considerations

Best regards
Sergio

---

From: Oleg Moskalenko <[email-masked]>
Date: Sat, 21 Sep 2013 17:57:01 -0700

HTTP Connect, indeed, may allow a similar functionality. But it will
require two things: a proxy configuration in the browsers, and an HTTP
Proxy set by enterprise IT department. That may be a challenge for a new
WebRTC project in an enterprise environment.

This draft allows transparent connection and operation, unlike the HTTP
proxy case.

There are tools (websockify) which make possible to use this draft with the
existing TURN servers. Putting the burden on the TURN server provider and
maintainer is easier in most cases than negotiating new IT requirements
with the enterprise IT managers.

Of course, advanced TURN servers may include it as part of the TURN server
implementation.

Oleg

On Sat, Sep 21, 2013 at 3:48 PM, Hutton, Andrew <
[email-masked]> wrote:

>
> I just don't see any advantage in the TURN over Websockets approach over
> the HTTP Connect initiated tunnel which works without any new protocol and
> therefore works with existing TURN servers.
>
> Andy
>
>
>
> From: [email-masked] [[email-masked]] on behalf of Sergio
> Garcia Murillo [[email-masked]]
> Subject: Re: [pntaw] New version of

---

From: Oleg Moskalenko <[email-masked]>
Date: Sat, 21 Sep 2013 18:02:49 -0700

... I was, of course, referring to the "TURN over websockets" draft, as
"this draft".

On Sat, Sep 21, 2013 at 5:57 PM, Oleg Moskalenko <[email-masked]>wrote:

> There are tools (websockify) which make possible to use this draft with
> the existing TURN servers. Putting the burden on the TURN server provider
> and maintainer is easier in most cases than negotiating new IT requirements
>> From: [email-masked] [[email-masked]] on behalf of
>> Sergio Garcia Murillo [[email-masked]]

---

From: "Hutton, Andrew" <[email-masked]>
Date: Sun, 22 Sep 2013 20:57:18 +0000

On: 22 September 2013 01:57 Oleg Moskalenko WroteL
> Proxy set by enterprise IT department. That may be a challenge for a
> new WebRTC project in an enterprise environment.

[AndyH] - The case of an enterprise WebRTC project taking place under the control of the enterprise IT department although within scope is not the prime reason for wanting the HTTP Connect mechanism.  There are various options for this use case and the important thing is that the browser behavior is standardized and understood by the IT department.

Probably more important at least for early deployments is making sure that a WebRTC service external to the enterprise is accessible when there is no IT department or when the IT department is not WebRTC aware and just wants it to work.  The power of WebRTC is that it brings new type of media to the web and it just has to work by default with additional controls possible if the network administrator wants to use them. If an enterprise already has a Web/HTTP Proxy deployed and a firewall configured to allow web traffic to flow via the proxy then this should also work when accessing WebRTC services. This has nothing to do with an enterprise deploying WebRTC for its own use.

> the existing TURN servers. 
> Putting the burden on the TURN server
> provider and maintainer is easier in most cases than negotiating new IT
> requirements with the enterprise IT managers.

[AndyH] As I tried to explain above the use case of prime importance is getting WebRTC to work with existing infrastructure and without requiring an enterprise to deploy stuff just because an enterprise user wants to use a WebRTC service maybe on a single use basis such communicating with a suppliers call centre.

> Of course, advanced TURN servers may include it as part of the TURN
> server implementation.
> 
> Oleg
> 
> On Sat, Sep 21, 2013 at 3:48 PM, Hutton, Andrew <andrew.hutton@siemens-
> enterprise.com> wrote:
> 
> I just don't see any advantage in the TURN over Websockets approach
> over the HTTP Connect initiated tunnel which works without any new
> protocol and therefore works with existing TURN servers.
> 
> Andy
>

---

From: Oleg Moskalenko <[email-masked]>
Date: Sun, 22 Sep 2013 22:36:34 -0700

On Sun, Sep 22, 2013 at 1:57 PM, Hutton, Andrew <
[email-masked]> wrote:

> [AndyH] - The case of an enterprise WebRTC project taking place under the
> control of the enterprise IT department although within scope is not the
> prime reason for wanting the HTTP Connect mechanism.  There are various
> options for this use case and the important thing is that the browser
> behavior is standardized and understood by the IT department.
>
> Probably more important at least for early deployments is making sure that
> a WebRTC service external to the enterprise is accessible when there is no
> IT department or when the IT department is not WebRTC aware and just wants
> it to work.  The power of WebRTC is that it brings new type of media to the
> web and it just has to work by default with additional controls possible if
> the network administrator wants to use them. If an enterprise already has a
> Web/HTTP Proxy deployed and a firewall configured to allow web traffic to
> flow via the proxy then this should also work when accessing WebRTC
> services. This has nothing to do with an enterprise deploying WebRTC for
> its own use.
>

An enterprise may have no HTTP proxy configured by default for the users
but still the enterprise may have some strict firewall rules. I know such
enterprises. Those enterprise projects will benefit from the
TURN-over-websockets protocol.

Each large enterprise IT has a complex history and complex web of policies.
If a new standard provides new capabilities and useful possible scenarios,
without imposing strict rules on IT departments, then I guess that would be
a right thing.

>
> [AndyH] As I tried to explain above the use case of prime importance is
> getting WebRTC to work with existing infrastructure and without requiring
> an enterprise to deploy stuff just because an enterprise user wants to use
> a WebRTC service maybe on a single use basis such communicating with a
> suppliers call centre.
>

I personally do not see anything wrong or criminal in a single use basis.

My understanding is that TURN-over-websockets allows WebRTC deployment
with minimal or no changes in the infrastructure. As I said before, not all
large companies are using HTTP proxy for user browsers.

---

From: Melinda Shore <[email-masked]>
Date: Sun, 22 Sep 2013 21:47:41 -0800

On 9/22/13 9:36 PM, Oleg Moskalenko wrote:
> Each large enterprise IT has a complex history and complex web of
> policies. If a new standard provides new capabilities and useful
> possible scenarios, without imposing strict rules on IT departments,
> then I guess that would be a right thing.

I think this is actually a pretty serious problem, but Elvis,
as they say, has left the building.  The IETF RAI area has
standardized protocols for avoiding the enforcement of local
access policies.  The earlier work on STUN and TURN was to
allow operation across NAT, which is (arguably) not a policy
mechanism, but you all seem to want to extend it to allow
operation across firewalls *which by policy do not permit
the traffic in question*.  It's probably too late to do much
about it but I hope that you're having lots of conversations
with lots of enterprises whose firewalls you're planning on
forcing your way through, to make sure that they're on board
with this.

Melinda

---

From: Oleg Moskalenko <[email-masked]>
Date: Sun, 22 Sep 2013 23:41:35 -0700

On Sun, Sep 22, 2013 at 10:47 PM, Melinda Shore <[email-masked]>wrote:

> but you all seem to want to extend it to allow
Melinda, you are assuming that the policies are a precise accurate
instrument that can be used to set the exact network access rules.

They are not. The reality is that the modern state of network policies is
rather behind the real-world requirements.

I suppose that a real solution would be an "enterprise TURN server" that is
located in the DMZ, and that routes all the TURN-related traffic and the IT
department will handle the policies on the TURN server: user database,
quotas, black and white IP lists, etc. The enterprise IT department is
always free to set such a TURN server. That would merge the two worlds,
perfectly. If they do not want to get into TURN server setup, but there is
a requirement for TURN operations, then there are these new draft specs for
"external" TURN servers.

I've been thinking and working on an "enterprise TURN server" for a while
and I think that eventually the companies will start setting them.

---

From: Melinda Shore <[email-masked]>
Date: Sun, 22 Sep 2013 22:47:03 -0800

On 9/22/13 10:41 PM, Oleg Moskalenko wrote:
> They are not. The reality is that the modern state of network policies
> is rather behind the real-world requirements.

My comfort level with telling people who run networks
that their network access management policies and technologies
are behind the times and because we know better then they
do about these things it's fine if we punch holes in their
firewalls without asking is not very high, to be honest.

At any rate I do think it's worth understanding (yes, I
used the "u" word) that you're using technologies that were
intended to address NAT problems for firewall traversal
and that there are some security issues that need closer
scrutiny, particularly the specifics of how you protect
against abuse by attackers.

Melinda

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 23 Sep 2013 00:01:16 -0700

> firewalls without asking is not very high, to be honest.

This is all not about comfort.

> against abuse by attackers.

I do not think that anybody would be arguing with this rather obvious
observation.

---

From: Melinda Shore <[email-masked]>
Date: Sun, 22 Sep 2013 23:14:41 -0800

> This is all not about comfort.

There is not much value in standardizing technologies which
are not going to be deployed, nor is there value in telling
the people who run networks that they're morons and the IETF
knows better than they do how they should be managing their
access policies.

> I do not think that anybody would be arguing with this rather obvious

It's hard to tell.  One thing that can help a lot is to
actually write the security considerations section of your
documents, rather than filling it in with a "TBD."  Seems to
be a common problem with rtcweb documents, and not at all
reassuring.

Melinda

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 23 Sep 2013 10:57:00 +0200

> forcing your way through, to make sure that they're on board

Hi Melinda,

The fact is that there is already an agreed requirement in WebRTC that 
supports it:

And while we could discuss about it, this would not be the correct 
mailing list to do it.

Given said that, I agree with your view that WebRTC should not force its 
way through
corporate firewalls, punching  open holes and sneaking TURN inside TLS 
to bypass the
enterprise policies.

The TURN over websocket proposal tries to address that issue by playing 
"nice" with
corporate firewalls, by encapsulating the WebRTC media into  legit and 
valid HTTP
traffic.

This will allow IT administrator to allow/block and apply same corporate 
policies to
WebRTC media as they would do with any web content. Without having to 
deploy
any new infrastructure and with the same administrative interfaces as 
they have
today.

Regarding the security section that you mention in a later email, I 
agree with you again
and it is a chapter we would have to address in next versions of the 
draft. Would you
be willing to collaborate in writing it by listing which kind of issues 
would you like to be
covered in there?

Best regards
Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 23 Sep 2013 10:59:20 +0200

El 22/09/2013 0:40, Hutton, Andrew escribió:
>
> We don't believe that discussing issues around DPI inspection is 
> within scope or desirable and we are not trying to work around it.

Why?

>  However all scenarios that involve accessing WebRTC services from 
> behind a firewall are within scope whether it is a service deployed by 
> an enterprise or not.
>
> Regarding requirement F37 I already raised an issue with this some 
> time ago and a change will be made in the next update to the use case 
> draft. The issue is that this should not refer to a firewall "that 
> only allows HTTP(S) traffic" but should include the case of HTTP Proxy 
> being deployed and the fw allowing traffic from the proxy even if it 
> is not HTTP(S). Once this change gets in to the use case draft I think 
> we are aligned with it.

Why are you changing the requirement and cutting the scope so it matches 
your proposed solution? Shouldn't it be the other way round?

Best regards
Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 23 Sep 2013 11:00:16 +0200

> I just don't see any advantage in the TURN over Websockets approach over the HTTP Connect initiated tunnel which works without any new protocol and therefore works with existing TURN servers.

How about transparent proxying?

Best regards
Sergio

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 23 Sep 2013 11:27:37 +0200

> [AndyH] - The case of an enterprise WebRTC project taking place under the control of the enterprise IT department although within scope is not the prime reason for wanting the HTTP Connect mechanis…

If there are various options already available, I would like them to get 
listed in the draft.

> Probably more important at least for early deployments is making sure that a WebRTC service external to the enterprise is accessible when there is no IT department or when the IT department is not WebRTC aware and just wants it to work.  The power of WebRTC is that it brings new type of media to the web and it just has to work by default with additional controls possible if the network administrator wants to use them. If an enterprise already has a Web/HTTP Proxy deployed and a firewall configured to allow web traffic to flow via the proxy then this should also work when accessing WebRTC services. This has nothing to do with an enterprise deploying WebRTC for its own use.I

I am all for "if an enterprise already has a Web/HTTP Proxy deployed and 
a firewall configured to allow web traffic to flow via the proxy then 
this should also work when accessing WebRTC services", but my real life 
experience is that it doesn't.

> [AndyH] As I tried to explain above the use case of prime importance is getting WebRTC to work with existing infrastructure and without requiring an enterprise to deploy stuff just because an enter…

I agree with you also in this and TURN over websockets does not require 
any deployment inside corporations in order to make it work.

Best regards
Sergio

---

From: <[email-masked]>
Date: Mon, 23 Sep 2013 09:35:01 +0000

Hi,

> > instrument that can be used to set the exact network access rules.

I agree it is hard to determine what the policy is based on the actual firewall etc. rules. For instance if all UDP is blocked may not necessarily mean that the high level policy is that VoIP is not allowed. Or, on the other hand, if outbound HTTPS to port 443 is open, it does not necessarily mean that the policy is to allow whatever apps to tunnel whatever traffic that way. 

> My comfort level with telling people who run networks that their network
> access management policies and technologies are behind the times and
> because we know better then they do about these things it's fine if we
> punch holes in their firewalls without asking is not very high, to be honest.
> 

While I'm in general supportive to the proposals in draft-hutton-, I also agree we need to consider the network admin's perspective as well. 

There will be networks and administrators that explicitly want to restrict WebRTC. I think one part of the WebRTC firewall traversal "solution" needs to be an explanation HOW they can do it.

Markus

---

From: <[email-masked]>
Date: Mon, 23 Sep 2013 09:45:46 +0000

Hi,

> How about transparent proxying?

Can you elaborate on this?

I think in either case the proxy sees possibly one transaction. In TURN over HTTP CONNECT established TLS connection, the proxy sees the HTTP CONNECT transaction and it's destination URI. If it's just "transparently" proxying, things will work, which is what we want. On the other hand, if there is some explicit policy, the proxy can also apply it - for instance if the destination domain is now allowed. I'm not sure if the TURN over WS has any advantages in this regard.

The disadvantage is that TURN over WS would require a change to TURN servers. I know you have argued that it is a very trivial change and I believe you, but nevertheless all existing servers would need to be upgraded and that's the problem. 

Markus

---

From: "Chenxin (Xin)" <[email-masked]>
Date: Mon, 23 Sep 2013 10:39:44 +0000

Hi, 

>I agree it is hard to determine what the policy is based on the actual firewall etc.
>rules. For instance if all UDP is blocked may not necessarily mean that the high
>level policy is that VoIP is not allowed. Or, on the other hand, if outbound HTTPS
>to port 443 is open, it does not necessarily mean that the policy is to allow
>whatever apps to tunnel whatever traffic that way.
[xin] yes, we should not focus on the firewall administrator policy, which is hard and should not be judged by us. If the IT admin wants, they always have methods to block webrtc data no matter by http connect or https or turn over websocket.
	Considering webrtc is a web application. A normal or fall-back media or data channel based on web should be considered, it is one benefit of *web*rtc. I think this is the key point we should discuss more. Websocket is a bidirection channel for web, which is wildly used as webrtc signaling channel. It is also really more convenient to carry webrtc data in it as a bidirection channel. I believe it will be better to consider more far for future. 
    About the change to turn server. It is better to add the function to turn server but add a websocket to tcp proxy(websockify) before turn server also work for existed deployment. We are working on this, and will give a simple prototype to validate it.
>While I'm in general supportive to the proposals in draft-hutton-, I also agree we
>need to consider the network admin's perspective as well.
>
>There will be networks and administrators that explicitly want to restrict
>WebRTC. I think one part of the WebRTC firewall traversal "solution" needs to
>be an explanation HOW they can do it.
[xin] I think Markus pointed out an important things. We should discuss about it more to decide if these works is necessary. If media or data of VOIP through http or websocket channel is new thing for firewall, It is better to clarify it , because our target is give a web-fallback channel for a web application.

Regards,
  Xin

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 23 Sep 2013 12:42:56 +0200

+1

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 23 Sep 2013 12:55:22 +0200

> I think in either case the proxy sees possibly one transaction. In TURN over HTTP CONNECT established TLS connection, the proxy sees the HTTP CONNECT transaction and it's destination URI. If it's j…
I was meaning that if a transparent proxy is in place you won't be able 
to do directly the HTTP connect request.

> The disadvantage is that TURN over WS would require a change to TURN servers. I know you have argued that it is a very trivial change and I believe you, but nevertheless all existing servers would…
While I agree, this issue has not been a show-stopper for adopting new 
technologies in WebRTC ;) . Also, there are already other proposals 
(like HTTP REST apis for TURN servers) that would require changes to the 
existing TURN server deployments.

Anyway, in our first prototype, we would try to demonstrate how TURN 
over websockets could be used with an un-modified  TURN server via a 
websockify proxy.

Best regards
Sergio

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 23 Sep 2013 11:21:45 +0000

On: 23 September 2013 10:35 Markus.Isomaki Wrote:
> 
> There will be networks and administrators that explicitly want to
> restrict WebRTC. I think one part of the WebRTC firewall traversal
> "solution" needs to be an explanation HOW they can do it.
> 

I agree with this it is something we need to discuss and elaborate on in the draft.

The motivation behind the draft is to standardize the browser behavior in a way that there is a good chance of WebRTC media traversing firewalls by default but also to make it clear how browsers behave so that policy can be enforced when needed.

Andy

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 23 Sep 2013 11:33:33 +0000

Below.

> From: Sergio Garcia Murillo [mailto:[email-masked]]
> Sent: 23 September 2013 09:59
> To: Hutton, Andrew
> Cc: [email-masked]
> We don't believe that discussing issues around DPI inspection is within
> scope or desirable and we are not trying to work around it.
> 
> Why?
> 

We don't have any use cases relating to this and I think it is a subject we are unlikely to agree on or standardize in the IETF.

> Regarding requirement F37 I already raised an issue with this some time
> ago and a change will be made in the next update to the use case draft.
> The issue is that this should not refer to a firewall "that only allows
> HTTP(S) traffic" but should include the case of HTTP Proxy being
> deployed and the fw allowing traffic from the proxy even if it is not
> HTTP(S). Once this change gets in to the use case draft I think we are
> aligned with it.
> 
> Why are you changing the requirement and cutting the scope so it
> matches your proposed solution? Shouldn't it be the other way round?
>

Because I think the requirement is wrong and too specific so I see the change as widening the scope. The current text also implies a RTP over HTTP solution which has already been discussed and did not get support.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 23 Sep 2013 13:49:02 +0200

> We don't have any use cases relating to this and I think it is a subject we are unlikely to agree on or standardize in the IETF.

I believe it would be better not to remove it from the problem 
statement, keep it as a valid scenario and consider it when evaluating 
the possible solutions.
I am not saying that the final agreed solution should work with DPI 
(although I really  would prefer it does), but at least we should be 
able to get a complete picture on which scenarios are meant to work with 
WebRTC and which ones are not.

Best regards
Sergio

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 23 Sep 2013 13:09:56 +0000

> [email-masked]
> Sent: Monday, September 23, 2013 3:05 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> I agree it is hard to determine what the policy is based on the actual
> firewall etc. rules. For instance if all UDP is blocked may not necessarily
> mean that the high level policy is that VoIP is not allowed. 

Good point. The current technique Firewalls in Enterprise use are "block UDP by default" and also perform SIP inspection (ALG). Firewall pin-holes are opened/closed for UDP media streams based on SIP ALG.

-Tiru.

> Or, on the other
> hand, if outbound HTTPS to port 443 is open, it does not necessarily mean that
> the policy is to allow whatever apps to tunnel whatever traffic that way.
> 
> While I'm in general supportive to the proposals in draft-hutton-, I also
> agree we need to consider the network admin's perspective as well.
>

---

From: Melinda Shore <[email-masked]>
Date: Mon, 23 Sep 2013 08:06:59 -0800

> "solution" needs to be an explanation HOW they can do it.

That seems reasonable to me - the network administrator really
needs to be able to say "no" to certain kinds of traffic,
including WebRTC traffic.  I'm not sure that it's possible
to allow more finely-grained policy, which might be desirable,
but this is a start and something to discuss with people who
actually run networks.

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Mon, 23 Sep 2013 08:11:01 -0800

> be willing to collaborate in writing it by listing which kind of issues

Yes, definitely.  The state of security considerations
text is something that should be considered a priority.
FWIW I don't think that protecting pinhole-punching
technologies from being subverted by attackers is easy.

Melinda

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 23 Sep 2013 13:28:51 -0700

On Mon, Sep 23, 2013 at 9:11 AM, Melinda Shore <[email-masked]>wrote:

> > Would you
> Yes, definitely.

That's great !

> The state of security considerations

This is a grey area of the technology and addressing some areas of concerns
would be very helpful.

The difficulties are objective and natural because the whole field of NAT
technology (and the fact that NAT deployment and firewall deployment are
related) is somewhat of imperfect nature.