Source MAC address spoofing DoS attack

The flooding attacks (or mishaps) on large layer-2 networks are well known and there are ample means to protect the network against them, for example storm control available on Cisco’s switches. Now imagine you change the source MAC address of every packet sent to a perfectly valid unicast destination.

The switches receiving your traffic would try to learn every new MAC address and would quickly run out of TCAM. For example, Catalyst 3560 can hold up to 12.000 MAC addresses; after that, older (but perfectly valid) MAC addresses would be removed from TCAM and traffic sent to them would be flooded throughout the network (and hitting storm control limits). If I did the math right, you need less than 100 milliseconds to saturate the MAC address table on that switch using 100 byte frames on a 100 Mbps link.

You can easily prevent this attack in an enterprise environment, where you can use security features like secure MAC addresses, but you can’t use the same trick in a Service Provider environment, where you have to allow your Carrier Ethernet customers to use whatever MAC addresses they like. If your Carrier Ethernet gear supports 802.1ah (Provider Backbone Bridges; MAC-in-MAC encapsulation), the attack affects only the access switches connected to the same I-SID (customer); the backbone switches never see customer’s MAC addresses. If you use 802.1ad (Q-in-Q encapsulation), all L2 switches that see the spoofed packets are affected.

There are at least two safeguards against this attack: limit the number of source MAC addresses per port or limit the MAC address learning rate per port. I’m not sure which switches have security features along these lines, but I know many vendor engineers read my blog, so please feel free to describe what your gear can do in the comments. Thank you!

3 comments:

  1. Dmitri Kalintsev16 August, 2011 10:37

    Ivan,

    A few points, I guess. Firstly, I sincerely hope not too many SPs today use enterprise gear for their networks nowadays, which means it is either MPLS/VPLS or MAC-in-MAC; in my experience it is the former in most cases. However, older access networks could well still be using Q-in-Q, and there the the issue may well be present.

    Very common way of dealing with the threat in question that I've seen is limiting the number of MACs an SP service would learn from a UNI to something small, like 5. It is pretty non-disruptive from customer's point of view - even if you exceed the limit, you are still reachable (via flooding - see note on rate limiting below), and if traffic volume is small many people wouldn't even notice. Also it is very common to connect L2 services to routers (so no problem there in first place).

    > traffic sent to them would be flooded throughout the network (and hitting storm control limits)

    Depends on configuration - storm control limits are often applied to broadcast separately from unknown unicast and yet separately from multicast, which means that while broadcast storm controls may be in place (which is a common practice), unknown unicast controls may be not.

    Also I don't think flooding will happen throughout the network - as far I can remember overflowing TCAM doesn't overwrite port VLAN membership configuration, so flooding will likely be contained with a particular VLAN - CE-VLAN or S-VLAN.

    ReplyDelete
  2. We use port security and storm control. Our L2VPN services are sold as a service you must connect a router to, and only allow 8 MAC addresses on the UNI.

    ReplyDelete
  3. I came up against questions like these a few years back running a metro-e service provider. We often found that the mac limit per port would cause customers to have issues when they'd accidentally bridge something to their WAN (happens more than you might like to think) and the routers would periodically drop out as too many things started broadcasting. There's basically no way to tell the difference between an attack and customers doing something stupid. But the Q-in-Q core and some decent security on the edge let it scale enough to end up deploying the whole thing over MPLS/VLL so I guess from that point of view it was sufficient.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.