At the SIDROPS working group at IETF 113 last month, there was an emerging proposal related to RPKI, which seeks to sign over Remotely Triggered Black Hole (RTBH) requests.
What are RTBH requests?
Blackholing is a technique to minimize the impact of Denial of Service (DoS) attacks where you use the Border Gateway Protocol (BGP) to signal to routing infrastructure to drop such traffic to prevent the attacked IP from receiving a flood of traffic. By pushing this signal as far ‘upstream’ as you can, you reduce the impact of these attacks on other routes too.
There’s unavoidable damage to the specific IP prefixes you blackhole, but you can mitigate this by limiting who sees the blackhole request and maximizing the useful traffic flow to this IP. You can also invoke separate mechanisms to send traffic via some kind of filter, such as a CAPTCHA system for end-user requests that are proxied in, via a path that isn’t subject to the blackhole request. This is documented in detail in RFC 3882 and RFC 7999.
There are variations of blackholing to trigger source addresses and use more complex mechanisms to direct which traffic is dropped. The simple mechanism is to find the smallest chunk of receiving IP prefixes you can direct into the blackhole and request a BGP speaker to stop sending the traffic on.
RTBHs are a mechanism to send requests to blackhole from a specially managed node, using internal BGP (iBGP) as the controller. They do so by sending routes to the edge, which talk to other Autonomous Systems (ASes). This signalling can also be propagated beyond your own AS if you have the right arrangement with your BGP peers. But it begs the question — why should they believe this request to drop traffic being sent to you? Doesn’t it represent an attacking threat all of its own?
It’s all about intent
The problem here is that without some proof of intent, it’s too easy to either lower the barrier to spoofed requests or require an unreasonable burden on the global community to accept longer (more specific) Route Origin Authorizations (ROAs) to show the intent is justified.
RFC 7999 defines a BGP well-known community to assist in BGP signalling of the RTBH beyond your own AS, as a request to neighbors. You want to do this because the problem of a DoS of any kind (distributed or not) is the locality of the chokepoint; you probably start close to the target and then find as you limit the ingress of bad traffic you are congested further and further upstream. At some point, you reach the limit of your iBGP’s ability to force packet drops inside your own AS and need to ask your BGP peers to do this for you.
For point-to-point links (perhaps a long fibre path interstate, or even a submarine cable) this means you can move the traffic away from the point of maximum pain, that is, the other side of the pipe that is congested with unwanted traffic. But why would you trust this mechanism?
Let’s sign a request to make a RTBH a trusted request
In their proposal, presented to the SIDROPS working group, Job Snijders (Fastly), Mikael Abrahamsson (NTT) and Ben Maddison (Workonline) have leveraged the ASN.1 structural form of the ROA, defined in RFC 6482, to define a new object about prefixes.
In the case of ROAs, the signer is the delegate and has RPKI authority to make statements about the prefix and its routing intent. In the ROA they ask for people to accept the nominated AS number as the Origin-AS for the specified limits of prefix length.
In this new object, currently named DOA (this name may be subject to change), the request details:
- Which origins are authorized to inject RTBH routes.
- Which communities will be used to signal RTBH intent.
- What prefix lengths RTBH routes have.
- Which peer ASes may an RTBH route be received from.
This means the signed object provides clear, authenticated proof of the intent by the address delegate.
If an RFC 7999 well-known BGP community is seen signalling the need for an RTBH to be brought live, you know:
- Who can originate the RTBH.
- How they signal it.
- What limits on the prefix to expect.
- What BGP peers to expect the signal from.
There’s much more technical detail in the IETF draft (and slides), including details on how this is structured, the intended validation logic, and how it applies to the interpretation of BGP messages.
At this stage, this work is still under consideration for adoption, but I think that it’s well worth being discussed and adopted, because it is the kind of simple extension of RPKI proof of intent by the address-holding delegate to an operational burden in routing that has a trust problem.
The limit of the role of the RIR system is to support the signing object type inside hosted RPKI, and for independent certificate authority software developers to also support the signed object type in their codebase. This is a low-bar burden, which has immediate value, and is not inventing new things in BGP but adding signing (proof) to an existing operations mechanism.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
George: nice article, thanks – and the proposal definitely makes sense. what’s the status? I see a version that expired Sept 8, 2022 – is there a newer (or plans to make)? Also, did you consider validating the RTBH community in the BGP update directly? (I’m asking since this may be possible with a design we work on)
Hi Amir, glad you enjoyed the article. Please accept my apologies for the delay in replying.
It’s not uncommon for drafts to have a short life, but also to re-awaken as a function of time and interest in the ideas. If you want to engage with the authors, they’re reachable collectively via the email alias draft-spaghetti-sidrops-rpki-doa.authors@ietf.org -I don’t speak BGP for a living, but the authors do and I’m sure they’d welcome a conversation about approaches to RTBH.