You may have seen the news that Twitter has begun Route Origin Authorization (ROA).
Twitter bound a ROA to their anycast prefix 69.195.191.0/24, being originated by AS13414. What are the implications? Like Twitter, it’s a bit complicated, but what does this actually mean?
You’ve seen that blue tick mark against verified users, right? ROA is not that, but the blue tick gives us a metaphor to understand this change.
The blue tick means that the identity of the poster has been verified. That’s it. It doesn’t tell you if that source is reliable, it doesn’t tell you how the tweet made its way to your screen, and it certainly doesn’t tell you anything about the folks retweeting the message and sending it all over the place. It could still be amplified by mischievous bots who repurpose it for their own malicious goals!
ROA is a little bit like this. It’s confirmation of the origin AS, but not the path, and not the be-all-and-end-all for security. It’s a good step, but it’s just one step. Let’s look at what that step actually involves.
Origin-ASes need to be secured
In BGP, you announce that you can reach things, and you pass on things that you hear can be reached, via you. BGP is a giant rumour machine. It’s all gossip!
No matter what else happens, it’s good that Twitter’s origin-AS (the place that says it can handle Twitter’s traffic) is now secured. That’s a big step. It stops anyone else saying ‘no no, we are the sinkhole for that traffic’, and taking traffic away from routes that it should be using, as long as people check all origin-AS statements against the ROA.
Securing origin-AS doesn’t stop bad things from happening
Unfortunately, there are two properties in BGP which need to be protected in order to protect a route: The origin, and the path.
The path is made up of all the gossip (BGP updates) that is put together for each BGP speaker. This gossip is a list of seen paths. The seen paths are sequences of ASes that form a ‘chain’ to that origin.
There is a ‘best path’ and if no other criteria are chosen, this ‘best path’ is the shortest sequence of ASes to get to that origin. There are alternate paths too, sometimes. They are ‘longer’ ways to get there. They become backup paths, if the best path is lost (withdrawn).
A ROA addresses the origin but doesn’t protect the path.
So, if somebody can make you think they have a ‘better’ (shorter) path to Twitter’s prefix, you will use it, without other instructions. They might be lying! And, another kind of better path exists: a more specific path refers to a smaller subset of the addresses.
As long as the BGP speaker claims to ‘pass it on’ to Twitter’s origin-AS (so, the path is different, but the end outcome is said to be the same) you won’t know better, and if the speaker actually does pass the traffic on to Twitter, you may not even notice. However, this mysterious third party gets to see all the data in flow along the path. They can snoop.
Twitter set a maximum length of 24, which is probably good
Twitter did use an RPKI ROA feature called Max Length and set it to 24, so nobody should believe a BGP message claiming to ‘see’ Twitter as two ‘longer’ prefixes of /25, or four of /26, or eight of /27 and so on. This is good, because although it’s commonly held that BGP doesn’t ‘pass around’ prefixes longer than 24, it actually does, quite a lot. Longer prefixes are more specific and become the best path, as noted above.
Also, there is a problem of ‘acquired default’. The default-free zone in BGP is supposed to prevent you from just tossing data in a corner when you’re not sure what to do with it. However, many accidentally leak routes to 0.0.0.0/0, which is formally the same as the default route. So in practice, there is a default.
BGP paths for Twitter (to Twitter’s origin) can’t gossip about specifics longer than a /24. Accepting long prefixes is how the Pakistan YouTube leak occurred. Pakistan ISPs announced /25 for YouTube in an attempt to make the rest of Pakistan sink traffic to them, black holing YouTube. It accidentally leaked to the outside world, attracting all of the world’s YouTube traffic to Pakistan, with disastrous results for YouTube globally.
It’s not just Twitter, it’s who does routing to Twitter
It’s good that Twitter signed the ROA, and only Twitter can sign the ROA, but actually applying filters to stop bad things happening depends on who’s routing towards Twitter, rather than Twitter itself. BGP may be a giant gossip system, but forwarding data is still based on what is heard. The decision to accept or reject BGP routes is made by those providing the path to Twitter’s origin-AS, for their customers.
Applying ROV filters and not misrouting traffic is not Twitter’s job, so we need to look at the parties who connect to Twitter, or forward packets towards Twitter. Several research groups, including APNIC Labs, are doing just that. Here’s an interesting graphic of where in the world you can see RPKI ROA being applied to packet forwarding.
They’re still tweets, signing ROA won’t fix ‘fake news’
It’s good that Twitter is ‘trusted’ in BGP, it means that (hopefully) fewer people will claim to be Twitter, and helps reduce the chance of you being re-routed into some kind of twisted universe of spam and malware, but folks have to remember what’s said in Twitter remains a critical concern.
Just because a tweet sends you information doesn’t mean it’s real! This ROA measure is great, but doesn’t change the reliability of the tweet content one bit.
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.