From 5f4db85ac2c3a756ac05638a5cd033a0b9ffec82 Mon Sep 17 00:00:00 2001 From: Thomas Fossati Date: Fri, 10 Nov 2023 09:55:07 +0100 Subject: [PATCH 1/2] Yaron's review * add fwd reference to the threat model when the problem is presented in the intro * RRC is a sub-protocol * separate description of attack from its mitigation * ack Yaron Fix #67 Signed-off-by: Thomas Fossati --- draft-ietf-tls-dtls-rrc.md | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/draft-ietf-tls-dtls-rrc.md b/draft-ietf-tls-dtls-rrc.md index c2bf247..7b6ff7b 100644 --- a/draft-ietf-tls-dtls-rrc.md +++ b/draft-ietf-tls-dtls-rrc.md @@ -70,6 +70,11 @@ CID-address binding is updated in that endpoint's session state. This is done in order to give the receiving endpoint confidence that the sending peer is in fact reachable at the source address (and port) indicated in the received datagram. +{{regular}} of this document explains the fundamental mechanism that aims to reduce the DDoS attack surface. +Additionally, in {{enhanced}}, a more advanced address validation mechanism is discussed. +This mechanism is designed to counteract off-path attackers who try to place themselves on-path by racing packets that trigger address rebinding at the receiver. +To gain a detailed understanding of the attacker model, please refer to {{attacker}}. + Apart from of its use in the context of CID-address binding updates, the path validation capability offered by RRC can be used at any time by either endpoint. For instance, an endpoint might use RRC to check that a peer is still reachable at @@ -104,9 +109,9 @@ exchanged `rrc` extensions. # Return Routability Check Message Types This document defines the `return_routability_check` content type -({{fig-rrc-msg}}) to carry Return Routability Check protocol messages. +({{fig-rrc-msg}}) to carry Return Routability Check messages. -The protocol consists of three message types: `path_challenge`, `path_response` +The RRC sub-protocol consists of three message types: `path_challenge`, `path_response` and `path_drop` that are used for path validation and selection as described in {{path-validation}}. @@ -149,7 +154,7 @@ struct { {: #fig-rrc-msg align="left" title="Return Routability Check Message"} -Future extensions to the Return Routability Check protocol may +Future extensions to the Return Routability Check sub-protocol may define new message types. Implementations MUST be able to parse and ignore messages with an unknown `msg_type`. (Naturally, implementation MUST be able to parse and understand the three RRC message types defined in this document.) @@ -165,7 +170,7 @@ currently associated with that CID value, the receiver SHOULD perform a return routability check as described in {{path-validation}}, unless an application layer specific address validation mechanism can be triggered instead (e.g., CoAP Echo {{?RFC9175}}). -# Attacker Model +# Attacker Model {#attacker} We define two classes of attackers, off-path and on-path, with increasing capabilities (see {{fig-attacker-capabilities}}) partly following terminology @@ -221,6 +226,8 @@ the server in response is larger compared to the received packet (e.g., a CoAP server returning an MTU's worth of data from a 20-bytes GET request {{?I-D.irtf-t2trg-amplification-attacks}}) the attacker can use the server as a traffic amplifier toward the victim. +### Mitigation Strategy + When receiving a packet with a known CID and a spoofed source address, an RRC-capable endpoint will not send a (potentially large) response but instead a small `path_challenge` message to the victim host. Since the host is not able @@ -253,6 +260,8 @@ likelihood that the attack is unsuccessful. Note however that, unlike QUIC, DTLS has no "non-probing" packets so this would require application specific mechanisms. +### Mitigation Strategy + {{fig-off-path}} illustrates the case where a receiver receives a packet with a new source IP address and/or new port number. In order to determine whether this path change was not triggered @@ -718,7 +727,8 @@ Hanno Becker, Marco Tiloca, Martin Thomson, Mohit Sahni, -Rich Salz and +Rich Salz, +Yaron Sheffer and Sean Turner for their input to this document. From c91df609f8a94508ec783d21099b99b78c385e17 Mon Sep 17 00:00:00 2001 From: Thomas Fossati Date: Fri, 10 Nov 2023 10:35:49 +0100 Subject: [PATCH 2/2] Achim's suggestion --- draft-ietf-tls-dtls-rrc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-tls-dtls-rrc.md b/draft-ietf-tls-dtls-rrc.md index 7b6ff7b..f1ca01d 100644 --- a/draft-ietf-tls-dtls-rrc.md +++ b/draft-ietf-tls-dtls-rrc.md @@ -72,7 +72,7 @@ that the sending peer is in fact reachable at the source address (and port) indi {{regular}} of this document explains the fundamental mechanism that aims to reduce the DDoS attack surface. Additionally, in {{enhanced}}, a more advanced address validation mechanism is discussed. -This mechanism is designed to counteract off-path attackers who try to place themselves on-path by racing packets that trigger address rebinding at the receiver. +This mechanism is designed to counteract off-path attackers trying to place themselves on-path by racing packets that trigger address rebinding at the receiver. To gain a detailed understanding of the attacker model, please refer to {{attacker}}. Apart from of its use in the context of CID-address binding updates,