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.

  • For BGP, OSPF, RADIUS, PIM, L2TPv2, LDP, and DHCP protocols, the remark-type should be configured as ToS

  • For the IGMP and PPPoE protocols, the remark-type can be be configured as p-bit or tos

  • The outbound-marking attributes such as name, code-point and remark-type are mandatory

  • If the name of the protocol is L2-all, then the remark-type should configured as p-bit

  • If the name of the protocol is L3-all, then the remark-type should configured as tos

  • Redundancy related control traffic can be marked with specific tos value with the L3-all option

set forwarding-options class-of-service control-plane-qos outbound-marking protocol <protocol-name> <remark-type-value> codepoint <codepoint-value>

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.

  • If control plane security is disabled, this configuration has no effect in the system

  • Protocol-specific configuration will take priority over ALL configuration in the control-plane-security protocol

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
              }
            ]
          }
        ]
      }
    }
  }