Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?

Ca By <cb.list6@gmail.com> Thu, 12 June 2014 12:37 UTC

Return-Path: <cb.list6@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325D31B29EE for <rtcweb@ietfa.amsl.com>; Thu, 12 Jun 2014 05:37:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcQdsrGxWmrM for <rtcweb@ietfa.amsl.com>; Thu, 12 Jun 2014 05:37:41 -0700 (PDT)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 105AE1A0080 for <rtcweb@ietf.org>; Thu, 12 Jun 2014 05:37:40 -0700 (PDT)
Received: by mail-wg0-f41.google.com with SMTP id a1so1196935wgh.12 for <rtcweb@ietf.org>; Thu, 12 Jun 2014 05:37:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5ZTTT9AWE9mxAWJoByZvU7wYrBmTTq4lf/jUMrrhQgQ=; b=rSq7pmnXEo/vRnDyTnyiJalzaJxxZ+Xzeds/NaHBV9Q7riLgoWpK1QrfIZt0KWG9oU jTsiJ54SYEKUt9b5V01Pik8Mc0VLcdsbBNL/cyd8Y9fHHEy4qt1hqtaEmk4sfbiDltZL CGXBatH26ZYlGGLkuCTI3DLXC8cBhN9BCIA4Z1x9zdE8xks+on03dxiY/wCd6cFcxb17 2xEU/8+c26YIxCR39aILUDmf5Zsl5GIUWhjHK8DU/oWLJKouZqfb3SV59SajAP522VRn ntdvrKeJV3vyCz9W9pgWTzxjiDSizcfZBHJF81Tgu5xom7GpgMFe5NSjAefP6kSYT3ud myXA==
MIME-Version: 1.0
X-Received: by 10.194.61.193 with SMTP id s1mr61872886wjr.36.1402576659480; Thu, 12 Jun 2014 05:37:39 -0700 (PDT)
Received: by 10.216.39.1 with HTTP; Thu, 12 Jun 2014 05:37:39 -0700 (PDT)
Received: by 10.216.39.1 with HTTP; Thu, 12 Jun 2014 05:37:39 -0700 (PDT)
In-Reply-To: <057DC1BB-CEDA-4E28-A9EC-41C3FE5673F3@cisco.com>
References: <CAOJ7v-2FTAKGd2ZUNt9PZBW9pFu7c9v7Gx8Z8vFOQo4K3dyr5Q@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D35B4E7@ESESSMB209.ericsson.se> <CALiegfncVjR-cQV=coLdmO6OODgbuP-pZ2fxopcWfgGZm+jHyQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D35B859@ESESSMB209.ericsson.se> <CALiegfn7WuyA8qbKWGs4JrNutqF9teXiEN8eqd0UJk5vRrX4TQ@mail.gmail.com> <539786C7.8090806@gmail.com> <E1FE4C082A89A246A11D7F32A95A17828E406A88@US70UWXCHMBA02.zam.alcatel-lucent.com> <CAG=SL7mGHuP0KBuvPGQ8bG0+CxHB7WjemCxZ5WxCXB8XgpOhCQ@mail.gmail.com> <E1FE4C082A89A246A11D7F32A95A17828E407D35@US70UWXCHMBA02.zam.alcatel-lucent.com> <53984062.1090202@gmail.com> <E1FE4C082A89A246A11D7F32A95A17828E407F64@US70UWXCHMBA02.zam.alcatel-lucent.com> <53986129.4050209@gmail.com> <E1FE4C082A89A246A11D7F32A95A17828E40858D@US70UWXCHMBA02.zam.alcatel-lucent.com> <53987FC3.7060408@gmail.com> <6025bc75-db01-45d4-ac4a-50a39740f15a@email.android.com> <E1FE4C082A89A246A11D7F32A95A17828E408FC8@US70UWXCHMBA02.zam.alcatel-lucent.com> <057DC1BB-CEDA-4E28-A9EC-41C3FE5673F3@cisco.com>
Date: Thu, 12 Jun 2014 05:37:39 -0700
Message-ID: <CAD6AjGTNp9VAj9X9=Y8KdNB_3W5RT+6mZ0eLwG0r3povcTzS=g@mail.gmail.com>
From: Ca By <cb.list6@gmail.com>
To: "Pal Martinsen (palmarti)" <palmarti@cisco.com>
Content-Type: multipart/alternative; boundary="047d7b86cdc28f071504fba2d3f9"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/O2f0Az9qZ3qDsIB26dYk6a0v9dQ
Cc: Javier Cerviño <jcague@gmail.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or not to UDP?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 12 Jun 2014 12:37:43 -0000

On Jun 12, 2014 4:31 AM, "Pal Martinsen (palmarti)" <palmarti@cisco.com>
wrote:
>
>
> On 12 Jun 2014, at 11:58, Karl Stahl <karl.stahl@intertex.se> wrote:
>
> >>>    F18     The browser must be able to send streams and
> >>>            data to a peer in the presence of NATs and
> >>>            Firewalls that block UDP traffic.
> >
> >> Yes. Using TURN servers is the way in which it is possible to fulfil
this
> > requirement.
> >
> > Further in draft-ietf-rtcweb-use-cases-and-requirements-14:
> > "the straddling TURN server ... It must be
> >   possible to configure the browsers used in the enterprise with
> >   network specific STUN and TURN servers.  This should be possible to
> >   achieve by auto-configuration methods."
> > F20     The browser must support the use of STUN and TURN
> >           servers that are supplied by entities other than
> >           the web application (i.e. the network provider).
> >
> > This is a TURN server with one interface on the Enterprise LAN where the
> > browser
> > simple shall place the WebRTC media. (The other interface should be
public.)
> >
> > The way for the browser to autodiscover such network provided (from the
> > enterprise and ISP) TURN server is being worked in
> > draft-patil-tram-turn-serv-disc-01.txt.
> >
> > This resolves any firewall restriction not allowing WebRTC media (by
> > paralleling the firewall with the TURN server), and also allows the
> > enterprise or ISP to point out a better path for the WebRTC media
(instead
> > of through the often data crowded firewall default gateway).
> > (This will also be needed with IPv6.)
> >
>
> I have problems understanding how this solves any issues. I doubt many
enterprise network managers would install a TURN server in parallel with
their FW. Would be fair easier and safer to open up the appropriate ports
in the firewall towards the TURN server.  They could then allow only UDP to
allow for DPI and see that it is actually RTP traffic flowing.
>

I believe they will install a TURN server in parallel to a firewall, like
many enterprises install SBCs in parallel to firewalls. Enterprise
firewalls are generally not optimized for multimedia traffic.

CB
> Having a TURN server supporting UDP/TCP/TLS as communication between the
client and TURN server would solve almost all connectivity problems. We
should, as Harald also pointed out, not try to force us throughout the FW
if the admin do not want the traffic to go through.
>
> .-.
> Pål-Erik
>
>
>
>
>
>
>
>
>
>
> > /Karl
> >
> > -----Ursprungligt meddelande-----
> > Från: rtcweb [mailto:rtcweb-bounces@ietf.org] För Harald Alvestrand
> > Skickat: den 12 juni 2014 06:17
> > Till: Makaraju, Maridi Raju (Raju); Sergio Garcia Murillo; Javier
Cerviño
> > Kopia: rtcweb@ietf.org
> > Ämne: Re: [rtcweb] Retry: DTLS carrying RTP/SAVPF over ICE: To UDP or
not to
> > UDP?
> >
> > On 06/11/2014 08:38 PM, Makaraju, Maridi Raju (Raju) wrote:
> >>> The MUST was a consensus call in London. See the minutes for numbers.
I
> > was one of >the ones who were surprised at the strength of the
consensus.
> >> [Raju] I thought one of the implicit (may be explicit in
> > draft-ietf-rtcweb-use-cases-and-requirements-14) requirement for WebRTC
is
> > "implementations should work right out of the box without extra boxes
(e.g.
> > TURN) in between under UDP restrictive firewalls".
> > Unfortunately, nobody's found a way to make that true even for all
common
> > NATs/firewalls that want to permit the communication.
> >
> > TURN servers are the least obnoxious way to make sure apps can work in
the
> > presence of symmetric NATs.
> > We could wish that this wasn't so, but we could also wish that NATs
would go
> > away and everyone would run IPv6; neither is likely to happen this year.
> >
> > Of course, in the presence of firewalls where the admin does *not* want
to
> > permit the communication, we neither can nor should make communication
work.
> >
> >
> >> Then I see the following requirement in
> > draft-ietf-rtcweb-use-cases-and-requirements-14. It did not mention use
of
> > TURN in the text.
> >>
> >>    F18     The browser must be able to send streams and
> >>            data to a peer in the presence of NATs and
> >>            Firewalls that block UDP traffic.
> >
> > Yes. Using TURN servers is the way in which it is possible to fulfil
this
> > requirement.
> >
> >>
> >> BR
> >> Raju
> >>
> >
> > _______________________________________________
> > 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