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: <20150105221034.0f69d6fd@urahara>
Date:	Mon, 5 Jan 2015 22:10:34 -0800
From:	Stephen Hemminger <stephen@...workplumber.org>
To:	Bernhard Thaler <bernhard.thaler@...et.at>
Cc:	davem@...emloft.net, bridge@...ts.linux-foundation.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH 1/1] bridge: remove BR_GROUPFWD_RESTRICTED for arbitrary
 forwarding of reserved addresses

On Tue,  6 Jan 2015 01:56:15 +0100
Bernhard Thaler <bernhard.thaler@...et.at> wrote:

> BR_GROUPFWD_RESTRICTED bitmask restricts users from setting values to
> /sys/class/net/brX/bridge/group_fwd_mask that allow forwarding of
> some IEEE 802.1D Table 7-10 Reserved addresses:
> 	(MAC Control) 802.3		01-80-C2-00-00-01
> 	(Link Aggregation) 802.3	01-80-C2-00-00-02
> 	802.1AB LLDP			01-80-C2-00-00-0E
> BR_GROUPFWD_RESTRICTED may have been set as an extra protection against
> forwarding these control frames as forwarding 802.1X PAE (01-80-C2-00-00-03)
> in 802.1X setups satisfies most common use-cases.
> Other situations, such as placing a software based bridge as a "TAP" between two
> devices may require to forward e.g. LLDP frames while debugging network problems
> or actively changing/filtering traffic with ebtables.
> 
> This patch allows to set e.g.:
> 	echo 65535 > /sys/class/net/brX/bridge/group_fwd_mask
> which sets no restrictions on the forwardable reserved addresses.
> 
> - the default value 0 will still comply with 802.1D and not forward any
>   reserved addresses
> - values such as 8 for forwarding 802.1X related frames will behave the
>   same way as with BR_GROUPFWD_RESTRICTED currently in place, so backward
>   compatibility to current scripts using group_fwd_masks shoudl be possible
> 
> Administrators and network engineers however will be able to arbitrarily
> forward any reserved addresses without BR_GROUPFWD_RESTRICTED. This will
> be non-standard compliant behavior, but forwarding of any reserved address
> right from the beginning is. Users should be aware of this anyway and
> know what/why they are doing when setting values such as 65535, 32768, 16384,
> 4, 2 for group_fwd_mask
> 
> This patch was tested on a bridge with two interfaces created with bridge-utils.
> 
> Signed-off-by: Bernhard Thaler <bernhard.thaler@...et.at>

I am ok with forwarding LLDP because some people need it.
But allowing forwarding STP or PAUSE frames is bad.

We don't let people do things that break networks. Other examples
already exist like set all 0 ethernet addresses, or the restrictions
on allowing net 127 in IP addresses.
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ