DTLS Return Routability Check (RRC)

[sbernard31]

There is a new draft-tschofenig-tls-dtls-rrc-00 which comes to complete draft-ietf-tls-dtls-connection-id.

With some recommendations and a new return routability check mechanism.

1. the receiver MUST NOT update its view of the peer's IP
   address and port number with the source specified in the UDP datagram
   before cryptographically validating the enclosed record(s)

Reading the code, I think this is what we do currently.

2. Furthermore, when using CID, anti-replay protection MUST be enabled.

Maybe we can add a warning if the DTLS configuration does not match this requirement.

3. It is RECOMMENDED that implementations of the CID ... added peer address update events to their APIs. Applications can then use these events as triggers to perform an application layer return routability check.

I think this could make sense even for monitoring, but I'm not sure to see how this could look like 🤔
Maybe a flag in endpointcontext ?

4. While an equivalent check can be performed at the application layer (modulo the DTLS API exposing the address update event to the calling application), it is advantageous to offer this functionality at the DTLS layer.

It's a fresh new draft, so I think there is no hurry about implementing this.

(There is an IETF discussion about this)

[boaks]

First discussion

I don't plan to mitigate that in the near future.

[sbernard31]

I just read the discussion. You seems to not really appreciate this DTLS RRC feature at least for CoAP 😁.

I would just know :

About 1. I well understand the code ?

About 2. If you are agree about adding a warning in builder ? (I can do that)

About 4. I didn't think so mush about that but my first impression is that RRC at DTLS level is not a so bad idea, but I'm ok to say it's to soon to talk about implementation. So let's this aside for now.

About 3. After reading the discussion and thinking a more about that is. I feel we need more than just a callback.
The idea is to validate peer address at application layer. So we need :

• a way to tell to application layer that address need to be verified.
• a way for the application layer to say to DTLS layer that the address is verified.
• a way to postpone request waiting address is verified or raised a new error if request can not be sent because address is not verified and so let the application layer retry later (in this case does it mean we also need a kind of callback to say that peeraddress is now validated?)
  So this seems not so straightforward, I'm not even sure to see how this could looks like. Do you any idea about how this could looks like ?
  All of this makes me think that a RRC at DTLS level would be maybe more straightforward for users.

[boaks]

About 1.
Yes, but I may have found an other related issue, see reordering and address updates . For the new one I would just wait for some feedback before I implement it.

About 2.
With my proposal for reordering and address updates the implementation gets decoupled from the setUseWindowFilter or setUseAntiReplayFilter. Using the last validated epoch/sequence_number is independent from that filters.

About 3.
Sure. But it's a lot of work. It may require two ip-addresses per connection (verified/unverified), and FMPOV a implementation of echo-request-tag. That's a lot of work, So I assume, not for 2.0

About 4.
My expectation is, that for many use-cases it's not required!
e.g. receiving data and just sent a ACK/SUCCESS back (or even nothing with RFC7967 )

And just to remind:
I'm much more afraid of being attacked directly by such an "on-path-attacker", than I'm afraid of attacking an other peer! Such an attack of an other peer will be that inefficient (assuming that "constrained coap client" will not send too much requests), that I don't believe, it will happen too often.

[boaks]

PR #1012

Just wait for mid of next week, if some feedback is given for the reordering and address updates

[sbernard31]

About 1. an 2.
reordering and address updates : Really good catch ! I think your remarks make totally sense.

About 3.

So I assume, not for 2.0
Of course.

About 4.
At Sierra, we are not using CID (unfortunately I feel we will not use it at short/mid term whereas I think we should...). But with our use-cases this could make sense but 3. could do the job too. Hard to know what could be the best approach. :-)

About getting feedback for tlswg/dtls-conn-id#69, you should maybe point your issue on this thread : http://ietf.10.n7.nabble.com/draft-tschofenig-tls-dtls-rrc-00-DTLS-Return-Routability-Check-RRC-td599108.html ?

[boaks]

I guess, Hannes is very busy with dtls 1.3 . And FMPOV, I would go for 2.0.0-M16 without PR #1012 . It's not a big thing, if this takes some more days or weeks.

About 4.

I tried to prepare a android app, which "proofs" the benefits for DTLS1.2 CID.
Without CID, the more and more sleeping devices requires too many (resumption) handshakes. If only a few application data s send per wake up, that ends in a very bad ratio. And it applies to both, TLS 1.2 or DTLS 1.2. The app showed that more impressive, than I would have expected. My results from 4000 DTLS 1.2 CID request (150 bytes per request) was a oval all usage of 200 bytes per request with retries and resumption handshakes. Without CID was about 350 over all, with TLS 1.2 its currently about 600 (mainly because the resumption seems not working too well. But even the standard TLS 1.2 message takes about 220 bytes, which is sure above the DTLS 1.2, but even above the DTLS 1.2 CID over all traffic.
So, we will see, if that "power consumption / sleeping device" use-cases drives the DTLS 1.2 CID more.

About 3:

I'm still very sure, that this is no real issue. Let me try to distinguish between short wake ups, just to send data, and longer wake ups, also to check, it data is send to the device. For the first, there is simply no issue, it's only a ACK/SUCCESS (or nothing). The second would be something as the LWM2M "registration update", and that could be verified with the "echo-request-tag".

[sbernard31]

I rethink a little bit about it.
My understanding is that you think that RRC is rarely needed or at least not rarely needed for CoAP use cases.

But concretely for someone who is using CID with Leshan/Californium, I understand there is nothing to prevent this kind of attack ? Correct ?

If we should add something which approach do you advice ?

[boaks]

My understanding is that you think that RRC is rarely needed or at least not rarely needed for CoAP use cases.

There have been many discussions. Let me point to DTLS CID - Issues, a collection of links to statements. That also includes my own major statement on the tls-mail-list:

"Address validation ensures that an endpoint cannot be used for a
traffic amplification attack. In such an attack, a packet is sent to a
server with spoofed source address information that identifies a victim.
If a server generates more or larger packets in response to that packet,
the attacker can use the server to send more data toward the victim than
it would be able to send on its own.

The primary defense against amplification attack is verifying that an
endpoint is able to receive packets at the transport address that it
claims."

In my opinion, the primary defense depends on the use-case.

1. Just don't sent anything back is the very primary defense.

That will not work for all use-cases, therefore the secondary defense is

2. Just don't sent back more than received.

(Considering DDoS results in a combination of the primary and secondary
defense, means only send back responses, limited by size and number.)

That again limits also the use-cases, therefore the third defense is
then the

3. "primary defense" of QUIC.

The difference between QUIC and RRC could analyzed from both ends.
The one may justify, why they don't consider something and therefore do
less. The others may also justify, why they consider something
additionally, and therefore do more.

So, as long as only small messages are sent back, there is no threat.

But concretely for someone who is using CID with Leshan/Californium, I understand there is nothing to prevent this kind of attack ? Correct ?

There is no general threat (see above). Only, if larger messages must be sent back. CoAP may also use draft-ietf-core-echo-request-tag, if implemented, to mitigate that. E.g. the lwm2m register-interface may be protected by such a echo-tag, "only", if the lwm2m server has something to send back (I remember ... :-) ).

The current californium/scandium implementation doesn't consider that for now. (Too busy with other stuff, and some months ago, it seems for me to be unclear, what the assumed attack surface is including or not. I simply don't belief, that this is the largest threat. If you control such an heavy on-path-adversary there will be more valuable targets for now, than DTLS CID. Hope, that's changing and DTLS CID gets major technology and "worth to be attacked" :-). )

If we should add something which approach do you advice ?

That's open for me. A RRC on the DTLS 1.2 layer itself will also have its use. We will see, which gets first specified and/or implemented, DTLS-RRC or CoAP-echo-request-tag. One of the pain points is always, that it requires other implementations to support this as well. Otherwise, we will only run some Cali clients on raspberries :-).

[sbernard31]

There is no general threat

Just to be sure, I understand this correctly :

Common use case is :

• LWM2M Client send UPDATE request
• LWM2M Server send the UPDATE response
• LWM2M Server send some WRITE/READ/EXECUTE request (potentially large request)

So in this particular common use case, without RRC or echo-request-tag, I guess, if an "attack" intercept the UPDATE request, spoof the source address. He can amplify traffic.
But with the anti-replay, he can do it only once by intercepted update request ? correct ? and so not really a good way to do a DoS attack ?

[boaks]

He can amplify traffic.

First I assume, that the scenario is precisely:
...

• LWM2M Server send one WRITE/READ/EXECUTE request (potentially large request) and waits for the response to send the next queued request (or has that changed?).

With that, it depends mainly on the factor of that request to the registration update.

But with the anti-replay, he can do it only once by intercepted update request ? correct ? and so not really a good way to do a DoS attack ?

Yes, at least in my opinion. A DDoS attack isn't formed by some amplified messages, it requires masses of them.
And for masses, the technique has to be adopted. That opens a time frame, where I can use DTLS CID with PSM CAT-NB modems to send data to the cloud and the "small" 2.04 back without countermeasures.

For more, it requires more development time and/or engagement of other parties.

[boaks]

A very first and experimental implementation is available as feature branch rrc. In order to follow the instruction, a feature-release is required. I hope that could be provided begin of next week.