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

"Chenxin (Xin)" <hangzhou.chenxin@huawei.com> Wed, 22 January 2014 12:03 UTC

Return-Path: <hangzhou.chenxin@huawei.com>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DBD1A043E for <pntaw@ietfa.amsl.com>; Wed, 22 Jan 2014 04:03:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.736
X-Spam-Level:
X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwKJNfcD6J2O for <pntaw@ietfa.amsl.com>; Wed, 22 Jan 2014 04:03:35 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 992931A043D for <pntaw@ietf.org>; Wed, 22 Jan 2014 04:03:34 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAH50356; Wed, 22 Jan 2014 12:03:33 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Jan 2014 12:03:20 +0000
Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 22 Jan 2014 12:03:32 +0000
Received: from SZXEMA504-MBX.china.huawei.com ([169.254.7.191]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Wed, 22 Jan 2014 20:03:25 +0800
From: "Chenxin (Xin)" <hangzhou.chenxin@huawei.com>
To: "Hutton, Andrew" <andrew.hutton@unify.com>, "pntaw@ietf.org" <pntaw@ietf.org>
Thread-Topic: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-03.txt
Thread-Index: AQHPFdOd2Vn6yFd4yUSx85JgARaXd5qNhEhAgAMSnnCAABDIoA==
Date: Wed, 22 Jan 2014 12:03:24 +0000
Message-ID: <9E34D50A21D1D1489134B4D770CE0397680AA8CE@SZXEMA504-MBX.china.huawei.com>
References: <9F33F40F6F2CD847824537F3C4E37DDF17CBE35E@MCHP04MSX.global-ad.net> <9E34D50A21D1D1489134B4D770CE0397680AA8A5@SZXEMA504-MBX.china.huawei.com>
In-Reply-To: <9E34D50A21D1D1489134B4D770CE0397680AA8A5@SZXEMA504-MBX.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.17.195]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [pntaw] I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-03.txt
X-BeenThere: pntaw@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <pntaw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pntaw>, <mailto:pntaw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pntaw/>
List-Post: <mailto:pntaw@ietf.org>
List-Help: <mailto:pntaw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pntaw>, <mailto:pntaw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2014 12:03:37 -0000

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

Best Regards,
     Xin 


>-----Original Message-----
>From: pntaw [mailto:pntaw-bounces@ietf.org] On Behalf Of Chenxin (Xin)
>Sent: Wednesday, January 22, 2014 7:48 PM
>To: Hutton, Andrew; pntaw@ietf.org
>Subject: Re: [pntaw] I-D Action:
>draft-hutton-rtcweb-nat-firewall-considerations-03.txt
>
>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
>
>
>>-----Original Message-----
>>From: pntaw [mailto:pntaw-bounces@ietf.org] On Behalf Of Hutton, Andrew
>>Sent: Monday, January 20, 2014 8:10 PM
>>To: pntaw@ietf.org
>>Subject: [pntaw] FW: I-D Action:
>>draft-hutton-rtcweb-nat-firewall-considerations-03.txt
>>
>>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:i-d-announce-bounces@ietf.org] On Behalf Of
>>internet-drafts@ietf.org
>>Sent: 20 January 2014 11:35
>>To: i-d-announce@ietf.org
>>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-consideratio
>ns
>>/
>>
>>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-consideratio
>ns
>>-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
>>I-D-Announce@ietf.org
>>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
>>pntaw@ietf.org
>>https://www.ietf.org/mailman/listinfo/pntaw
>_______________________________________________
>pntaw mailing list
>pntaw@ietf.org
>https://www.ietf.org/mailman/listinfo/pntaw