Limit reorder buffer

[boaks]

No description provided.

[boaks]

Fixes #273

[mrdeep1]

In general seems to be OK, but have no easy way of re-ordering packets to test.

[mrdeep1]

This can flood the logging (as done by the PoC) . Suggest you add in

patch1.txt

[mrdeep1]

Do we need to be generous and set the default limit to 1024?

[mrdeep1]

On further thinking, this needs to be at least the MTU size, otherwise a single large PDU will not get processed.

[boaks]

The question, I tried to answer:
How much data is required to be queued for an valid handshake (PSK/RPK)?
If someone want to queue more, the value may be just provided from outside.

[mrdeep1]

We need a sensible limit to prevent a DoS. I have found

Handshake Data Size (Length): A typical DTLS 1.3 handshake utilizing RPKs transmits approximately 894 bytes of total data.

I know we are not DTLS 1.3, but...

[boaks]

approximately 894 bytes of total data

The point is not DTLS 1.3, the point is rather, it's not the "total data".

See RFC 6347 - Flights:

A peer is not waiting for the "total data", the peer waits for a flight.

And so the maximum size to keep in the reorder buffer is the one of the largest flight.
Therefore the comment:

 * Using RPK the largest server flight has about 450 bytes
 * and the largest server flight has about 400 bytes

I guess, there will then be something: "but under attack".
There may happen much more under attack and everyone may just chose 1 or 2 k, if wanted.

And also just to mention, the most peers with PSK&RPK will be able to send the flights in one message and reordering will not happen at all.

[mrdeep1]

OK

[mrdeep1]

Given that the RPK is defined as RFC7250 3. Structure of the Raw Public Key Extension as being up to 2^24-1 in size

   // certificate type defined in this document.
            case RawPublicKey:
              opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>;

which is bigger than an MTU (but in reality impractical), the aggregate size should be limited to a maximum PDU size.

This then allows only ~1500 bytes to be allocated when under DoS attack, but safely covers general use.

[boaks]

RPK may use in general more data ...
But in tinydtls only one curve/group is supported (secp256r1).
I toke the numbers from a real handshake with wireshark.

[mrdeep1]

But in tinydtls only one curve/group is supported (secp256r1).

Fair comment. But this may get added to in the future and cause a bit of confusion when packets effectively get dropped. Hence the suggested limit of a MTU size,

[boaks]

I'm pretty sure, if other curves/groups will be supported in the future, we will not forget to adjust this value :-).

[mrdeep1]

Providing https://github.com/user-attachments/files/32920552/patch1.txt is added, this is good to go.

[boaks]

I add the "reported" flag to the dtls_handshake_parameters_t instead of the dtls_peer_t to slightly reduce the memory consumption and time using it.

[mrdeep1]

LGTM.