The typical focus when dealing with network security is those end systems that are used to hold information, like e-commerce or database systems. But what would happen to the security of these systems if the infrastructure that they rely on to forward their traffic is exploited? These pieces of equipment cannot hide behind a large sophisticated firewall as they are used to forward traffic and must be able to process it without adding considerable delay. Cisco has developed a feature to specifically protect these pieces of equipment from attack: the control plane policing feature. This article takes a looks at this feature, what it is, how it works, and how it can be configured to secure this equipment.
Control Plane Policing Concepts
The control plane policing feature has been developed to protect against attacks focused at these infrastructure devices; the three different types of traffic that are forwarded to the control plane include:
- Routing protocol control traffic
- Traffic destined for an IP address that is assigned to the device
- Traffic that comes from management protocols like Simple Network Management Protocol (SNMP), Telnet, and secure shell (SSH)
To best mitigate for the different types of attacks that are possible, an architecture needed to be developed that was useable with many different products and allowed for a security mechanism that secured for these different types of attack. This architecture was designed to treat the control plane as a separate entity with its own input and output ports. The layout for this architecture is shown in Figure 1.
)
This architecture includes four main components:
- Control Plane—The control plane is a collection of processes that are run on the device at the process level of the Route Processor (RP) and provides high-level control for most Cisco IOS functions.
- Central switch engine—The central switch engine is a device that is responsible for the high-speed routing of IP packets; it is also typically used to provide high-speed input and output services to non-distributed interfaces.
- Distributed switch engine (line cards)—The distributed switch engine is responsible for the high-speed switching of IP packets on distributed line card without using the resources of the central switch engine; it is also used to provide high-speed input and output services to the distributed interfaces on the line card.
- Non-Distributed line cards—These non-distributed line cards are responsible for receiving packets and occasionally perform input and output services, all packets on these line cards are forwarded to the central switch engine.
There are two separate paths that traffic can take when being routed to the control plane: a distributed path and a non-distributed path. With this in mind, two different levels of control plane policing were developed: one called aggregate control plane services that subjected all control plane traffic to a set of policies, and a second called distributed control plane services that allowed a set of policies to be applied to specific distributed line card. Keep in mind that regardless of whether traffic goes through a distributed line card or not, it will always be subject to aggregate control plane services. Figure 2 shows an example of how traffic destined for the control plane is processed when using distributed and non-distributed line cards.
)
Both of these different services can be used to either police or drop (on most devices) traffic that matches a configured policy. To define this policy, the Modular Quality of Service Command-Line interface (MQC) is used; this configuration is shown in the next section.
Control Plane Policing Configuration
The first thing that needs to be reviewed is the MQC and how it is used to implement control plane policing. The MQC provides a commonly used method of implementing a policy using a three-part configuration process:
- Class map creation—A class map is used to classify the traffic that will be subject to the configured policy. To perform this, a number of different match commands have been developed; the common match commands used with control plane policing include match access-group, match ip dscp, match ip precedence, and certain match protocol commands.
- Policy map creation—A policy map is used to specify the policy action that will be taken against a specific class of traffic (as specified by the class map).
- Application of a policy map—A policy map is then applied; when using control plane policing, this policy is applied directly to the control plane (aggregate) or to a specific distributed line card (distributed).
The steps that are required to create a class-map, policy-map, and to apply either aggregate or distributed control plane policing on a supporting device are shown in Table 1.
|
Step 1 |
Enter global configuration mode. |
router#configure terminal |
|
Step 2 |
Enter class map configuration mode. |
router(config)#class-map [match-any | match-all] class-map-name The default method of matching is to match all statements that are configured. |
|
Step 3 |
Configuring the matching criteria. |
router(config-cmap)#match ... There are a number of different match commands that can be used. |
|
Step 4 |
Enter policy map configuration mode. |
router(config-cmap)#policy-map policy-map-name |
|
Step 5 |
Specify the class-map to use to match traffic for this policy. |
router(config-pmap)#class class-map-name |
|
Step 6 |
Specify a policy action. |
router(config-pmap-c)#police rate [burst-normal] [burst-max] conform-action action exceed-action action [violate-action action] The rate is specified in either bytes per second (bps) or packets per second (pps); the valid range for bps is 8000 through 10000000000 and for pps is 2000000. or router(config-pmap-c)#drop |
|
Step 7 |
Enter control plane configuration mode. |
Aggregate control plane policing: router(config-pmap-c)#control-plane or Distributed control plane policing: router(config-pmap-c)#control-plane [slot slot-number] |
|
Step 8 |
Apply the configured policy map to the control plane. |
Aggregate control plane policing: router(config-cp)#service-policy {input | output} policy-map-name Note: Output policing is done in silent mode with no error messages being sent or Distributed control plane policing: router(config-cp)#service-policy {input} policy-map-name |
|
Step 9 |
Exit to privileged mode. |
router(config-cp)#end |
Summary
The real tricky part of control plane policing configuration is the understanding of how a policy is created with the MQC. As the MQC is used for a number of different features other than control plane policing feature, learning how it works is well worth the time. With infrastructure devices being a big target for those looking to exploit networks, the implementation of a method to protect the control plane on these devices directly is vital. Hopefully this article has provided a starting point in learning what is possible with this feature and how it can be used to protect these network devices.