netdev - Re: ARP response with link local IP, why not broadcast

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: <CACP96tS3LH9Uqr-YeYZ=EF893=T-YsjdDELq7v0uXSzzwyOL7Q@mail.gmail.com>
Date:	Wed, 22 Jul 2015 10:29:25 +0200
From:	Sowmini Varadhan <sowmini05@...il.com>
To:	Sebastian Fett <db_extern@....de>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: ARP response with link local IP, why not broadcast

On Wed, Jul 22, 2015 at 9:49 AM, Sebastian Fett <db_extern@....de> wrote:

>> what is your use case?
>>
>
> My problem ist a local network of audio devices. It is a valid possibility
> that two halfs of the setup are set up individually (Stage left and stage
> right). Both local networks will auto configure themselves via link local
> and will be stable. But there always can be two devices with the same IP in
> both networks.
> At one point those two networks will be connected. With the current
> behaviour the conflicting devices will never know of each other and the
> address conflict.

Ah yes, this is a valid problem (Partition-Join tolerance) and one that is
being discussed in the Ipv6 context on 6man:
http://www.ietf.org/mail-archive/web/ipv6/current/msg22712.html

FWIW, when Solaris implemented ACD (rfc 5227) the compromise
that was made between bcasting *every* ARP response whle solving
the type or issue that you describe was to use a periodic ARP "announce",
advertising the IP address (a Grat ARP) with exponential backoff.
If a duplicate address is triggered (as would happen in the scenario
that you describe) the system would fall into the aggressive defend mode.

ARP announcemnts were bcast, but the noise is mitigated by tunable
exponential backoff.

Of course, all of this only helps to *detect* the duplicate- eventually
some other entity has to jump in and arbitrate on which one should
"own" the address.

> The devices are controlled by a central PC using avahi/bonjour. It will know
> of all conflicting devices, but will only be able to talk to the one that
> happens to be in it's ARP cache. And renewing that cache will not change
> anything, because it will happen with unicast messages.
>
> I looked at a Dante Controller (an audio data streaming device). And here
> all ARP messages are answered with broadcasts.
>
> I think that behaviour is acceptable because it only happens in local
> networks. Waking up sleeping devices will not be a concern there.

I dont know if a short term solution that makes sense here is to have
a tunable for this.

But even the "always bcast arp response" will fail if you have a silent
rejoin of the partitioned network- there is a reliance on the owner
of an address bcasting their ARP resp at some point right?

(there's also a DoS vector here- I can create a lot of bcast traffic
by arping for an address..)
>
> That brings me to another question. When I react to an ARP packet in a
> userspace program, can I keep that packet from reaching the kernel as well?
> I would like to avoid to completely handle ARP in userspace.
>
--
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