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

[Sebastian Moeller <[e-mail]>]

Hi Bob,



> On May 8, 2021, at 19:04, Bob Briscoe <[e-mail]> wrote:
> 
> 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.

	[SM] Well, L4S novel re-ordering behaviour can turn a VPN configuration that worked just fine into one that throws spurious replay attack warnings. IMHO that indicates that the VPN was properly configured for its envoronment before, so the party changing the environment, L4S in this case, carries at least as much responsibility as the VPN. 
	Side-note, it gets predictable, that all new L4S failure modes are immediately interpreted as someone else's fault.

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

	[SM] It is a define, so ATM you need to compile a new kernel, so for many end-user this is effectively a hard ceiling...

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

	[SM] Or to bleach ECT(1) on tunnel egress to head off such behavior... Really I consider your evaluation of responsibility in this issue a bit offensive. L4S breaks existing known-working configurations, and all we say, is fix your VPN, really?

Best Regards
	Sebastian


> 
> 
> 
> Bob
> 
>> 
>>  - Jonathan Morton
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>