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

[Bob Briscoe <[e-mail]>]

Jonathan,

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.

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.

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



Bob

On 08/05/2021 15:22, Jonathan Morton wrote:
>> On 8 May, 2021, at 9:45 am, Pete Heist <[e-mail]> wrote:
>>
>> I noticed that this issue seems to affect tunnels with replay window
>> sizes of 32 and 64 packets regardless of the bottleneck bandwidth,
>> likely because the peak C sojourn times can also increase as the
>> bandwidth decreases. IMO, this seems like a safety concern from the
>> standpoint that the deployment of DualPI2 can cause harm to
>> conventional traffic, in IPsec tunnels using common defaults in
>> particular, beyond that which is caused by DualPI2 itself.
> It turns out that there's also a Denial of Service attack enabled by this phenomenon - one which does not rely on any legitimate L4S endpoints being deployed or used.  It is a property of the passive deployment of DualQ.
>
> We assume a VPN tunnel upon which Sequence Verification is in use (RFC-4303 §3.4.3), over a path that includes a DualQ-Coupled qdisc (draft-ietf-tsvwg-aqm-dualq-coupled), abbreviated DualQ.  We further assume that an attacker is able to send traffic with chosen ECN codepoints into the input end of this tunnel.  We outline two attack scenarios, the second of which further assumes that the attacker sends traffic directly over the DualQ path, not via the tunnel, which requires that the attacker knows more information than the first attack scenario.  The threat is the ability to deny any useful traffic being conveyed by the VPN tunnel, at a significantly lower cost than a conventional DDoS.
>
> In the first attack scenario, the attacker generates two distinct streams of traffic, named Lambda and Omega, both of which are directly into the input end of the tunnel.  The Lambda stream is bulk data with an ECN codepoint that filters into the C queue - either Not-ECT or ECT(0).  The Omega stream is a low-volume stream of small packets with an ECN codepoint that filters into the L queue - either ECT(1) or CE.  It is not necessary for either stream to be accepted by a host at the receiving end, only by the endpoints of the VPN itself.
>
> The purpose of the Lambda stream is to keep the C queue of the DualQ full, and it is sufficient to send MTU-sized packets in only slightly greater volume than the capacity of the link.  We will assume for analysis that DualQ maintains the C queue at its AQM setpoint, which is 25ms by default.
>
> The purpose of the Omega stream is to bypass the Lambda stream by taking the "fast lane" through the DualQ instance, and thereby control the leading edge of the Sequence Verification window of the VPN receiver.  If the leading edge of the window can be kept so far ahead of the traffic arriving via the C queue that the latter always falls behind the trailing edge of the window, then the amount of useful traffic conveyed by the VPN in the same direction falls to nil - a successful Denial of Service.
>
> The required Sequence Verification window to deny this attack scenario full effectiveness is the VPN packet throughput of the C queue multiplied by the difference in queue sojourn times between the C and L queues, plus the interval between packets delivered in the Omega stream.  Since the default SV window in some popular VPNs is 32 or 64, this attack can be fairly easy to implement.
>
> Another mitigation that the VPN could apply is to limit the throughput of the VPN, such that it cannot by itself be used to saturate the DualQ link and thus keep the C queue full.  We address this with the second attack scenario, which bypasses such a mitigation.
>
> In the second attack scenario, the Lambda stream is sent directly to the DualQ link rather than through the VPN.  The Omega stream is still sent through the VPN.  The properties of the two streams are mostly similar otherwise to those of the first attack scenario, but the volume of the Omega stream must be increased.
>
> The second attack scenario will succeed if the number of Omega packets delivered during any interval of time equal to the difference between the C and L queue sojourn times is greater than the Sequence Verification window.  This is also easy to achieve if the Omega packets are small and the SV window is at the usual defaults of 32 or 64.
>
> The cause of this attack enablement is that DualQ can reorder packets from the same flow under fairly precise control of an attacker.  A straight FIFO, or a flow-aware qdisc that treats a VPN as a single flow (such as RFC-8290 fq_codel or Cake), delivers packets from any given flow in-order, and is thus immune from this attack.  Adding DualQ-like semantics to any of these carries the risk of enabling the attack as described above.
>
>   - Jonathan Morton
>

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