Re: [rtcweb] consent freshness [was RE: STUN for keep-alive]

"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Mon, 19 September 2011 16:39 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 5572F21F8C12 for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 09:39:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.493
X-Spam-Level:
X-Spam-Status: No, score=-10.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 WVxCp9ztaAkS for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 09:39:28 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id BAB5921F8BDC for <rtcweb@ietf.org>; Mon, 19 Sep 2011 09:39:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=6733; q=dns/txt; s=iport; t=1316450511; x=1317660111; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=6yfw/evJXg3dlF6Vyb6KUKsdIZ8Vm09NCu1S+5qJomc=; b=nHjsr95LjtCh8JZmZ+6j8SrEjUMQRL8hZbzThJMyojKNMOPsoZnj2VZE hPDZgEgUvOgGND0YBjkiRMNtVJGDPb7btlDT4phT4Iu4m+DlGYSnQijfC tJFWe7P0Ofaj7K18P7ovEkhdD3lqLZg3RvyYR9AD60XPtUgMjwbx/Q/Z9 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApcAAF9wd05Io8UQ/2dsb2JhbABCmFGOZ3eBUwEBAQEDAQEBCQYBHT4LDAICAgEIEQQBAQsGFwEGARoMHwkIAQEEAQoICAEZh1mXEQGdcwKGFmAEhz8ukQKMDw
X-IronPort-AV: E=Sophos;i="4.68,406,1312156800"; d="scan'208";a="55181392"
Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 19 Sep 2011 16:41:49 +0000
Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8JGfIVl028946; Mon, 19 Sep 2011 16:41:48 GMT
Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Sep 2011 22:11:47 +0530
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 19 Sep 2011 22:11:45 +0530
Message-ID: <1D062974A4845E4D8A343C6538049202066497EF@XMB-BGL-414.cisco.com>
In-Reply-To: <4E77613B.4020805@ericsson.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] consent freshness [was RE: STUN for keep-alive]
Thread-Index: Acx24cVBAkoYrwjBRWKmAVnEVQm9mQAA1mrA
References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com><7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com><7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com><7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se><4E70D2E6.1000809@alvestrand.no><CABcZeBORi5NLSsztnMfkwL43p9oKG9mi6e1WWOaiafAO_DpTVg@mail.gmail.com><7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se><CABcZeBO9hUSYZhLrcfbaK9HLGXq-q1EvqWOy6-gAN5xom6Z2-A@mail.gmail.com><092401cc749b$8fd64940$af82dbc0$@com><CABcZeBPgRD6kb2gg=m9NckSa1wrzwzJS6527nYqFG34b0cjfgQ@mail.gmail.com><4E765E4A.3050801@alvestrand.no><0ced01cc76de$28731630$79594290$@com> <4E77613B.4020805@ericsson.com>
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, "Dan Wing (dwing)" <dwing@cisco.com>
X-OriginalArrivalTime: 19 Sep 2011 16:41:47.0557 (UTC) FILETIME=[05EAD550:01CC76EB]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive]
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: Mon, 19 Sep 2011 16:39:29 -0000

Another aspect to consider:
As per RFC 3550, the bare minimal valid RTCP packet is a compound RTCP packet containing:
- An RR packet with the reception report count set to 0 (RC=0) and
- An SDES packet with CNAME

Such a packet would look like this:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
header |V=2|P|    RC=0 |   PT=RR=201   |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     SSRC of packet sender                     |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
header |V=2|P|   SC=1  |  PT=SDES=202  |             length            |
       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
chunk  |                     SSRC of packet sender                     |
  1    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    CNAME=1    |     length    |user & domain padded to 32-bit |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I've seen endpoints sending/accepting such a packet as an indication for session liveliness. However, there is no entropy at all in this packet. Suppose an attacker manages to bring the receiver down and captures such a RTCP packet. The attacker can keep replaying it (from the spoofed source transport address) to make the sender believe that the receiver is still alive and muted.

Perhaps, RTCWeb apps should try to negotiate an RTCP extension carrying a monotonically increasing number that must be part of every RTCP report together with SRTCP, for replay attack protection. 

Muthu

|-----Original Message-----
|From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund
|Sent: Monday, September 19, 2011 9:05 PM
|To: Dan Wing (dwing)
|Cc: rtcweb@ietf.org
|Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive]
|
|On 2011-09-19 17:09, Dan Wing wrote:
|>> -----Original Message-----
|>> From: Harald Alvestrand [mailto:harald@alvestrand.no]
|>> Sent: Sunday, September 18, 2011 2:11 PM
|>> To: Eric Rescorla
|>> Cc: Dan Wing; rtcweb@ietf.org
|>> Subject: Re: [rtcweb] STUN for keep-alive
|>>
|>> On 09/16/2011 08:30 PM, Eric Rescorla wrote:
|>>> On Fri, Sep 16, 2011 at 11:07 AM, Dan Wing<dwing@cisco.com>  wrote:
|>>>>> -----Original Message-----
|>>>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
|>>>>> Behalf Of Eric Rescorla
|>>>>> Sent: Wednesday, September 14, 2011 10:32 AM
|>>>>> To: Christer Holmberg
|>>>>> Cc: rtcweb@ietf.org
|>>>>> Subject: Re: [rtcweb] STUN for keep-alive
|>>>>>
|>>>>> On Wed, Sep 14, 2011 at 10:20 AM, Christer Holmberg
|>>>>> <christer.holmberg@ericsson.com>  wrote:
|>>>>>> Hi,
|>>>>>>
|>>>>>>> One new concern in this context is maintaining the consent
|>> freshness.
|>>>>>>> The browser needs to be sure that the recipient of traffic is
|>> stil
|>>>>> responding in a way that can't be forged. It's likely RTCP provides
|>>>>> this (though we'd need to analyze to be sure) but perhaps better
|>> would
|>>>>> be to mandate STUN checks
|>>>>>>> at enough frequency that you get some sort of level of
|>> freshness....
|>>>>> maybe every 2 minutes or something.
|>>>>>> Please note that the STUN keep-alives are implemented using STUN
|>>>>> indication messages, so there are no replies (nor does the receiver
|>>>>> perform an authentication check).
|>>>>>
|>>>>>
|>>>>> Oh... I had forgotten that.... that's not good.
|>>>> The RTCP receiver reports should be adequate for 'consent
|>> freshness', no?
|>>>> If I still like receiving the traffic, I'll report that I'm
|>> receiving it.
|>>>> If I have crashed or disconnected or am not listening on that port,
|>> I won't.
|>>> I believe so, though I'd have to make sure there's enough entropy.
|>> And of course
|>>> some implementations may not do RTCP...
|>> Depending on RTCP seems less uncomfortable with SRTP than with
|>> plaintext
|>> RTCP.
|>> I don't think we want to support RTCP-less applicaitons; if saying "no"
|>> to them helps them not occur (it doesn't always help...)
|>
|> (Case in point: RTCP has long been a requirement for RTP, but
|> implementation was still skipped by Cisco, and probably others.)
|>
|> I don't know how much entropy Eric was looking for.  RTCP receiver
|> reports only echo back the SSRC, which is 32 bits and is going to
|> be static for the duration of each RTP session (yes, SSRC collision
|> could make it change.  But that is atypical.)  STUN request/response
|> echoes back the 96-bit transaction id, which changes as often as the
|> requestor likes (typically each new STUN transaction).
|
|As I wrote in
|http://www.ietf.org/mail-archive/web/rtcweb/current/msg01327.html
|
|The amount of entropy in an RTCP message may be as low as 8 bits. If
|certain restrictions is accepted then we can probably reach 20-24 bits
|without requiring more than basic RTCP provides.
|
|>
|> Which would someone skip -- skip sending/implementing RTCP for
|> consent freshness, or skip sending/implementing STUN request/response
|> for consent freshness?  The STUN request/response is also additional
|> data, whereas RTCP is something that is "already being sent" (thus
|> the consent freshness isn't adding more bits on the wire).
|
|I think RTCP may work for consent freshness. A longer series of
|consistent RTCP messages to maintain the consent seems reasonable,
|despite the low number of entropy bits per actual message. But, I do
|think RTCP might have to few bits for the initial check where one wants
|a rapid indication that it is fine to send media at higher bit-rates.
|
|Cheers
|
|Magnus Westerlund
|
|----------------------------------------------------------------------
|Multimedia Technologies, Ericsson Research EAB/TVM
|----------------------------------------------------------------------
|Ericsson AB                | Phone  +46 10 7148287
|Färögatan 6                | Mobile +46 73 0949079
|SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
|----------------------------------------------------------------------
|
|_______________________________________________
|rtcweb mailing list
|rtcweb@ietf.org
|https://www.ietf.org/mailman/listinfo/rtcweb