BGP and RPKI: securing Internet routes

In December 2019, NIST publishes the SP 800-189 guide, devoted to resilient interdomain traffic exchange (RITE). It gives initial guidance for protecting routing control traffic, preventing IP address spoofing, and detecting and mitigating certain denial-of-service attacks². It replaces publication SP 800-54, released in July 2007 and withdrawn on 17 December 2019³.

The 2019 recommendations include many measures on BGP. For routing, they cite RPKI, BGP origin validation and prefix filtering¹. Against denial-of-service attacks, they first target IP address spoofing, with source address validation (SAV) through access control lists and uRPF (unicast Reverse Path Forwarding). They also cite remotely triggered black hole (RTBH) filtering, Flowspec and response rate limiting (RRL)¹.

The 2007 text already explained what BGP is and why it matters for the Internet, and proposed best practices applicable to almost all the BGP routers then available. It noted that the improved protocols proposed generally required substantial changes to the protocol and might not work with existing implementations³.

The sources do not address employees: what follows applies their findings to everyday work, without claiming that they prescribe it.

• IT or purchasing manager: ask the internet or hosting provider whether it applies BGP origin validation, RPKI and prefix filtering, which NIST recommends to operators¹.
• IT manager: also ask the provider to check that the source addresses of the packets it sends are legitimate, which falls under the source address validation that NIST recommends¹.
• Company targeted by criminal activity: report it, ask its network providers to trace the spoofed traffic to its origin, and share the information with the community, Google advises⁴.
• Employee: treat the network as ground you do not control. The cases below show that traffic passes through networks that nobody controls end to end, which is why confidentiality should not be entrusted to it alone.

Believing that the company network is a closed circuit is the first. Traffic passes through third-party networks, beyond the company's control.

The second pitfall is to assume that routing protection is enough. NIST places it within a set of measures that also includes anti-spoofing and denial-of-service filtering¹.

The third is to confuse the different network incidents. A denial-of-service attack floods its target with useless traffic; according to Google, it does not expose users' data and does not lead to a compromise, but can cause an outage and a loss of trust if it is not mitigated quickly⁴.

March 2014: YouTube flooded by browsers

According to Google, in March 2014, malicious JavaScript injected into thousands of websites by a man-in-the-middle attack on the network led hundreds of thousands of browsers to flood YouTube with requests, up to a peak of 2.7 million requests per second⁴. This is not a BGP hijack, and Google's text does not present it as one. It shows that traffic can be modified along the way and turned against a service, which justifies the employee's caution toward the network.

September 2017: a 2.5 Tbps denial of service

Google says it absorbed a 2.5 Tbps attack in September 2017, the culmination of a six-month campaign. The attacker had used several networks to spoof 167 million packets per second to 180,000 exposed CLDAP, DNS and SNMP servers, which then sent large responses back to Google. The attack had no impact⁴. Google reported thousands of vulnerable servers to their network providers and worked with them to trace the origin of the spoofed packets, so that they would be filtered⁴. The case illustrates the IP address spoofing that NIST's recommendations seek to prevent¹.

Google's 2018 traffic hijacks and the 2008 YouTube and Pakistan Telecom incident appear in none of the sources cited here and are therefore not described here.