DTLS anti replay mechanism

[Philago]

Hello,

Is it possible to deactivate the DTLS anti replay mechanism (slidding window) ?

RFC6347 §3.3 states that "DTLS optionally supports record replay detection"

Thanks !

Best regards

[sbernard31]

AFAIK, this is not deactivable with scandium.

[boaks]

May be you can give us more information about your use-case?

https://tools.ietf.org/html/rfc6347#section-3.3

DTLS optionally supports record replay detection. The technique used
is the same as in IPsec AH/ESP, by maintaining a bitmap window of
received records. Records that are too old to fit in the window and
records that have previously been received are silently discarded.
The replay detection feature is optional, since packet duplication is
not always malicious, but can also occur due to routing errors.
Applications may conceivably detect duplicate packets and accordingly
modify their data transmission strategy.

So, do you want such a statistic?

[Philago]

Hello,

thank you for you answers.

No I don't want any statistics.

In my use case the data will be sent through different paths (packets 1,2,3,4 are sent on one path, packets 5,6,7,8 on another path,..) with different delays for each path. So depending on the size of the slidding window, if the lastest data sent arrive first, the oldest data sent may be discarded and I do not want that to happen. That's why I am asking if the anti replay mechanism can be deactivated.

Have a good day

[boaks]

And a "receive window" of 64 is not enough?
Which size would you prefer or do you really want to disable it?

[boaks]

Feel free to add a new comment to this issue or create a new issue, if this topic gets interesting again for you.

[boaks]

#824 (comment)

yes I am still interested in disabling the anti replay mechanism or at least to have the possibility to configure the size of the receive window

OK, so disable would be enough? Should we go for

NO: no anti replay
WINDOW: anti replay only for the current window, older messages are NOT filtered out and will be decrypted (if possible and not causing a MAC error).
FULL: full anti replay as currently implemented

[Philago]

Hello @boaks ,

just to understand the window case:

• Messages older then the window are accepted
• Messages inside the window are accepted / discarded if sent twice
• Message newer than the window are discared

Am I correct ? If it's the case it's OK on my side

[boaks]

Message which are newer than the window, are always forwarded to the MAC check.
If that is passed, then the windows is updated.

[Philago]

Thanks for the clarification.

It's OK for me

[boaks]

I will prepare a PR (hopefully this week).
So you will be able to check, if it works for you.

[boaks]

Please check PR #906, if it works for you.
(Either fetch the PR or the branch disable_filter from https://github.com/bsinno/californium ).

[boaks]

@Philago

I would appreciate, if you can give us your feedback about the PR.
I will start to request a review next week, but it's easier, if you have verified, that it really solves your issue ;-).

[Philago]

Hello,

sorry for my late answer. I'll see if I can set up a test early next week to check if it works. Anyway if it's possible to deactivate the window or accept old messages, it will work for us.

[boaks]

OK. If you can manage to test it, perfect. Otherwise we merge it and in the "worst case", fix it again after testing :-).

[boaks]

It's merged. Don't hesitate to report, if it's not working for you as expected.

[Philago]

Hello @boaks,

I was not able to set up a test last week. When I'll be able to test it, I'll report issues if I find some.

Thank you very much

[boaks]

Hi @Philago,

do you plan to use this "disabled filter" and DTLS 1.2 CID together?
If so, the IETF reported currently some findings, see github.com/tlswg/dtls-conn-id, issues 64 .

FMPOV, github.com/tlswg/dtls-conn-id, issues 69, would be an approach, which may work without a "filter window".

Do you have collected any experience, if the ip-addresses of your delayed received messages are more up to date, then the newest ones according the epoch/sequence_number (consider to be not under attack)?

If not, should we go for a configurable PR #1012 ?

[Philago]

Not yet.

When I am in the case where the messages are received out of order on the receiver side no source IP address is more up tot date than the other.

I agree with you, updating the IP address only on newest record would work, even if the anti-replay window is deactivated. #1012 seems fine by me. I replied on the issue tlswg/dtls-conn-id#64 to be sure that we have the same understanding of the issues and the possible solutions.

So for the anti-replay window, we will still have a 3 options no window, window and full ? With the window mode as follows:
Messages older then the window are accepted
Messages inside the window are accepted / discarded if sent twice
Message newer than the window are acceptted and the window is updated

Thanks

Philippe

[boaks]

Yes, to keep the "window" options and to control the address updates, I think introducing the "newer" filter should work.

[boaks]

@Philago

Hi, are you still using Californium?
I thought about the "delayed path" and I currently consider to add a feature to skip the anti replay filter on record base. One idea is to extend

protected void DTLSConnector.processDatagram(DatagramPacket packet, InetSocketAddress router, boolean skipAntiReplayFilter);

would that work for you?
(It's not about remove the other features, disable, and disabled_window, it's more about limiting the security gap.)