netdev - Re: icmpv6: issue with routing table entries from link local addresses

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]

Date:   Mon, 12 Sep 2016 22:03:55 -0400
From:   Sowmini Varadhan <sowmini05@...il.com>
To:     Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:     Andreas Hübner <andreas@....de>,
        netdev <netdev@...r.kernel.org>,
        "d. caratti" <davide.caratti@...il.com>,
        Sowmini Varadhan <sowmini.varadhan@...cle.com>
Subject: Re: icmpv6: issue with routing table entries from link local addresses

On Mon, Sep 12, 2016 at 1:26 PM, Hannes Frederic Sowa
<hannes@...essinduktion.org> wrote:
> Hello,
>
> On 12.09.2016 16:27, Andreas Hübner wrote:

>>
>> I have the following setup:
>>   - 2 directly connected hosts (A+B), both have only link local addresses
>>     configured (interface on both hosts is eth0)
           :
>>       fe80::/64 dev eth1  proto kernel  metric 256
>>       fe80::/64 dev eth0  proto kernel  metric 256
           :
>> The issue I currently have is, that the echo reply that host B should
>> generate is never sent back to host A. If I change the order of the
>> routing table entries on host B, everything works fine.
>> (host A is connected on eth0)
   :
> This shouldn't be the case. We certainly carry over the ifindex of the
> received packet into the routing lookup of the outgoing packet, thus the
> appropriate rule, with outgoing ifindex should be selected.

Like Hannes,  I too would first check "is B sending out the echo-resp? on
which interface?".

But a couple of unexpected things I noticed in linux: the link-local
prefix should have a prefixlen of /10 according to
http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml
but "ip -6 route show"  lists this as a /64..

moreover, even though I cannot use "ip [-6] route add.." to add the
same prefix multiple times (with different nexthop and/or interface)
unless I explicitly mark them as ECMP with /sbin/ip, it seems like you
can create the same onlink prefix on multiple interfaces, but the
kernel will not treat this as an ECMP group (and sometimes this
can produce inconsistent results depending on the order of
route addition, e.g., for ipv4 rp_filter checks). I dont know if some
variant of  this (latter observation) may be the reason for the behavior
that  Andreas reports.

--Sowmini