Re: [TLS] DTLS 1.3 ACKs
Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 24 October 2017 13:59 UTC
Return-Path: <ilariliusvaara@welho.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64FB13F59A for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 06:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 RnMjtSLVoU2X for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 06:59:35 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 574A51388A0 for <tls@ietf.org>; Tue, 24 Oct 2017 06:59:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 1C16653731; Tue, 24 Oct 2017 16:59:33 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id IZGRkBzIiBlT; Tue, 24 Oct 2017 16:59:32 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 2FDC827B; Tue, 24 Oct 2017 16:59:29 +0300 (EEST)
Date: Tue, 24 Oct 2017 16:59:29 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Message-ID: <20171024135929.ijathkbwc3vh4635@LK-Perkele-VII>
References: <CABcZeBNvaZmbvUTmzvGznqSBmEDn4KAeFXxyxHcR25bV9WVUDg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABcZeBNvaZmbvUTmzvGznqSBmEDn4KAeFXxyxHcR25bV9WVUDg@mail.gmail.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Er7gD2ir0hCRYtCSSFim-k9T31Y>
Subject: Re: [TLS] DTLS 1.3 ACKs
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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, 24 Oct 2017 13:59:38 -0000
On Mon, Oct 23, 2017 at 06:14:33PM -0700, Eric Rescorla wrote: > We now have DTLS 1.3 implemented in NSS, which went pretty cleanly. What is the _worst_ case memory usage (both sending and receving) for handling the acknowledgements and guaranteeing forward progress in all reasonable cases? There is not much discussion in the draft about memory usage of ACK handling and how to limit it. This matters very much if using DTLS for (effectively) small devices, which are seemingly a major usecase. One strategy I see on receive side is just keeping fixed 150 RSN ack buffer on receive side, reset for every flight, and if this ever overflows, abort the connection. Maintaining this buffer needs 1201 bytes of memory (the odd byte is for occupancy count). On limited devices, one might shrink this buffer further. And then have per-byte bitmasks and unreceived count for buffered handshake message (eats n/8 + few bytes for n byte message). On sending side, one resource-limited strategy is to keep newest retransmit number and acknowledged flag for each 480 byte chunk. Unencrypted records can be special. This eats (8 bytes for each starting 480 bytes in each message in flight buffer plus about two dozen fixed bytes)... With 480-byte chunking, single-chunk packets would confortably fit in IPv4 minMTU, and double-chunk/double-length packets would comfortably fit in IPv6 minMTU. The sender-side strategy can not handle receivers that signal maximum fragment size below 512 bytes or so... Actually, I don't think maximum fragment size is actually useful in DTLS, what you want for DTLS is maximum *packet* size. Also, this strategy limits the flight size, but should be enough for anything reasonable. > The one thing we ran into was the potential need to ACK in cases where you > can't process *any* records (e.g., you receive what's actually EE, but you > can't decrypt it). In this case, you want to send an empty ACK. > > See PR: > https://github.com/tlswg/dtls13-spec/pull/14 The ACK structure definition does not seem to allow empty ACK. -Ilari
- [TLS] DTLS 1.3 ACKs Eric Rescorla
- Re: [TLS] DTLS 1.3 ACKs Ilari Liusvaara
- Re: [TLS] DTLS 1.3 ACKs Martin Thomson
- Re: [TLS] DTLS 1.3 ACKs Nikos Mavrogiannopoulos
- Re: [TLS] DTLS 1.3 ACKs Ilari Liusvaara