[c-nsp] All multicast punting to CPU on 6500

[Phil Mayers]

On 12/16/2012 04:49 PM, Robert Williams wrote:
> Hi,
>
> I'm sensing a lot of frustration / anger / hatred for NLB, having
> never really used it myself I'll just back away from that quietly :)

Hehe...

> Unfortunately the test is valid because the situation actually arose
> when a Windows NLB cluster went offline and there was a load of DDoS
> traffic heading to it. The whole reason I'm even working on this is
> because it 'did' happen, unfortunately...

Sure. However, a couple of things to note:

1. You haven't specified if you're using static ARP *and* static mac 
address table entries for the MS NLB MACs, as per the URL Tony linked 
to. This is essential, and note the 6500-specific items at that URL.

I'm assuming you have the static ARP entries because IOS won't respond 
to a dynamic ARP with a multicast mac, but maybe you don't have the 
static MAC entries, which was causing the CPU punt?

2. In response to your more general question about how to block this 
kind of thing, it's worth noting that there are more types of ACL on the 
box than CoPP! Specifically CoPP has limitations on the sup720 that mean 
it can only do unicast IPv4 in hardware.

You may find an actual ACL on an physical interface fares better; since 
you said you didn't want multicast at all, possibly a MAC ACL blocking 
the IPv4 and IPv6 multicast MACs?

>
> However, aside from <cough> NLB, what stops a compromised device from
> being used to emit such traffic maliciously?

Nothing. Sadly, every router in the world can be destroyed with a little 
ingenuity by a directly-attached client. This annoys me - it doesn't 
seem so terribly hard to stop this. But hardware-based platforms are 
often not fully general, and aren't flexible enough to do what is needed 
(essentially microflow policing of all CPU-punts with a "key" of input 
interface, source mac/ip/port).

However, an alternative way of answering that question is: you stop it, 
by way of your operations, administration and management, and your 
policies stop it, by way of letting you disconnect the host. 
Unsatisfactory I know - where is the "Cisco self-defending network" when 
you need it ;o)

> In the colocation world we have seen examples where the attacker just
> rents a couple of VPS instances with the same provider as their
> target and uses it to take down the target from the 'inside' by
> messing with the providers' infrastructure.

That is genuinely interesting and scary. Particularly given the woeful 
security features on most equipment, that is very hard to defend against 
in general. I don't suppose there's any public write-up of such an 
instance, that you know of?

It goes without saying that untrusted customers should be on separate 
layer2 networks, but that only solves some problems.

> The (two lines in linux) example I was testing with would be a nice
> way to do this, at least until the provider tracks it down and pulls
> it. Which in itself could be tricky if the CPU is maxed out and/or
> your traffic graphing shows only 'unicast' traffic PPS, thus is blind
> to multicast.

These are all excellent points, and I share your frustration - network 
devices that crap out inexplicably due to external load, and don't even 
log info that hints at the cause, drive me crazy.

But they're in the majority, sadly :o(

Cheers,
Phil