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 mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
