netdev - Re: [RFC] ipv4: support for request type gratuitous ARP

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: <201001112331.37187.opurdila@ixiacom.com>
Date:	Mon, 11 Jan 2010 23:31:37 +0200
From:	Octavian Purdila <opurdila@...acom.com>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: [RFC] ipv4: support for request type gratuitous ARP

On Sunday 10 January 2010 23:21:05 you wrote:
> From: Octavian Purdila <opurdila@...acom.com>
> Date: Tue, 5 Jan 2010 00:04:44 +0200
> 
> > Signed-off-by: Octavian Purdila <opurdila@...acom.com>
> > ---
> >
> > I've noticed that even though we currently support response type
> > gratuitous ARP [response type, source mac, dest mac, source IP, source
> > IP] *with a clean ARP table* we do not support the request type [request
> > type, source mac, ff:ff:ff:ff:ff:ff, source IP, source IP].
> 
> Please don't submit your patches in this manner.
> 
> All of these relevant, interesting, details belong in the commit
> message.  But any text you place aftr the "---" line will be omitted
> from the commit message when your patch is applied by automated GIT
> tools.
> 

Got it.

> I've done some research and I'm happy to apply your patch to
> net-next-2.6 once it is submitted properly.
> 

Thanks, I'll resubmitted it properly in a bit.

> In fact we need to do some more research in this area because
> generally we should more mimick the processing order of ARP prescribed
> in the RFC.  In particular we should test the operation code lastly,
> which would avoid these kinds of inconsistencies.
> 
> I'm worried though about security issues as well, as we make more the
> acceptance more and more liberal, it becomes that much easier for
> machines on the local network to poison ARP entries and use that to
> either accept all traffic destined for a particular node or simply
> deny that node access to the network.
> 
> In particular the kernel currently explicitly does not accept
> unsolicited ARP, and this is controlled by the ARP_ACCEPT per-device
> option.
> 
> 	if (IPV4_DEVCONF_ALL(dev_net(dev), ARP_ACCEPT)) {
> 		/* Unsolicited ARP is not accepted by default.
> 		   It is possible, that this option should be enabled for some
> 		   devices (strip is candidate)
> 		 */
> ...
> 

Good point, I'll try to respin the patch to do this check for the request type 
gratuitous ARP as well.

Thanks!

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