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

[Bob Briscoe <[e-mail]>]

Jonathan,

On 08/05/2021 16:25, Jonathan Morton wrote:
>> 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.

[BB] WMM (Wifi MultiMedia).

> 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.

[BB] I understood this already when Pete said it. My point was that, you 
seem to want this to be a criticism of L4S, rather than of poorly 
configured VPNs. Surely you are not saying the IETF should halt any 
advances that reduce delay, like Diffserv and L4S, just because the 
replay windows of VPNs are poorly configured today?

> The Wireguard implementation in Linux has a hard ceiling at 8192 packets - is that enough?

[BB] A hard ceiling in /soft/ware?


>> 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.

[BB] So the player has a strong incentive to configure the replay window 
of her VPN properly.



Bob

>
>   - Jonathan Morton

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/