Control Plane Security Configuration
As highlighted above, there are two fundamental mechanisms how traffic is redirected to the CPU, via protocol ACLs, and via route lookup. These are addressed in following two sections.
Secure Control Plane Traffic via Protocol ACLs
This section describes the configuration options for control plane traffic that is redirected to the CPU via protocol ACLs. These ACLs are automatically created by the protocols, and do not need to be - and cannot be - configured manually. For example if you configure a routing protocol like BGP, the required ACLs to match and punt the BGP packets to the control plane are created automatically.
Enabling the Control Plane Security Feature
By default, all packets matching the protocol ACLs will be sent to the control plane without any rate limit, except for PPPoE. The RBFS Control Plane Security feature allows to add policers to all protocol ACLs. If enabled, this feature creates a set of default policers, and applies them to the protocol ACLs. Thereby the control plane gets secured against DDoS attacks matching these ACLs.
Syntax:
set forwarding-options control-plane-security <attribute> <value>
Attribute | Description |
---|---|
state (enable|disable) |
Enable or disable the control-plane security feature. Default: enable. |
Example:
{ "rtbrick-config:forwarding-options": { "control-plane-security": { "state": "enable" } } }
Configuring Host Path QoS
The host-path-qos enable
feature is disabled by default. Once it is enabled, you cannot disable it.
To enable the `host-path-qos' feature, enter the following command:
Syntax:
set forwarding-options class-of-service control-plane-qos ingress-qos <attribute> <value>
Attribute | Description |
---|---|
state (enable|disable) |
Enable or disable the host path QoS feature. Default: disabled. |
Example
supervisor@rtbrick>LEAF01: cfg> show config forwarding-options class-of-service control-plane-qos { "rtbrick-config:control-plane-qos": { "ingress-qos": { "state": "enable" } } }
By enabling this feature, the default scheduler and queue configurations are installed and the CPU ports queue mapping will change. Also, all control plane ACLs will be reprogrammed to update action_forward_class
.
Marking Outbound Control Plane Traffic
RBFS enables you to configure the various protocols to mark the egress control plane traffic. The control plane traffic can be marked with type-of-service (ToS) values.
|
Option | Description |
---|---|
<protocol-name> |
Specifies the protocol name. |
<remark-type-value> |
Specifies the remark type value that can be p-bit or tos. |
<codepoint-value> |
Specifies the codepoint value. The supported range for p-bit outbound-marking is 0-7. |
Example: Marking Outbound CP Traffic Configuration
supervisor@rtbrick>LEAF01: cfg> show config { "ietf-restconf:data": { "rtbrick-config:forwarding-options": { "class-of-service": { "control-plane-qos": { "outbound-marking": { "protocol": [ { "protocol": "bgp", "remark-type": "tos", "codepoint": 192 }, { "protocol": "dhcp", "remark-type": "p-bit", "codepoint": 5 }, { "protocol": "l3-all", "remark-type": "tos", "codepoint": 224 }, { "protocol": "igmp", "remark-type": "p-bit", "codepoint": 7 }, { "protocol": "igmp", "remark-type": "tos", "codepoint": 192 }, { "protocol": "ppp", "remark-type": "p-bit", "codepoint": 7 }, { "protocol": "ppp", "remark-type": "tos", "codepoint": 192 }, { "protocol": "radius", "remark-type": "tos", "codepoint": 100 } ] } } } } } }
Marking of Outbound Control Plane VLAN P-bits for ARP/ND
You can configure VLAN P-bit marking for ARP and ND packets in outbound control plane traffic.
When a user configures the p-bit for both the ARP protocol and "l2-all," the setting for the ARP protocol takes priority. If the p-bit for the ARP is removed, the system will then apply the "l2-all" configuration. This same behavior applies to the ND protocol as well. |
Syntax:
set forwarding-options class-of-service control-plane-qos outbound-marking protocol <protocol> p-bit codepoint <codepoint>
Example: Configuring p-bit for ARP/ND
set forwarding-options class-of-service control-plane-qos outbound-marking protocol arp p-bit codepoint 5 set forwarding-options class-of-service control-plane-qos outbound-marking protocol nd p-bit codepoint 4
Example:
"rtbrick-config:forwarding-options": { "class-of-service": { "control-plane-qos": { "outbound-marking": { "protocol": [ { "protocol": "arp", "remark-type": "p-bit", "codepoint": 5 }, { "protocol": "nd", "remark-type": "p-bit", "codepoint": 4 } ] } } } }
Configuring Control Plane QoS Per IFP
The marking of control plane packets can be configured on a per-IFP basis for PPPoE, whereas it was previously set globally for each protocol in earlier releases of RBFS.
The priority of p-bit/ToS settings is processed in this order: IFP (highest), protocol level, and l2-all/l3-all (lowest). |
The table below shows each protocol’s supported QoS types and IFP support.
Protocol | QoS Type Supported | Support for IFP-based QoS |
---|---|---|
BGP |
tos |
No |
OSPF |
tos |
No |
LDP |
tos |
No |
ISIS |
p-bit |
No |
IPoE |
tos |
No |
DHCP Relay |
p-bit |
No |
RADIUS |
tos |
No |
PPPoE |
p-bit/tos |
Yes (only p-bit) |
IGMP |
p-bit/tos |
No |
L2TP |
tos |
No |
ARP/ND |
p-bit |
No |
PIM |
tos |
No |
Syntax:
set forwarding-options class-of-service control-plane-qos outbound-marking protocol <protocol-name> [p-bit / tos] ifp <ifp-name> codepoint <codepoint>
Configuration Example:
supervisor@rtbrick>: cfg> set forwarding-options class-of-service control-plane-qos outbound-marking protocol ppp p-bit ifp ifp-0/0/1 codepoint 3 supervisor@rtbrick>: cfg> set forwarding-options class-of-service control-plane-qos outbound-marking protocol ppp p-bit ifp ifp-0/0/2 codepoint 4 supervisor@rtbrick>: cfg> commit
The example below shows the result of the configuration.
"rtbrick-config:forwarding-options": { "class-of-service": { "control-plane-qos": { "outbound-marking": { "protocol": [ { "protocol": "ppp", "remark-type": "p-bit", "ifp": [ { "ifp": "ifp-0/0/1", "codepoint": 3 }, { "ifp": "ifp-0/0/2", "codepoint": 4 } ] } ] } } } }
Viewing Control Plane QoS Details
The command shows qos control-plane displays QoS remarking types, interface names, and codepoints for all or specified protocols.
The following example displays QoS control plane information for the protocol 'ppp'.
supervisor@rtbrick>: cfg> show qos control-plane protocol ppp Protocol Remark Type Interface Codepoint ppp p-bit all 5 ifp-0/0/1 3 ifp-0/0/2 4
Restricting Management Access
If you enable inband management access for example via SSH, protocol ACLs will be created that match on the enabled protocols and redirect the management traffic to the control plane. By default, this traffic is not restricted in terms of source IP addresses. You can optionally restrict management access to trusted IP addresses by applying a source prefix list. An additional match condition will then be added to the protocol ACLs for inband management.
Configuring a Prefix List
Syntax:
set forwarding-options prefix-list <options>
Option | Description |
---|---|
<prefix-list-name> ipv4-prefix <ipv4_prefix> |
Prefix list configuration for IPv4. |
<prefix-list-name> ipv6-prefix <ipv6_prefix> |
Prefix list configuration for IPv6. |
Applying a Prefix List
Syntax:
set inband-management instance <instance-name> source-prefix-list <list-name>
Example: Inband Management Configuration with Source Prefix List
"rtbrick-config:inband-management": { "instance": [ { "name": "default", "ssh": "true", "ntp": "true", "source-prefix-list": "list1" } ] }, "rtbrick-config:forwarding-options": { "prefix-list": [ { "prefix-list-name": "list1", "ipv4-prefix": [ { "ipv4-prefix": "198.51.100.100/24" }, { "ipv4-prefix": "198.51.100.33/24" }, { "ipv4-prefix": "198.51.100.44/24" } ] }
The inband management is provided to only the source address specified in the prefix list if the prefix list is configured. If the prefix list not configured, it works for all source IPs. Also, the prefix addresses configured should be of /32. |
Configuring Protocol ACL Options
This section describes how to configure policers per protocol and configure match on IPv4 ToS or IPv6 TC fields for protocol ACLs.
|
Syntax:
set forwarding-options control-plane-security protocol <protocol-name> <attribute> <value>
Option | Description |
---|---|
protocol <protocol-name> |
Name of the protocol. You can configure individual protocols, and/or all protocols using the 'ALL' value keyword. |
match-tc <tc-value> |
Configure IPv6 TC value. The range is 0 to 248. |
match-tos <tos-value> |
Configure IPv4 ToS value. The range is 0 to 248. |
policer <policer> |
Configure policer name. |
Example:
{ "ietf-restconf:data": { "rtbrick-config:forwarding-options": { "class-of-service": { "policer": [ { "policer-name": "_DEFAULT_POLICER_BGP_LL", "flags": "color-blind", "level1-rates": { "cir": 1000, "cbs": 1000, "pir": 1200, "pbs": 1000 }, "levels": 1, "type": "two-rate-three-color" } ] }, "control-plane-security": { "state": "enable", "protocol": [ { "protocol": "PIM", "policer": "_DEFAULT_POLICER_PIM", "match-tos": 192, "match-tc": 120 } ] } } } }
Secure Control Plane Traffic via Route Lookup
This section describes the configuration to secure the control plane for traffic that is redirected to the CPU via route lookup. Any packet sent to one of the router’s IP addresses ("my IP") and not matching any ACL, will be redirected to the CPU via route lookup. By default this type of traffic is not restricted or rate-limited. In order to secure the control plane, you need to apply ACLs by configuration. Please note you do not need to consider and allow any protocol traffic that is already captured by the automatically created protocol ACLs. You only need to explicitly define rules for any other traffic sent to "my IP". In the simplest case, you can deny any other traffic sent to the router. Typically you will want to allow some additional traffic like ICMP, and deny anything else.
Configuring ACLs
This section describes how to configure ACLs to secure the control plane to protect "my IP". In RFBS, ACLs are applied globally, that is, you do not need to attach them by configuration. Besides, for ACLs matching traffic sent to one of the router’s IP addresses, the redirect-to-cpu
action applies implicitly and does not need to be configured.
Syntax:
set forwarding-options acl <options>
Option | Description |
---|---|
l3v4 |
ACL configuration for IPv4 |
l3v6 |
ACL configuration for IPv6 |
rule <rule-name> |
Name of the ACL rule |
ordinal <ordinal-value> |
Number of the configuration entry. Please note the order of the configuration entries (ordinals) does not determine the processing. |
match <condition> |
Supported match conditions are IP source/destination prefix, prefix lists, source/destination Port, IP protocol, and direction. |
action <action> |
Supported actions are permit, drop, and police. |
priority <value> |
ACL entry priority. Determines the processing precedence for multiple matching i.e. conflicting rules. A less-specific rule should have a lower priority so that a more-specific rules takes precedence. Default: 10. |
Example 1: Denying any Traffic destined to the Router’s Loopback Addresses
supervisor@rtbrick>LEAF01: cfg> show config forwarding-options acl { "rtbrick-config:acl": { "l3v4": { "rule": [ { "rule-name": "BLOCK_LOOPBACK_TRAFFIC_v4", "ordinal": [ { "ordinal-value": 20, "match": { "destination-ipv4-prefix": "198.51.100.43/24", "direction": "ingress" }, "action": { "drop": "true" }, "priority": 20 } ] } ] }, "l3v6": { "rule": [ { "rule-name": "BLOCK_LOOPBACK_TRAFFIC_v6", "ordinal": [ { "ordinal-value": 20, "match": { "destination-ipv6-prefix": "2001:db8:0:10::/32", "direction": "ingress" }, "action": { "drop": "true" }, "priority": 20 } ] } ] } } } supervisor@rtbrick>LEAF01: cfg>
Example 2: ACL allowing and rate-limiting ICMPv4/v6, and denying any other Traffic
supervisor@rtbrick>LEAF01: cfg> show config forwarding-options acl { "rtbrick-config:acl": { "l3v4": { "rule": [ { "rule-name": "BLOCK_LOOPBACK_TRAFFIC_v4", "ordinal": [ { "ordinal-value": 20, "match": { "destination-ipv4-prefix": "198.51.100.43/24", "direction": "ingress", "ip-protocol": "ICMP" }, "action": { "permit": "true" }, "priority": 20 } ] } ] }, "l3v6": { "rule": [ { "rule-name": "BLOCK_LOOPBACK_TRAFFIC_v6", "ordinal": [ { "ordinal-value": 20, "match": { "destination-ipv6-prefix": "2001:db8:0:10::/32", "direction": "ingress", "ip-protocol": "IPv6_ICMP" }, "action": { "permit": "true" }, "priority": 20 } ] } ] } } }