Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <78d776a9-4299-ff4e-8ca2-096ec5c02d05@bluematt.me>
Date:   Sat, 17 Apr 2021 22:26:30 -0400
MIME-Version: 1.0
Subject: Re: PROBLEM: DoS Attack on Fragment Cache
Content-Language: en-US
To:     Keyu Man <kman001@ucr.edu>
Cc:     Willy Tarreau <w@1wt.eu>, Eric Dumazet <edumazet@google.com>,
        David Ahern <dsahern@gmail.com>,
        Florian Westphal <fw@strlen.de>, davem@davemloft.net,
        yoshfuji@linux-ipv6.org, dsahern@kernel.org,
        Jakub Kicinski <kuba@kernel.org>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, Zhiyun Qian <zhiyunq@cs.ucr.edu>
References: <02917697-4CE2-4BBE-BF47-31F58BC89025@hxcore.ol>
 <52098fa9-2feb-08ae-c24f-1e696076c3b9@gmail.com>
 <CANn89iL_V0WbeA-Zr29cLSp9pCsthkX9ze4W46gx=8-UeK2qMg@mail.gmail.com>
 <20210417072744.GB14109@1wt.eu>
 <CAMqUL6bkp2Dy3AMFZeNLjE1f-sAwnuBWpXH_FSYTSh8=Ac3RKg@mail.gmail.com>
 <20210417075030.GA14265@1wt.eu>
 <c6467c1c-54f5-8681-6e7d-aa1d9fc2ff32@bluematt.me>
 <CAMqUL6bAVE9p=XEnH4HdBmBfThaY3FDosqyr8yrQo6N_9+Jf3w@mail.gmail.com>
From:   Matt Corallo <netdev-list@mattcorallo.com>
In-Reply-To: <CAMqUL6bAVE9p=XEnH4HdBmBfThaY3FDosqyr8yrQo6N_9+Jf3w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Sure, there are better ways to handle the reassembly cache overflowing, but that is pretty unrelated to the fact that 
waiting 30 full seconds for a fragment to come in doesn't really make sense in today's networks (the 30 second delay 
that is used today appears to even be higher than RFC 791 suggested in 1981!). You get a lot more bang for your buck if 
you don't wait around so long (or we could restructure things to kick out the oldest fragments, but that is a lot more 
work, and probably extra indexes that just aren't worth it).

Matt

On 4/17/21 21:38, Keyu Man wrote:
> Willy's words make sense to me and I agree that the existing fragments
> should be evicted when the new one comes in and the cache is full.
> Though the attacker can still leverage this to flush the victim's
> cache, as mentioned previously, since fragments are likely to be
> assembled in a very short time, it would be hard to launch the
> attack(evicting the legit fragment before it's assembled requires a
> large packet sending rate). And this seems better than the existing
> solution (drop all incoming fragments when full).
> 
> Keyu
> 
> On Sat, Apr 17, 2021 at 6:30 PM Matt Corallo
> <netdev-list@mattcorallo.com> wrote:
>>
>> See-also "[PATCH] Reduce IP_FRAG_TIME fragment-reassembly timeout to 1s, from 30s" (and the two resends of it) - given
>> the size of the default cache (4MB) and the time that it takes before we flush the cache (30 seconds) you only need
>> about 1Mbps of fragments to hit this issue. While DoS attacks are concerning, its also incredibly practical (and I do)
>> hit this issue in normal non-adversarial conditions.
>>
>> Matt
>>
>> On 4/17/21 03:50, Willy Tarreau wrote:
>>> On Sat, Apr 17, 2021 at 12:42:39AM -0700, Keyu Man wrote:
>>>> How about at least allow the existing queue to finish? Currently a tiny new
>>>> fragment would potentially invalid all previous fragments by letting them
>>>> timeout without allowing the fragments to come in to finish the assembly.
>>>
>>> Because this is exactly the principle of how attacks are built: reserve
>>> resources claiming that you'll send everything so that others can't make
>>> use of the resources that are reserved to you. The best solution precisely
>>> is *not* to wait for anyone to finish, hence *not* to reserve valuable
>>> resources that are unusuable by others.
>>>
>>> Willy
>>>