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

"Muthu Arul Mozhi Perumal (mperumal)" <> Wed, 27 November 2013 02:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A1C251AE051 for <>; Tue, 26 Nov 2013 18:06:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A7IrOLlMnY1S for <>; Tue, 26 Nov 2013 18:06:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9BD9B1AE061 for <>; Tue, 26 Nov 2013 18:06:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2613; q=dns/txt; s=iport; t=1385518003; x=1386727603; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3NB0I2CTXAN52EWuqnwQ+iXRN/caDTCFe/ll83Ifksc=; b=Uqzte8gVIhkrJX2xzgvyB8fP+Y9Lm9uREgxuonoO8lPWlfKuM3+F+smL 7Ielg5QyeiixSLee6kUXuW6bQ2tLzb2D0akc1xZWad73ov+fbcaOnm/xq f514+6NR51q+wVrz7AFEZXENbOp594L2Xik0PynHqfWOGvSLIBzp3E9Tw I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.93,779,1378857600"; d="scan'208";a="287759423"
Received: from ([]) by with ESMTP; 27 Nov 2013 02:06:43 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id rAR26hhR015402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 02:06:43 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 20:06:42 -0600
From: "Muthu Arul Mozhi Perumal (mperumal)" <>
To: Martin Thomson <>, "Tirumaleswar Reddy (tireddy)" <>
Thread-Topic: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00
Thread-Index: AQHO6tMq3kHRuwrIQkmVqlzIxQ7eZJo4UCJA
Date: Wed, 27 Nov 2013 02:06:41 +0000
Message-ID: <>
References: <> <> <BLU169-W10885AF717BCBB60830502093E60@phx.gbl> <> <BLU169-W11416B2C0D42888C078A7F493E60@phx.gbl> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Wed, 27 Nov 2013 02:06:50 -0000

Are there cases where you won't do ICE but do DTLS, for WebRTC? If not, I think you can combine the best of both:
- The initial consent is established by ICE connectivity checks already.
- The receipt of any authenticated packet, including DTLS heartbeat, grants 
  you consent to send more packets.
- If you doesn't receive any packet and consent is about to expire, send a 
  STUN binding request that is comparatively less CPU intensive.

Minimal overhead overall :)


|-----Original Message-----
|From: rtcweb [] On Behalf Of Martin Thomson
|Sent: Tuesday, November 26, 2013 11:43 PM
|To: Tirumaleswar Reddy (tireddy)
|Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00
|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.
|rtcweb mailing list