Hi Achim and Thomas,
I should have numbered my comments for easier reference. Oh well.
I think the suggestions you make below would be sufficient, thanks. Since my
comments are about clarity and not content, I leave it up to you; I won't block
the document either way.
In my personal opinion, it would make the document easier to read if you
inlined at least a summary of the relevant definitions from [RFC9146],
[RFC9000], [Sect. 6 of this document] into the intro.
This is personal style, but I think that anything that's core to understanding the main
points of a document should be inlined, rather than forcing the user to go fishing in a
half-dozen other documents. I like the phrase "blah blah from [RFCxxxx], which is
reproduced here for clarity".
-Mike
"Knowing is a barrier which prevents learning" -- Frank Herbert, Dune.
On Tuesday, June 10th, 2025 at 5:17 AM, Thomas Fossati
<thomas.foss...@linaro.org> wrote:
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
