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

Simon Perreault <> Wed, 22 May 2013 09:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7DA5421F9640; Wed, 22 May 2013 02:30:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=-0.637, BAYES_00=-2.599, NO_RELAYS=-0.001, PLING_QUERY=1.39]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZbBkohnjdwa0; Wed, 22 May 2013 02:30:43 -0700 (PDT)
Received: from ( [IPv6:2620:0:230:8000::2]) by (Postfix) with ESMTP id CDA0A21F963C; Wed, 22 May 2013 02:30:42 -0700 (PDT)
Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:f83b:cff2:9a05:711]) by (Postfix) with ESMTPSA id 529C747143; Wed, 22 May 2013 05:30:41 -0400 (EDT)
Message-ID: <>
Date: Wed, 22 May 2013 11:30:51 +0200
From: Simon Perreault <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Karl Stahl <>
References: <> <> <BLU169-W4995BC8B88C6AD60F4CA5093A20@phx.gbl> <> <> <> <> <> <> <000001ce5677$4b471650$e1d542f0$> <> <005f01ce56cb$6acb47e0$4061d7a0$>
In-Reply-To: <005f01ce56cb$6acb47e0$4061d7a0$>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [BEHAVE] [rtcweb] Why? Quality! New Version Notification for draft-chenxin-behave-turn-websocket-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 May 2013 09:30:44 -0000

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