netdev - Re: arp_filter and IPv6 ND

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAeewD9CDQZp0u6L6JtZ96cboKDCRB=yY92F+-ufsA8=OEgyUw@mail.gmail.com>
Date:   Sat, 3 Dec 2016 16:21:17 +0200
From:   Saku Ytti <saku@...i.fi>
To:     Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:     netdev@...r.kernel.org
Subject: Re: arp_filter and IPv6 ND

On 2 December 2016 at 20:39, Hannes Frederic Sowa
<hannes@...essinduktion.org> wrote:

Hey,

> E.g. you can use IP addresses bound to other interfaces to send replys
> on another interface. This can be useful if you have a limited amount of
> IP addresses on the system but much more interfaces. Especially if they
> are limited in scope, like in IPv6.
>
> Basically Cisco's feature of "unnumbered interface" is always provided
> in Linux. And there are certainly cases where you would want to use it,
> e.g. emulate private-vlan feature for network separation.

Got it, thanks, the explanation makes sense. And indeed it's valid
case, but also it is the exception, not the rule. I think it would be
entirely change the default and people who want 'unnumbered' style
behaviour (like some BRAS scenarios), will know how to and why to
configure it.

> Also in the BGP setup, you might have it easier to establish loopback
> neighbor contact by just using static on-link routes, without caring
> about more complex numbering there (otherwise you pretty soon introduce
> OSPF or some other routing protocol to do the recursive forward resolution).

The BGP is running on-link, it's just that the BGP is advertising loop
of Linux. Why the loop ends up in ND cache, I don't know.

>> Grand, not that I feel comfortable writing it. I'd rather see the
>> whole suppression functionality moved to neighbour.c from being AFI
>> specific.
>
> Yes sure, please provide a patch. A separate sysctl is necessary anyway
> because the current one is within the ipv4 procfs directory hierarchy.

Sorry, not a comfortable C programmer, I'm pretty confident I could
get it working, but I'm more confident that patch would be entirely
rejected and rewritten by someone who knows what they are doing.
I see no reason not to have AFI specific toggle, just logic and code
should be AFI agnostic, like GC (ARP/ND cache time) stuff in
neighbour.c is nicely done. Frankly whole ARP/ND code could do with
refactoring to make arp.c and ndisc.c more wire-format stuff and
behavioural code more in neighbour.c.

-- 
  ++ytti