On Mon, Jan 11, 2016 at 01:08:56PM -0500, Vlad Yasevich wrote:

On 01/11/2016 11:33 AM, Marcelo Ricardo Leitner wrote:

quoted

On Mon, Jan 11, 2016 at 05:32:10PM +0800, Herbert Xu wrote:

quoted

David Miller [off-list ref] wrote:

quoted

From: Eric Dumazet <redacted>
Date: Wed, 30 Dec 2015 11:57:31 -0500

quoted

I am against using rhashtable in SCTP (or TCP) at this stage, given the
number of bugs we have with it.

Come on Eric, we've largely dealt with all of these problems.  I haven't
seen a serious report in a while.

Well there is still the outstanding issue with softirq insertion
potentially failing with ENOMEM if we fail to expand the hash
table using just kmalloc.

So if the target user does softirq insertions, I would wait until
the fix for that is ready.

It does some, yes. If listening socket is not backlogged, there will be
N inserts at each new association, where N is the number of IP addresses
that the client is advertising.

This is done on the second stage of the SCTP handshake. Not easily
DoS-able as it requires receiving a packet from server and replying
based on it, plus N is limited by MTU.

How is N limited by MTU?  INIT and COOKIE chunks are allowed to exceed
mtu and will be IP fragmented.  So it seems that N is limited by 65535-overhead,
where overhead is all the headers plus the sctp cookie info.  That can
be quite a lot of addresses.

Oups, you're right. One then can trigger quite some inserts with a
single new assoc attempt, yes.

  Marcelo