The DOWNGRADE BGP Community for Denial-of-Service Attack Mitigation
draft-spaghetti-grow-downgrade-bgp-community-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| 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]