Control plane ACL in EXOS

[Paul_Thornton]

Those on here who know me will know that this is something I bring up around once a year; I thought that this time, I'd put it on here to see if we can gather some crowd-support rather than raise another TAC case that goes nowhere.

Extreme is the only serious vendor (and I'm taking them alongside the likes of Cisco, Juniper, Brocade, etc. here) that don't have a decent way to protect the switch control plane (CPU) during normal operation.

Yes, there's all of the 'dos-protect' pps stuff, and that's great at what it does; but that doesn't stop random packets hitting the CPU's bgp, ospf, ssh, snmp etc. processes. The CPU then has to apply its (software) ACL to reject/ignore the connection.

What is missing is that there isn't a way to manually create a 'controlplane.pol' which is applied between the dataplane and CPU, to specifically allow to the CPU and discard everything else. Yes, you need to know what you are doing when creating this policy or you'll break routing protocols etc. That same caveat applies with any vendor.
As a result, anyone using Extreme kit in a service provider environment has devices that are vulnerable to background low-rate attacks from the Internet which do (I have several TAC cases to prove it) cause random kernel panics and/or reboots, and are not seen by dos-protect as they aren't a high pps attack on the switch.

The work around, such that it is, involves building complex ingress port policy files that allow downstream/upstream traffic through the switch but block traffic destined to it - and when you have a switch that's acting as an edge router with maybe 40 IP addresses (v6 and v4), this becomes a support nightmare for day-to-day operations.

I don't think there is a hardware reason why this can't be achieved - the CPU is in essence a logical port on the data plane, but even if the underlying hardware can't do this then surely implementing pf or some other generic Linux firewall in the EXOS kernel would be better than what we have today.

Unfortunately, it seems that Extreme no longer really care about service provider customers - as things like this and other bugs which are specifically painful to the SP community remain un-addressed for years, despite TAC cases and regular polite (and sometimes not so polite) reminders.

Does anyone else agree - or am I the one person in the community who thinks this is an issue?

Paul.

[rfm]

Hi Paul, I was searching for control plane protection on EXOS and end-up at this thread. Do you have any updates on this case? Did you/Extreme find a better solution than regular ACLs as suggested?

[BrandonC]

Hi Paul,

Sorry for the delay in getting back with you. I've looked into this, and it looks like there is not a way to do this currently. However, I have opened up feature request 01174686 for this.

-Brandon

[BrandonC]

Hi Paul,

You can apply an ACL to 'any', which will be applied on all ports and VLANs, which may be a good place to apply an ACL like this.

However, I agree, it would be simpler to just apply the ACL on the link between the switching chip and the CPU, so you don't have to worry about affecting any traffic flowing through the switch. This would also likely be more efficient with regards to ACL hardware utilization.

Let me look into this a little further, and I'll let you know what I find out.

-Brandon

[Paul_Thornton]

Hi Brandon,

Thanks for that. I must confess that I'd forgotten about deny-cpu, and have used it in the past. The very fact that is there means that this should be easily do-able, which is frustrating.

It certainly helps (in that you can, to a degree, stop worrying about the traffic going through the switch and focus on the CPU itself) but it comes with two main issues:

Firstly, there's no single place to apply it between data and control plane so you still have to apply an ACL with the relevant terms on all ingress ports of the switch, and bear in mind that some of these ports or VLANs may require other ACL terms as well, you can end up with a situation where there are multiple policy files to keep in sync manually. There's also the issue of hardware resources when you go here - as I'm always a little worried that in such a scenario, you edit one term on a port with a 'busy' and suddenly you're out of slice capacity. The TAC are great at helping to optimise policy files - and explain how best to do it - but there's finite capacity in the silicon.

Secondly, from a security standpoint, denying things you know about and permitting everything else isn't great.

The first one of these is, to my mind, the bigger problem. You know, for example, that the switch is listening on ports 22, 179, 80 etc. and can have a set of permits at the top of your policy for known sources to anywhere, and then a deny-cpu from anywhere afterwards - first match wins so that should work, and it is a step in the right direction. I'll go and refine my messy ACLs to be slightly neater 🙂

I don't think copy-cpu-off helps here, as I understood it, it only prevents a packet that you've already set 'copy-cpu' on from being mirrored to the CPU (and if the packet is destined only for the CPU, it is functionally equivalent to deny-cpu).

Paul.