netdev - Re: [Bridge] Re: [RFC] bridging: don't forward EAPOL frames

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

Date:	Tue, 27 Nov 2007 16:28:41 +0100
From:	Johannes Berg <johannes@...solutions.net>
To:	Andy Gospodarek <andy@...yhouse.net>
Cc:	Stephen Hemminger <shemminger@...ux-foundation.org>,
	netdev <netdev@...r.kernel.org>,
	bridge <bridge@...ux-foundation.org>
Subject: Re: [Bridge] Re: [RFC] bridging: don't forward EAPOL frames


> > > Not needed because the bridge is already handling it:
> > >
> > > 1) If running STP (ie true bridge), then all link local multicast is only received by
> > > the bridge and never forwarded.
> >
> > Well, typical access point setups bridge the wireless AP interface with
> > wired, EAPOL frames can be unicast (and 802.11 specifies to do so) and
> > we want to avoid having them unicast to another host.
> >
> > Also, 802.1X in C.3.3 recommends not bridging the *ethertype* rather
> > than depending on the link-local multicast address because otherwise
> > eapol frames can be unicast into the network behind the (authorized)
> > port which is undesirable.

> I agree with Stephen, that based on the way it's likely people use
> linux bridges it seems like this is something that could be configured
> rather than simply dropping those frames without any chance to forward
> them.

Well Stephen is wrong in one thing that eapol need not be link local
multicast for 802.11, it's unicast there so the dropping of link local
packets doesn't help.

> There are probably quite a few people out there who will not
> expect this change, so it should be easy to change during runtime.

I'm not aware of any use for EAPOL frames traversing the network. I'm
also not aware of any proper 802.1X implementation for linux bridges but
I didn't do too much research yet. I don't see why people would rely on
EAPOL frames being bridged when the protocol is by definition local to a
link.

> Don't forget that a simple ebtables rule could also drop EAPOL if needed.

Indeed, but I'd prefer the bridge to do the right thing in absence of
configuration.

johannes

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)