Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt

"Avasarala, Ranjit (NSN - IN/Bangalore)" <> Wed, 17 July 2013 05:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FC5221F9D7E; Tue, 16 Jul 2013 22:50:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B+z7keczTavn; Tue, 16 Jul 2013 22:50:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F225D21F9D75; Tue, 16 Jul 2013 22:50:51 -0700 (PDT)
Received: from ([]) by ( with ESMTP id r6H5okNv000695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Jul 2013 07:50:46 +0200
Received: from ([]) by ( with ESMTP id r6H5oYFP019158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 07:50:45 +0200
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 17 Jul 2013 13:48:52 +0800
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Wed, 17 Jul 2013 13:48:52 +0800
From: "Avasarala, Ranjit (NSN - IN/Bangalore)" <>
To: "Muthu Arul Mozhi Perumal (mperumal)" <>
Thread-Topic: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
Thread-Index: AQHOgiT6JQEMzVPeD0imnIi9kp/qUZloXWjA
Date: Wed, 17 Jul 2013 05:48:51 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R)
X-purgate: clean
X-purgate: This mail is considered clean (visit for further information)
X-purgate-size: 3795
X-purgate-ID: 151667::1374040247-00002EAE-9CF423F9/0-0/0-0
Cc: "" <>, "" <>
Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt
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: Wed, 17 Jul 2013 05:50:58 -0000

Hi Muthu

Though using STUN request/response may be good for querying about consent, I feel it is overloading the functionality of STUN. Many publicly available STUN servers or those that are part of Call servers may not support this.

Can't there be some other neutral mechanism to query peer's consent - through signaling? 


-----Original Message-----
From: [] On Behalf Of ext Simon Perreault
Sent: Tuesday, July 16, 2013 6:34 PM
To: Muthu Arul Mozhi Perumal (mperumal)
Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt

Le 2013-07-16 14:43, Muthu Arul Mozhi Perumal (mperumal) a écrit :
> |> |>    Liveness timer: If no packets have been received on the local port in
> |> |>    Tr seconds, the WebRTC browser MUST inform the JavaScript that
> |> |>    connectivity has been lost.  The JavaScript application will use this
> |> |>    notification however it desires (e.g., cease transmitting to the
> |> |>    remote peer, provide a notification to the user, etc.).
> |> |
> |> |This seems to me like it will not fulfill the goal set in the abstract:
> |> |"to ensure that a malicious JavaScript cannot use the browser as a
> |> |platform for launching attacks". If the JavaScript is free to ignore the
> |> |notification from the browser, then it has no security benefits. If you
> |> |want to reach that goal, the browser needs to forcefully stop transmitting.
> |>
> |> That goal is fulfilled by the consent checks -- the browser would stop transmitting everything on
> |that candidate pair, including liveness checks, if there is a consent failure.
> |
> |That's not what the draft says. It says that the browser "notifies" the
> |JS app. It needs to say that the browser MUST stop sending.
> No. That section is about liveness check and its intention is just notify the JavaScript of a potential connectivity loss. It is when the consent check fails the browser actually stops sending everything. Does the draft need more text on the distinction between consent and liveness tests?

Ah! No, you're right, and the text is already perfectly clear about
this. No need to change. I was just confused.

> |> |>    When not actively sending traffic on a nominated candidate pair,
> |> |>    performing consent freshness does not serve any purpose from a
> |> |>    security perspective.
> |> |
> |> |I don't understand what this means. Why is the "security perspective"
> |> |important here? Aren't we concerned about keepalives?
> |>
> |> You mean one could use keepalives (Binding indications) for launching attacks, so consent freshness
> |would be required for sending them as well?
> |
> |No.
> |
> |This is a section about keepalives. I just don't understand this
> |sentence, and I don't understand why it talks about security.
> Ok, let me elaborate:
> - Consent freshness is not necessary when the browser is not sending any 
>   traffic on a candidate pair.
> - If the browser is not performing consent freshness on a candidate pair 
>   for the above reason, it performs ICE keepalives (or RTP keepalives) to
>   refresh NAT bindings.
> Of course, the browser could continue performing consent freshness even when it is not sending any other traffic on that candidate pair and skip ICE keepalives.

Ah, ok I understand with your explanation. It makes sense. There should
be a way to reformulate the text to make it clearer.

rtcweb mailing list