From: Willy Tarreau <w@1wt.eu>
To: Eric Dumazet <edumazet@google.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
"David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, netdev <netdev@vger.kernel.org>,
Maciej Zenczykowski <maze@google.com>
Subject: Re: [PATCH net] ipv6: tcp: drop silly ICMPv6 packet too big messages
Date: Wed, 7 Jul 2021 18:27:36 +0200 [thread overview]
Message-ID: <20210707162736.GA2337@1wt.eu> (raw)
In-Reply-To: <CANn89iJcEiYJa7dv+nwUw-EF4KpeNCCPHb1NBhn7M0Nhw9gVrg@mail.gmail.com>
On Wed, Jul 07, 2021 at 06:25:10PM +0200, Eric Dumazet wrote:
> On Wed, Jul 7, 2021 at 6:15 PM Willy Tarreau <w@1wt.eu> wrote:
> >
> > On Wed, Jul 07, 2021 at 06:06:21PM +0200, Eric Dumazet wrote:
> > > On Wed, Jul 7, 2021 at 5:59 PM Willy Tarreau <w@1wt.eu> wrote:
> > > >
> > > > Hi Eric,
> > > >
> > > > On Wed, Jul 07, 2021 at 08:46:30AM -0700, Eric Dumazet wrote:
> > > > > From: Eric Dumazet <edumazet@google.com>
> > > > >
> > > > > While TCP stack scales reasonably well, there is still one part that
> > > > > can be used to DDOS it.
> > > > >
> > > > > IPv6 Packet too big messages have to lookup/insert a new route,
> > > > > and if abused by attackers, can easily put hosts under high stress,
> > > > > with many cpus contending on a spinlock while one is stuck in fib6_run_gc()
> > > >
> > > > Just thinking loud, wouldn't it make sense to support randomly dropping
> > > > such packets on input (or even better rate-limit them) ? After all, if
> > > > a host on the net feels like it will need to send one, it will surely
> > > > need to send a few more until one is taken into account so it's not
> > > > dramatic. And this could help significantly reduce their processing cost.
> > >
> > > Not sure what you mean by random.
> >
> > I just meant statistical randomness. E.g. drop 9/10 when under stress for
> > example.
>
> It is hard to define ' stress'. In our case we were maybe receiving 10
> ICMPv6 messages per second " only "
>
> I would rather define the issue as a deficiency in current IPv6 stack vs routes.
>
> One can hope that one day the issue will disappear.
Aie. I thought you were speaking about million PPS. For sure if 10 pkt/s
already cause harm, there's little to nothing that can be achieved with
sampling!
Thanks for the clarifications!
Willy
next prev parent reply other threads:[~2021-07-07 16:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-07 15:46 [PATCH net] ipv6: tcp: drop silly ICMPv6 packet too big messages Eric Dumazet
2021-07-07 15:59 ` Willy Tarreau
2021-07-07 16:06 ` Eric Dumazet
2021-07-07 16:15 ` Willy Tarreau
2021-07-07 16:25 ` Eric Dumazet
2021-07-07 16:27 ` Willy Tarreau [this message]
2021-07-07 16:30 ` Eric Dumazet
2021-07-07 16:30 ` Maciej Żenczykowski
2021-07-07 22:25 ` Martin KaFai Lau
2021-07-08 5:52 ` Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210707162736.GA2337@1wt.eu \
--to=w@1wt.eu \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=kuba@kernel.org \
--cc=maze@google.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).