IETF Logo Mail Archive

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

Martin Thomson <martin.thomson@gmail.com> Wed, 27 November 2013 17:24 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625121AD79D for <rtcweb@ietfa.amsl.com>; Wed, 27 Nov 2013 09:24:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X25pBItQX6GC for <rtcweb@ietfa.amsl.com>; Wed, 27 Nov 2013 09:24:07 -0800 (PST)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9F15D1AD628 for <rtcweb@ietf.org>; Wed, 27 Nov 2013 09:24:07 -0800 (PST)
Received: by mail-wg0-f43.google.com with SMTP id k14so4555338wgh.22 for <rtcweb@ietf.org>; Wed, 27 Nov 2013 09:24:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gLwHjl/wcyEPDcrDNhx8Q2ucwCyztcx3IVw5YuqOh9M=; b=k00LnXTKA4Q7i0htwW2D6tNh88OSiYy+yRTk1E/nbPQ3mu3WToF2GN1CaSZPplnl0N g8kR7chKlmUQcUfaEXr5A0nVFXiER2EdivbhIWs0GvebtMnKWCg2oUJd6DtoI5++gsD7 QCdE2AljRfGsANZ4Wz3I/fQlKvZTHSmdpQWBErm61V/K7pDM5IQZwIX2uln/5IK6FLb1 cFeMdAd2gCTpmkQq3v31X7UCAV9by6/9XBQMRiJZLcbn28r4YxW4C1811qBYcUNSU+sT rpSN5KOxQgjMBBIyFxf/OfNCGZcpVNYzVvqhvLLhkYFw6uzuIzwH3uKzvWVJr2zvChVx 2E9Q==
MIME-Version: 1.0
X-Received: by 10.194.94.167 with SMTP id dd7mr12698241wjb.43.1385573046589; Wed, 27 Nov 2013 09:24:06 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Wed, 27 Nov 2013 09:24:06 -0800 (PST)
In-Reply-To: <E721D8C6A2E1544DB2DEBC313AF54DE224363368@xmb-rcd-x02.cisco.com>
References: <CEAB0083.6FBE3%rmohanr@cisco.com> <5285E318.3090006@ericsson.com> <BLU169-W10885AF717BCBB60830502093E60@phx.gbl> <CABkgnnVpikDFwzfc=6CnHDOb6rmoe5-54AdYPyrbRvU34Epfig@mail.gmail.com> <BLU169-W11416B2C0D42888C078A7F493E60@phx.gbl> <913383AAA69FF945B8F946018B75898A2426E369@xmb-rcd-x10.cisco.com> <CABkgnnU5RqbF-PPtihGU+rtuqemN9f7N7nXLB05_OpF7EmhxjQ@mail.gmail.com> <E721D8C6A2E1544DB2DEBC313AF54DE224363368@xmb-rcd-x02.cisco.com>
Date: Wed, 27 Nov 2013 09:24:06 -0800
Message-ID: <CABkgnnV6Ta+Hukps6HRQsvaHVis+aZ0NdT7wvL3VZ2NVRpRoZw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "Muthu Arul Mozhi Perumal (mperumal)" <mperumal@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Cc: "draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org" <draft-ietf-rtcweb-stun-consent-freshness@tools.ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] RFC 6520 vs. draft-ietf-rtcweb-stun-consent-freshness-00
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: Wed, 27 Nov 2013 17:24:09 -0000

On 26 November 2013 18:06, Muthu Arul Mozhi Perumal (mperumal)
<mperumal@cisco.com> 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
improvement.

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.

v2.23.0 | Report a Bug | By Email