Re: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-considerations

Sergio Garcia Murillo <> Fri, 20 September 2013 22:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4EF0F21F9E63 for <>; Fri, 20 Sep 2013 15:32:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.52
X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 65-BjVpliyma for <>; Fri, 20 Sep 2013 15:32:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::232]) by (Postfix) with ESMTP id 0B37221F9E5E for <>; Fri, 20 Sep 2013 15:32:43 -0700 (PDT)
Received: by with SMTP id u57so1111910wes.9 for <>; Fri, 20 Sep 2013 15:32:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=sSKKMATG/fSbEWV557bCbsz4z/kT54gM9C8Fb7R74Ek=; b=ERPJMRDS5Ayk/J6tfgr3GLgJBEZQyb4KQA3/4l+6H8baefSsrDHVTAISleRB1GnMF8 VKJH1wAav+TD8VMia8FbLJ/Soi2K+nQuQGdf2MVuuqo5KHcemNM5SvLZJh55co49+7eO bCaSSgL1xwHggUbPi37V4NAwnl9F5zc9z5TlxFXyGihQVqq176V/GuBLDoDzv7d6zcYB +Vx2bB76MNvPoCmF6KjoUon/X4KZBZSmTnejwSKdA24mpruWv0wF6TwG3JtnKtn/87gM eZesN/4qqlk7S1M0zGYf6b/1TBOGhKiDlg6CLpYKN6m4XIzUnBlDzKUUV+ms0Or/Nt14 OsGQ==
X-Received: by with SMTP id d4mr4439641wik.7.1379716363197; Fri, 20 Sep 2013 15:32:43 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id mb7sm8090559wic.10.1969. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Sep 2013 15:32:42 -0700 (PDT)
Message-ID: <>
Date: Sat, 21 Sep 2013 00:32:38 +0200
From: Sergio Garcia Murillo <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------020802050704070804080806"
Subject: Re: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-considerations
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Sep 2013 22:32:45 -0000

HI Andrew

Why are you leaving out of scope the case when the WebRTC service is not 
deployed by the corporate organization and/or the HTTP proxy has DPI 

    When WebRTC is deployed by the corporate IT department one can assume
    that the corporate IT configures the corporate NATs, Firewalls, DPI
    units, TURN servers accordingly.  If so desired by the organization
    WebRTC media streams can then be established to WebRTC peers outside
    of the organization subject to the applied policies.  In order to
    cater for NAT/FWs with address and port dependent mapping
    characteristics [RFC4787  <>], the peers will introduce a TURN server
    [RFC5766  <>] in the public internet as a media relay.  Such a TURN
    server could be deployed by the organization wanting to assert policy
    on WebRTC traffic.


    This section considers a scenario where all HTTP(S) traffic is routed
    via an HTTP proxy.  We assume that the HTTP proxy is tranparent and
    just tunnels traffic after e.g. enforcing an acceptable use policy
    with respect to domains that are allowed to be reached.  We don't
    consider cases where the HTTP proxy is used to deploy HTTP traffic
    validation.  This includes DPI validation that the traffic is, in
    fact, HTTP or HTTPS-looking or a HTTP proxy that breaks into the TLS
    exchange and looks for HTTP in the traffic.

In my point of view that is not fullfilling WebRTC requirement:

    F37     The browser must be able to send streams and
            data to a peer in the presence of FWs that only
            allows http(s) traffic.

Best regards

El 20/09/2013 19:06, Hutton, Andrew escribió:
> Hi All,
> We have submitted draft-hutton-rtcweb-nat-firewall-considerations-02 in which we have tried to take account of the feedback we have received over the last couple of months.
> Please review and send comments to this list I really hope we can make some progress towards adopting this now.
> Regards
> Andy
> -----Original Message-----
> From: [] On Behalf Of
> Sent: 20 September 2013 15:33
> To:
> Subject: I-D Action: draft-hutton-rtcweb-nat-firewall-considerations-02.txt
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 	Title           : RTCWEB Considerations for NATs, Firewalls and HTTP proxies
> 	Author(s)       : Thomas Stach
>                            Andrew Hutton
>                            Justin Uberti
> 	Filename        : draft-hutton-rtcweb-nat-firewall-considerations-02.txt
> 	Pages           : 12
> 	Date            : 2013-09-20
> Abstract:
>     This document describes mechanism to enable media stream
>     establishment for Real-Time Communication in WEB-browsers (WebRTC) in
>     the presence of network address translators, firewalls and HTTP
>     proxies.  HTTP proxy and firewall deployed in many private network
>     domains introduce obstacles to the successful establishment of media
>     stream via WebRTC.  This document examines some of these deployment
>     scenarios and develops requirements on the web browsers designed to
>     provide the best possible chance of media connectivity between WebRTC
>     peers.
> The IETF datatracker status page for this draft is:
> There's also a htmlized version available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> I-D-Announce mailing list
> Internet-Draft directories:
> or
> _______________________________________________
> pntaw mailing list