Re: [rtcweb] consent freshness [was RE: STUN for keep-alive]
"Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com> Thu, 22 September 2011 12:17 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 5298C21F8770 for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 05:17:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.488
X-Spam-Level:
X-Spam-Status: No, score=-10.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 93UDqiskM5nu for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 05:17:12 -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 BC4D221F8783 for <rtcweb@ietf.org>; Thu, 22 Sep 2011 05:17:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=4169; q=dns/txt; s=iport; t=1316693983; x=1317903583; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=eB8KdeVhTj917A78g/UA6pVEyS8RFcBxMXOooAG6H4E=; b=iVCB9lIciMglibdLy4ktOxy0DaArnoKJYZr0GTGQiwljdtYtWg675YN8 mwlb0wxOAHtGVwI7ENGkvwiMiDDfgltBxpcgLfVf1G2thLHiRJJd0zgxi tVMGyLNJMTS3zImCT4HJHFF8Sfshj1CE+2cRBNJqYhoYqwvLoQlCAG3+Y o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AswAANwme05Io8UQ/2dsb2JhbABCmQmOd3iBUwEBAQEDDAYBHUkMAgICAQgRBAEBCwYJAgwBBgEaKwkIAQEECwgIGp4yAZ43AoN7B4IZYASHQS6RCYwP
X-IronPort-AV: E=Sophos;i="4.68,423,1312156800"; d="scan'208";a="55694708"
Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 22 Sep 2011 12:19:17 +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 p8MCJ1SA021240; Thu, 22 Sep 2011 12:19:17 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); Thu, 22 Sep 2011 17:49:14 +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: Thu, 22 Sep 2011 17:49:11 +0530
Message-ID: <1D062974A4845E4D8A343C65380492020672C04A@XMB-BGL-414.cisco.com>
In-Reply-To: <4E784C38.2010909@ericsson.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] consent freshness [was RE: STUN for keep-alive]
Thread-Index: Acx3bd9fEcquWi4ZQ0+xMYLnTrDIXgAAvfFA
References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se><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> <1D062974A4845E4D8A343C6538049202066497EF@XMB-BGL-414.cisco.com> <4E784C38.2010909@ericsson.com>
From: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-OriginalArrivalTime: 22 Sep 2011 12:19:14.0278 (UTC) FILETIME=[D7787860:01CC7921]
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: Thu, 22 Sep 2011 12:17:13 -0000
|That is a possibility, but I think one can start by ensuring |that one actually check for ones own traffic being reported |back. That gives you some entropy. Which is a slightly longer |context gives you good verification that you are not contining |sending into a location where there receiver you intended to |have sent to moves away. Agree it would suffice in general. However, for cases like double hold (SDP offer with a=inactive) where you would be neither sending nor receiving media the attacker can keep replaying the RTCP packets with an empty report block (that no zero entropy) making you think the other end is still alive. Of course, you may ultimately disconnect the call but it could mean a DOS attack.. Muthu |-----Original Message----- |From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] |Sent: Tuesday, September 20, 2011 1:48 PM |To: Muthu Arul Mozhi Perumal (mperumal) |Cc: Dan Wing (dwing); rtcweb@ietf.org |Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive] | |On 2011-09-19 18:41, Muthu Arul Mozhi Perumal (mperumal) wrote: |> 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. | |well, the reasonable assumption if you are using this for consent |freshness is to verify that your flow is reported on in a reasonable |way. That do provide some entropy in sequence number and Last SR field |in the report block as I wrote in my other email. | |> |> 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. | |That is a possibility, but I think one can start by ensuring that one |actually check for ones own traffic being reported back. That gives you |some entropy. Which is a slightly longer context gives you good |verification that you are not contining sending into a location where |there receiver you intended to have sent to moves away. | |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] 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