Re: [TLS] Record header size?

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 17 November 2015 21:53 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E49E1B3165 for <tls@ietfa.amsl.com>; Tue, 17 Nov 2015 13:53:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 eywcv72c8Ph5 for <tls@ietfa.amsl.com>; Tue, 17 Nov 2015 13:52:58 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8A61B3166 for <tls@ietf.org>; Tue, 17 Nov 2015 13:52:57 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 33030284D23; Tue, 17 Nov 2015 21:52:56 +0000 (UTC)
Date: Tue, 17 Nov 2015 21:52:56 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20151117215255.GO18315@mournblade.imrryr.org>
References: <C5F506DC-F814-4C0B-AFAA-86CF790817A7@akamai.com> <CABcZeBP5QPQAXKvM_oEAzex0-vrVWMvOW0yZuamvF5hxAHtmtw@mail.gmail.com> <87egfoe4n2.fsf@alice.fifthhorseman.net> <D5A18321-BA89-4047-91A0-D0259E70F0D9@akamai.com> <CABcZeBP8YSnv16Goa4-5ZVRS5eyq1N9-Qe1GwkV=A6EmWWE86w@mail.gmail.com> <75C621A0-AAFB-4BB9-9958-17864699C2C7@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <75C621A0-AAFB-4BB9-9958-17864699C2C7@akamai.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/3MP58C8QHuMvQYXqeQ3fVe0CyNY>
Subject: Re: [TLS] Record header size?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Nov 2015 21:53:00 -0000

On Tue, Nov 17, 2015 at 09:26:57PM +0000, Short, Todd wrote:

> Embedded systems don�t have the luxury of mbuf-type of buffer scheme (as
> you describe for NSS). Many have ethernet-frame sized buffers in
> locked/pinned memory that read in a whole ethernet frame, and then strip
> off headers by advancing pointers into the frame. This minimizes copies,
> and the goal is to have a zero-copy network stack.

Right, both IP and TCP add padding after options to align the
payload on a 32-bit boundary.  So the TLS record layer always starts
at a 32-bit aligned address, which ensures that the record payload
is always misaligned.  Padding the record header with zeros to the
next multiple of 32-bits could plausibly improve the performance
of bare-metal zero-copy implementations.

-- 
	Viktor.