Re: [rtcweb] NAT/Firewall considerations (RE: I-D Action: draft-ietf-rtcweb-transports-00.txt)

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
> cb.list6
> Sent: Tuesday, August 27, 2013 9:35 PM
> To: Alan Johnston
> Cc: <rtcweb@ietf.org>
> Subject: Re: [rtcweb] NAT/Firewall considerations (RE: I-D Action: draft-ietf-
> rtcweb-transports-00.txt)
> 
> The I-D says this
> 
> "As last resort in order to cater
> 
>    for NAT/FWs with address and port dependent filtering characteristics"
> 
> What is the first resort?
> 
> <ascending soap box>
> 
> Specifically, i would like the document to say that end points and
> intermediate systems should support IPv6 and attempt IPv6
> connectivity...which means they must support IPv6.
> 
> IPv6 is a middle box / NAT avoidance mechanism, but these early days
> of WebRTC show no support for IPv6.
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=797262
> 
> The draft should explicitly describe that secure e2e connectivity
> should be attempted first with all address families, not short cuts
> that make WebRTC more fragile by relying on middle boxes (TURN).
> 
> I am not opposed to this draft, and find TURN to be a useful way to
> police traffic and bridge disparate address families, but it is a
> slippery slope where we try to avoid one middle box with another.

Yes, this method may not work with Enterprises that use Firewalls that perform DPI on HTTP, detect port misuse etc and for HTTPS either act as TLS Proxy or monitor the TLS handshake for valid certificates etc. Enterprises in addition to firewalls also could use cloud connector which re-directs HTTP/HTTPS traffic to cloud based "Security As A Service" for DPI, reputation based filtering etc.

-Tiru.

> 
> CB
> 
> On Tue, Aug 27, 2013 at 7:55 AM, Alan Johnston
> <alan.b.johnston@gmail.com> wrote:
> > Agree that enterprises need this plus a few other TURN extensions.
> >
> > I support adoption as WG draft.
> >
> > - Alan -
> >
> >
> >
> > On Aug 27, 2013, at 9:52 AM, Salvatore Loreto
> > <salvatore.loreto@ericsson.com> wrote:
> >
> > +1
> >
> >
> > On 8/27/13 2:53 PM, Markus.Isomaki@nokia.com wrote:
> >
> > Hi,
> >
> >
> >
> > I would support the adoption of the NAT and Firewall considerations
> > (http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-
> 01)
> > as a WG document. Or to be more precise, I very much agree with the
> > requirements summarized in Section 5. Especially this one seems important to
> > me:
> >
> >
> >
> > o  connect to a TURN server via a HTTP proxy using the HTTP connect
> >
> >       method,
> >
> >
> >
> > If we want WebRTC to work from many corporate networks I'm aware of, it
> > would not be possible without this as a fallback capability.
> >
> >
> >
> > Markus
> >
> >
> >
> >
> >
> >
> >
> > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
> > ext Bernard Aboba
> > Sent: 21 August, 2013 00:44
> > To: Hutton, Andrew; rtcweb@ietf.org; Harald Alvestrand
> > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt
> >
> >
> >
> > The NAT/Firewall considerations document does go into detail on the various
> > traversal scenarios, which helps inform the discussion of what should or
> > should not be supported in terms of transport.  Section 5 summarizes the
> > recommendations as follows:
> >
> > 5.  Requirements for RTCWEB-enabled browsers
> >
> >
> >
> >
> >
> >    For the purpose of relaying RTCWEB media streams or data channels a
> >
> >    browser needs to be able to
> >
> >
> >
> >    o  connect to a TURN server via UDP, TCP and TLS,
> >
> >
> >
> >    o  connect to a TURN server via a HTTP proxy using the HTTP connect
> >
> >       method,
> >
> >
> >
> >    o  connect to a TURN server via the HTTP(s) ports 80/443 instead of
> >
> >       the default STUN ports 3478/5349,
> >
> >
> >
> >    o  upgrade the HTTP proxy-relayed connection to the TURN server to
> >
> >       use TLS,
> >
> >
> >
> >    o  use the same proxy selection procedure for TURN as currently done
> >
> >       for HTTP,
> >
> >
> >
> >    o  switch the usage of the HTTP proxy-relayed connection with the
> >
> >       TURN server from HTTP to STUN/TURN,
> >
> >
> >
> >    o  use a preconfigured or standardized port range for UDP-based media
> >
> >       streams or data channels,
> >
> >
> >
> >    o  learn from the proxy configuration script about the presence of a
> >
> >       local TURN server and use it for sending UDP traffic to the
> >
> >       internet,
> >
> >
> >
> >    o  support ICE-TCP for TCP-based direct media connection to the
> >
> >       RTCWEB peer.
> >
> >
> >
> >> From: andrew.hutton@siemens-enterprise.com
> >> To: rtcweb@ietf.org; harald@alvestrand.no
> >> Date: Tue, 20 Aug 2013 16:31:28 +0000
> >> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-00.txt
> >>
> >> Section 2.2 "Middle Box Related Functions" should also I assume cover the
> >> case of using a HTTP Proxy or an enterprise TURN server and reference
> >> http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-
> 01
> >> assuming we can get this adopted.
> >>
> >> 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
> >
> >
> > _______________________________________________
> > 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