linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Julian Anastasov <ja@ssi.bg>
Cc: netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
	matti.gottlieb@intel.com
Subject: Re: [PATCH 3/4] ipv4: add option to drop gratuitous ARP packets
Date: Mon, 13 Apr 2015 13:17:13 +0200	[thread overview]
Message-ID: <1428923833.2355.14.camel@sipsolutions.net> (raw)
In-Reply-To: <alpine.LFD.2.11.1504111340170.2449@ja.home.ssi.bg>

On Sat, 2015-04-11 at 13:59 +0300, Julian Anastasov wrote:
> > + /*
> > +  *	For some 802.11 wireless deployments (and possibly other networks),
> > +  *	there will be an ARP proxy and gratuitous ARP frames are attacks
> > +  *	and thus should not be accepted.
> > +  */
> > +	if (IN_DEV_CONF_GET(in_dev, DROP_GRATUITOUS_ARP) && sip == tip)
> > +		goto out;
> 
> 	Does it happen for any pkt_type? 

Yes, it's supposed to.

> IN_DEV_ARP_ACCEPT
> is not ON by default, so new entries are not created but

Correct, this protects against "gratuitous updates" in a way.

> update can happen at any time, even with simple request like
> who-has OURIP tell PROXYIP and sha=hacker_mac sent by
> attackers. Is that the only gap that needs to be protected
> with this patch?

Realistically, I'd expect networks that deploy this to implement other
things that prevent clients from messing up the network. I'd expect, for
example, that ARP packets are simple dropped in the AP bridge if it
implements proxy service and wants to control the network tightly.

It can still be desirable to not let gratuitous ARP packets update the
cache entry though. IPv6 for example automatically marks such updated
entries stale, IIRC, so there I had even bigger issues with testing and
I need to check if I even need the 4th patch in this series.

However, there's also a compliance test here that requires this
behaviour, and checks specifically that a gratuitous ARP doesn't update
an existing cache entry.

> 	May be only arptable_filter can help here to
> protect ARP?

That could be possible, I'll check.

Thanks!

johannes



  reply	other threads:[~2015-04-13 11:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-10  7:54 [PATCH 1/4] ipv4: add option to drop unicast encapsulated in L2 multicast Johannes Berg
2015-04-10  7:54 ` [PATCH 2/4] ipv6: " Johannes Berg
2015-04-10  7:54 ` [PATCH 3/4] ipv4: add option to drop gratuitous ARP packets Johannes Berg
2015-04-10 12:56   ` Sergei Shtylyov
2015-04-10 13:11     ` Johannes Berg
2015-04-11 10:59   ` Julian Anastasov
2015-04-13 11:17     ` Johannes Berg [this message]
2015-11-04 16:19     ` Johannes Berg
2015-04-10  7:54 ` [PATCH 4/4] ipv6: add option to drop unsolicited neighbor advertisements Johannes Berg
2015-04-10 12:19 ` [PATCH 1/4] ipv4: add option to drop unicast encapsulated in L2 multicast Julian Anastasov
2015-04-10 13:10   ` Johannes Berg
2015-04-11 10:39     ` Julian Anastasov
2015-04-13 10:57       ` Johannes Berg
2015-04-13 12:04         ` Julian Anastasov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1428923833.2355.14.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=ja@ssi.bg \
    --cc=linux-wireless@vger.kernel.org \
    --cc=matti.gottlieb@intel.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).