Skip to main content

The DOWNGRADE BGP Community for Denial-of-Service Attack Mitigation
draft-spaghetti-grow-downgrade-bgp-community-00

Document Type Active Internet-Draft (individual)
Authors Job Snijders , Saku Ytti
Last updated 2026-08-04
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-spaghetti-grow-downgrade-bgp-community-00
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,
              <https://www.rfc-editor.org/info/rfc1997>.

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

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

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,
              <https://www.rfc-editor.org/info/rfc7947>.

   [RFC8622]  Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for
              Differentiated Services", RFC 8622, DOI 10.17487/RFC8622,
              June 2019, <https://www.rfc-editor.org/info/rfc8622>.

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

   <CODE BEGINS>

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

   <CODE ENDS>

A.2.  Nokia SR-OS

   <CODE BEGINS>

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

   <CODE ENDS>

Snijders & Ytti          Expires 5 February 2027                [Page 7]
Internet-Draft           DOWNGRADE BGP Community             August 2026

A.3.  Cisco IOS-XR

   <CODE BEGINS>

   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
    !
   !

   <CODE ENDS>

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]