[TLS] DTLS 1.3 ACK sorting, and when to clear the ACK buffer

[David Benjamin <[e-mail]>]

Hi all,

In another thread, I was asked whether I thought I had gotten a complete
list of issues, and I said it is hard to know when one is done realizing
all the things one hasn't realized yet. Particularly in the process of
implementing things. That seems to have been correct. Here's another topic
for the list. :-)

So, Section 7 says the ACK contains:
> A list of the records containing handshake messages in the current flight
which the endpoint has received and either processed or buffered, in
numerically increasing order.
https://www.rfc-editor.org/rfc/rfc9147.html#name-ack-message

First, it is ambiguous what "numerically increasing order" means when there
are two integers in a packet number, not one. But, more importantly, I'm
not sure this matches what implementations do. I haven't tested carefully,
so I may be wrong about this, but at a glance, I don't think either NSS or
wolfSSL's DTLS 1.3 implementations (are there any other DTLS 1.3
implementations yet) do this?

Keep in mind that appending records to the list as you receive them will
*not* result in numerical order because packets may be reordered. If no one
is following this rule anyway, perhaps we should just remove it?

In particular, it seems a natural implementation will result in receive
order, not numerical order. Implementations should bound their ACK buffers
to avoid DoS, and are expected to preferentially ACK more recent records:

> Implementations MAY acknowledge the records corresponding to each
transmission of each flight or simply acknowledge the most recent one. In
general, implementations SHOULD ACK as many received packets as can fit
into the ACK record, as this provides the most complete information and
thus reduces the chance of spurious retransmission; if space is limited,
implementations SHOULD favor including records which have not yet been
acknowledged.

Given that, the natural implementation is some kind of bounded MRU queue of
records, where old ones fall off the end. (I'm planning to use a ring
buffer for our implementation.) To get numerical order, you'd need to
re-sort when sending an ACK. That is not hard, but it's unclear to me
what's the point.

Next, the spec's guidance on when to clear the ACK buffer seems odd to me.
Section 7 also says:

> During the handshake, ACKs only cover the current outstanding flight
(this is possible because DTLS is generally a lock-step protocol). In
particular, receiving a message from a handshake flight implicitly
acknowledges all messages from the previous flight(s). Accordingly, an ACK
from the server would not cover both the ClientHello and the client's
Certificate message, because the ClientHello and client Certificate are in
different flights. Implementations can accomplish this by clearing their
ACK list upon receiving the start of the next flight.

The claim that clearing this ACK list accomplishes this is not true, for
several reasons:

First, there's nothing stopping you from receiving a (redundant) portion of
the previous flight while you're receiving the new one. You'll notice all
the sequence numbers are old and ignore them when processing, but that
still keeps the record eligible for an ACK. Moreover, it's still important
ACK to old fragments. When the old fragment is in the *current* flight, the
peer may have lost an earlier ACK and not realize they can stop
retransmitting. It's only old fragments in *previous* flights that are
unnecessary to ACK, but the specification does not suggest to distinguish
them. (Distinguishing them would require extra state in the record layer to
store a low watermark for the flight, and that seems a waste. There's no
real harm in adding that record to the ACK buffer.)

Next, packets can be reordered. You might receive not the start of the next
flight, but the middle of the next flight. In general, any DTLS record
layer rule keyed on the start of a flight is suspect because of packet
reordering. But actually I'm not sure if the spirit of this rule is correct
at all.

If the peer sent flight N-1, you sent N, and now you're in the middle of
receiving flight N+1, you can stop ACKing flight N-1 as soon as you start
*sending* N. You don't need to wait to receive N+1. *Every* fragment of N
implicitly ACKs all of N-1, so as soon as you're ready to send any part of
N, you may as well send that instead of ACKing individual records because
then you also make progress in the connection. The spec instead says to
wait until receiving part of N+1, which seems later than needed and may not
even exist.

(Neither version achieves the stated goal in the spec. The stated goal
seems to require tracking extra state.)

With all that said, it seems odd to be clearing the ACK buffer at all. I've
gathered the reason to ACK by record number instead of message ranges (and
thus require the implementation keep around some state) was so that RTT
measurements could work despite retransmits. Is that right? But if the
happy path doesn't ACK most records in the first place, you won't actually
get an estimate out of it.

David