IETF Logo Mail Archive

Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt

"Hutton, Andrew" <andrew.hutton@siemens-enterprise.com> Thu, 23 May 2013 13:09 UTC

Return-Path: <andrew.hutton@siemens-enterprise.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 2298421F93B1; Thu, 23 May 2013 06:09:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.787
X-Spam-Level:
X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[AWL=-0.578, BAYES_00=-2.599, PLING_QUERY=1.39]
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 HuWam1ftClVd; Thu, 23 May 2013 06:08:57 -0700 (PDT)
Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 421F121F93BC; Thu, 23 May 2013 06:08:55 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 481C41EB8648; Thu, 23 May 2013 15:08:54 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.159]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0328.009; Thu, 23 May 2013 15:08:54 +0200
From: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>
To: Simon Perreault <simon.perreault@viagenie.ca>, Karl Stahl <karl.stahl@intertex.se>
Thread-Topic: [BEHAVE] [rtcweb] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt
Thread-Index: AQHOVs8PvK/QKOM3AUmVgv4HMJ4KjZkSvTfQ
Date: Thu, 23 May 2013 13:08:53 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF115A0F16@MCHP04MSX.global-ad.net>
References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com> <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <BLU169-W4995BC8B88C6AD60F4CA5093A20@phx.gbl> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net> <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it> <9F33F40F6F2CD847824537F3C4E37DDF1159E317@MCHP04MSX.global-ad.net> <000001ce5677$4b471650$e1d542f0$@stahl@intertex.se> <519C7B17.8070405@viagenie.ca> <005f01ce56cb$6acb47e0$4061d7a0$@stahl@intertex.se> <519C904B.2040305@viagenie.ca>
In-Reply-To: <519C904B.2040305@viagenie.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "behave@ietf.org" <behave@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-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: Thu, 23 May 2013 13:09:01 -0000

At least with regard to draft-hutton-rtcweb-nat-firewall-considerations we are not attempting to enter or add to any existing arms race between clients and firewalls.

We are only describing how to use existing IETF protocols which already extensively discuss firewall traversal (E.g. TURN / RFC 5766) to meet the RTCWEB requirements in this area which have existed in http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-10 for almost two years now.

Of course if a network administer wants to block RTCWEB media they should be able to so and nobody is I believe suggesting that we try to prevent this.

Regards
Andy



> -----Original Message-----
> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On
> Behalf Of Simon Perreault
> Sent: 22 May 2013 10:31
> To: Karl Stahl
> Cc: rtcweb@ietf.org; behave@ietf.org
> Subject: Re: [BEHAVE] [rtcweb] Why? Quality! New Version Notification
> for draft-chenxin-behave-turn-websocket-00.txt
> 
> Le 2013-05-22 11:04, Karl Stahl a écrit :
> >> Firewall traversal is a completely different beast.
> >
> > Not really. There are always firewall functions included in "a NAT"
> (e.g.
> > open for traffic from inside to outside and you can then get traffic
> back
> > the same path - with some timeout), even if the RFCs only call the
> box "a
> > NAT". I prefer to say NAT/Firewall.
> 
> You're focusing on the technical aspect. The difference I'm considering
> is not technical.
> 
> NAT traversal is performed with the agreement of everyone involved,
> whereas firewall traversal is a battle between the client implementer
> and the firewall administrator. There's also a potential arms race:
> firewalls will evolve with the ability to block whatever we
> standardize,
> so we will need a newer traversal method, which firewalls will end up
> blocking as well, etc. etc. etc. We don't want to play that game.
> 
> NAT traversal: ok
> Firewall traversal: not for the IETF
> 
> Simon
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave

v2.23.0 | Report a Bug | By Email