netdev - RE: Solving address deletion bottleneck in SCTP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20241107081813.2095995-1-gnaaman@drivenets.com>
Date: Thu,  7 Nov 2024 08:18:13 +0000
From: Gilad Naaman <gnaaman@...venets.com>
To: david.laight@...lab.com
Cc: gnaaman@...venets.com,
	linux-sctp@...r.kernel.org,
	lucien.xin@...il.com,
	marcelo.leitner@...il.com,
	netdev@...r.kernel.org
Subject: RE: Solving address deletion bottleneck in SCTP

From: David Laight <David.Laight@...LAB.COM>
> From: Gilad Naaman
> > Sent: 28 October 2024 12:49
> ...
> > the list `net->sctp.local_addr_list` gets obscenely long.
> > 
> > This list contains both IPv4 and IPv6 addresses, of all scopes, and it is
> > a single long list, instead of a hashtable.
> > 
> > In our case we had 12K interfaces, each with an IPv4 and 2 IPv6 addresses
> > (GUA+LLA), which made deletion of a single address pretty expensive, since
> > it requires a linear search through 36K addresses.
> ...
> 
> Is that the list that SCTP uses in order to pass all of its local addresses
> to the remote system during connection establishment?

Yes, it is exactly that list.

> In which case it really makes no sense to have the list at all if it contains
> more than a handful of addresses.
> 
> Indeed the whole notion of 'send ALL my addresses' is just plain broken.
> What happens in practise is that applications pretty much always have to
> bind to all (typically both) the relevant addresses to stop the system
> sending IP addresses that are unroutable from the remote system - and
> may even refer to an entirely different local network.
>
> Passing this buck to the application isn't really right either.
> It ought to be a property of the network topology.
> But that is hard to describe.
> The two systems 10.1.1.1 and 10.1.1.2 could both have private 192.168.1.x
> networks (without IP forwarding) and other 10.1.1.x hosts could be
> randomly connected to either network.
> 
> 	David

Yeah, I'm not entirely sure what should even happen in this case.

I feel like I could use a CONFIG_SCTP_INIT_ADDRESS and CONFIG_SCTP_AUTO_ASCONF,
where setting both to false removes this behaviour and list.
Not sure if it makes sense, though.