Re: [rtcweb] Consent freshness - revisiting the RTCP option
"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Wed, 09 May 2012 07:35 UTC
Return-Path: <mperumal@cisco.com>
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 767A021F849A for <rtcweb@ietfa.amsl.com>; Wed, 9 May 2012 00:35:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.574
X-Spam-Level:
X-Spam-Status: No, score=-10.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 NPEXSn1+E2Kn for <rtcweb@ietfa.amsl.com>; Wed, 9 May 2012 00:34:59 -0700 (PDT)
Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5943A21F8491 for <rtcweb@ietf.org>; Wed, 9 May 2012 00:34:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=2384; q=dns/txt; s=iport; t=1336548899; x=1337758499; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=6SliWO4zQ+OEjgDi0O+wjManBKR6F8s6kApHj7gfygI=; b=Vz30egN1EOPDIv1VjNzFem1F5MLO1dk+qhhr9lJM8LGDROu3cXjMJeFb hlYkvhp66HiLlLxnQUHgAc0qgyrL7LAPc6clSwhatpOA5uuDdFr9aYcdC TXm4KxFempheDWedp+eJZvRCFmahUyitjnICspmLflMJ/e92D1ejPcJbA 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap8EAJEdqk9Io8UY/2dsb2JhbABEtEeCDAEBAQQBAQEPAR0KNAsMBAIBCBEEAQELBhcBBgEmHwkIAQEEAQoICAEZh2wLmnugMIsMGYUWYwSIYptzgWmCcYFOBwER
X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="11770981"
Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 09 May 2012 07:34:57 +0000
Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q497YvPo024040; Wed, 9 May 2012 07:34:57 GMT
Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 May 2012 13:04:57 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 09 May 2012 13:04:56 +0530
Message-ID: <1D062974A4845E4D8A343C65380492020865B735@XMB-BGL-414.cisco.com>
In-Reply-To: <4FAA150C.5020301@alvestrand.no>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] Consent freshness - revisiting the RTCP option
Thread-Index: Ac0tsNqCEaA9e71pQsqr9NpOv87TXwAA46mg
References: <4FA99618.9050700@alvestrand.no><CABcZeBMqGdKEFsxncK0fuVJnpyR2_hDbdfmcH4wTz_x-Q1iPUA@mail.gmail.com> <4FAA150C.5020301@alvestrand.no>
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: Harald Alvestrand <harald@alvestrand.no>, Eric Rescorla <ekr@rtfm.com>
X-OriginalArrivalTime: 09 May 2012 07:34:57.0084 (UTC) FILETIME=[3B99B7C0:01CD2DB6]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Consent freshness - revisiting the RTCP option
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: Wed, 09 May 2012 07:35:00 -0000
More reasons why RTCP may not be suitable for consent freshness: 1. RTCP (as described in RFC3550) is receiver based, so the browser can't explicitly request for consent. If consent freshness fails (for e.g, RTCP packets temporarily lost because of network flapping), the browser would have to wait for the peer to send RTCP before it can start transmitting media. Worst, if the peer isn't an active sender it may not send any RTCP RR until it receives media. It could send a bare minimum RTCP RR (an RR with RC=0 and SDES with CNAME), but that has zero entropy: http://www.ietf.org/mail-archive/web/rtcweb/current/msg01497.html 2. There are still some endpoints that don't send / pay attention to RTCP: http://www.ietf.org/mail-archive/web/rai/current/msg01257.html For these cases an intermediary like an SBC would have to manufacture them. Manufacturing them for just consent freshness would be expensive compared to generating STUN request/response. Muthu |-----Original Message----- |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand |Sent: Wednesday, May 09, 2012 12:26 PM |To: Eric Rescorla |Cc: rtcweb@ietf.org |Subject: Re: [rtcweb] Consent freshness - revisiting the RTCP option | |On 05/08/2012 11:59 PM, Eric Rescorla wrote: |> On Tue, May 8, 2012 at 2:54 PM, Harald Alvestrand<harald@alvestrand.no> wrote: |>> Just because I realized I didnt understand something, I ask..... |>> |>> We rejected RTCP RR as a consent freshness mechanism because RR is trivial |>> to fake. |>> But - now we have SRTP as mandatory-to-use, which means that all RTCP RRs |>> are integrity protected, origin authenticated and replay protected (do I |>> have that right?). |>> |>> What is the reason why this is not sufficient protection to use RTCP RR as a |>> consent freshness mechanism? |> This isn't a complete analysis, but if you are using SDES for key management, |> then the site knows the SRTCP keys, so I don't *think* SRTCP is buying you |> much. I haven't thought through this completely though, so maybe there is |> still some additional value. |Ah - had forgotten that the attacker is assumed to observe the |signalling path. Thanks. | |_______________________________________________ |rtcweb mailing list |rtcweb@ietf.org |https://www.ietf.org/mailman/listinfo/rtcweb
- Re: [rtcweb] Consent freshness - revisiting the R… Harald Alvestrand
- [rtcweb] Consent freshness - revisiting the RTCP … Harald Alvestrand
- Re: [rtcweb] Consent freshness - revisiting the R… Eric Rescorla
- Re: [rtcweb] Consent freshness - revisiting the R… Magnus Westerlund
- Re: [rtcweb] Consent freshness - revisiting the R… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] Consent freshness - revisiting the R… Harald Alvestrand