search

ktls / af_ktls

Linux Kernel TLS/DTLS Module
GNU General Public License v2.0
159 stars 25 forks source link

DTLS window handling from user space #13

Open fridex opened 8 years ago

fridex commented 8 years ago

The current implementation of DTLS sliding window handling behaves correctly only if there are no out of order DTLS records. If we receive a record that is not at the beginning of the window, and user space asks for seq number, the seq number can be incorrect. There should be returned seq number which corresponds to the very first record expected within the sliding window:

An example scenario:

  1. user space sets seq number to be (epoch 1, seq num 1)
  2. kernel receives (epoch 1, seq num 3) - within window, record is accepted
  3. kernel receives (epoch 1, seq num 4) - within window, record is accepted
  4. user space asks for seq number, the kernel responds with (epoch 1. seq num 3) - incorrect, should be (epoch 1, seq num 2)

Since DTLS window is part of the state, there should be probably appropriate {get,set}sockopt(2) call to populate the sliding window to user space. This would allow to sync user space with DTLS socket and vice versa. There has to be kept in mind that sliding window in user space can be of different size than the one in the kernel.

fridex commented 8 years ago

https://github.com/ktls/af_ktls/issues/87 is also relevant here. IMHO we should make possible to get DTLS window state to userspace, otherwise we are dealing with possible reply attacks here.

In case of DTLS, the userspace should ask for seq_number and DTLS window in order to correctly continue with the session.

fridex commented 8 years ago

A simpler version would drop records and aggressively advance when coming back to userspace: we could simply advance dtls window to the newest received , e.g. (see include/linux/count_zeros.h for count_leading_zeros):

seq_numeber += (sizeof(dlts_window_mask)*CHAR_BIT) - count_leading_zeros(dtls_window_mask)

The implementation highly depends on #87.