netdev - Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0 (was: Strange behavior in arp probe reply, bug or feature?)

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:	Tue, 20 Nov 2007 00:16:07 -0500
From:	Bill Fink <billfink@...dspring.com>
To:	Alexey Kuznetsov <kuznet@....inr.ac.ru>
Cc:	Jonas Danielsson <the.sator@...il.com>,
	linux-kernel@...r.kernel.org, davem@...emloft.net,
	jmorris@...ei.org, netdev@...r.kernel.org,
	akpm@...ux-foundation.org
Subject: Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0 (was:
 Strange behavior in arp probe reply, bug or feature?)

On Mon, 19 Nov 2007, Alexey Kuznetsov wrote:

> Hello!
> 
> > Is there a reason that the target hardware address isn't the target
> > hardware address?
> 
> It is bound only to the fact that linux uses protocol address
> of the machine, which responds. It would be highly confusing
> (more than confusing :-)), if we used our protocol address and hardware
> address of requestor.
> 
> But if you use zero protocol address as source, you really can use
> any hw address.
> 
> > The dhcp clients I examined, and the implementation of the arpcheck
> > that I use will compare the target hardware field of the arp-reply and
> > match it against its own mac, to verify the reply. And this fails with
> > the current implementation in the kernel.
> 
> 1. Do not do this. Mainly, because you already know that this does not work
>    with linux. :-) Logically, target hw address in arp reply is just
>    a nonsensial redundancy, it should not be checked and even looked at.

Repeating what I posted earlier from the ARP RFC 826:

	"The target hardware address is included for completeness and
	network monitoring.  It has no meaning in the request form,
	since it is this number that the machine is requesting.  Its
	meaning in the reply form is the address of the machine making
	the request.  In some implementations (which do not get to look
	at the 14.byte ethernet header, for example) this may save some
	register shuffling or stack space by sending this field to the
	hardware driver as the hardware destination address of the
	packet.

Unless there is some other RFC that supercedes this, which doesn't appear
to be the case since it's also STD37, it appears to me that the current
Linux behavior is wrong.  It clearly states that for the ARP reply, the
target hardware address is "the address of the machine making the request",
and not the address of the machine making the reply as Linux is apparently
doing.

> 2. What's about your suggestion, I thought about this and I am going to agree.
> 
>    Arguments, which convinced me are:
> 
>    - arping still works.
>    - any piece of reasonable software should work.
>    - if Windows understands DaD (is it really true? I cannot believe)
>      and it is unhappy about our responce and does not block use
>      of duplicate address only due to this, we _must_ accomodate ASAP.
>    - if we do,we have to use 0 protocol address, no choice.

I agree the target protocol address should be 0 in this case.

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