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

"Ram Mohan R (rmohanr)" <> Fri, 11 April 2014 10:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 717011A05C3 for <>; Fri, 11 Apr 2014 03:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.373
X-Spam-Status: No, score=-8.373 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WNpfcN9ai8Nq for <>; Fri, 11 Apr 2014 03:16:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BF30D1A0573 for <>; Fri, 11 Apr 2014 03:16:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2563; q=dns/txt; s=iport; t=1397211361; x=1398420961; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=e4lQEKBwcco2cm19yPZV5KlDsr9wOMHNYs+YmmS0OUQ=; b=AoY1/v/afUXIwU7tDzsfvqlpto9JtKzMylwQwU2JehSpjzeUdCEuCtfx Xr2p51EKXwptUK4Eitpc97DMlQfuw7qVAZ1nPjO91KyT/ZZ30QXNdBdHU N7YDpSx25XKIjPDYYptPA2spUsLAuD8TOzE5DbG75FPQBdnTk5+eQR6Wo 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.97,841,1389744000"; d="scan'208";a="34905880"
Received: from ([]) by with ESMTP; 11 Apr 2014 10:16:00 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s3BAG19w016028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Apr 2014 10:16:01 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Fri, 11 Apr 2014 05:16:00 -0500
From: "Ram Mohan R (rmohanr)" <>
To: "" <>, Oleg Moskalenko <>
Thread-Topic: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness
Thread-Index: AQHPU9ox18KS0rN1tEWX369fwer6hpsM5mAA
Date: Fri, 11 Apr 2014 10:16:00 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness
X-Mailman-Version: 2.1.15
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: Fri, 11 Apr 2014 10:16:07 -0000

Hi Ted,

Thanks for forwarding the feedback from Oleg. Please see inline for answers

>From:  Ted Hardie <>
>Date:  Monday, 7 April 2014 11:50 pm
>To:  "" <>, Oleg Moskalenko
>Subject:  [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness
>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 <>
>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.

Agree. A malicious browser that does not conform to this spec can do any
thing. I am not sure if we really any text to be added for that in the

>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 common).

Agree. We had revised a lot of text in the solution description section of
the draft (draft-ietf-rtcweb-stun-consent-freshness-02).
The text now is very generic and does not assume any specific timer
values. Please review the latest text and let us know if that looks ok.


>Overall, I think that this proposal is very useful.
>Best regards,