Open kazuho opened 5 years ago
I've marked this as editorial, because we should write something about it. But I think this is covered by existing use cases. It is easy enough to configure QUIC-LB parameters so that most CIDs are invalid. I do not understand what is gained by having LBs use 5-tuple instead of the CID.
A CID-aware LB should be easily able to drop traffic, yes. The issue is that you might not be actively maintaining CID state on the far side of a peering link. Perhaps that's simply something that needs to change in a QUIC world.
@martinduke
I do not understand what is gained by having LBs use 5-tuple instead of the CID.
This becomes a requirement if you want to have same degree of protection when using QUIC as when using TCP.
In case of TCP, the connection state can be managed by the LB, and the LB blocks packets (except SYN) that do not have associated state (including the 5-tuple). If a QUIC LB is to provide the same degree of protection, it needs to drop packets arriving from an unexpected source address, even if those packets carry legitimate CIDs. To do that, the address needs to be encoded within the CID.
In QUIC Interim, @mikebishop suggested that it is sometimes beneficial to block malicious QUIC-like traffic at the edge on an network, so that the network behind the edge does not need to be over-provisioned.
I think that can be done using the capability of QUIC-LB, or by possibly just slightly adjusting the design. Essentially, what we need is a LB that validates the CID and drops invalid ones but respects the 5-tuple in terms of forwarding packets, instead of routing the packets based on the CID. Nodes behind the edge would calculate the MAC value and embed it as part of the CID they issue.
Maybe it'd be worth checking such a use-case can covered by QUIC-LB, as well as clarifying how that can be done.