GROW J. Snijders Internet-Draft BSD Intended status: Informational S. Ytti Expires: 5 February 2027 NTT DATA 4 August 2026 The DOWNGRADE BGP Community for Denial-of-Service Attack Mitigation draft-spaghetti-grow-downgrade-bgp-community-00 Abstract This document outlines a method to mitigate Denial of Service (DoS) attacks by using a well-known BGP community named "DOWNGRADE" as signal to neighboring networks to treat traffic destined towards "DOWNGRADE" tagged IP prefixes with low precedence. The "downgrade" strategy offers an appealing alternative to Remote Triggered Blackhole (RTBH) filtering, because RTBH filtering completes the DoS attack and hampers the defender's ability to monitor whether the attack is still ongoing. 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 February 2027. 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 Snijders & Ytti Expires 5 February 2027 [Page 1] Internet-Draft DOWNGRADE BGP Community August 2026 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. The DOWNGRADE Community . . . . . . . . . . . . . . . . . . . 3 3. Operational Considerations . . . . . . . . . . . . . . . . . 3 3.1. Traffic Marking on Egress . . . . . . . . . . . . . . . . 3 3.2. Mitigation Duration . . . . . . . . . . . . . . . . . . . 4 3.3. Internet Exchange Route Server Transparency . . . . . . . 4 3.4. Scope of Downgrade Routes . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 6.2. Informative References . . . . . . . . . . . . . . . . . 5 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Denial of Service (DoS) attacks are a common occurance and effective mitigation continues to pose a challenge to network operators globally. The traditional approach of signaling neighboring networks to not send _any_ traffic towards the IP prefix under duress poses a significant dilemma: without filtering the destination network segment as a whole suffers from attack, conversely, the use of RTBH filtering itself is an extension of the attack as it causes reachability issues for the beset destination. Even worse, reachability issues often persist beyond the actual attack, because RTBH filtering itself negatively impacts the defender's ability to observe the presence of attack traffic. From a timing perspective it is hard to use RTBH filtering with tactical precision. This document proposes an different approach, the "downgrade" strategy: rather than defenders requesting neighboring networks to discard traffic wholesale, defenders can request for deprioritization of selected traffic in the forwarding-plane. The goal is to protect all other packet traffic from competition with the attack volume aggregate while not completely banning attack traffic from the network. The approach allows networks to protect themselves from attack traffic by providing relative preferential treatment to other traffic aggregates. Snijders & Ytti Expires 5 February 2027 [Page 2] Internet-Draft DOWNGRADE BGP Community August 2026 The aforementioned "downgrade" mitigation strategy does not fully resolve DoS attacks as the root cause remains unaddressed, but it might be a better practise than RTBH filtering. It should also be noted that approach relies on there being at least some unused capacity during the attack. This document specifies a standard well-known BGP community ([RFC1997]) value for use in the global Internet routing system, describes operational considerations for mitigating through downgrading, and for illustration purposes contains some configuration examples. 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. The DOWNGRADE Community This document defines the use of a new well-known BGP transitive community, DOWNGRADE. The semantics of this community allow a network to interpret the presence of this community as an advisory qualification to treat any traffic being sent towards the tagged prefix with lower precedence. That is, in the case of congestion, DOWNGRADE tagged traffic SHOULD be dropped prior to dropping any other traffic. 3. Operational Considerations 3.1. Traffic Marking on Egress Operators SHOULD mark downgraded traffic with Differentiated Services Code Point (DSCP) Class Selector 1 (CS1) at the egress to the next network domain. Such marking can help the defender in monitoring whether a lower-effort forwarding priority was applied. The CS1 DSCP '000001' marking is also known as the Lower-Effort (LE) DSCP marking, see [RFC8622] for more considerations on a Lower-Effort Per-Hop Behavior (LE PHB) . Snijders & Ytti Expires 5 February 2027 [Page 3] Internet-Draft DOWNGRADE BGP Community August 2026 3.2. Mitigation Duration The duration of attack mitigation measures using the aforementioned "downgrade" strategy should be proportional to the threat and SHOULD discontinued as soon as the attack has passed. 3.3. Internet Exchange Route Server Transparency Internet Exchange (IX) Route Servers (RS) ([RFC7947]) SHOULD pass through the DOWNGRADE community transparently. While IX RS themselves operate in the control-plane, the peers of the RS could benefit from receiving the DOWNGRADE community. 3.4. Scope of Downgrade Routes Similar to how IX RS ought to pass through the BLACKHOLE community (see Section 3.3), the global Internet routing system as a whole likely benefits from downgrading close to the traffic source. Operators SHOULD NOT remove the BLACKHOLE community from route announcements. 4. Security Considerations DoS attacks are a pervasive long-standing issue and happen frequently in network operations. Traditional RTBH-based attack mitigation techniques rely on traffic discardure, which unfortunately throws the baby out with the bathwater. In contrast, the aforementioned "downgrade" strategy aims to reduce collatoral damage by forwarding as much traffic as possible. BGP announcements carrying the DOWNGRADE community should only be accepted and honored if the neighboring network is authorized to advertise the prefix. The method of validating announcements is to be chosen according to the operator's routing policy. 5. IANA Considerations Through this document IANA is requested to register in the "BGP Well- known Communities" registry as follows: DOWNGRADE (= 0xFFFFTBD) 6. References 6.1. Normative References Snijders & Ytti Expires 5 February 2027 [Page 4] Internet-Draft DOWNGRADE BGP Community August 2026 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 6.2. Informative References [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, "Internet Exchange BGP Route Server", RFC 7947, DOI 10.17487/RFC7947, September 2016, . [RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services", RFC 8622, DOI 10.17487/RFC8622, June 2019, . Appendix A. Configuration Examples This section contains configuration examples for a number of commonly used networking and telecommunications equipment manufacturers to illustrate how matching on a BGP community can be used to lower priority in the forwarding-plane. For the sake of brevity, these examples omit configuration stanzas for setting LE DSCP '000001' on network domain egress. A.1. HPE Juniper Junos forwarding-options { family inet { filter { output ff-qppb-v4; } } family inet6 { filter { output ff-qppb-v6; } Snijders & Ytti Expires 5 February 2027 [Page 5] Internet-Draft DOWNGRADE BGP Community August 2026 } } routing-options { forwarding-table { export [ ft-qppb ]; } } policy-options { community downgrade members 65535:TBD; ## FIXME TBD IANA policy-statement ft-qppb { term qppb-le { from community downgrade; then { destination-class qppb-le; accept; } } term rest { then { accept; } } } } firewall { family inet { filter ff-qppb-v4 { term dcu { from { destination-class qppb-le; } then { forwarding-class le; accept; } } term rest { then { accept; } } } } family inet6 { filter ff-qppb-v6 { Snijders & Ytti Expires 5 February 2027 [Page 6] Internet-Draft DOWNGRADE BGP Community August 2026 term dcu { from { destination-class qppb-le; } then { forwarding-class le; accept; } } term rest { then { accept; } } } } } A.2. Nokia SR-OS configure { policy-options { community "downgrade" { member "65535:TBD" ## FIXME TBD IANA } } policy-statemeent "bgp-in" { entry 100 { from { community { name "downgrade" } } action { action-type next-entry fc l2 priority low } } } } Snijders & Ytti Expires 5 February 2027 [Page 7] Internet-Draft DOWNGRADE BGP Community August 2026 A.3. Cisco IOS-XR community-set downgrade 65535:TBD ## FIXME TBD IANA end-set ! route-policy qppb-v4 if community matches-any downgrade then set qos-group 1 else pass endif end-policy ! route-policy qppb-v6 if community matches-any downgrade then set qos-group 1 else pass endif end-policy ! router bgp ASN address-family ipv4 unicast table-policy qppb-v4 ! address-family ipv6 unicast table-policy qppb-v6 ! ! Authors' Addresses Job Snijders BSD Software Development The Netherlands Email: job@bsd.nl URI: https://www.bsd.nl Saku Ytti NTT DATA Cyprus Email: ytti@ntt.net Snijders & Ytti Expires 5 February 2027 [Page 8] Internet-Draft DOWNGRADE BGP Community August 2026 URI: https://www.gin.ntt.net/ Snijders & Ytti Expires 5 February 2027 [Page 9]