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

Harald Alvestrand <harald@alvestrand.no> Mon, 11 March 2013 20:04 UTC

Return-Path: <harald@alvestrand.no>
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 8A98821F8E5F for <rtcweb@ietfa.amsl.com>; Mon, 11 Mar 2013 13:04:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100]
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 qNYJXbabTn5X for <rtcweb@ietfa.amsl.com>; Mon, 11 Mar 2013 13:04:25 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8226C21F8E67 for <rtcweb@ietf.org>; Mon, 11 Mar 2013 13:04:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 896F539E1C4; Mon, 11 Mar 2013 21:04:22 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ki67uJAGX8Ew; Mon, 11 Mar 2013 21:04:22 +0100 (CET)
Received: from [IPv6:2001:df8:0:16:b4fd:eac0:98eb:c482] (unknown [IPv6:2001:df8:0:16:b4fd:eac0:98eb:c482]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1D95539E1AD; Mon, 11 Mar 2013 21:04:20 +0100 (CET)
Message-ID: <513E38BD.6070105@alvestrand.no>
Date: Mon, 11 Mar 2013 21:04:13 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: "Reinaldo Penno (repenno)" <repenno@cisco.com>
References: <45A697A8FFD7CF48BCF2BE7E106F06040901B656@xmb-rcd-x04.cisco.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040901B656@xmb-rcd-x04.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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 20:04:25 -0000

On 03/11/2013 08:52 PM, Reinaldo Penno (repenno) wrote:
>
> On 3/11/13 12:34 PM, "Hannes Tschofenig" <hannes.tschofenig@gmx.net> wrote:
>
>> On Mar 11, 2013, at 2:02 PM, Reinaldo Penno (repenno) wrote:
>>
>>>>> 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.
>> STUN and TURN don't require any support from ISPs.
> If ISPs want to provide RTCweb like services don't they need STUN and TURN
> Servers so that ICE can gather candidates?

ISPs may want to offer services. But that's independent of their role as 
ISPs.
Anyone can offer a STUN or TURN server, and they can be anywhere on the 
Internet.

PCP, on the other hand, has to be available on the specific firewall or 
NAT box you intend to traverse. If it isn't there, it won't work.
>> Both protocols are used today.
> Yes, today. But that did not stop design decisions to include these
> protocols in ICE at a they time were not deployed at all.

Sorry, I can't parse that.

ICE was deployed to support applications that needed ICE; there was no 
need to deploy more than 1 STUN/TURN server in order to start using STUN 
and TURN.