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

Magnus Westerlund <> Thu, 22 September 2011 12:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E6D921F8B80 for <>; Thu, 22 Sep 2011 05:35:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.524
X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xauzuwqAO7xB for <>; Thu, 22 Sep 2011 05:35:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BB8FA21F8C0B for <>; Thu, 22 Sep 2011 05:35:09 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-75-4e7b2c12177f
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id B5.DC.20773.21C2B7E4; Thu, 22 Sep 2011 14:37:38 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Thu, 22 Sep 2011 14:37:38 +0200
Message-ID: <>
Date: Thu, 22 Sep 2011 14:37:24 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: "Muthu Arul Mozhi Perumal (mperumal)" <>
References: <><><><><><><><><><092401cc749b$8fd64940$af82dbc0$@com><><><0ced01cc76de$28731630$79594290$@com> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.3.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "" <>
Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Sep 2011 12:35:11 -0000

On 2011-09-22 14:19, Muthu Arul Mozhi Perumal (mperumal) wrote:
> |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..

If neither party is actually transmitting media then the only traffic is
RTCP in either directions. Thus one RTCP compound packet per SSRC per
regular reporting interval. Unless you have an app that open a lot of
media streams that is usually pretty low bit-rate. And if you actually
have a lot of streams, then the bit-rate will saturate at the configured
RTCP rate. But I would note this is in fact a potential attack vector if
one can set the RTCP bit-rate arbitrary high.

Secondly, I think in those cases a timer on the inactivity from both
parties should be considered to terminate the session.


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: