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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 871121ADEB7 for <>; Wed, 27 Nov 2013 09:38:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 GRZZLXSRqINw for <>; Wed, 27 Nov 2013 09:38:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 19EF31AD628 for <>; Wed, 27 Nov 2013 09:38:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2580; q=dns/txt; s=iport; t=1385573885; x=1386783485; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6j/Lk1qCf+FM01ztP7enz7wURIIWPtmMo1oxa49+c7k=; b=L6mDFdu2iD2uz1VUnbtm1omGVoo/hCSW/rvkgVATUOYENOJeKfVMdtc9 yOr/NnfiO/d6zwmtRgiXS9pEVNKR6IjyEOQFSyn+7Ez739XmZoUqUsJ1f GL6gidGTg8U4aaXQXWSXUhlVBWTR2W4BXFiZhhJteehZkoMiQd4eSrPpY A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.93,783,1378857600"; d="scan'208";a="2704364"
Received: from ([]) by with ESMTP; 27 Nov 2013 17:38:05 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id rARHc5Jm016214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 17:38:05 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Wed, 27 Nov 2013 11:38:04 -0600
From: "Muthu Arul Mozhi Perumal (mperumal)" <>
To: Martin Thomson <>
Thread-Topic: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00
Thread-Index: AQHO65WAELUuQiNDn0uSYfT1pzheJ5o5VRlQ
Date: Wed, 27 Nov 2013 17:38:04 +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="utf-8"
Content-Transfer-Encoding: base64
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 17:38:07 -0000

|-----Original Message-----
|From: Martin Thomson []
|Sent: Wednesday, November 27, 2013 10:54 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: Tirumaleswar Reddy (tireddy);;
|Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00
|On 26 November 2013 18:06, Muthu Arul Mozhi Perumal (mperumal)
|<> wrote:
|> 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 :)
|I disagree.  One of the merits of using the DTLS handshake to
|establish initial consent, authenticated packets to maintain it, and
|the DTLS heartbeat in the absence of authenticated packets is that it
|is all DTLS.  As someone who writes software, being able to keep all
|the logic constrained to a single software module is a significant

Well, my point is, for WebRTC you can also do the same optimization by confining the logic to the STUN module -- both can establish and maintain consent without generating additional traffic for majority of the use-cases.

From a security perspective, I don't see a real advantage of one over the other.


|I don't believe the CPU cost of a DTLS heartbeat to be expensive
|enough to justify changes to this.  Given that you aren't using the
|CPU for crypto at all when you send it, I'm pretty sure that the CPU
|cost can be borne.