Securing the Control Plane Overview
Control Plane Traffic
Control plane security enables you to filter or rate-limit unwanted traffic that is transmitted from the forwarding plane to the control plane. In RBFS, you can use Access Control Lists (ACL) and policers to secure the router’s control plane.
All routing protocols, management protocols, service protocols run in the control plane. The output of these protocols result in certain databases like routing table, MAC table, ARP table, etc., which eventually get programmed in the forwarding plane.
In the diagram above, you see the routing protocols (BGP, OSPF, ISIS), management protocols (SSH, RESTCONF, etc), service protocols (RADIUS, NTP, TACACS+), and access protocols (PPPoE, DHCP, L2TP, PPP) associated with the control plane. The control plane is generally implemented in software by using general-purpose processors. These protocols typically build a large number of databases like routing, switching, and ACL tables.
In contrast, a forwarding plane is associated with a copy of the databases (Routing, Switching, ACL, etc) built by the control plane. These entries typically contain the match and action which decide the packet flow in the forwarding plane. The forwarding plane functionality is realized in high performance Application Specific Integrated Circuits (ASICs) that are capable of handling very high packet rates.
There are two kinds of traffic:
-
Control traffic: Control traffic is destined to the device itself, that means, packets are handled by the router itself. The traffic is classified as control traffic based on matching destination IP, or because of ACL rules, or because of some kind of exception that occurred while parsing the packet (non-acceptable fields, TTL expiry, etc).
-
Transit traffic: Transit traffic not destined to the device itself. These packets will be sent out on one of the routers physical interfaces.
All control traffic packets will be destined to the CPU port(s). These packets are redirected to the control plane for further processing. However, general purpose processors in the control plane are not designed for packet processing, and might get overloaded if the rate of control plane traffic is too high, for example caused by a DDoS attack. Therefore you should to protect the router control plane by implementing mechanisms to filter completely or rate-limit traffic not required or unwanted at the control plane level.
Securing the Control Plane
In RBFS, there are two fundamental mechanisms how control-plane traffic is redirected to the CPU:
-
Via protocol ACLs
-
Via route lookup
Both mechanisms need to be considered and secured separately, as described in the following sections.
Control Plane Traffic via Protocol ACLs
All routing protocols (BGP, OSPF, ISIS), management protocols (SSH, RESTCONF, etc), service protocols (RADIUS, NTP, TACACS+), and access protocols (PPPoE, DHCP, L2TP, PPP), if enabled by configuration, automatically create Access Control Lists (ACLs) required to punt the protocol traffic to the control plane CPU. ACLs are the building block for securing the control plane. An ACL defines a rule, which typically contains match conditions and actions. If a packet matches the rule conditions, the associated actions will be applied. Protocol ACLs do not need to be defined by configuration. Another benefit is, they are very specific, for example match on auto-discovered IPv6 link-local neighbors. The protocol ACLs can verified using the 'show acl (detail)' command.
Example 1: Protocol ACL created by LLDP
supervisor@rtbrick: op> show acl detail Rule: lldp.ifp-0/0/1.trap.rule ACL type: l2 Ordinal: - Match: Attachment point: ifp-0/0/1 Direction: ingress Destination MAC: 01:80:c2:00:00:0e Action: Redirect to CPU: True Result: Trap ID: LLDP <...>
Example 2: Protocol ACL created by RADIUS
supervisor@rtbrick: op> show acl detail Rule: radius-srv1-v4-auth-trap ACL type: l3v4 Ordinal: - Match: Source L4 port: 1812 IP protocol: UDP Action: Redirect to CPU: True Result: Trap ID: Radius <...>
By default, for most of the control protocols, there is a single action Redirect to CPU: True. Thereby all traffic matching the match criteria gets punted to the CPU without any rate limit. There is one exception, for PPPoE only the traffic is rate-limited by default. As shown in the following example, there is an additional action Policer profile name: created by default that limits the PPPoE traffic to 50 Mbps per session:
Example 3: Protocol ACL with Policer created by PPPoE
supervisor@rtbrick: op> show acl detail
Rule: pppoed_hostif-0/0/1_7-7-1-4090_8863
ACL type: PPPOE
Ordinal: -
Match:
Attachment point: ifl-0/0/1
Ethertype: 34915
Action:
Redirect to CPU: True
Policer profile name: _DEFAULT_POLICER_50_MB
Result:
Trap ID: PPPoE
<...>
For all other protocols, rate limiting needs to enabled by configuration in order to secure the control plane. This is described in section 2.1 below.
Control Plane Traffic via Route Lookup
By default, any other traffic destined to one of the router’s IP addresses, commonly referred to as "my IP", and not matching any ACL is redirected to the CPU via a route lookup. This applies to loopback as well physical interface addresses. In order to secure the control plane against malicious traffic sent to one of the router’s IP addresses (not matching any protocol ACL), ACLs need to be defined by configuration. In RFBS, such "manually" created ACLs are referred to user-defined ACLs.
Typically you will want to completely block some unwanted traffic sent to "my IP", but allow and rate-limit some required traffic like for example ICMP. Please note, when designing the security ACLs to protect "my IP", you do NOT need to consider the protocol traffic already handled by the protocol ACLs.
When configuring ACLs, protocol ACLs and user-defined ACLs may conflict. For example, an ACLs created by the BGP routing protocol might match on TCP traffic sent to the routers loopback address with port 179. A user-defined ACL however might deny any traffic sent to this loopback address. In this case, protocol ACLs shall take precedence over user-defined ACLs, so that you do not accidentally break the protocol operation. In RBFS, this is implemented using different ACL database priorities.
Configuring ACLs to protect "my IP" is described in section 2.2 below.
Limitations and Notes
-
The control-plane security features are supported on hardware platforms. They are not supported on virtual deployments.
-
On the Edgecore AS5916-54XKS platform, BGPv6 with link-local peering uses route lookup instead of protocol ACLs. Therefore traffic sent to IPv6 link local addresses cannot be restricted via ACL to not break BGPv6 link-local peerings.