Re: [PATCH RFC/RFT net-next 00/17] net: Convert neighbor tables to per-namespace

[Michael Richardson <mcr@sandelman.ca>]

[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]

>>>>> David Ahern <dsahern@gmail.com> writes:
dsahern@kernel.org wrote:
    > Nikita Leshenko reported that neighbor entries in one namespace can
    > evict neighbor entries in another. The problem is that the neighbor
    > tables have entries across all namespaces without separate accounting
    > and with global limits on when to scan for entries to evict.

    > Resolve by making the neighbor tables for ipv4, ipv6 and decnet per
    > namespace and making the accounting and threshold limits per namespace.

This is a good improvement, thank you.
We absolutely need to keep a DOS against a single netns from causing
evictions in another netns.

Within a namespace there may be neighbours entries that are more
sure/valid/useful than others.  I would like an API to be able to
mark them explicitely, but that could come leter.

In particular, in the 802.15.4 case, NE that arrive via encrypted
channels should be preferred over entries that arrive over unencrypted
channels.  This is needed for IETF 6tisch secure join work, for instance.

I believe that we could use network namespaces to implement though.

I had not considered that before, and I think that it will work, but
there might be something subtle that I've missed.  (Alex?)
It appears that one can tune the amount of space on a per-namespace basis:

+	nd_tbl->gc_thresh1	= 128;
+	nd_tbl->gc_thresh2	= 512;
+	nd_tbl->gc_thresh3	= 1024;

> Remove open use of arp_tbl and nd_tbl in favor of the new
> ipv{4,6}_neigh_table helpers. Since the existence of the IPv6 table
> is managed by the core networking, the IS_ENABLED checks for IPv6
> can be removed in favor of "is the table non-NULL".

What's the advantage of changing this check? (I am ignorant)


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 464 bytes --]