The DOWNGRADE BGP Community for Denial-of-Service Attack Mitigation
BSD Software Development
The Netherlands
job@bsd.nl
https://www.bsd.nl
NTT DATA
Cyprus
ytti@ntt.net
https://www.gin.ntt.net/
Operations and Management Area (OPS)
GROW
DDoS
BGP
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.
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.
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 () value for use in the global Internet routing system, describes operational considerations for mitigating through downgrading, and for illustration purposes contains some configuration examples.
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 when, and only when, they appear in all capitals, as shown here.
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.
Operational Considerations
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 for more considerations on a Lower-Effort Per-Hop Behavior (LE PHB) .
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.
Internet Exchange Route Server Transparency
Internet Exchange (IX) Route Servers (RS) () 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.
Scope of Downgrade Routes
Similar to how IX RS ought to pass through the BLACKHOLE community (see ), 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.
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.
IANA Considerations
Through this document IANA is requested to register in the "BGP Well-known Communities" registry as follows:
DOWNGRADE (= 0xFFFFTBD)
References
Normative References
BGP Communities Attribute
This document describes an extension to BGP which may be used to pass additional information to both neighboring and remote BGP peers. [STANDARDS-TRACK]
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
Informative References
Internet Exchange BGP Route Server
This document outlines a specification for multilateral interconnections at Internet Exchange Points (IXPs). Multilateral interconnection is a method of exchanging routing information among three or more External BGP (EBGP) speakers using a single intermediate broker system, referred to as a route server. Route servers are typically used on shared access media networks, such as IXPs, to facilitate simplified interconnection among multiple Internet routers.
A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services
This document specifies properties and characteristics of a Lower- Effort Per-Hop Behavior (LE PHB). The primary objective of this LE PHB is to protect Best-Effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, i.e., when resources become scarce, BE traffic has precedence over LE traffic and may preempt it. Alternatively, packets forwarded by the LE PHB can be associated with a scavenger service class, i.e., they scavenge otherwise-unused resources only. There are numerous uses for this PHB, e.g., for background traffic of low precedence, such as bulk data transfers with low priority in time, non-time-critical backups, larger software updates, web search engines while gathering information from web servers and so on. This document recommends a standard Differentiated Services Code Point (DSCP) value for the LE PHB.
This specification obsoletes RFC 3662 and updates the DSCP recommended in RFCs 4594 and 8325 to use the DSCP assigned in this specification.
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.
HPE Juniper Junos
<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>
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>
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>