Control Plane Protection or Control Plane Policing

Control Plane Protection (CPP) or Control Plane Policing (CoPP) is a security mechanism designed to safeguard the control plane of a network device from various types of attacks and resource exhaustion. The control plane is responsible for processing and maintaining the device's routing protocols, management traffic, and other critical functions. CPP/CoPP allows administrators to define and enforce policies to control the rate of incoming control plane traffic, preventing it from overwhelming the device's resources and negatively impacting its ability to function properly. By specifying acceptable thresholds for various types of control plane traffic, such as ICMP, routing updates, or SNMP, CPP/CoPP ensures that essential control plane processes continue to operate efficiently while mitigating the risk of denial-of-service (DoS) attacks and other security threats that target the control plane. This proactive approach enhances the overall security and resilience of the network infrastructure.

Lab:

What is Plane?
Every communicating device i.e., Router, Switch, etc., have two parts, Control-Plane and Data-Plane, we also have Management-Plane, which is nothing but a subset of control plane. Plane usually describes how devices will handle and process the packet it receives.

What is a Control Plane?
Control-Plane, is the brain of the device that carries out all control processing. It handles routing table and updates, Link-state database, Routing protocols like ospf, bgp, etc., Switching Protocols like STP. Similarly, we have Management Plane, that is subset of control plane which handles management traffic like SSH, HTTP, Telnet, etc.

What is a Data Plane?
Data-Plane, is basically the hand of the device that carries out all packet forwarding process. Data plane is also known as Forwarding plane, as it performs ASIC based forwarding that is express forwarding of the packet between the multiple ports of a router. To achieve this, a lot of data plane implementation is done in the hardware. This includes performing CEF based lookups/caching and using port-based ASICs. The FIB, LFIB, Adjacency table are all part of data plane.

What is a CoPP and CPPr and Why do we need it?
To understand why we need CoPP or CPPr, we need to first understand what control-plane does, following are some of the important tasks that Control-Plane does.

Control-Plane is responsible to building and maintaining network tables, for which it would need to send routing updates and keep-alive messages to all active neighbors.
Control-plane also looks after the packet that were not forwarded via CEF in data-plane, for such packets control-plane would need intervene and perform some CPU intensive tasks like checking routing table.
Control-plane also looks after the packets that are destined to the device itself, like management traffic or any type of traffic that comes for the device itself.

Now considering all the above points, let us take a scenario where attacker spoofs itself as a router and forms neighborship with our router and then starts bombarding our router with continuous routing updates, or even worse attacker performs DOS/DDoS on our routers IP. Then in all the scenarios, routers control-plane would be flooded with all unwanted traffic resulting in exhaustion of routers resources. In production environment, to tackle this issue we generally use Control-Plane Policing (CoPP) and Control-Plane Protection (CPPr).

CoPP and CPPr

Control-Plane Policing or CoPP we can control complete access to the entire Control-Plane. If we see the architecture of control plane, with control-plane we have three distinctive sub-interfaces:

Host sub-interface:
This interface looks after the traffic that is directly destined to one of the interfaces (Physical interface as well as Logical interface) of our device.
Transit sub-interface: This interface looks after the traffic that is not directly destined to one of the interfaces of our device but the traffic that is traversing using some control-plane information on our device. Like tunnel traffic transiting via router.
CEF Exception sub-interface:
This interface looks after the traffic that are CEF Exceptions. Non-IP Traffic coming on router, like ARP or CDP, where the device still needs to process the packet and send reply. These exception packets will travel through CEF Exception sub-interface.

With CoPP we can only act on complete control-plane, but we cannot individually act on the specific sub-interface of the control-plane this is where we use CPPr or Control Plane Protection which allows us to take granular action of the control-plane sub-interfaces.

How to Configure Control-Plane Policing

In the following example, we will be configuring policy to limit telnet traffic coming through control plane by using control-plane policy as well as control-plane protection policy.

In our topology, we have R1 router connected to R2, and we will be configuring control-plane policy on R2 router to drop telnet traffic if it exceeds limit of 9000 bits per second.

Step 1: We will be first configuring an access-list on R2 router to identity telnet traffic.

R2(config)#access-list 101 permit tcp any any eq 23

Step 2: In this step, we will configure Class-Map to match the identified traffic.

R2#conf t
R2(config)#class-map Telnet\_Class
R2(config-cmap)#match access-group 101
R2(config-cmap)#exit

Step 3: Now we will create Policy-Map to act on the identified traffic in class-map.
Here our action will be to police the rate by which our control-plane should receive traffic. We will keep limit to be 9000 bits per second, if the rate of traffic is below 9000 bits per second our conform-action will be to permit the traffic but if rate of traffic exceeds the limit then our exceed-action will be to drop the exceeded packets.

R2(config)#policy-map Telnet\_Policy
R2(config-pmap)#class Telnet\_Class
R2(config-pmap-c)#police 9000 conform-action transmit exceed-action drop
R2(config-pmap-c-police)#exit
R2(config-pmap-c)#exit
R2(config-pmap)#exit

Step 4: In this step, we will be configuring Service-Policy Map, to apply the policy-map on our control plane. This will create control-plane policy on our router.

R2(config)#control-plane
R2(config-cp)#service-policy input Telnet\_Policy
R2(config-cp)#exit
\*Nov 27 09:40:03.3: %CP-5-FEATURE: Control-plane Policing feature enabled on Control plane aggregate path

Step 5: In this step, we will be sending telnet traffic from R1 to R2 router and will be verifying the counters on R2 router.

R2#show control-plane aggregate counters
Control plane aggregate path counters :

Feature                  Packets Processed/Dropped/Errors

--------------------------------------------------------
Control-plane Policing          0/0/0

--------------------------------------------------------

R2#

As we see, currently the counters are clear and now let us start generating some telnet traffic from R1 router to R2 router.

R1#telnet 10.0.0.2
Trying 10.0.0.2 ... Open


User Access Verification

Password:
R2>
R2>
---------------------------------------------------------------------------------------------------------

R2#show control-plane aggregate counters
Control plane aggregate path counters:

Feature                  Packets Processed/Dropped/Errors

--------------------------------------------------------
Control-plane Policing         20/0/0

--------------------------------------------------------

R2#

As we can see that the packet processed counters have increased as we have generated traffic for our control-plane.

How to Configure Control-Plane Protection Policy

Similarly, to configure control-plane protection policy. The only change in our configuration will be to apply service-policy map on control-plane host sub-interface rather than applying it on control-plane.

In the same topology as above, we will be first removing the service-policy map and then we will apply the same service-policy map on control-plane host sub-interface, making it control-plane protection policy.

Step 1: In this step, we will be removing service-policy map from control-plane.

R2(config)#control-plane
R2(config-cp)#no service-policy input Telnet\_Policy
\*%CP-5-FEATURE: Control-plane Policing feature disabled from Control plane aggregate path

As we can see that we have successfully removed service-policy map from control-plane, thus disabling control-plane policy.

Step 2: In this step, we will be inserting service-policy map on control-plane host sub-interface.
But before applying policy, let us verify the counters for host sub-interface.

R2#show control-plane host counters
R2#

As we can see above, at present there are no counters for host sub-interface.
Now let us insert service-policy map and verify once again.

R2(config)#control-plane host
R2(config-cp-host)#service-policy input Telnet\_Policy
R2(config-cp-host)#exit
R2(config)#exit
\*Nov 27 10:33:49.165: %CP-5-FEATURE: Control-plane Policing feature enabled on Control plane host path

As we can see above, we have successfully enabled control-plane protection for host sub interface.

Step 3: In this step, we will be sending traffic from R1 router to R2 router and verifying the control-plane host counters.

R2#show control-plane host counters
Control plane host path counters:

Feature                  Packets Processed/Dropped/Errors
--------------------------------------------------------
Control-plane Policing          0/0/0
--------------------------------------------------------
R2#

R1#telnet 10.0.0.2
Trying 10.0.0.2 ... Open

User Access Verification

Password:
R2>
--------------------------------------------------------------------------------------

R2#show control-plane host counters
Control plane host path counters :

Feature                  Packets Processed/Dropped/Errors

--------------------------------------------------------
Control-plane Policing         18/0/0

--------------------------------------------------------

As we can see above, after generating telnet traffic we can now see packets being processed.