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

"Karl Stahl" <karl.stahl@intertex.se> Wed, 22 May 2013 09:05 UTC

Return-Path: <karl.stahl@intertex.se>
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 50EF421F8FDB; Wed, 22 May 2013 02:05:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.985
X-Spam-Level:
X-Spam-Status: No, score=0.985 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, MSGID_MULTIPLE_AT=1.449, 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 fNJ7jOfUbfpq; Wed, 22 May 2013 02:05:40 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.152]) by ietfa.amsl.com (Postfix) with ESMTP id A0F2621F8E8E; Wed, 22 May 2013 02:05:36 -0700 (PDT)
Received: from ([79.136.100.76]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201305221104535380; Wed, 22 May 2013 11:04:53 +0200
From: Karl Stahl <karl.stahl@intertex.se>
To: 'Simon Perreault' <simon.perreault@viagenie.ca>, behave@ietf.org, rtcweb@ietf.org
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>
In-Reply-To: <519C7B17.8070405@viagenie.ca>
Date: Wed, 22 May 2013 11:04:34 +0200
Message-ID: <005f01ce56cb$6acb47e0$4061d7a0$@stahl>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac5Wwm4Iz5ivH6XVS8ew4EYtZaoshgABmkjA
Content-Language: sv
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: Wed, 22 May 2013 09:05:45 -0000

> 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.

ICE/TURN/STUN handles both the NAT and firewall issues to a limit.

And the drafts behave-turn-websocket and other about tunneling through
http(s) ports are an attempt to extend the limit where the firewall function
(not NAT) is blocking RTCweb (in this case).

Actually I think ICE/TURN/STUN even works with a firewall that does not have
NAT enabled at all (as long as UDP ports from inside to outside are open to
use). 

Having said that, I of course agree that IETF should not extend TURN with
tunneling to pass through a restrictive firewall.

/Karl
 

-----Ursprungligt meddelande-----
Från: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] För Simon
Perreault
Skickat: den 22 maj 2013 10:00
Till: behave@ietf.org; rtcweb@ietf.org
Ämne: Re: [rtcweb] [BEHAVE] Why? Quality! New Version Notification for
draft-chenxin-behave-turn-websocket-00.txt

Le 2013-05-22 01:02, Karl Stahl a écrit :
> Doesn’t the network administrator that configured the firewall have a 
> legitimate right to decide what traffic should be on his network?

IMHO this is the strongest argument.

STUN/TURN/ICE have always been about NAT traversal. Firewall traversal is a
completely different beast. It implies a kind of battle between the client
and the firewall, where the client implementer is trying to be smarter than
the firewall administrator. This is a battle the IETF should not engage in.
Let the vendors play that game.

Simon
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb