Ask HN: Is Google Compute down?
79 comments
Hi all - Seth from Google here. Our team is aware and we are working on mitigation. In short, a third party telco provider is advertising on one of our IP blocks. Unfortunately that's all the information I can share at this time.
We've updated our status page with as much information as we can provide at this time: https://status.cloud.google.com/incident/cloud-networking/18...
Our teams are continuing to work with upstream and downstream service providers to remedy the issue.
Our teams are continuing to work with upstream and downstream service providers to remedy the issue.
EDIT: This is a general statement, I am not complaining to google here.
This kind of thing should not be possible. Are there any protocol proposals or other kind of upgrades to the routing protocols that would prevent these kind of mistakes/attacks?
This kind of thing should not be possible. Are there any protocol proposals or other kind of upgrades to the routing protocols that would prevent these kind of mistakes/attacks?
Yes there is an approach out there, solving many problems of the internet at once. It‘s called SCION and is being used in production at large swiss banks today.
https://www.scion-architecture.net/
https://www.scion-architecture.net/
I am surprised how fragile is the internet given how our society is increasingly becoming critically reliant on it.
On the other hand it's not that fragile everywhere and for everyone. When ISP markets are not monopolized and the service doesn't rely on a big cloud - much fewer users will get rerouted through random countries and the service itself can failover to properly working datacenters, tolerating all those BGP misdesigns.
It's if the internet doesn't like all that centralization with all that market domination. It's naturally resilient only when there is a lot of competition.
It's if the internet doesn't like all that centralization with all that market domination. It's naturally resilient only when there is a lot of competition.
The internet was not really built with security in mind. Look at DNSSEC or BGPSEC.
> This kind of thing should not be possible.
It sounds like you're asking google to solve https://en.wikipedia.org/wiki/BGP_hijacking ?
It sounds like you're asking google to solve https://en.wikipedia.org/wiki/BGP_hijacking ?
Sorry, I didn't intend it to be directed at google.
The Internet is assembled out of duct tape. We apologize for the design.
Check out BGPSec and RPKI - they should prevent issues like this one. They're not widely implemented/enforced. Maybe it's going to change though now that it looks like we've got a "misconfiguration" somewhere every month or so.
Resource Public Key Infrastructure, but ISPs are too cheap to actually implement it.
yeah there's been proposals on improving BGP security for at least 14 years that I've been aware of :)
Getting the big ISPs/Telcos to adopt them... that's another matter
Getting the big ISPs/Telcos to adopt them... that's another matter
I'm thinking 1998 and Peiter Zatko
There are a lot of proposals but the problem is quite difficult to begin with and also involves centralizing policy. And then the chosen protocol has to be implemented by parties that tend to move at a glacial pace.
Reminds me of the time Pakistan knocked YouTube offline by hijacking their IPs globally[0]
Edit: Didn't someone recently share a tool to monitor BGP hijack attempts?
[0]: https://www.cnet.com/news/how-pakistan-knocked-youtube-offli...
Edit: Didn't someone recently share a tool to monitor BGP hijack attempts?
[0]: https://www.cnet.com/news/how-pakistan-knocked-youtube-offli...
I love that Google monitors this site. I really appreciate you reaching out and letting us know the current status!
thanks for the update! FWIW we started noticing the connectivity problems around 2018-11-12 21:17 UTC
Thanks for the info. We have reports showing it started a bit earlier than that, but every piece of information is helping in managing an incident. I'll make sure the team is aware.
Google IPs seem to be being routed to China for us.
We have servers in San Jose that cannot access Google services. Trace route shows everything going to China when leaving the San Jose data center. We can access the same services from Vancouver just fine.
We have servers in San Jose that cannot access Google services. Trace route shows everything going to China when leaving the San Jose data center. We can access the same services from Vancouver just fine.
How many times does this have to happen before China's privileges to do things like this get revoked? At this point, it can't be just a mistake and must be some state-sponsored hacking. Seems like a great way to find out where a particular Spotify user's IP address is.
> China's privileges to do things like this get revoked
By revoking China's privileges, you reinventing the Great Firewall. Or at least part of how it works, by "revoking routing privilege of selected IP ranges."
You know what, that's the narrative of China's wall building proposal in the place. To end USA's "Internet supremacy" and to advocate "Internet sovereignty".
By revoking China's privileges, you reinventing the Great Firewall. Or at least part of how it works, by "revoking routing privilege of selected IP ranges."
You know what, that's the narrative of China's wall building proposal in the place. To end USA's "Internet supremacy" and to advocate "Internet sovereignty".
What are you going to do? Divide the internet in half? I say that in a joking way but it’s a possibility.
You don’t need to cut the internet in half to limit China to routing IP adresses that are allocated to China.
IIRC, Google can try to dictate a BGP policy that says not to accept any routes that goes through China. However, without any verification checks (via cryptography), an entity can lie about the path that they are advertising.
No, the peers just outside of China can choose to reject advertisements of Google by China. Google can’t do much.
There is already a wall. This may be a case of something leaking through it.
Despite the subdomain, the IP for ChinaTelecom-gw.transtelecom.net (217.150.59.249) seems to be based in Russia, as does the carrier: https://en.wikipedia.org/wiki/TransTelekom
Seems likely to be TT's gateway to CT. New theory: TransTelecom brought up a new gateway to ChinaTelecom, which incorrectly gossiped all advertisements from ChinaTelecom. This caused a leak, since CT has bgp highjacking of Google IP ranges for the GFW within China, but ordinarily doesn't leak them outside the country. TransTelecom misconfigured the gateway to broadcast everything advertised by ChinaTelecom, bringing external traffic into the GFW.
I doubt the GFW uses BGP to route traffic to it.
It needs to filter traffic to any address, and wouldn't have specific google ranges configured.
It needs to filter traffic to any address, and wouldn't have specific google ranges configured.
That's a pretty good theory.
Reading through the comments here I'm recognizing "China Telecom" from an article on a BGP hijack that was published about a week ago, I still had the article open in my browser:
https://arstechnica.com/information-technology/2018/11/stran...
In another comment in this thread I read:
> Seems like its time to start or accelerate a working group on secure BGP.
Indeed things can't go on like this for much longer...
https://arstechnica.com/information-technology/2018/11/stran...
In another comment in this thread I read:
> Seems like its time to start or accelerate a working group on secure BGP.
Indeed things can't go on like this for much longer...
I am on the East Coast, in Florida and seeing the same thing with traffic heading to China, lots of "chinatelecom-gw.transtelecom.net" in traceroutes I have never seen prior.
We urgently need a solution for routing traffic to IP addresses that is better than BGP.
Agreed. This appears to be a repeat of the attack covered here: https://news.ycombinator.com/item?id=18385920
I'm not familiar with BGP routing attacks; the article above seems to imply the attacker needs to compromise certs in order to glean useful data from the attack.
If that's accurate, is this Google-oriented traffic vulnerable to this type of attack?
I'm not familiar with BGP routing attacks; the article above seems to imply the attacker needs to compromise certs in order to glean useful data from the attack.
If that's accurate, is this Google-oriented traffic vulnerable to this type of attack?
for Google traffic, assuming certificate pinning is in place, I can't see this being that successful.
However for more general traffic, well look at the trusted root list in your browser/OS. Realise that every single one of those trusted routes can issue certificates for a given domain...
However for more general traffic, well look at the trusted root list in your browser/OS. Realise that every single one of those trusted routes can issue certificates for a given domain...
Thanks. Since it appears all this traffic is Google-related, any guesses as to what the attacker could have gained here?
This could just be a mistake of course, malicious intent isn't needed :)
Of the top of my head, assuming malicious intent, well not all browser (especially older ones) do certificate pinning, so perhaps then Chinese users of Google services using old browsers would find their traffic being intercepted?
Past that the leakage would seem fairly minor, a list of source IP addresses and destination hosts.
Of the top of my head, assuming malicious intent, well not all browser (especially older ones) do certificate pinning, so perhaps then Chinese users of Google services using old browsers would find their traffic being intercepted?
Past that the leakage would seem fairly minor, a list of source IP addresses and destination hosts.
Funny, a day after I posted this...
https://news.ycombinator.com/item?id=18429099
Is our first time actually rolling over the entire stack to AWS - and it worked!
GCP outage currently is massive, can't even use other regions.
Edit: This also affected AWS Oregon region earlier. I do not know how yet, but they too were unreachable briefly. Seems to be okay now.
https://news.ycombinator.com/item?id=18429099
Is our first time actually rolling over the entire stack to AWS - and it worked!
GCP outage currently is massive, can't even use other regions.
Edit: This also affected AWS Oregon region earlier. I do not know how yet, but they too were unreachable briefly. Seems to be okay now.
So... what's the current state of a secure BGP? I feel like this in the top 3 security threats to the whole of the internet.
[deleted]
Does anybody else have chinatelecom-gw.transtelecom.net [217.150.59.249] in the traceroute for www.google.com
Also showing up on a traceroute to spotify.com for me.
Gitlab.com as well, earlier.
17 195.219.156.146 (195.219.156.146) 152.490 ms 152.423 ms *
18 * * mskn17ra-lo1.transtelecom.net (217.150.55.21) 198.658 ms
19 * * Google-gw.transtelecom.net (217.150.44.9) 192.230 ms
20 * * 108.170.250.111 (108.170.250.111) 172.086 ms
17 195.219.156.146 (195.219.156.146) 152.490 ms 152.423 ms *
18 * * mskn17ra-lo1.transtelecom.net (217.150.55.21) 198.658 ms
19 * * Google-gw.transtelecom.net (217.150.44.9) 192.230 ms
20 * * 108.170.250.111 (108.170.250.111) 172.086 ms
What is today the day for?
yeah, GCP is having a serious outage. Our site is down, so's Pivotal Tracker
Edit: We're also in Los Angeles, connecting to us-central1. Seems to be a pattern?
Edit: We're also in Los Angeles, connecting to us-central1. Seems to be a pattern?
Bugsnag's app.bugsnag.com is down as well.
I'm in Los Angeles and I can access my GCP Console but I can't access Google services like google.com or Maps or Gmail.
EDIT: Some services are intermittently responsive. I had ~5 minutes of no access to anything. Some are slowly coming back.
EDIT: Some services are intermittently responsive. I had ~5 minutes of no access to anything. Some are slowly coming back.
we manage services deployed in every GCE region, and our monitoring in London is reporting every GCE region having intermittent connectivity. no problems with our services in the other major clouds (we use basically all of them)
I have trouble accessing YouTube. I live in Sherman Oaks (a town of Los Angeles).
There's a current BGP prefix hijacking issue currently being mitigated.
I hate to break it to everyone, but the technology to filter this sorta thing has existed for a very long time, but people often don't use it.
Most of the time this sort of thing is accidental (IE: operator error)so a lot of operators kinda ignore it.
Check out "IRR Power Tools" if you're interested.
Same thing here in San Diego. Traceroute to spotify.com going through LA, San Jose, NY, London, Amsterdam, Frankfurk, "mskn17ra-lo1.transtelecom.net", then ChinaTelecom-gw.transtelecom.net.
I'm getting the same thing. Servers are in us-east1 and tracert is ending at chinatelecom-gw.transtelecom.net [217.150.59.249]
YouTube and Spotify unresponsive here.
World War III on the Internet front!
I'm in LA and seeing similar routing through chinatelecom-gw.transtelecom.net
Might be related to: https://status.cloud.google.com/incident/cloud-networking/18...
Also in LA, had intermittent issues with google.com and Spotify all morning.
edit: linked to wrong issue
Also in LA, had intermittent issues with google.com and Spotify all morning.
edit: linked to wrong issue
unlikely, IMO. this is a routing problem, either a deliberate attack or else a gigantic screwup
[deleted]
Well, my instance seems to be working
[deleted]
I'm in Los Angeles but the servers are hosted on us-central1