Re: [tinydtls-dev] handshake message not received due to long processing

[Olaf Bergmann <bergmann@xxxxxxx>]

Hi Jan,

Thanks for your suggestions. You are right: The asymmetric crypto in
tinydtls is way too slow, and your observations are correct (though not
necessarily the assessment of what is causing these effects):

Jan Kühn <kuehnj@xxxxxxxxxxxxxxxxxxxxxxxxxx> writes:

> In the handshake, after receiving ClientHello the Server sends 5
> messages to the client: ServerHello, Certificate, ServerKeyExchange,
> Certificate Request, ServerHelloDone. The problem is, that some of the
> packets are not received by the client, however this is not due to
> random package loss. It appears that the client’s radio has a fifo
> buffer overflow because it doesn’t handle the messages fast enough.

There might be another effect kick in here: As Contiki uses cooperative
threading, data received on the network interface is not handled while
other threads run. Now, the tinydtls thread takes loooong for the ECC
operations during the handshake, blocking the network interface during
this time.

> First the problem was that I had a lot of debugging messages on the
> serial port and the client didn’t get the ServerKeyExchange message.
> After removing the debugging outputs, it worked fine until the client
> receives ServerKeyExchange. As I’m using the ECC cipher suite, the
> client has to perform a ECDSA verification which takes 20 seconds! In
> that time the client receives CertificateRequest and ServerHelloDone;
> CertificateRequest can be processed, ServerHelloDone however doesn’t
> fit in the client’s radio buffer and is therefore lost.
>
> To the solution:
>
> Eventually I want to use the CC2538’s ECC hardware components which
> should speed up the processing dramatically and hopefully solve this
> issue.

I guess it would.

> But as putting in the hardware will most probably lead to other
> bugs I would like to get the pure software implemented DTLS handshake
> running first. I see two options:
>
> 1. Artificially slow down the handshake message so both sides have
> enough time to process (simple but nasty).

No way.

> 2. Use a second buffer to first receive all handshake messages before
> starting any long processing. I think that the netq structure might be
> quite useful for this because it can store all the handshake messages.
> But I’m not sure how exactly it is used (I think the purpose is
> message reordering?) and if I could use it for this matter. Do you
> think this might work at all? Also do I have to use a “second” netq or
> might it be possible to use the one that is already used.

I am not sure if this works. Maybe in conjunction with splitting off the
handshake handling so that it is more cooperative.

> 3. I’m open for any other suggestions.

The easiest thing to try is to replace the incredibly slow ECC
implementation by a faster version. Bug #492756 [0] already addresses
this. Depending on the actual curve you need, you could also go for
NaCl.

[0] https://bugs.eclipse.org/bugs/show_bug.cgi?id=492756

> Another problem is, that if processing takes too long, even if all
> messages would be received, the retransmit process will kick in. I
> solved this by increasing the retransmit timer dramatically, which
> also doesn’t feel like a very good solution.

Not really, because on the server side, you do not have much influence
on the client's retransmission timers.

Grüße
Olaf