Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00

Martin Thomson <> Tue, 26 November 2013 18:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 928831ADFE3 for <>; Tue, 26 Nov 2013 10:13:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id adzUc35Ea2F3 for <>; Tue, 26 Nov 2013 10:13:01 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c05::22e]) by (Postfix) with ESMTP id E740F1ADFB1 for <>; Tue, 26 Nov 2013 10:13:00 -0800 (PST)
Received: by with SMTP id ey16so882269wid.13 for <>; Tue, 26 Nov 2013 10:13:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gnvTpUFKIT9vVmoM5H8igW1sHfXd18u5d9HO+7pLYy0=; b=Y3YO8pfkVKIc0IEyXXbSl6XEtQIYrrdXmPgnsT4zjsUBQwzgqbUosX6daNTGjSJ4Zc rMEedQFhJXg6/w3WuQjUXWfiygMpzE/8KPzr662z+mDhdmLkEg7xTGaJ1npX67DoXEa0 bP+H1sDsvII2WUfIo+Y9wE9Q8IBKqMnOEBjVKMC1SNnO/o/poHQ5TNTSc3U4KQgefzCO KmasuKaQ2ibPEAAU8R8un2lDHzqsaRidBPQRGOdqJ2e+3uqebyZQTqF7uXieZ1vlO/Px BEJh5YeJ8e0RPuWPl3RH4pZ4JeAKn9GaFjQHX2WGFRFCRrYnHzMeZjEB3UxTqd0ynGn4 EMrw==
MIME-Version: 1.0
X-Received: by with SMTP id mb17mr19319571wic.64.1385489580285; Tue, 26 Nov 2013 10:13:00 -0800 (PST)
Received: by with HTTP; Tue, 26 Nov 2013 10:13:00 -0800 (PST)
In-Reply-To: <>
References: <> <> <BLU169-W10885AF717BCBB60830502093E60@phx.gbl> <> <BLU169-W11416B2C0D42888C078A7F493E60@phx.gbl> <>
Date: Tue, 26 Nov 2013 10:13:00 -0800
Message-ID: <>
From: Martin Thomson <>
To: "Tirumaleswar Reddy (tireddy)" <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>, "" <>
Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00
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: Tue, 26 Nov 2013 18:13:02 -0000

These are good observations.

On 26 November 2013 02:34, Tirumaleswar Reddy (tireddy)
<> wrote:
> [1] and [2] can be solved by mandating WebRTC endpoints to support consent.

Yes, that would be the plan.  We would also have to force the
inclusion of peer_allowed_to_send(1) in the extension, lest things get

> [3] DTLS heartbeat seems to be more CPU intensive than STUN consent (Generating arbitrary content (payload and padding 40 bytes), encrypting it). Though this may not a concern since heartbeat will only be sent when authenticated packets are not received.

I'm thinking: a) not a concern because it's only a factor if you
aren't sending, and b) not a concern because it's not a lot of work to
generate an authenticated packet.  Less work I think if you are using
AES-GCM modes.

> [4] DTLS heartbeat doubles the timer value at each retransmission but with STUN consent retransmission is repeated every 500ms. There seems to be no application level control on the retransmission mechanism used by OpenSSL DTLS implementation.

That's a good point, I'll have to check to see if we need to update
6520, or whether just saying to avoid retransmission is sufficient.
(I think the latter, but don't care too much.)

> [5] With STUN consent, browser can find the RTT time which is not possible with OpenSSL DTLS heartbeat API.

This is true to exactly the same extent for both forms.  Some STUN
implementations don't allow for the sending of a single check, they
also do the full exponential backoff thing.