| Internet-Draft | Stateful CoPP | July 2026 |
| Li, et al. | Expires 5 January 2027 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 5 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[RFC6192] 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 [RFC6192] 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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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.¶
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.¶
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) [RFC3704] 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.¶
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.¶
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.¶
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.¶
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.¶
Stateful CoPP is complementary to existing control plane protection practices. GTSM [RFC5082] 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 [RFC5925] and TCP MD5 [RFC2385] 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 [RFC2827], BCP 84 [RFC3704]) 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. [RFC7454] 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.¶
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.¶
This document has no IANA actions.¶
The authors would like to thank the members of the OPSAWG Working Group for their review and feedback.¶