Subject: [quicwg/base-drafts] Martin Duke Transport Comment 2 (#4453)

From: Lucas Pardue <[email-masked]>
Date: Tue, 22 Dec 2020 10:01:44 -0800

@martinduke said:

> 21.13 "This means that client-controlled fields, such as the initial
> Destination Connection ID used on Initial and 0-RTT packets SHOULD NOT be used
> by themselves to make routing decisions." There was a lot of discussion in the
> QUIC-LB design team about whether this was an attack to be worried about or
> not, and we came down in favor of "not".
> 
> More importantly, I don't see how this is practical advice. If we're to use
> Retry SCIDs to route subsequent packets, then load balancers have to use the
> DCID of Initials. Without validating the token, which most LBs will not do,
> they have no way of distinguishing between attacker-generated DCIDs with a
> bogus token and those that originally came from the server. One option is to
> simply remove this recommendation.
> 
> Alternatively, you could leave this section unaltered and delete the bit in
> 8.1.2 about using Retry to reroute packets. In practice, keeping 21.13 would
> require a revision of QUIC-LB to just use 4-tuple routing for long header
> packets or make it less robust for new versions.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4453

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Dec 2020 14:59:49 -0800

I think that the point of this section is to highlight the possibility that routing based on client-selected values exposes servers to load that is balanced under client - and therefore attacker - control.  I don't think that it needs to include such a strong recommendation.

If people deploying load balancers are not concerned about this, then that is good.  That makes the recommendation less good.

As this is very old text, it needs a bit of a cleanup anyway.  I'm going to suggest something along the lines of my statement above in a pull request and we can polish the wording there.

I don't think that we should remove the Retry SCID language.  That remains an option for servers, even if they don't want to exercise the option (whether load balancers look at Retry tokens is very much down to how the various functions are distributed).  What could happen is that the Retry SCID is chosen so that the next initial can be routed as though it were chosen by a client, but in such a way as it results in the connection being sent to a lightly-loaded server instance.  That is, if the load balancer routes inchoate Initials based on connection ID, knowledge of that routing algorithm is used to direct traffic.  That said, I understand that what is more likely here is that Initials with inauthentic Destination Connection ID fields will be routed using other information: round-robin, random, five-tuple, or whatever.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4453#issuecomment-749823004

---

From: martinduke <[email-masked]>
Date: Tue, 22 Dec 2020 15:06:20 -0800

I think you're proposing that the text I quoted be deleted. That is satisfactory, and what I would recommend as well.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4453#issuecomment-749825763