Hi Mike, Thanks very much for the detailed review.
On top of Achim's replay, see also a few other comments inline. On Mon, Jun 09, 2025 at 11:51:50AM +0100, Mike Ounsworth wrote:
[...] Naïve question (I am not a DTLS / routing expert). Does this spec introduce a new DDoS surface in the case that the new (preferred) path is longer, and therefore the connection will keep pausing to do this path-check? I expected to see somewhere a recommendation for a guard against that – only do this once per pair of paths, or something similar.
To trigger RRC you need to be able to send a "good" DTLS record, otherwise, the receiver will drop it on the floor and continue as if nothing happened. To do that, you either replay an old record and hope the receiver doesn't have anti-replay on (at least in some form -- see §6 of RFC9146), or you are racing a copy of an outstanding record over a shorter/faster path. It is not possible to make the receiver start doing RRC work otherwise, i.e., cheaply enough to introduce more DDoS surface.
I would like to see the Introduction add a paragraph about mandatory-to-implement and interop implications of this draft; give a sense of whether this is a mandatory-to-implement extension to DTLS, or optional, and whether one side of the connection can perform this successfully even if the other end does not support it. I think the text I’m looking for is: “This specification defines a RECOMMENDED mechanism for DTLS 1.2 and 1.3. DTLS 1.2 and 1.3 implementations SHOULD implement this and include it in all DTLS ClientHellos, but note that no security value is obtained unless both parties support it”, but I’ll leave it to the experts to frame the correct wording.
OK, makes sense. Would something like the following work? A client offering the connection_id extension SHOULD also offer the rrc extension, unless the application using DTLS has its own address validation mechanism.
Intro needs more description of what the vulnerability is, and which party is gaining protection against which type of adversary by implementing this. You have this nicely and in great detail in Section 6, but I would pull a short summary up to the Intro. After reading section 6, I see that you are solving two problems: amplification-to-a-victim, and path-hijacking. You have some good sentences in Section 6 that you could pull up into a short summary of the issue and fix.
The intro defers to §6 of RFC9146 for providing the context and problem description, and to §6 of RFCTHIS "to gain a *detailed* understanding of the attacker model". IMHO we are good.
Nit: Section 4: “Future extensions to the Return Routability Check sub-protocol may define new message types.” … should that be a normative “MAY”?
I don't think tehre is anything normative in that sentecne.
Section 6: It would be nice if you synced up with the terminology for type of attack / attacker as defined in Section 3 of RFC3552. What you have is close to S. 3.2 of RFC3552; probably just needs a reference and a sentence “We extend the definitions of “on-path” and “off-path” attackers as given in [RFC3552] to more precisely fit the specifics addressed by this specification”. Could / should also site definitions in RFC 4949.
We could add: This definition differs from that of Section 3.5 of RFC3552 in that an off-path attacker is able to observe packets. However, we already reference RFC9000, which makes the exact same point. Alternatively, to avoid repetition, we could refine the reference to RFC9000 (adding §21.1). WDYT?
Section 6.1.1: “When receiving a packet with a known CID and a spoofed source address, an RRC-capable endpoint will…” Technically, the endpoint doesn’t know for a fact that it’s spoofed, right? I assume that the whole point of defining a challenge-response sub-protocol here is to distinguish the legitimate path-changes from attacks, right? I would say instead “When receiving a packet with a known CID and a source address that does not match, the RRC-capable endpoints will begin by assuming that it is spoofed and verify by …”
§6.1.1 needs to be read in the context established by §6.1 which describes the amplification attack. In such context, the sender is assumed to be the attacker that spoofs the source address to trick the receiver. If that creates confusion, we could say instead: When receiving a packet with a known CID that has a source address different from the one currently associated with the DTLS connection, [...] It's slightly more clumsy but still readable.
Section 6: “The attack is more reliable if relatively few packets are sent or if packet loss coincides with the attempted attack.” I’m a little confused about the grammar of this sentence. I could see this meaning one of several things: That the attack is harder if the victim channel has some naturally-occuring (unrelated) packet loss that the attacker has no control over, but happens to coincide with the attack. That the attacker needs to induce packet loss in order to perform the attack, and this is easier if it’s an otherwise noise-free channel. That the off-path that the attacker is trying to migrate to should be noise-free. Either way, making this sentence more precise would help
The sentence says that the attacker has an easier life if: 1. the application layer exchange is somewhat sparse, which can help avoid dealing with the connection moving back to the legit path, 2. packet loss on the legit path occurs simultaneously as the attacker is executing the race, therefore increasing the chances of the attacker winning the race.
Grammar: “In order to determine whether this path change was not triggered by an off-path attacker” In English, you don’t use the “whether … not” construction. I would suggest either: “... determine whether this path change was triggered by …” or “... determine that this path change was not triggered by …”
I like the second suggestion, thanks!
Joke: Figure 5 looks like what happens when I try to change my tax address with the government; and this triggers all sorts of paper mail to all my registered addresses.
:-)
You use language like “attacker trying to place itself on path”. Would it be more evocative to say “hijack the path”? Your described attack here seems to agree with the definition of “Hijack Attack” given in RFC 4949.
Maybe, but I am not sure. The attack as a whole is a combination of active and passive wiretapping (in 4949 terms) whereas "hijack attack" is defined as "A form of active wiretapping". So the match doesn't seem perfect.
“If the path via the attacker is reliably faster than the old path despite multiple attempts to use that old path, it is not possible to distinguish between an attack and an improvement in routing.” This is funny. I am picturing a Wired.com article titled “Actor X hijacks the entire internet by providing faster, more reliable service”. Right. Hard to really call that an attack.
:-)
Section 7 intro: I feel like this needs some tie-back to the negotiation done during the ClientHello / ServerHello step.
We point to here in the forward direction (from §4): 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 Section 7. I beelive this should be sufficient.
Like, the entirety of Section 7 only happens if this session negotiated to use RRC, right?
Yes
Section 7.2 / 7.3 is literally the first time in the document that the terms “Basic” / “Enhanced” appear. You at least need to introduce this at the top of section 7.
What about: It then initiates the return routability check. This document describes two kinds of checks: basic (Section 7.2) and enhanced (Section 7.1). The choice of one or the other depends on whether the off-path attacker scenario described in Section 6.2 is to be considered.
Basic vs Enhanced something that needs to be negotiated? Are these interop-equivalent and therefore implementer’s choice? … some introduction needed.
I believe these specific points are already discussed in §7. cheers, thanks! t _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
