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

Date:	Mon, 14 Oct 2013 17:56:10 +0200
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Bjørn Mork <bjorn@...k.no>
Cc:	netdev@...r.kernel.org
Subject: Re: [RFC] ipv6: always join solicited-node address

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 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.

Greetings,

  Hannes

--
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