Re: [tsvwg] L4S dual-queue re-ordering and VPNs

[Jonathan Morton <[e-mail]>]

> On 8 May, 2021, at 6:05 pm, Bob Briscoe <[e-mail]> wrote:
> 
> As just pointed out (my email crossed yours), existing established Diffserv technology is also prone to this problem, and it's lower hanging fruit for an attacker, because the delay-delta is typically larger.

Perhaps - but usable Diffserv deployments at the last-mile are not very common.  L4S proposes to put a DualQ instance in front of every cable internet subscriber, making it much easier for an attacker to predict how he needs to conduct his attack than the equivalent with Diffserv.  If the PHB is implemented at a backbone node rather than a last-mile head-end, the bandwidth required to saturate DualQ is also much less than to saturate the Diffserv queue.

Also, if ECT(0) traffic is what gets stuffed down the C queue, how much can the sojourn time grow before packets start getting dropped, and is that situation persistent under an unresponsive load?  The difference in queue depth might *not* actually be much different from the Diffserv case.

> The solution to all these interactions between a poorly configured replay protection window and queues with different delay differences is simply to configure a replay window appropriate to the packet rate of the VPN tunnel, taking account of expected delay differences between queues.

Maybe so, but the small replay window size is the environment that exists today.  Perhaps it will improve in future, but I think it has to be increased by several orders of magnitude to make this attack infeasible.  The Wireguard implementation in Linux has a hard ceiling at 8192 packets - is that enough?

> Whatever, VPNs rarely provide open access for traffic from unauthorized sources to enter the VPN.

One common application of VPNs is to hide players' home IP addresses from other players in multiplayer games.  They do this to prevent a type of griefing whereby an opposing player launches a DDoS attack to effectively disconnect them from the game, or lag them enough to get an easy kill.  This is possible because fast-paced games tend to send data directly between players to reduce latency, rather than going through a central server which is a better choice for slower-paced games.

If a player uses a VPN to connect to the game, then the remote end of the VPN is the address given to the other players.  A DoS attack that could be launched into such a VPN endpoint would be highly attractive to a griefer.

 - Jonathan Morton