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.

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
>