Re: [rtcweb] STUN for keep-alive - RTCP-less applications
Harald Alvestrand <harald@alvestrand.no> Sat, 24 September 2011 16:53 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 39FBA21F888A for <rtcweb@ietfa.amsl.com>; Sat, 24 Sep 2011 09:53:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.271
X-Spam-Level:
X-Spam-Status: No, score=-109.271 tagged_above=-999 required=5 tests=[AWL=1.028, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 XCKqCPBjNF40 for <rtcweb@ietfa.amsl.com>; Sat, 24 Sep 2011 09:53:03 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 99B2621F8888 for <rtcweb@ietf.org>; Sat, 24 Sep 2011 09:53:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B779D39E0E7; Sat, 24 Sep 2011 18:55:40 +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 tYdco6n78+vz; Sat, 24 Sep 2011 18:55:40 +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 375D039E082; Sat, 24 Sep 2011 18:55:40 +0200 (CEST)
Message-ID: <4E7E0B8C.5010807@alvestrand.no>
Date: Sat, 24 Sep 2011 18:55:40 +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: Iñaki Baz Castillo <ibc@aliax.net>
References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <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> <4E7DF923.1070308@alvestrand.no> <CALiegfn-c6EN6K880ZAJLd7r3NcxjPnqAh=W28JMY6FPLXaHeg@mail.gmail.com> <4E7DFFAA.2040306@alvestrand.no> <CALiegf=YZkjeeqYwPW6Ym0-Fn1NQs2yJNv3MOKR1AdB+Y7y7Uw@mail.gmail.com>
In-Reply-To: <CALiegf=YZkjeeqYwPW6Ym0-Fn1NQs2yJNv3MOKR1AdB+Y7y7Uw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: rtcweb@ietf.org
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 16:53:04 -0000
On 09/24/2011 06:24 PM, Iñaki Baz Castillo wrote: > >> Does this seem reasonable? > No, but what are we trying to prevent? In this case (keepalive using RTCP) we're trying to prevent the Javascript running in user A's browser from connecting to user B, having user B hang up, and the packets continuing to flow "forever" from A to B. > a malicious site could always > initiate a session with a user in behalf of him best friend. I mean a > valid audio/video session (with ICE, RTCP, SRTP and so). The the user > (the WebRTC client) sends RTP there and the malicious site/user > uploads it to Youtube. How can rtcweb security constrains prevent > that??? > > In the other side, if user A establishes an audio session with user B, > and user B indicates a "malicious" address in the SDP (and does not > send RTCP reports) then user A would realize in just a few seconds > that "something is wrong since there is no audio" and would hangup. In > the meanwhile user A would send a few useless UDP packets to somewhere > within his LAN network, is that so critic? If the JS in user A negotiates one connection to user B and another to user C, and hears audio from user C, when would he realize that user B had dropped off the conference call? > I really wonder what we are trying to achieve in all these threads > about security in rtcweb. > If you can formulate your wondering in terms of "draft-ietf-rtcweb-security should be changed to say *this* to make it clear", that would be most helpful. I think I'll take my own advice and shut up on this thread...
- [rtcweb] STUN for keep-alive Christer Holmberg
- Re: [rtcweb] STUN for keep-alive Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] STUN for keep-alive Christer Holmberg
- Re: [rtcweb] STUN for keep-alive Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] STUN for keep-alive Christer Holmberg
- Re: [rtcweb] STUN for keep-alive Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] STUN for keep-alive Christer Holmberg
- Re: [rtcweb] STUN for keep-alive Jonathan Lennox
- Re: [rtcweb] STUN for keep-alive Randell Jesup
- Re: [rtcweb] STUN for keep-alive sisalem
- Re: [rtcweb] STUN for keep-alive Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive Harald Alvestrand
- Re: [rtcweb] STUN for keep-alive Eric Rescorla
- Re: [rtcweb] STUN for keep-alive Christer Holmberg
- Re: [rtcweb] STUN for keep-alive Göran Eriksson AP
- Re: [rtcweb] STUN for keep-alive Eric Rescorla
- Re: [rtcweb] STUN for keep-alive Dan Wing
- Re: [rtcweb] STUN for keep-alive Dan Wing
- Re: [rtcweb] STUN for keep-alive Dzonatas Sol
- Re: [rtcweb] STUN for keep-alive Eric Rescorla
- Re: [rtcweb] STUN for keep-alive Dan Wing
- Re: [rtcweb] STUN for keep-alive Dzonatas Sol
- Re: [rtcweb] STUN for keep-alive Harald Alvestrand
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Olle E. Johansson
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Olle E. Johansson
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive Magnus Westerlund
- [rtcweb] consent freshness [was RE: STUN for keep… Dan Wing
- Re: [rtcweb] consent freshness [was RE: STUN for … Magnus Westerlund
- Re: [rtcweb] consent freshness [was RE: STUN for … Dan Wing
- Re: [rtcweb] consent freshness [was RE: STUN for … Eric Rescorla
- Re: [rtcweb] consent freshness [was RE: STUN for … Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] STUN for keep-alive Randell Jesup
- Re: [rtcweb] consent freshness [was RE: STUN for … Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Colin Perkins
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Colin Perkins
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] consent freshness [was RE: STUN for … Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Magnus Westerlund
- Re: [rtcweb] consent freshness [was RE: STUN for … Magnus Westerlund
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] consent freshness [was RE: STUN for … Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] consent freshness [was RE: STUN for … Randell Jesup
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Magnus Westerlund
- Re: [rtcweb] consent freshness [was RE: STUN for … Magnus Westerlund
- Re: [rtcweb] consent freshness [was RE: STUN for … Randell Jesup
- Re: [rtcweb] STUN for keep-alive Cullen Jennings
- Re: [rtcweb] STUN for keep-alive Michael Tüxen
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Hadriel Kaplan
- Re: [rtcweb] consent freshness [was RE: STUN for … Magnus Westerlund
- Re: [rtcweb] consent freshness [was RE: STUN for … Harald Alvestrand
- Re: [rtcweb] consent freshness [was RE: STUN for … Stefan Håkansson LK
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Olle E. Johansson
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Harald Alvestrand
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Harald Alvestrand
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Harald Alvestrand
- Re: [rtcweb] STUN for keep-alive - RTCP-less appl… Iñaki Baz Castillo