[rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness

Ted Hardie <ted.ietf@gmail.com> Mon, 07 April 2014 18:20 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 78A271A04AF for <rtcweb@ietfa.amsl.com>; Mon, 7 Apr 2014 11:20:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.599
X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id pvI2mUaqKlyu for <rtcweb@ietfa.amsl.com>; Mon, 7 Apr 2014 11:20:14 -0700 (PDT)
Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id ECFB01A0847 for <rtcweb@ietf.org>; Mon, 7 Apr 2014 11:20:10 -0700 (PDT)
Received: by mail-ig0-f175.google.com with SMTP id ur14so3968410igb.8 for <rtcweb@ietf.org>; Mon, 07 Apr 2014 11:20:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=UBB6WqZCP/PNkeHlH3uw4vFtr+2xPx0J8ti3dihMfCo=; b=vcGXGftjYZ0bABGU8dy+AwqHCv//fUGVF8hhEaqfc6r65+YIADeIA22PSSXwcMWi9l JNyEm3dR9j0luVRWXdr1OpxYjLEhg7Xu+UZO5uA8H2hl/RD5jsf8GDAGyGQl0UhYKRBY nC9MzlU4h9L+rf5QUO2+atb/oVfewbisBIAJSuT5uLgrHhgBfXKFWGRLmpvNJeMVKUbH aBaR0qlWlDlskRDVjRFQZodzchOBfGpB3NTLycDN3jpln5OgBnYUx6RZN6wqRvsa/+24 Rd3L7yvOkf2RTXa+P1MhlUHfzdKDhEjoinAx7qwvjCX7Qc5w1Q14zmag+W3FF6Re+PpD HDbw==
MIME-Version: 1.0
X-Received: by with SMTP id c9mr2043971icq.90.1396894805289; Mon, 07 Apr 2014 11:20:05 -0700 (PDT)
Received: by with HTTP; Mon, 7 Apr 2014 11:20:05 -0700 (PDT)
Date: Mon, 07 Apr 2014 11:20:05 -0700
Message-ID: <CA+9kkMBqnJbpSBr9SQN_zSRr41=eaQ096sr9TTSAJ5LC7hZO-g@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>, Oleg Moskalenko <mom040267@gmail.com>
Content-Type: multipart/alternative; boundary="001a1130c446a8703a04f677eab4"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/CjJkxxpe06kILY3sabsTnQNldv4
Subject: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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, 07 Apr 2014 18:20:21 -0000


The chairs recently asked for a review
draft-ietf-rtcweb-stun-consent-freshness; Oleg was kind enough to do one.
Below is the review.



On Fri, Apr 4, 2014 at 12:40 AM, Oleg Moskalenko <mom040267@gmail.com>wrote:
Hi Ted

I went through the document and I have two things to comment:

1) This document defines a "voluntary" pattern of the browser behavior.
Nothing stops the determined attacker from taking the WebRTC code and
creating a malicious client application that ignores all proposed
connectivity checks. May be it is worth mentioning in the "Security
Considerations" section.

2) I have a feeling that the document is written with somewhat optimistic
idea about the modern IP network qualities. The proposed timeouts are
probably too small. I am hearing from our TURN server users that in modern
Wi Fi public networks that's common to observe a freeze the IP traffic for
several seconds. After that "freeze" the connectivity is restored. The
users do not want the connection to be broken during that time - they want
the video screen frozen, temporary. I had to make adjustments to the TURN
server in our recent versions so that it does not disconnects the sessions
too quickly under those conditions (when TCP is used). I have a feeling
that you may have the same complains that the browser stops transmission in
public Wi Fi networks too quickly. I'd suggest to review the wording of the
proposal (like re-transmission after 500 ms and 15 secs timeout) to make it
more tolerant for the bad IP networks (which are surprisingly are rather

Overall, I think that this proposal is very useful.

Best regards,