Subject: [pntaw] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-03.txt

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 20 Jan 2014 12:09:39 +0000

I updated draft-hutton-rtcweb-nat-firewall-consideration.

The main change is that the draft now explores the different options that are available for handling such things as HTTP Proxies in a WebRTC environment and no longer recommends a specific solution. 

Would be good to restart the discussion on these options and determining the best way forward to ensuring we get some defined standardized behavior for WebRTC for these scenarios.

So please go ahead and make comments.

Regards
Andy

-----Original Message-----
From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 20 January 2014 11:35
To: [email-masked]
Subject: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-03.txt

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

        Title           : RTCWEB Considerations for NATs, Firewalls and HTTP proxies
        Authors         : Thomas Stach
                          Andrew Hutton
                          Justin Uberti
	Filename        : draft-hutton-rtcweb-nat-firewall-considerations-03.txt
	Pages           : 14
	Date            : 2014-01-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 specifies requirements on WebRTC enabled 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-03

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

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: "Hutton, Andrew" <[email-masked]>
Date: Tue, 21 Jan 2014 09:27:05 +0000

I probably should have referenced draft-penno-rtcweb-pcp-00 in our firewall considerations draft.

However I just noticed it has expired do the authors intend to maintain this draft?

Regards
Andy

> From: pntaw [mailto:[email-masked]] On Behalf Of Hutton, Andrew
> Sent: 20 January 2014 12:10
> To: [email-masked]
> Subject: [pntaw] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-
> considerations-03.txt
> 
> The main change is that the draft now explores the different options
> that are available for handling such things as HTTP Proxies in a WebRTC
> environment and no longer recommends a specific solution.
> 
> Would be good to restart the discussion on these options and
> determining the best way forward to ensuring we get some defined
> standardized behavior for WebRTC for these scenarios.
> 
> pntaw mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pntaw

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 21 Jan 2014 09:36:56 +0000

> From: Hutton, Andrew [mailto:[email-masked]]
> Sent: Tuesday, January 21, 2014 2:57 PM
> To: [email-masked]; Tirumaleswar Reddy (tireddy); Dan Wing (dwing);
> [email-masked]; Reinaldo Penno (repenno); Reinaldo
> Penno (repenno)
> Subject: RE: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-
> 03.txt
> 
> However I just noticed it has expired do the authors intend to maintain this
> draft ?

Hi Andy,

Yes, we plan to the update the draft with a new section explaining how PCP can also be used to prioritize over-the-top WebRTC media in local and immediately adjacent access networks. 

Cheers,
-Tiru.

> > that are available for handling such things as HTTP Proxies in a
> > WebRTC environment and no longer recommends a specific solution.
> >
> > 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-Draft directories: http://www.ietf.org/shadow.html or
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 21 Jan 2014 01:37:10 -0800

I have a comment on section 5 of the document.

One thing that I'd definitely like to see enforced in the browser's
implementation of the TURN client protocol is the support of 300 Alternate
Server error message. This is becoming an issue because of the possible
volume of the WebRTC media traffic. If the browsers are supporting the
error 300, then a TURN server administrator can relatively easy set a load
balancing scheme. If the browsers do not support it, then it becomes a more
complicated issue and an implementation-dependent procedure.

As far as I know, no current browser supports 300 response from TURN
server. It would be very nice if the TURN server administrator could rely
on that feature.

Oleg

On Mon, Jan 20, 2014 at 4:09 AM, Hutton, Andrew <[email-masked]>wrote:

> The main change is that the draft now explores the different options that
> are available for handling such things as HTTP Proxies in a WebRTC
> Would be good to restart the discussion on these options and determining
> the best way forward to ensuring we get some defined standardized behavior
> for WebRTC for these scenarios.
>
>         Filename        :
> draft-hutton-rtcweb-nat-firewall-considerations-03.txt
>         Pages           : 14
>         Date            : 2014-01-20
>
> Abstract:
> submission

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 21 Jan 2014 11:01:14 +0000

Hi Oleg,

I am thinking this maybe should be a comment against http://tools.ietf.org/html/draft-ietf-rtcweb-transports-01#section-2.2 but would be happy to add it to draft-hutton-rtcweb-nat-firewall-considerations if people think it is the right place.

Regards
Andy

> From: Oleg Moskalenko [mailto:[email-masked]]
> Sent: 21 January 2014 09:37
> To: Hutton, Andrew
> Cc: [email-masked]
> Subject: Re: [pntaw] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-
> considerations-03.txt
> 
> implementation of the TURN client protocol is the support of 300
> Alternate Server error message. This is becoming an issue because of
> the possible volume of the WebRTC media traffic. If the browsers are
> supporting the error 300, then a TURN server administrator can
> relatively easy set a load balancing scheme. If the browsers do not
> support it, then it becomes a more complicated issue and an
> implementation-dependent procedure.
> server. It would be very nice if the TURN server administrator could
> rely on that feature.
> 
> Oleg
> 
> On Mon, Jan 20, 2014 at 4:09 AM, Hutton, Andrew
> <[email-masked]> wrote:

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 21 Jan 2014 15:45:56 +0100

> I am thinking this maybe should be a comment against http://tools.ietf.org/html/draft-ietf-rtcweb-transports-01#section-2.2 but would be happy to add it to draft-hutton-rtcweb-nat-firewall-consider…

It's not specifically a firewall issue (it applies every time you have a 
NAT), so I think -transport- is the right place for it (and discussion 
should be on the RTCWEB list).

---

From: Simon Perreault <[email-masked]>
Date: Tue, 21 Jan 2014 10:06:29 -0500

Le 2014-01-21 04:37, Oleg Moskalenko a écrit :
> If the browsers are supporting the error 300, then a TURN server
> administrator can relatively easy set a load balancing scheme. If
> the browsers do not support it, then it becomes a more complicated
> issue and an implementation-dependent procedure.
>

+1

In addition, I believe the missing keyword to understand the importance 
of this is "anycast".

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 21 Jan 2014 09:31:49 -0800

Harald, if you think that your "transports" draft is the right place to
include the 300 response requirement, and you do not mind including it,
then I am fine with that.

Thanks
Oleg

On Tue, Jan 21, 2014 at 6:45 AM, Harald Alvestrand <[email-masked]>wrote:

>> I am thinking this maybe should be a comment against
>> http://tools.ietf.org/html/draft-ietf-rtcweb-transports-01#section-2.2but would be happy to add it to draft-hutton-rtcweb-nat-firewall-considerations
>> if people think it is the right place.
>>
>

---

From: "Chenxin (Xin)" <[email-masked]>
Date: Wed, 22 Jan 2014 11:47:38 +0000

Hi,

   I have a question on the this draft:

  1. Section 2.3. NAT/Firewall open only for TCP on restricted ports

       In this case the firewall blocks all outgoing traffic except for TCP
   traffic to specific ports, for example port 80 (HTTP) for HTTP or 443
   for HTTPS(HTTPS).  A TURN server listening to its default ports (3478
   for TCP/UDP, 5349 for TLS) would not be reachable in this case.
   However, the TURN server can still be reached when it is configured
   to listen to e.g. the HTTP(S) ports.

   If It is possible that, NAT/Firewall forbid none-http data on 80/443, which will make the client failed to connect to turn server.

   I want there could be a discussion on that scenario --
      ' NAT/Firewall open only for http packet on restricted ports without the presence of http proxy'
   Is such kind of scene common and valuable to webrtc application?  Need we consider such nat/fw case and requirement? should we handle this now or consider it as a future research.
　 I think this mailing list is the right place to discuss it.

  2. Section 3.3
     All scenarios besides this have a solution to make webrtc application successful. I still think recommend solution should be added. In my opinion, http connection, alpn, turn over websocket are candidates. 

  3. Requirements for RTCWEB-enabled browsers

    " support a mechanism for connecting to a TURN server in the
      presence of a firewall that only permits connections that orginate
      from a HTTP Proxy.  The mechanism is for further study."

     Why a future study mechanism becomes a requirement?  for section 3.3?

    "use the same proxy selection procedure for TURN as currently done
      for HTTP (e.g. Web Proxy Autodiscovery Protocol (WPAD) and .pac-
      files for Proxy-Auto-Config)"

      I do not understand  why you put this requirement in the draft. Which scenario is it relared to?

   4. confusion about the discussion on pntaw?

     I think the pntaw is established for rtcweb transport areas. However, Because of no chairs, there were many discussion but no decision. I do not know if rtcweb agenda have considered the discussion in pntaw, at least I did not see it in IETF88. I still think there should be a way to conclude and make decision on related topics on pntaw. I suggest chairs could leave some time slot for pntaw topics in IETF89, or other ways. After all, pntaw is a sub-list of rtcweb. 

Best Regards,
     Xin 

>Sent: Monday, January 20, 2014 8:10 PM
>To: [email-masked]
>Subject: [pntaw] FW: I-D Action:
>The main change is that the draft now explores the different options that are
>available for handling such things as HTTP Proxies in a WebRTC environment and
>no longer recommends a specific solution.
>
>Would be good to restart the discussion on these options and determining the
>best way forward to ensuring we get some defined standardized behavior for
>WebRTC for these scenarios.
>

---

From: "Chenxin (Xin)" <[email-masked]>
Date: Wed, 22 Jan 2014 12:03:24 +0000

Besides , I support that this draft should be considered to be accepted by rtcweb-transport documents too.

Best Regards,
     Xin 

>From: pntaw [mailto:[email-masked]] On Behalf Of Chenxin (Xin)
>Sent: Wednesday, January 22, 2014 7:48 PM
>To: Hutton, Andrew; [email-masked]
>Subject: Re: [pntaw] I-D Action:
>   If It is possible that, NAT/Firewall forbid none-http data on 80/443, which will
>make the client failed to connect to turn server.
>
>   Is such kind of scene common and valuable to webrtc application?  Need we
>consider such nat/fw case and requirement? should we handle this now or
>consider it as a future research.
>     All scenarios besides this have a solution to make webrtc application
>successful. I still think recommend solution should be added. In my opinion, http
>connection, alpn, turn over websocket are candidates.
>
>     I think the pntaw is established for rtcweb transport areas. However,
>Because of no chairs, there were many discussion but no decision. I do not know
>if rtcweb agenda have considered the discussion in pntaw, at least I did not see it
>in IETF88. I still think there should be a way to conclude and make decision on
>related topics on pntaw. I suggest chairs could leave some time slot for pntaw
>topics in IETF89, or other ways. After all, pntaw is a sub-list of rtcweb.
>
>
>Best Regards,
>     Xin
>
>
>>https://datatracker.ietf.org/doc/draft-hutton-rtcweb-nat-firewall-consideratio
>ns
>>/
>>
>>http://www.ietf.org/rfcdiff?url2=draft-hutton-rtcweb-nat-firewall-consideratio
>ns
>>-03
>>
>>