Stateful Control Plane Policing
draft-li-opsawg-stateful-copp-00

OPSAWG                                                             Z. Li
Internet-Draft                                                     Z. Du
Intended status: Standards Track                            China Mobile
Expires: 5 January 2027                                          J. Wang
                                                                W. Cheng
                                                                G. Zhang
                                                                  Centec
                                                                  X. Sun
                                                                   Inesa
                                                                 C. Zhao
                                                                    SAIA
                                                             4 July 2026

                    Stateful Control Plane Policing
                    draft-li-opsawg-stateful-copp-00

Abstract

   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.

Status of This Memo

   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.

Li, et al.               Expires 5 January 2027                 [Page 1]
Internet-Draft                Stateful CoPP                    July 2026

Copyright Notice

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Stateful CoPP Classification  . . . . . . . . . . . . . . . .   3
     2.1.  Peer Identity and Session State . . . . . . . . . . . . .   3
     2.2.  Ingress Interface . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Per-Source Rate Limiting  . . . . . . . . . . . . . . . .   4
   3.  Operational Considerations  . . . . . . . . . . . . . . . . .   4
     3.1.  Dynamic Updates . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Forwarding-Plane Implementation . . . . . . . . . . . . .   5
     3.3.  Combining Criteria  . . . . . . . . . . . . . . . . . . .   5
   4.  Relationship to Existing Work . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   [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

Li, et al.               Expires 5 January 2027                 [Page 2]
Internet-Draft                Stateful CoPP                    July 2026

   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.

1.1.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  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.

2.1.  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.

Li, et al.               Expires 5 January 2027                 [Page 3]
Internet-Draft                Stateful CoPP                    July 2026

   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.

2.2.  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) [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.

2.3.  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.

3.  Operational Considerations

Li, et al.               Expires 5 January 2027                 [Page 4]
Internet-Draft                Stateful CoPP                    July 2026

3.1.  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.

3.2.  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.

3.3.  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.

4.  Relationship to Existing Work

   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

Li, et al.               Expires 5 January 2027                 [Page 5]
Internet-Draft                Stateful CoPP                    July 2026

   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.

5.  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.

6.  IANA Considerations

   This document has no IANA actions.

7.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2385]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
              Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
              1998, <https://www.rfc-editor.org/info/rfc2385>.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
              May 2000, <https://www.rfc-editor.org/info/rfc2827>.

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
              2004, <https://www.rfc-editor.org/info/rfc3704>.

Li, et al.               Expires 5 January 2027                 [Page 6]
Internet-Draft                Stateful CoPP                    July 2026

   [RFC5082]  Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
              Pignataro, "The Generalized TTL Security Mechanism
              (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
              <https://www.rfc-editor.org/info/rfc5082>.

   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
              June 2010, <https://www.rfc-editor.org/info/rfc5925>.

   [RFC6192]  Dugal, D., Pignataro, C., and R. Dunn, "Protecting the
              Router Control Plane", RFC 6192, DOI 10.17487/RFC6192,
              March 2011, <https://www.rfc-editor.org/info/rfc6192>.

   [RFC7454]  Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
              and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
              February 2015, <https://www.rfc-editor.org/info/rfc7454>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Acknowledgements

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

Authors' Addresses

   Zhiqiang Li
   China Mobile
   Beijing
   100053
   China
   Email: lizhiqiangyjy@chinamobile.com

   Zongpeng Du
   China Mobile
   Beijing
   100053
   China
   Email: duzongpeng@chinamobile.com

Li, et al.               Expires 5 January 2027                 [Page 7]
Internet-Draft                Stateful CoPP                    July 2026

   Junjie Wang
   Centec
   Shanghai
   201203
   China
   Email: wangjj@centec.com

   Wei Cheng
   Centec
   Shanghai
   201203
   China
   Email: chengw@centec.com

   Guoying Zhang
   Centec
   Shanghai
   201203
   China
   Email: zhanggy@centec.com

   Xun Sun
   Inesa
   Shanghai
   200030
   China
   Email: sunxun@inesa.com

   Chunhao Zhao
   SAIA
   Shanghai
   200125
   China
   Email: chunhao.zhao@sh-aia.com

Li, et al.               Expires 5 January 2027                 [Page 8]