Peer address validation

[thomas-fossati]

Alice has an active DTLS session + CID with Bob.

• Eve (man-on-the-side) sends junk packet with the CID currently in use between Alice and Bob and a spoofed source address of Victor
  • If Bob updates the peer address before the record is validated, he creates DoS/DDoS surface.
• Eve (man-on-the-side) replays previous packet from Alice and changes source address to that of Victor
  • If Bob has anti-replay disabled — even if he validates the records in the packet — he creates DoS/DDoS surface.
• Eve (man-in-the-middle) modifies packet from Alice to have the source address of Victor
  • Expanded DoS/DDoS surface is unavoidable.

While the first two can be addressed, I don't know how to stop (or even mitigate the third).

We should add text to the SecCons along the following lines:

[...]
When using CID, anti-replay MUST be enabled.
When a record with CID is received, the receiver MUST NOT update
its view of the peer address with the source specified in the UDP packet
before cryptographically validating the enclosed record(s).  Failing to do
so, creates a (D)DoS opportunity for a man-on-the-side attacker.
Use of CID creates the opportunity for an active man-in-the-middle to
trigger backscatter traffic for each CID-bearing packet it can modify.
[hic sunt leones]

[thomas-fossati]

We have the same problem in 1.3, but there the active man-in-the-middle attack described above could be mitigated by triggering an "address validation" sub protocol (via post-handshake) either on each and every peer address change or when the rate of peer address changes is above a certain threshold.

[boaks]

I would assume, that such an attack makes only sense, if an "amplified response" is expected. Is that the right assumption?
That seems to be out of the scope of DTLS (means DTLS doesn't define such a response).
Therefore I think, it could only be recommended, that a DTLS CID implementation tracks, if the associated ip-address should be considered as "verified". Each address change would reset that, and only a "Heartbeat" (if supported), or the next layer could set it as "verified" again. The DTLS CID implementation then limits the maximum application message size for unverified destinations and reports a violation as error. It depends on the "next layers", if and how such a verification will be done (may be by explicit trigger a "heartbeat", if supported).
Using CoAP, I would assume, that a lot of outgoing traffic is just a ACK/SUCCESS, which is pretty small and so requires no special behaviour. For larger outgoing messages echo-request-tag could be considered, as this was already recommended as protection mechanisms for such cases, see Carstens answer to "The CoAP protocol is the next big thing for DDoS attacks"

[thomas-fossati]

I have some reservations wrt the use of Heartbeat as an address validation tool:

• it works outside the established crypto context (therefore HeartbeatResponse messages can be forged);
• support has become really patchy (examples: mbedtls, wolfssl don't have it, Openssl has removed it)

IIUC, your suggestion is for the DTLS stack to expose an address validation callback that must be supplied by the application? Not sure it'll fly -- the protocol should really clean up after itself if it creates attack surface, rather than relying on higher layers to do the mending -- but we can try if this is the only option.

[boaks]

IIUC, your suggestion is for the DTLS stack to expose an address validation callback that must be supplied by the application? Not sure it'll fly -- the protocol should really clean up after itself if it creates attack surface, rather than relying on higher layers to do the mending -- but we can try if this is the only option.

If the validation should be done in DTLS, it may cause more traffic. By the way, I don't thought on a "callback". It may be more a isVerified(address), setVerified(address), and a new error code when sending too large messages. But the implementation is out of the cope of the spec. Therefore I would only recommend something as that.

[boaks]

I have some reservations wrt the use of Heartbeat as an address validation tool:

it works outside the established crypto context (therefore HeartbeatResponse messages can be forged);
support has become really patchy (examples: mbedtls, wolfssl don't have it, Openssl has removed it)

"outside the established crypto context":
I don't get that. Why is this "outside the established crypto context"? The peer send either a tls_cid with inner heartbeat or a heartbeat to the address to verify (and not to amplify, it should be a small one). That destination peer either has the crypto context, then the peer could response proper (using tls_cid with inner heartbeat), or the peer will drop the record with MAC violation.

But may be, you can provide some more details about that.

"patchy":
Though the implementations must be updated for CID anyway, the could also cleanup the heartbeat.

[boaks]

"Heartbeat":
OK, it seems to be "usually" something different. I assumed, that, if cid is negotiated, any record will be a tls_cid, so even a heartbeat will be sent as inner type. But that may be just my interpretation.

[thomas-fossati]

If the validation should be done in DTLS, it may cause more traffic.

Why?

By the way, I don't thought on a "callback". It may be more a isVerified(address), setVerified(address), and a new error code when sending too large messages. But the implementation is out of the cope of the spec. Therefore I would only recommend something as that.

Peer address change is asynchronous from the PoV of the application. Your proposal above seems to imply the application does regular checks? But, yeah, the API details don't really matter (it's just an "implementation quality" consideration), as long as there's a usable API. I'm still very unsure this would be an acceptable way forward though.

"Heartbeat":
OK, it seems to be "usually" something different. I assumed, that, if cid is negotiated, any record will be a tls_cid, so even a heartbeat will be sent as inner type. But that may be just my interpretation.

Interestingly we don't say anything explicitly in this respect, so one can rightfully interpret it that way. This (i.e., requiring address validation via the heartbeat ping while limiting outgoing traffic to a minimum until the heartbeat pong is received) seems like a good way forward to me. (Certainly preferable to leaving the onus on the application.)

[boaks]

Why?

Because I assume, that at least for CoAP, an ACK/SUCCESS doesn't require something additional and would cover a large part of "my traffic". And the left over traffic is something for "echo tag". But that just assumes CoAP.

[boaks]

I'm still very unsure this would be an acceptable way forward though.

I simply prefer, that this "forwarding to upper layer" is not excluded from the valid solutions.

[thomas-fossati]

I'm still very unsure this would be an acceptable way forward though.

I simply prefer, that this "forwarding to upper layer" is not excluded from the valid solutions.

It's not a question of excluding options: an implementation does exactly what it wants to.

The point is that it's not possible to inflict requirements on all L7 specs from a spec at L4.5 :)

[boaks]

The point is that it's not possible to inflict requirements on all L7 specs from a spec at L4.5 :)

Sure, all is not possible. But for those L7, which have defined means, it should be possible to apply them in order to optimize their way of using it.

[thomas-fossati]

The point is that it's not possible to inflict requirements on all L7 specs from a spec at L4.5 :)

Sure, all is not possible. But for those L7, which have defined means, it should be possible to apply them in order to optimize their way of using it.

Yeah, if an implementation (especially an embedded one) wants to provide cross protocol optimisations, I don't see how we can outlaw it. What we need to describe here though is how to achieve internal coherency at the DTLS layer, without requiring external dependencies.

[Philago]

Hello @thomas-fossati ,

I have questions on the attacks you described

Eve (man-on-the-side) sends junk packet with the CID currently in use between Alice and Bob and a spoofed source address of Victor
If Bob updates the peer address before the record is validated, he creates DoS/DDoS surface.
=> I do not see where the attack is, if the packet is junk, even with a correct CID, the rercord will be rejected by dtls,

Eve (man-on-the-side) replays previous packet from Alice and changes source address to that of Victor
If Bob has anti-replay disabled — even if he validates the records in the packet — he creates DoS/DDoS surface.
=> If the receiver updates the IP address only on new records received, the issue disapears right ? Even with anti-replay disabled. The records sent over and over again by the attacker will not create DoS/DDoS surface.

Eve (man-in-the-middle) modifies packet from Alice to have the source address of Victor
Expanded DoS/DDoS surface is unavoidable.
=> The draft you initiated with @hannestschofenig should fix the issue right ? https://tools.ietf.org/html/draft-tschofenig-tls-dtls-rrc-00

Thanks

Philippe

[thomas-fossati]

Hey @Philago ,

• Eve (man-on-the-side) sends junk packet with the CID currently in use between Alice and Bob and a spoofed source address of Victor
  • If Bob updates the peer address before the record is validated, he creates DoS/DDoS surface.

I do not see where the attack is, if the packet is junk, even with a correct CID, the rercord will be rejected by dtls,

Even assuming that the record is rejected by the crypto layer, if the peer's address is successfully subverted in the connection context of the receiver (i.e. before any crypto processing is done), then any "return" traffic will be routed to that spoofed address -- either an existing one, i.e. the victim of a DDoS, or a blackhole to just deny service to the real peer).

• Eve (man-on-the-side) replays previous packet from Alice and changes source address to that of Victor
  • If Bob has anti-replay disabled — even if he validates the records in the packet — he creates DoS/DDoS surface.

If the receiver updates the IP address only on new records received, the issue disapears right ? Even with anti-replay disabled. The records sent over and over again by the attacker will not create DoS/DDoS surface.

I'm not sure I understand your remark. The spoofed peer will be "active" in the connection context of the subverted endpoint until a new record comes in from the legitimate peer. During that time window, any return traffic from the subverted endpoint is both a real DoS on the legitimate peer and a potential DDoS on a victim chosen by the attacker.

• Eve (man-in-the-middle) modifies packet from Alice to have the source address of Victor
  • Expanded DoS/DDoS surface is unavoidable.

The draft you initiated with @hannestschofenig should fix the issue right? https://tools.ietf.org/html/draft-tschofenig-tls-dtls-rrc-00

That's the intention.

[boaks]

I'm not sure I understand your remark.

Try to read issue #69 .

Updating the address is not only an issue under attack, it's also an issue assuming message reordering.
With assumed reordering, there are no strong arguments for "window filter" or "newer epoch/sequence_number filter". But the second one will work, even when a "window filter" would otherwise drop "very slow messages".

[thomas-fossati]

I'm not sure I understand your remark.
Try to read issue #69 .

Updating the address is not only an issue under attack, it's also an issue assuming message reordering.
With assumed reordering, there are no strong arguments for "window filter" or "newer epoch/sequence_number filter". But the second one will work, even when a "window filter" would otherwise drop "very slow messages".

I've read #69, and I agree with it (i.e., the receiver must not take into account old reordered records as far as peer address update is concerned). Yet I don't understand how does that relate to @Philago's comment?

[boaks]

If the receiver updates the IP address only on new records received, the issue disapears right ? Even with anti-replay disabled.

"newer record" based on the epoch/sequence_number.
That results in: if the address is only updated for "newer records, based on the epoch/sequence_number", then the RFC6347 "anti-replay window" may be disabled. That results in processing potential duplicate records (and you may be faced a "timeshift attack", but this is not introduced by CID),
but not in a attack surface introduced by CID.

My current main concern about this is:
There may be many, many risks.
But from my view point, the "DTLS 1.2 Connection ID" should focus on the risks, introduced or boosted by that. And not mention general ones without explain them as such general ones.

[thomas-fossati]

Ah gotcha. Yes, I agree that to counter attack 2 above all is needed is #69, which also is necessary for general correctness of the protocol in presence of reordering at the network layer.

[Philago]

Hello @thomas-fossati,

thank you for your answers and thank you @boaks to have clarified my position.

So to sum up we can tackle 1 and 2 with the address only being updated for "newer records, based on the epoch/sequence_number". 3 will be addressed with draft-tschofenig-tls-dtls-rrc-00

Correct ?

[thomas-fossati]

So to sum up we can tackle 1 and 2 with the address only being updated for "newer records, based on the epoch/sequence_number". 3 will be addressed with draft-tschofenig-tls-dtls-rrc-00

Correct ?

Looks likely. I have tried to capture the discussion on my fork

@boaks @Philago could you please check if this matches your thinking?

[thomas-fossati]

Closed by #70