The DOWNGRADE BGP Community for Denial-of-Service Attack Mitigation

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 25 March 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 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

Denial of Service (DoS) attacks are a common occurrence, and effective mitigation continues to pose challenges 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 a 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. This approach allows networks to protect themselves from attack traffic by providing relative preferential treatment to other traffic aggregates.¶

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 this 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.¶

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 its presence 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

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 indiscriminate traffic discardure and while this does eliminate unwanted attack traffic, it also disrupts valuable non-attack traffic as an unfortunate side-effect. In contrast, the aforementioned "downgrade" strategy aims to reduce collateral damage by forwarding as much traffic as possible.¶

BGP announcements carrying the DOWNGRADE community SHOULD be accepted and honored only 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)¶

Appendix A. Acknowledgements

The authors wish to thank Massimiliano Stucchi and Bryton Herdes for their review and feedback.¶

Appendix B. 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.¶

<CODE BEGINS>

forwarding-options {
    family inet {
        filter {
            output ff-qppb-v4;
        }
    }
    family inet6 {
        filter {
            output ff-qppb-v6;
        }
    }
}

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 {
            term dcu {
                from {
                    destination-class qppb-le;
                }
                then {
                    forwarding-class le;
                    accept;
                }
            }
            term rest {
                then {
                    accept;
                }
            }
        }
    }
}

<CODE ENDS>

<CODE BEGINS>

configure {
    policy-options {
        community "downgrade" {
            member "65535:TBD"  ## FIXME TBD IANA
        }
    }
    policy-statement "bgp-in" {
        entry 100 {
            from {
                community {
                    name "downgrade"
                }
            }
            action {
                action-type next-entry
                fc l2
                priority low
            }
        }
    }
}

<CODE ENDS>

<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