[MMUSIC] ICE/DTLS optimization (was: Merging ICE aggressive and regular nomination)

Justin Uberti <juberti@google.com> Sun, 03 August 2014 18:07 UTC

Return-Path: <juberti@google.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 557821A0B12 for <mmusic@ietfa.amsl.com>; Sun, 3 Aug 2014 11:07:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.079
X-Spam-Status: No, score=-1.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id PzUlO4SQ4vm3 for <mmusic@ietfa.amsl.com>; Sun, 3 Aug 2014 11:07:05 -0700 (PDT)
Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 259D71A0B14 for <mmusic@ietf.org>; Sun, 3 Aug 2014 11:07:01 -0700 (PDT)
Received: by mail-vc0-f174.google.com with SMTP id la4so9753380vcb.33 for <mmusic@ietf.org>; Sun, 03 Aug 2014 11:07:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=K9oiXNuCrMeachjOl/pJ38vT06zwhGGa8FqIKk/7Pjk=; b=UqYZ2dTwbGTfaRjglKXNdP7uEGXs5Lu8pkrHfTcgCDaO+68OO7k9NFPErNNe6UB0bw reaGrnRKsibKwmjj9N6DS6b9D9jmAyYl45XlnR8PtjTVr1qZBj9HHCHOBB20am0h9tjC MxSdhdRCUkOpu1vDhvQntav3ZXR6Zpi/rbhGKegOR38S/NkFCdubyldUcLl5ZeBluydR mFfh1SGyQa7+v8UD9KGrFyqs5pIGHDC89A6Lq4s8M7BkGZJPiV7GhGqjWOHBZbRW8J87 lAxIPxgVfR/dZeiz/kaqDKuZByu7aUkQ8PKv5CnPoSvJ7iLvYtlqw9wPwRkuMaLbwmL7 p3QQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=K9oiXNuCrMeachjOl/pJ38vT06zwhGGa8FqIKk/7Pjk=; b=VkKQ/6wbeODWDIC1uNIl295d1avZUc3Uzj+559liWQiyLuOiKPV8l3KltUNolBj2Zu njXFcBLA05twxV8ymoflz060UQbd7umAp1eIeH7Vih3DUhmXQ/b+2tTLRQgdp3bPKkZ2 jxN/XySHcsjZAEsXRnBeRGV4/gSJz5Y5R4kzBLPbAdy2QnO7QodzAv/wkxVnsZTuQIwd FRFp/9abFuIAU4j83vEd7CYjkjKM8UZgYTaBePBFpI9uHE8tSwJfj/RW92tNqR2+2Z6T ALXYhkIYN15yodbxmOUNqoBzhv1AzDTK8XjG6HDGiWPlRF1pQTLKLZJCqbLVjkUWU1VA RVsQ==
X-Gm-Message-State: ALoCoQm6NL0aubQY8IDg7vbttcQ5aRme6l40jl05OH5gRDMu1DGLdOZ3y+EcpiUiGI6p47d/ylPQ
X-Received: by with SMTP id p8mr7931365vdp.28.1407089220942; Sun, 03 Aug 2014 11:07:00 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 3 Aug 2014 11:06:40 -0700 (PDT)
From: Justin Uberti <juberti@google.com>
Date: Sun, 3 Aug 2014 11:06:40 -0700
Message-ID: <CAOJ7v-03iSNNNVMV=1vM1nUuwgCsk6JkyxPcrDEpk7MTr1LmBQ@mail.gmail.com>
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: multipart/alternative; boundary=20cf3033447f2e9b1304ffbd7d31
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Nqw_TBdI-C1hRZ5ihMb5fR_5NYU
Cc: Jonathan Lennox <jonathan@vidyo.com>, mmusic <mmusic@ietf.org>
Subject: [MMUSIC] ICE/DTLS optimization (was: Merging ICE aggressive and regular nomination)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Aug 2014 18:07:07 -0000

On Sun, Aug 3, 2014 at 9:22 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

> 2014-08-03 17:44 GMT+02:00 Iñaki Baz Castillo <ibc@aliax.net>et>:
> > So why not the opposite?: Add the DTLS ClientHello packet into a new
> > STUN attribute (may be called "DTLS_PACKET"). Issues above solved:
> >
> > - STUN is processed as normal.
> >
> > - The *same* DTLS HelloClient can be set into *different* ICE Binding
> > requests, so there is a single DTLS handshake.
> >
> > - From the point of view of the sender, it is the same scenario in
> > which the sender sends a ICE Binding request followed by a DTLS
> > HelloClient, but with the guarantee that the ICE request will arrive
> > "first" :)
> >
> > - From the point of view of the receiver, it first receives (and
> > validates) the ICE Binding request, then generates the ICE response
> > and then processes the DTLS HelloClient contained in the "DTLS_PACKET"
> > attribute of the Binding request. This adds very little complexity to
> > existing implementations.
> More on this:
> - If the receiver supports the "DTLS_PACKET" STUN attribute it will
> add the DTLS ServerHello response (along with others) into the
> "DTLS_PACKET" of the ICE Binding Response.
> - If the ICE response has no "DTLS_PACKET" attribute then the client
> must send a "common" DTLS ClientHello.
> - DTLS packets to be exchanged after the STUN exchange (regardless
> DTLS_PACKET was supported or not) can be directly sent over UDP/TCP.
I agree it would be better to have the DTLS packet inside of STUN, rather
than the converse. I would also suggest that we make this agnostic of the
encapsulated protocol, e.g. allow for something like TURN's DATA attribute
to carry generic data in a binding request.

Note that it the actual upside here may turn out to be somewhat limited
given TLS 1.3's zero-RTT handshake modes.