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

"Reinaldo Penno (repenno)" <repenno@cisco.com> Mon, 11 March 2013 18:03 UTC

Return-Path: <repenno@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6372521F8A98 for <rtcweb@ietfa.amsl.com>; Mon, 11 Mar 2013 11:03:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.521
X-Spam-Level:
X-Spam-Status: No, score=-10.521 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nys6AsMh2-6a for <rtcweb@ietfa.amsl.com>; Mon, 11 Mar 2013 11:03:00 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDF811E80F2 for <rtcweb@ietf.org>; Mon, 11 Mar 2013 11:02:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4141; q=dns/txt; s=iport; t=1363024979; x=1364234579; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=hh/58cDLTwHjWPjfvuSlULvbHE6sK4vrIhqP/raNGfA=; b=gvwpdOUd3/HW1EzOOODj1d/l1p6Izw2gEtqfDzUxz0rCr2A1tdGHMV2b SMnTI7TzOttLFbgt0baeJYMlusAycajWBGr/mm/7T8wQaaUrwmVta5wV3 HF4JZC15EvRa2q1xT7Huefrni96uaFnLzNV1egzUqS3UDoRXZyEefTaBL k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAGMbPlGtJV2b/2dsb2JhbABDxGKBXxZ0gikBAQEEAQEBNzQXBgEIEQQBAQEKFAkuCxQIAQgCBAESCAGICgy+MBeOXSYNBQaCWWEDl3OKQYUWgVSBNoIo
X-IronPort-AV: E=Sophos;i="4.84,825,1355097600"; d="scan'208";a="183206749"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 11 Mar 2013 18:02:58 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2BI2wo2014181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Mar 2013 18:02:58 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Mon, 11 Mar 2013 13:02:58 -0500
From: "Reinaldo Penno (repenno)" <repenno@cisco.com>
To: Harald Alvestrand <harald@alvestrand.no>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
Thread-Index: AQHOHoKpVPM3WtZH0EiYxevcVicwOg==
Date: Mon, 11 Mar 2013 18:02:57 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040901B3A9@xmb-rcd-x04.cisco.com>
In-Reply-To: <513E146D.4060009@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.86.245.189]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <343B43A414E95747BCFA6927E424597C@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-00.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Mar 2013 18:03:01 -0000

Hello,

On 3/11/13 10:29 AM, "Harald Alvestrand" <harald@alvestrand.no> wrote:

>On 03/11/2013 06:04 PM, Reinaldo Penno (repenno) wrote:
>> Hello,
>>
>> Why not use Port Control Protocol (PCP) to control Firewalls and NATs
>> explicitly?
>We can switch to that as soon as 100% of firewalls support it - until
>then, we have to be able to rely on other techniques.

I'm sure STUN and TURN servers are not universally deployed ('100%') in
ISP networks either.

But I'm not proposing dropping STUN/TURN in lieu of PCP, but using PCP as
an additional technique. Maybe you misunderstood what I was proposing.


>
>That's the deployment problem in a nutshell... I don't understand how
>the first firewall gets an advantage from having PCP, given that none of
>the apps support it, and I don't understand how the first app gets an
>advantage from having PCP, given that no firewalls support it.
>
>If PCP succeeds despite my misgivings, we can certainly revisit the issue.

I believe it should be considered as a viable option now since it is a
specific protocol to control NATs/Firewalls and Flow-aware devices
required Pv6 CPE requirements document, Broadband Forum and 3GPP specs.



>
>>
>> Thanks,
>>
>> On 3/11/13 9:56 AM, "Hutton, Andrew"
>> <andrew.hutton@siemens-enterprise.com> wrote:
>>
>>> FYI - We submitted this draft today it relates to the requirements in
>>>the
>>> use case draft for rtcweb to work in the presence of firewalls and http
>>> proxies etc.
>>>
>>> Look forward to feedback and hope that this can be considered for
>>> adoption by the working group.
>>>
>>> Regards
>>> Andy
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: i-d-announce-bounces@ietf.org
>>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of
>>> internet-drafts@ietf.org
>>> Sent: 11 March 2013 06:01
>>> To: i-d-announce@ietf.org
>>> Subject: I-D Action:
>>> draft-hutton-rtcweb-nat-firewall-considerations-00.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-00.txt
>>> 	Pages           : 8
>>> 	Date            : 2013-03-11
>>>
>>> Abstract:
>>>    This document describes mechanism to enable media stream
>>>    establishment in the presence of NATs, firewalls and HTTP proxies.
>>>    HTTP proxy and firewall policies applied in many private network
>>>    domains introduce obstacles to the successful establishment of media
>>>    stream via RTCWEB.  This document examines some of these policies
>>>and
>>>    develops requirements on the web browsers designed to provide the
>>>    best possible chance of media connectivity between RTCWEB peers.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> 
>>>https://datatracker.ietf.org/doc/draft-hutton-rtcweb-nat-firewall-consid
>>>er
>>> ations
>>>
>>> There's also a htmlized version available at:
>>> 
>>>http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-consideratio
>>>ns
>>> -00
>>>
>>>
>>> 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
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb