On Wed, Oct 25, 2017 at 12:59 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > 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?
Exact numbers are difficult, but in general, the sender needs to remember an entire flight, plus the records that it sends and the parts of the flight that were in those records. In our implementation, we use ~35 octets per handshake message fragment, which could be reduced, possibly by quite a bit. Worst case is with large messages and small MTU/record limit with lots of packet loss, where you might have a fairly large number of these records to track what was sent. That is in addition to whatever messages you send, which you have to remember once they are constructed (Certificate being a real wild card here, of course). As you say, you can limit this by ensuring that you limit the size of messages and the number of fragments that you have outstanding. The receiver really only needs to track the data it receives. We (currently) pretend not to receive packets if they aren't contiguous with the data we have, so our outstanding memory is at most one handshake message and a couple of status variables. Once the handshake message is complete, we process it. If we had progressive parsing and processing, that might go lower, but we don't target constrained devices. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
