netdev - Re: [RFC] ipv6: always join solicited-node address

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: <871u31trik.fsf@nemi.mork.no>
Date:	Thu, 31 Oct 2013 16:00:03 +0100
From:	Bjørn Mork <bjorn@...k.no>
To:	netdev@...r.kernel.org
Subject: Re: [RFC] ipv6: always join solicited-node address

Hannes Frederic Sowa <hannes@...essinduktion.org> writes:

> On Mon, Oct 14, 2013 at 09:09:59AM +0200, Bjørn Mork wrote:
>> Yes, but that would also make the IP layer try to resolve IP to link
>> layer addressess both for IPv4 and IPv6, which just won't work. At least
>> not for IPv4, where there just is no way to transport an ARP to the
>> modem.  And I assume it may fail for IPv6 too on any sane device.
>
> I don't think that clearing the IFF_NOARP flag would kill connectivity
> for either IPv4 or IPv6.

It does, because the neigbours cannot be resolved.

> It may compromise security for IPv6 though
> (no idea how the telco network behind the modem looks like).
>
>> > Is this a specific bug of the modem you are using or are all devices
>> > powered by this driver like this?
>> 
>> Unfortunately I have no IPv6 enabled SIM myself, so I have no
>> information about other devices.  This report was based on user
>> feedback.
>> 
>> I assume the bug is specific to this firmware implementation, probably
>> extending to all similar devices from the same vendor.  But it could be
>> more common than that.  The fact that the bug is there indicates that
>> this works just fine in Windows.
>> 
>> Yes, I realize that I am in ugly-hack-to-workaround-firmware-issues land
>> again... But it sure would be nice to have some way for a driver to
>> indicate that L2 neighbour tables are meaningless, but that any incoming
>> requests should still be answered.
>
> L2 neighbour tables are resolved on demand and won't be queried for the
> link you are talking about (at least for IPv6, but I assume IPv4, too).
>
> A new flag should have clear semantics then:
>
> * split IFF_NOARP to IFF_NOARP and IFF_NONDISC
> * split IFF_NOARP to IFF_NOLLRESOLV_RESPONSE and IFF_NOLLRESOLV_MODIFY
>   (each one flag which is applicable for both IPv4 and IPv6)
>
> I tend to lean towards the last alternative but still wonder if this is
> just overhead for this one buggy device.

Thanks a lot for your review and thoughts on this.  I do agree 100% with
your last comment here, and ended up with an in-driver workaround
instead.

It's not beautiful, but at least it doesn't add a lot of core code for
this very special purpose.



Bjørn
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html