Is the the Unknown Unicast Flooding Attack still exists in Software Defined Networking.

If not, how it was eliminated ?

1 Answer 1


The short answer is, it is software defined :-)

Let's unpack your question. An Unknown Unicast in a transparently bridged network is one who's destination MAC address isn't known. In transparent bridging we flood that out all interfaces. That address will reach the MAC address of interest (assuming it exists) and when that computer responds we'll see that MAC address in the source address of a ethernet frame and can record the port it was seen on.

Importantly, that Unknown Unicast MAC address requires a entry in the TCAM of the switch.

An Unknown Unicast Attack is when we send so many never-before-seen MAC addresses that the Unknown Unicast portion of the TCAM of the switch is filled with these rubbish addresses, and as the TCAM ages out the real MAC addresses then those real MAC addresses are fighting against the odds to be reinstated.

We can of course take measures against this in a switch. For example, by preferring established MAC address entries in the TCAM.

Now if we are using SDN to implement transparent ethernet bridging then the problem remains. The controller still has a table of MAC addresses, and we are filling the OpenFlow-switch with lots of rubbish (match, action) rules. Furthermore the OpenFlow traffic from the switch to the controller and the rate of change of (match, action) rules might begin to be an issue.

But we don't have to use SDN to implement transparent ethernet bridging. We could implement something which has the same effect without using the same mechanism. As a really simple example, the provisioning system could configure the SDN controller with the location of every MAC address. Then there is no Unknown Unicast processing at all, as all Unknown Unicasts are invalid and can be dropped immediately. Or we could do away with MAC addresses altogether, and simply configure the lower bytes of the IP address into the MAC address of the ethernet interfaces. The SDN controller application would then essentially route, with no ARP.

Or to take a wide area problem, if we are providing a metro ethernet service then we can simply encapsulate the received packet at the A-end client-facing interface, use our own MAC addressing to deliver it across our network to the B-end client-facing interface, and transmit the packet. Not looking into the customer's MAC addressing at all. You can see that this approach could also be used within data centre networking, and there are a variety of "tunnelling" schemes. Such tunnels mean that whatever the host claims as its MAC addressing is irrelevant, the network uses its own addressing which the host can't influence. So an unknown unicast attack is moot.

Finally, an important practical consideration is that the SDN controller can scoff at ISO layering. If someone is having a go at an attack, and that attack can be detected from the upper layers (eg, by an intrusion detection system) then the OpenFlow Controller can be told block that class of flows from ever being switched. It's these "whole of network synergies" which make SDN much more interesting than simply reimplementing transparent ethernet bridging. To date the synergy of interest has been datacentre provisioning, but there's obviously lots of untapped scope in internet networks.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.