Hi,
This is somewhat related to RT #1709
In the case where one record within the flight is lost, the DTLS state
machine will
continue to move forward without detecting it.
This is observed when the MTU is low and the cert was fragmented into
multiple records.
Let's say one fragment of the client's cert is lost, when the server
receives the subsequent ClientKeyExchange, CertificateVerifym
ChangeCipherSpec and Finish, it will happily compute the checksum, complains
and terminate the connection.
The right approach would be to wait for the peer to retransmit and make sure
all fragments had been reassmbled before computing checksum.
I understand that much of the DTLS code was borrowed from TLS where there is
no out-of-order or missing packets...
To reproduce, simply add a random packet dropper between the socket and
DTLS.
Thanks,
Alex.
Hi,
This is somewhat related to RT #1709
In the case where one record within the flight is lost, the DTLS state machine will
continue to move forward without detecting it.
This is observed when the MTU is low and the cert was fragmented into multiple records.
Let's say one fragment of the client's cert is lost, when the server
receives the subsequent ClientKeyExchange, CertificateVerifym ChangeCipherSpec and Finish, it will happily
compute the checksum, complains and terminate the connection.
The right approach would be to wait for the peer to retransmit and make sure all fragments had been reassmbled before computing checksum.
I understand that much of the DTLS code was borrowed from TLS where there is no out-of-order or missing packets...
To reproduce, simply add a random packet dropper between the socket and DTLS.
Thanks,
Alex.
