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.
> 
> [BB] WMM (Wifi MultiMedia).

That's not the last mile - that's within customer premises.  I would also question how often a DSCP would survive on the outer header of a VPN packet long enough to influence this mechanism.  But I would also note the increase in the use of fq_codel in wifi AP stacks, which would tend to reduce any differential delay to a greater degree than the C queue in DualQ does.  Those, taken together, might be significant reasons why problems have not been noticed up to now.

For the particular use case I mentioned, a player connecting over wifi would be ridiculed due to the inconsistent latency that wifi offers, especially in congested radio environments.

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

...

> My point was that, you seem to want this to be a criticism of L4S, rather than of poorly configured VPNs.

As often seems to happen, you seem to want to deflect any possible criticism of L4S onto some other piece of technology that it might happen to interact poorly with, so that you don't need to change L4S, only all those other things need to change or just plain go away.  You don't like FQ, or Codel, or fq_codel, or the continuing deployment of RFC-3168 compliant middleboxes in general, and you *certainly* don't like me personally.  I've got used to that.

The operative phrase here is that you're entitled to your own opinions, but not your own facts.

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

Configuring the replay window size is a game of compromises.  If it's too small, then a variety of effects can result in legitimate packets falling outside the window.  If it's too large, then there is presumably a greater risk of the replay attacks that it's designed to protect against being inadvertently permitted.  I don't know enough about the details of that to judge how serious that particular risk is - but the fact that many VPNs default to values near the minimum recommended in RFC-4303 is probably not a gross error of judgement.

I do note that RFC-4303 significantly post-dates most of the Diffserv specifications, so it notionally had the opportunity to consider the implications.  One way that VPNs could sidestep this particular problem in a Diffserv context is to fix a single DSCP on all outer headers, ensuring that they'll go through the same queue - and at least some of them actually do this.

But they can't really do the equivalent of this to the ECN field in an L4S context, because that would trigger the CE ambiguity problem without also sending the L4S traffic through the L queue.  Not unless they put Not-ECT on the outer header unconditionally - but that *would* be a step backwards.

I hope you can see the difference here.

>> The Wireguard implementation in Linux has a hard ceiling at 8192 packets - is that enough?
> 
> [BB] A hard ceiling in /soft/ware?

It's a value that you can't exceed merely by userspace configuration, only by patching the kernel.  Hence there will be significant inertia in raising it, if it needs to be raised.  Hence my question - *is* it large enough?  And following on from that, what are the downsides of choosing such a large value?

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

For normal operation, the default replay window is big enough.  For network paths that deliver packets more-or-less in-order, the default replay window is big enough.  It's only when an attack arises on a vulnerable path - a path *made* vulnerable by the installation of DualQ - that an adjustment becomes necessary.

So where is the cause, exactly?  And where should the cure be applied?

 - Jonathan Morton