Note that there are two completely separate sysctls here - the timeout on fragments, and the amount of memory available
for fragment reassembly. You have to multiply them together to reach the "Mbps of lost or deliberately-lost fragments
before we start dropping all future fragments". See the
On Sun, Apr 18, 2021 at 4:31 PM Matt Corallo
wrote:
>
> Should the default, though, be so low? If someone is still using a old modem
> they can crank up the sysctl, it does seem
> like such things are pretty rare these days :). Its rather trivial to,
> without any kind of attack, hit 1Mbps of
Should the default, though, be so low? If someone is still using a old modem they can crank up the sysctl, it does seem
like such things are pretty rare these days :). Its rather trivial to, without any kind of attack, hit 1Mbps of lost
fragments in today's networks, at which point all fragments
On Sat, Apr 17, 2021 at 10:26:30PM -0400, Matt Corallo wrote:
> 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
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
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
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
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
On Sat, Apr 17, 2021 at 06:44:40AM +0200, Eric Dumazet wrote:
> On Sat, Apr 17, 2021 at 2:31 AM David Ahern wrote:
> >
> > [ cc author of 648700f76b03b7e8149d13cc2bdb3355035258a9 ]
>
> I think this has been discussed already. There is no strategy that
> makes IP reassembly units immune to DDOS
On Sat, Apr 17, 2021 at 2:31 AM David Ahern wrote:
>
> [ cc author of 648700f76b03b7e8149d13cc2bdb3355035258a9 ]
I think this has been discussed already. There is no strategy that
makes IP reassembly units immune to DDOS attacks.
We added rb-tree and sysctls to let admins choose to use GB of
[ cc author of 648700f76b03b7e8149d13cc2bdb3355035258a9 ]
On 4/16/21 3:58 PM, Keyu Man wrote:
> Hi,
>
>
>
> My name is Keyu Man. We are a group of researchers from University
> of California, Riverside. Zhiyun Qian is my advisor. We found the code
> in processing IPv4/IPv6 fragments will
Hi,
My name is Keyu Man. We are a group of researchers from University
of California, Riverside. Zhiyun Qian is my advisor. We found the code
in processing IPv4/IPv6 fragments will potentially lead to DoS
Attacks. Specifically, after the latest kernel receives an IPv4
fragment, it will try to
12 matches
Mail list logo
