[6lowpan] GHC now crunches DTLS (Re: [Roll] draft-bormann-ghc)

Carsten Bormann <cabo@tzi.org> Fri, 29 March 2013 13:22 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: 6lowpan@ietfa.amsl.com
Delivered-To: 6lowpan@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9825721F9403; Fri, 29 Mar 2013 06:22:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.156
X-Spam-Status: No, score=-106.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id FNa9NZvslK2G; Fri, 29 Mar 2013 06:22:13 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id F3E9721F9401; Fri, 29 Mar 2013 06:22:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de []) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r2TDM6lV003394; Fri, 29 Mar 2013 14:22:06 +0100 (CET)
Received: from [] (p5489300F.dip.t-dialin.net []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2BDE136A2; Fri, 29 Mar 2013 14:22:06 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset="iso-8859-1"
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <26808a929674c2b96850f40a9d7cd686@xs4all.nl>
Date: Fri, 29 Mar 2013 14:22:04 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <BF38A4D5-1D3A-4789-B7A6-6F34AAD6F0B1@tzi.org>
References: <18113.1339529290@marajade.sandelman.ca> <FA27D934-E3D9-4D1D-A110-DE7B47F82B2A@yahoo.fr> <CABONVQb5G=9RhpStqa-E6ohz1SLUsxAhvVytBN7emvXXjLU8hA@mail.gmail.com> <87AC724B-DC1F-41C2-9F1F-4357FA7B45A3@tzi.org> <31218.1345834358@sandelman.ca> <94E510D0-CFD3-45D5-BB4B-081A27D6AA4E@tzi.org> <26808a929674c2b96850f40a9d7cd686@xs4all.nl>
To: "6lowpan@ietf.org" <6lowpan@ietf.org>
X-Mailer: Apple Mail (2.1503)
Cc: roll@ietf.org, "ipv6@ietf.org List" <ipv6@ietf.org>, "core (core@ietf.org)" <core@ietf.org>
Subject: [6lowpan] GHC now crunches DTLS (Re: [Roll] draft-bormann-ghc)
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Mar 2013 13:22:16 -0000

On Aug 25, 2012, at 13:41, peter van der Stok <stokcons@xs4all.nl> wrote:

> GHC applied to DTLS encrypted messages is interesting indeed. It may represent an important number of messages to transmit.
> I would concentrate on getting the GHC on DTLS results known and then start pushing ghc draft.

It took a while, but is now done:  GHC-06 is ready for consumption.


It turns out my gut feeling about how to design this was just about right, so with all the research done, the only technical change from the previous version is the addition of a 16-byte static dictionary.  This should result in about a 3-line change in an implementation (and 16 bytes of increased temporary buffer size).  The specification no longer fits on a single page because that includes a note about the reserved code points.

I also have removed the speculative parts of GHC-05 -- there was little interest in the added complexity.  There is a little bit of innovative formatting because I'm using XML2RFCv2 now; there should be fixes for this soon.

The examples have been expanded to show the compression of DTLS handshake and application data messages; if you subtract the actual payload (cleartext and authenticator), the total DTLS overhead is around 8 bytes for application data (so, including the TLS_PSK_WITH_AES_128_CCM_8 authenticator, a DTLS message is 16 bytes longer than an uncompressed NoSec one). The examples section also shows the very slight overall improvement to the compression (including a regression, where the example ND advertisement now needs a byte more).

I'm pretty sure now that we have reached the point of diminishing returns.
If we still had an active WG, I'd go for WG adoption and a WGLC soon.
We'll see how to handle this in the shutdown phase of the 6lowpan WG.
In the meantime, please do send in your comments (preferably to the 6LoWPAN list).

I'm CCing 6man because part of the proposal is a new ND (ICMPv6) option for node capability indication.
Specific comments on that probably best go to the 6man mailing list.

Grüße, Carsten