]> China Mobile

Beijing100053 China lizhiqiangyjy@chinamobile.com

China Mobile

Beijing100053 China duzongpeng@chinamobile.com

Centec

Shanghai201203 China wangjj@centec.com

Centec

Shanghai201203 China chengw@centec.com

Centec

Shanghai201203 China zhanggy@centec.com

Inesa

Shanghai200030 China sunxun@inesa.com

SAIA

Shanghai200125 China chunhao.zhao@sh-aia.com

OPS OPSAWG CoPP control plane security DoS rate limiting stateful Control Plane Policing (CoPP), as described in RFC 6192, classifies control-plane-destined traffic using static packet header fields. This static classification cannot distinguish legitimate protocol traffic from attack traffic that matches the same header-based rules. This document specifies Stateful CoPP, an operational practice in which the router's runtime protocol state -- including configured peer identities, session state, and expected ingress interfaces -- is incorporated into CoPP classification. Stateful CoPP allows confirmed legitimate traffic to receive preferential access to control plane CPU resources under attack conditions.

Introduction describes a method for protecting a router's control plane from denial-of-service attacks by deploying filters in the forwarding plane. The operational practice based on this method, Control Plane Policing (CoPP), classifies control-plane-destined traffic into protocol-specific categories (e.g., OSPF, BGP, SSH, SNMP) using ACLs that match on IP protocol number, source and destination address prefix, and transport-layer port number. Per-category rate limits are then applied to each class. CoPP as described in operates on static packet header fields and does not take into account the runtime state of the router's protocol sessions. This means that when an attacker crafts packets matching a legitimate protocol class -- for instance, TCP packets with destination port 179 from a spoofed address within a permitted BGP peer subnet -- the CoPP policy cannot distinguish these from genuine BGP traffic. Both share the same rate limit, and under sufficient attack volume, legitimate packets may be dropped. The router itself, however, maintains runtime state that is directly relevant: it knows exactly which protocol peers are configured, which sessions are currently established, and which interfaces those peers are connected to. This document specifies how this runtime state can be incorporated into CoPP classification. The practice of incorporating runtime state into CoPP policies is already deployed operationally. Common examples include installing per-peer ACL entries derived from the BGP neighbor configuration, and programming hardware filters that match established TCP session 5-tuples. This document brings together these practices and discusses their applicability, interactions, and operational considerations.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Stateful CoPP Classification Stateful CoPP extends the static CoPP model by incorporating information from the router's runtime protocol state into the forwarding-plane classification. The following subsections describe the categories of runtime state that are applicable and how each can inform classification decisions.

Peer Identity and Session State The router's protocol configuration contains the precise set of protocol peers: BGP neighbor addresses, OSPF interface assignments, LDP discovery sources, and so on. A packet whose source address exactly matches a configured peer address can be distinguished from a packet whose source merely falls within a permitted prefix range. For example, a router with configured eBGP peers at 198.51.100.1, 198.51.100.5, and 198.51.100.9 can install per-peer entries that give traffic from those exact addresses priority over other BGP-class traffic from the broader 198.51.100.0/24 range. This is equivalent to adding more specific match rules to the CoPP policy, derived automatically from the protocol configuration. Where session state is available, the classification can be further refined. Traffic from a BGP peer in Established state is expected protocol operation; a burst of BGP OPEN packets from an address whose session is already Established is anomalous. An implementation MAY adjust rate limits based on the current session state of each peer.

Ingress Interface For directly connected peers, the router knows which interface each peer is reachable through. A control plane packet arriving on an interface inconsistent with the expected path for the claimed source may indicate address spoofing. An implementation MAY validate the ingress interface of control plane packets against the expected interface for each configured peer. This is conceptually similar to strict-mode unicast Reverse Path Forwarding (uRPF) applied specifically to the set of known peer addresses. This check is most useful for directly connected single-hop peers and is less applicable in multihop scenarios.

Per-Source Rate Limiting Static CoPP applies aggregate rate limits to each protocol class. This means a single attacking source can consume the entire rate budget for a class, starving all legitimate peers. Per-source rate limiting distributes the class rate budget across individual sources. Each source is rate-limited independently, ensuring that a single misbehaving source cannot exhaust the class budget. The per-source rate SHOULD reflect the expected protocol behavior; for instance, a BGP peer in Established state with a 90-second hold time does not normally generate more than a few packets per second of KEEPALIVE traffic. Care SHOULD be taken to accommodate legitimate traffic bursts, such as BGP UPDATE storms during convergence events or OSPF LSA flooding after a topology change.

Operational Considerations

Dynamic Updates Stateful CoPP classification entries SHOULD be updated dynamically as the router's protocol state changes. When a new peer is configured, a session transitions to Established, or a peer is removed from the configuration, the corresponding forwarding-plane classification entries SHOULD be adjusted. Stale entries could create windows for attack traffic to receive unwarranted priority.

Forwarding-Plane Implementation Stateful CoPP classification SHOULD be evaluated in the forwarding plane or in dedicated hardware, as close to the network interfaces as possible. If classification consumes control plane CPU cycles, it could itself become a vector for resource exhaustion. Hardware support for per-source counters and per-peer ACL entries varies across platforms; the set of stateful criteria deployed should match the capabilities of the hardware.

Combining Criteria The stateful classification criteria described can be deployed independently. An operator may choose to deploy only peer identity checks, or only per-source rate limiting, depending on the deployment environment and hardware capabilities. When multiple criteria are deployed together, the method of combining them is an implementation choice. Operators SHOULD have the ability to configure which criteria are active and to adjust parameters for their environment.

Relationship to Existing Work Stateful CoPP is complementary to existing control plane protection practices. GTSM verifies that a packet's IP TTL indicates a directly connected sender. The ingress interface check provides similar topological verification. Both may be deployed together; GTSM operates on a per-protocol basis while ingress interface checking can be applied across all CoPP classes. TCP-AO and TCP MD5 authenticate individual TCP sessions. These operate at the TCP layer; packets failing authentication are discarded by the TCP stack but still consume forwarding-to-CPU bandwidth. Stateful CoPP classification based on peer identity can reduce this bandwidth consumption by filtering in the forwarding plane. Source address validation (BCP 38 , BCP 84 ) prevents spoofing from outside the network but does not prevent spoofing from within a permitted prefix range. Peer identity classification narrows the match to the exact set of configured peer addresses. describes BGP-specific operational security practices including GTSM, prefix-based ACLs, TCP-AO, and max-prefix limits. Stateful CoPP applies the same principles (peer-specific filtering, session-awareness) at the CoPP layer, generalizing them across all control plane protocols.

Security Considerations Stateful CoPP classification criteria that depend on dynamically learned state (such as per-source traffic rate baselines) may be susceptible to poisoning if an attacker can inject traffic during initial operation. Operators SHOULD establish baseline parameters under known-good conditions, and implementations SHOULD support operator-configured values as an alternative. Classification state derived from protocol configuration and session state MUST be maintained consistently between the control plane and the forwarding-plane component performing the classification. Inconsistency -- for example, granting CPU access priority for a peer removed from configuration -- could allow attack traffic to bypass rate limiting. Configuration of stateful CoPP parameters SHOULD be protected by the same access control that protects other router security configuration.

IANA Considerations This document has no IANA actions.

Acknowledgements The authors would like to thank the members of the OPSAWG Working Group for their review and feedback.