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

Cameron Byrne <cb.list6@gmail.com> Tue, 12 March 2013 02:51 UTC

Return-Path: <cb.list6@gmail.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 AC75721F8B35 for <rtcweb@ietfa.amsl.com>; Mon, 11 Mar 2013 19:51:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.32
X-Spam-Level:
X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 IsPIifG6EVj4 for <rtcweb@ietfa.amsl.com>; Mon, 11 Mar 2013 19:51:32 -0700 (PDT)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5D43A21F8A9B for <rtcweb@ietf.org>; Mon, 11 Mar 2013 19:51:32 -0700 (PDT)
Received: by mail-wg0-f41.google.com with SMTP id ds1so2787133wgb.0 for <rtcweb@ietf.org>; Mon, 11 Mar 2013 19:51:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=o8knrnSbFE4nxyS7wXu/rfSc1uXtASg5jPeKx1de9J4=; b=IaDzufcjEi545ywbUmLfth2Wu92jSMeMJoJGgH1JqnZuB0jkTXjzqbkXjizQhHz3uO dbUk0e6yxou8yN3ttVAW5lz+J219sxIF3ltl3QArSqozPzUaGhK7aJez0dIGdnugcITc 1UOTP2ohw5vw8HC2ACawGfo7N2IqvWbwcyzjB167h7ZCyKowYHVQ2kzJ23UD+vIgRPSF j9UAma22KLNCQbgr3SY4TnAQogzYgZFIOhH5AwpP6zCByov2X07D9Elu5ehPSdFUEtAE 1dnMbas4+8FQ1ACP6uS/C0w2yaIQJaLDQjSF6usQmFeblEjCOFX9KFE/wnsuIaIVABf3 Q6Zw==
MIME-Version: 1.0
X-Received: by 10.194.242.163 with SMTP id wr3mr23254857wjc.35.1363056691510; Mon, 11 Mar 2013 19:51:31 -0700 (PDT)
Received: by 10.194.20.35 with HTTP; Mon, 11 Mar 2013 19:51:31 -0700 (PDT)
Received: by 10.194.20.35 with HTTP; Mon, 11 Mar 2013 19:51:31 -0700 (PDT)
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040901BC8F@xmb-rcd-x04.cisco.com>
References: <CAD6AjGSCQME2mqKNawqtBoFvUq_URZ8mTFK94oX=aV8QrVj2tQ@mail.gmail.com> <45A697A8FFD7CF48BCF2BE7E106F06040901BC8F@xmb-rcd-x04.cisco.com>
Date: Mon, 11 Mar 2013 19:51:31 -0700
Message-ID: <CAD6AjGQwv=eS0-grpOmWQu9rL2jU+XBdVHBmvycq8WXHqA224Q@mail.gmail.com>
From: Cameron Byrne <cb.list6@gmail.com>
To: repenno@cisco.com
Content-Type: multipart/alternative; boundary=089e013d1da8e8045f04d7b15d07
Cc: 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: Tue, 12 Mar 2013 02:51:33 -0000

On Mar 11, 2013 7:46 PM, "Reinaldo Penno (repenno)" <repenno@cisco.com>
wrote:
>
> Agree with you on e2e IPv6 would be ideal. PCP is well suited to control
> IPv6 firewalls and it is one of the main use-cases as part of IPV6 CPE
> requirements RFC. Unless you think with IPv6 there will no IPv6 firewalls.
>

That is my plan. Ipv6 e2e ftw.

CB

> On 3/11/13 9:57 PM, "Cameron Byrne" <cb.list6@gmail.com> wrote:
>
> >On Mon, Mar 11, 2013 at 6:42 PM,  <Markus.Isomaki@nokia.com> wrote:
> >> Hi,
> >>
> >> ICE/STUN/TURN and PCP are not really competitors or alternatives to
> >>each other.
> >>
> >> A browser or any other client will anyway need to implement
> >>ICE/STUN/TURN to work its way through non-PCP supporting NATs, which
> >>will be the majority for a long time even if PCP became succesfull. The
> >>benefit of the ICE/STUN/TURN approach is that every organization or
> >>individual who deploys NATs or firewalls will not need to deploy STUN
> >>and TURN servers, but they can be deployed independently e.g. by the
> >>WebRTC service provider.
> >>
> >> However, PCP, even gradually deployed, would still be useful as well.
> >>As Reinaldo is saying, it would improve robustness it produces explict
> >>NAT mappings with explicit durations. Also, it can serve as an
> >>alternative to STUN/TURN in case the browser happens to be behind a
> >>PCP-capable NAT/FW. So, PCP can be seen as an optimization and should be
> >>used when it is available. PCP can also help clients behind NAT/FW to
> >>reduce their keep-alive rate which is applicable to WebRTC as well.
> >>However, as depicted in [1], knowing when a client can entirely rely on
> >>PCP is not always so easy to detect.
> >>
> >> I hope we will see PCP deployment especially in the mobile/cellular
> >>access, but as many people have pointed out, the success rate of this
> >>type of protocols has been quite low. So it will be a nice surprise
> >>rather than something I would count on if it happens.
> >>
> >> [1]
> >>
http://datatracker.ietf.org/doc/draft-reddy-pcp-optimize-keepalives/?incl
> >>ude_text=1.
> >>
> >> Markus
> >>
> >
> >I am hopeful e2e connectivity will be provided by IPv6 prior to PCP
> >reaching critical mass. This more because i am on bullish on v6 than
> >bearish on PCP.  That said, the more interesting use-case is v4 to v6
> >via TURN, but i believe that is already covered well ... another
> >reason ICE is a good fit.
> >
> >CB
> >>
> >>>-----Original Message-----
> >>>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
Behalf
> >>>Of ext Reinaldo Penno (repenno)
> >>>Sent: 11 March, 2013 22:14
> >>>To: Hutton, Andrew; Harald Alvestrand; rtcweb@ietf.org
> >>>Subject: Re: [rtcweb] FW: I-D Action: draft-hutton-rtcweb-nat-firewall-
> >>>considerations-00.txt
> >>>
> >>>
> >>>
> >>>On 3/11/13 12:58 PM, "Hutton, Andrew"
> >>><andrew.hutton@siemens-enterprise.com> wrote:
> >>>
> >>>>On: 11 March 2013 14:03 Reinaldo Penno (repenno) Wrote:
> >>>>
> >>>>
> >>>>>
> >>>>> I'm sure STUN and TURN servers are not universally deployed ('100%')
> >>>>> in ISP networks either.
> >>>>
> >>>>It is not required for an ISP to deploy a TURN server the webrtc TURN
> >>>>server is much more likely to be deployed by the web application
> >>>>provider which will instruct the browser to use it when accessing its
> >>>>service.
> >>>
> >>>The line between Application providers and ISPs is very blurry today.
> >>>Application provider can be over the top or it can be the ISP itself.
> >>>
> >>>
> >>>>
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>
> >>>>Understood but would need to understand what the benefits of doing so
> >>>>would be.
> >>>
> >>>
> >>>Yes, certainly.
> >>>
> >>>A protocol that allows a host to explicit control FW/NAT
> >>>mappings/pinholes
> >>>(both for incoming and outgoing connections IPv4/IPv6), including
> >>>lifetime,
> >>>knowing when such device restart/reboot, is more deterministic.
> >>>Client is always free to use STUN/TURN.
> >>>
> >>>
> >>>>
> >>>>Regards
> >>>>Andy
> >>>
> >>>_______________________________________________
> >>>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
>