Re: [TLS] DTLS 1.3 ACKs

[Ilari Liusvaara <[e-mail]>]

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