Core Routing Security: Protecting the Control Plane

What is the control plane and why protect It?

Core networks, such as the ones you'll find in service providers, large enterprises and public-sector backbones, offer plenty of fashionable security measures such as AI-driven anomaly detection, advanced encryption techniques and automated policy compliance. Yet behind these hot topics lies one of the most essential—and often overlooked—lines of defense: control plane protection.

The control plane—in simple terms—is the brain of a router. Its responsibilities include communicating with adjacent routers, making routing decisions and enforcing routing policies. These functions are handled by the router's CPU. The control plane eventually programs specific routing instructions into the data plane, where specialized chipsets (Forwarding ASICs) perform packet forwarding in hardware, with little-to-no "thinking."

Historically, core routing networks have often overlooked the importance of protecting the control plane.  This mistake stems from the common assumption that core networks are implicitly safe—shielded by the physical security of air-gapped backbones and the innocuous nature of internal routing adjacencies with trusted peers. This mindset persists today, despite a rapid expansion of attack surfaces and the sophistication of tactics that exploit routing protocols.

Fortunately, protecting the control plane is one of the easiest and most effective measures to implement on a core routing network.  Before implementing more advanced security features, every core backbone should first implement control plane protection as a basic security control.

Built-in defenses are good but not comprehensive  

Some of today's carrier-grade operating systems increasingly implement control plane protection as a default mechanism.  Some examples include Cisco IOS-XR Local Packet Transport Services (LPTS) and Juniper JunOS ddos-protection. These frameworks are active out-of-the-box and don't require any configuration or setup. They work by rate-limiting traffic destined for the router's control plane, preventing CPU overload that could cause a cascade of issues.

If you're running a Cisco- or Juniper-based core backbone, then you may not even notice this protection—yet it's quietly working behind the scenes to protect your control plane.

But while these built-in defenses are a great feature, they are not a substitute for operational awareness or intent.

A three-step approach to robust control plane protection

Step 1: Gain awareness and identify gaps

Even if your core routers do have some built-in control plane protection, it's likely not optimized to your specific set of protocols and use cases. To achieve robust protection, you need to comprehensively understand what your "normal" looks like.  Stop and consider the types of control plane traffic that you'd expect to see:

1. What routing protocols does the router use to communicate with its neighbors, such as IS-IS, OSPF, LDP, RSVP and BGP?
2. What management protocols do you use to communicate with the router, such as SSH, SNMP, TACACS/RADIUS, NTP and Syslog?
3. What diagnostic tools do you employ, such as ICMP and traceroute?
4. What network discovery protocols are in use, such as ARP, DHCP relay and LLDP?

Auditing this traffic can be done with rudimentary tooling such as logging, SNMP, flow records or passive packet capture.  You can even deploy bare-bones filters that are set to "log" unauthorized traffic rather than drop it—a very helpful way to discover any unexpected control plane traffic.

Once you've narrowed down the types of legitimate control plane traffic on your routers, you can better evaluate what your threat vectors are. For example, are you susceptible to IGP floods? BGP session hijacks? Spoofed packets that target router interfaces? Network reconnaissance that uses traceroute?

Understanding the behavior of your control plane is a critical step in knowing how to protect it.

Step 2: Classify and prioritize

In order to achieve effective control plane protection, you must be able to classify your control plane traffic into meaningful groups that can be prioritized appropriately. Consider the following four categories which we just referenced above (these four categories form a good baseline of prioritization, but your mileage may vary).

1. Routing protocol traffic – Typically, the routing protocols are treated with the highest priority because loss of a routing process such as IS-IS, OSPF or BGP is extremely likely to cause network disruption.
2. Management traffic – After routing protocol traffic, management traffic is the next-most critical control plane function, as it allows us to interact with the router for diagnostics and troubleshooting. This includes more than just SSH—it also includes "southbound interface" traffic coming from centralized controllers, such as SNMP or NetConf.
3. Diagnostic traffic – When things go wrong, your diagnostic tooling becomes critical. Therefore, it's reasonable to classify this traffic (like ICMP) above the default.
4. Discovery traffic – ARP is one of the great unsung heroes of computer networking—and if it stops working then packets stop flowing. Given its outsized importance, this discovery traffic should be thoughtfully prioritized somewhere above the default.

You may also come across unexpected control plane traffic—things like unsolicited TCP requests—that should be closely examined and possibly dropped or heavily policed.

Step 3: Take action and monitor

Once you've successfully identified your control plane traffic and strategically prioritized it, you can then define ACLs or filters that can apply rate limits, monitor traffic flows or identify anomalies. These filters can be applied to the router's logical system interface or, in some cases, directly to the control plane context.

One of the easiest ways to get started is to apply filtering rules that do not explicitly drop traffic but instead use counters and logs, providing you with a way to regularly inspect the results and discover unexpected traffic. You might be surprised at just how many different protocols are hitting your loopback or system IPs, or how often traffic bursts are happening.  After observing these filters in action for a while, you can then confidently apply rate-limiting or dropping actions.

Monitoring the health and security of your control plane should be an ongoing activity. As your routing architecture evolves, your strategy to protect the control plane should evolve with it. This means regularly reviewing and updating policies, including documentation.

Because ultimately, control plane protection is much more than a simple command or an out-of-the-box framework—it's a mindset of visibility and vigilance to protect what matters most.