Re: The obvious solution would be a "Web of Trust"
The thing is, there is no easy solution to this.
In the generalised case, only one peer knows what route their customer should be emitting - and that's the one directly providing the service. But that only applies for the "leaf nodes" - so if I get a line in form a couple of ISP to my little hosting biz, both of those ISPs can (and should) filter my BGP announcements to only allow the small set of IPs I have. That bit is relatively simple - and as long as every end-point provider does this basic filtering at source then one avenue of cock-up is blocked. But if they don't then ...
Both of those ISPs will be taking my traffic to one or more exchanges and publishing my routes alongside many others. So my route advertisements now appear coming from two different ISPs - the problem is that all those other peers connected at the exchange(s) will not know (or have any way of knowing) whether the routes the ISPs are sending on my behalf are genuine.
And it gets worse. Those peers will pick up my routes and propagate them across their network, and at some other point they will get broadcast to other peers. These other peers (now twice removed from any relationship with me) will not have any way to know whether or not they are genuine.
And so it goes on, with peers around the world getting further and further away from knowing who I am and who should be carrying traffic towards my IPs.
But that is only the simple case where the error is in a leaf node where it's relatively easy to know what routes should be advertised from there - the ISP asks me when providing connectivity what AS numbers I own and put those into their filter for the connection itself.
In the case here, the error happened at a transit peer that by definition must be handling lots of routes for people it knows nothing about.
In this case, what I think has happened is that internally they've setup routes to send Google traffic direct to Google via their peering arrangement. Basically that's a matter of "send this list of IP blocks via this gateway". At the same time, they should be filtering those same IP blocks from BGP announcements they make via other connections - specifically the sub-sea cable they operate. They made a mistake here, so the peering specific routes leaked out.
But as above, the other peers involved have no way of knowing that this was a mistake - it could be that the announcements they saw were the result of some new connection going in that made this a good route for the packets, something that's not easy to determine. The key thing is, these other peers really have no way of knowing whether that link genuinely is a route to those destinations. Just signing the route advertisements won't help - because all those routers will have to propagate the routes anyway, so seeing a route that's signed does not tell you anything about whether the router you received it from should actually be routing that traffic.
Bear in mind that the global routing table is heading on for 3/4 of a million entries, propagated across many thousands of routers operated by thousands of operators. It's hard to see how any web of trust could be setup that would handle that scale