Re: [tsvwg] L4S & VPN anti-replay interaction: Explanation

[Jonathan Morton <[e-mail]>]

> On 11 May, 2021, at 5:56 pm, Black, David <[e-mail]> wrote:
> 
> At the VPN receiver, the received L4S packets drive advancing the sliding window to higher sequence numbers.  If the sequence numbers in the arriving L4S packets get ahead of the sequence numbers in the arriving Classic packets by the size of the sliding window or more, the arriving Classic packets are dropped *even though they are not duplicates* (!).

The practical effects of this should also be described to give a full picture.

With normal, congestion-controlled traffic, the above condition results only during relatively brief periods when the C queue builds to some level (which may or may not be up to the AQM threshold).  The packets dropped for arriving outside the replay window cause a reduction in cwnd for that flow, which tends to empty the C queue.  The ultimate result is a reduction in throughput for traffic in the VPN using the C queue.

However, this behaviour can also be exploited by an attacker using unresponsive traffic to the C queue and a relatively small flow to the L queue, at least the latter being directed through the VPN.  This is capable of causing *all* VPN traffic using the C queue to be discarded due to violating the replay window, because the C queue is kept full permanently by the unresponsive traffic.  This is a Denial of Service attack which warrants a "Serious" risk severity rating.

 - Jonathan Morton