Re: [rtcweb] STUN for keep-alive - RTCP-less applications

Harald Alvestrand <harald@alvestrand.no> Sat, 24 September 2011 15:34 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F9C21F8B31 for <rtcweb@ietfa.amsl.com>; Sat, 24 Sep 2011 08:34:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.284
X-Spam-Level:
X-Spam-Status: No, score=-109.284 tagged_above=-999 required=5 tests=[AWL=1.315, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFwaSwI3JfJQ for <rtcweb@ietfa.amsl.com>; Sat, 24 Sep 2011 08:34:38 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E063E21F8B2B for <rtcweb@ietf.org>; Sat, 24 Sep 2011 08:34:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DE1C639E0E7 for <rtcweb@ietf.org>; Sat, 24 Sep 2011 17:37:07 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9Wcd0Sv-7dW for <rtcweb@ietf.org>; Sat, 24 Sep 2011 17:37:07 +0200 (CEST)
Received: from [192.168.0.14] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 5778339E082 for <rtcweb@ietf.org>; Sat, 24 Sep 2011 17:37:07 +0200 (CEST)
Message-ID: <4E7DF923.1070308@alvestrand.no>
Date: Sat, 24 Sep 2011 17:37:07 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <CABcZeBO9hUSYZhLrcfbaK9HLGXq-q1EvqWOy6-gAN5xom6Z2-A@mail.gmail.com> <092401cc749b$8fd64940$af82dbc0$@com> <CABcZeBPgRD6kb2gg=m9NckSa1wrzwzJS6527nYqFG34b0cjfgQ@mail.gmail.com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> <4E7AE83E.9090508@ericsson.com> <CALiegfmxjP5ojZeAoz6sYUkKwE7XOtTSGJAOydbX+sm23hrwjg@mail.gmail.com> <7DEACFFC-8AF3-4450-8844-FF6E187AE4D2@edvina.net> <CALiegf=5OPFjvn8WaJq_38OKuGkCed4-M0JTEKJczcCvkAj2YA@mail.gmail.com>
In-Reply-To: <CALiegf=5OPFjvn8WaJq_38OKuGkCed4-M0JTEKJczcCvkAj2YA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Sat, 24 Sep 2011 15:34:38 -0000

On 09/24/2011 03:37 PM, Iñaki Baz Castillo wrote:
>
> Hi. I dont mean that security decisions are taken by the final user, 
> but by the service provider. If it is a local intranet or the users 
> access the intranet via a secure vpn, security can be relaxed ans the 
> site provider could determine that plain rtp is allowed.
>
Remember that in the RTCWEB context, the service provider (the provider 
of the Javascript and the Web service) is presumed malicious.