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

["Hutton, Andrew" <[e-mail]>]

We don't believe that discussing issues around DPI inspection is within scope or desirable and we are not trying to work around it.  However all scenarios that involve accessing WebRTC services from behind a firewall are within scope whether it is a service deployed by an enterprise or not.

Regarding requirement F37 I already raised an issue with this some time ago and a change will be made in the next update to the use case draft. The issue is that this should not refer to a firewall "that only allows HTTP(S) traffic" but should include the case of HTTP Proxy being deployed and the fw allowing traffic from the proxy even if it is not HTTP(S). Once this change gets in to the use case draft I think we are aligned with it.

Regards
Andy





________________________________
From: [e-mail] [[e-mail]] on behalf of Sergio Garcia Murillo [[e-mail]]
Sent: Friday, September 20, 2013 11:32 PM
To: [e-mail]
Subject: Re: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-considerations

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 validation?


   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<http://tools.ietf.org/html/rfc4787>], the peers will introduce a TURN server
   [RFC5766<http://tools.ietf.org/html/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
Sergio

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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: 20 September 2013 15:33
To: [e-mail]<mailto:[e-mail]>
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:
https://datatracker.ietf.org/doc/draft-hutton-rtcweb-nat-firewall-considerations

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-hutton-rtcweb-nat-firewall-considerations-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
pntaw mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/pntaw