Op 12 november 2018 ontstonden er verbindingsproblemen met Google’s G Suite, een kritische softwareapplicatie die door tal van organisaties wordt gebruikt. De problemen beïnvloedden niet alleen G Suite, maar ook Google Search en Google Analytics. Wat bovendien opviel, was dat verkeer van de zoekdienst Google werd omgeleid naar China Telecom. Ook was er een Russische ISP in de route, wat aanleiding gaf tot bezorgdheid.
Nader onderzoek toonde aan dat verschillende zogenoemde vantage points van over de gehele wereld een vergelijkbare ongebruikelijke omleiding rapporteerden – en dat de omleidingen allemaal eindigden bij China Telecom.
Een visualisatie van de route schetste een interessant beeld. Verkeer uit Parijs naar www.google.com werd naar 216.58.204.132 geleid. Hoewel Google aangeeft dat veel /24-prefixes binnen zijn IP-adresreeks vallen, gold dat niet voor dit adres. In plaats daarvan bevatte het een /19-prefix. Bovendien was een verdachte melding te zien voor 216.58.192.0/19 met een complex AS-pad dat TransTelecom (AS 20485) in Rusland, China Telecom (AS 4809) in China en MainOne (AS 37282), een kleine ISP in Nigeria, omvatte.
De routes die te zien waren, weerspiegelden het BGP AS-pad. Echter, het verkeer werd tegengehouden door de Chinese firewall die eindigde bij de China Telecom-edgerouter.
Bovenstaand incident zorgde ervoor dat G Suite en Google Search onbereikbaar waren. Daarnaast belandde waardevol Google-verkeer in handen van ISP’s in landen met een lange geschiedenis van internetsurveillance. In totaal werden meer dan 180 prefixes door dit omleidingslek beïnvloed, oftewel een groot deel van de Google-diensten. Een nadere analyse laat zien dat de bron van dit lek de BGP-peering-connectie (border gateway protocol) was tussen MainOne (de Nigeriaanse provider) en China Telecom. MainOne heeft een peering-connectie met Google via IXPN in Lagos en beschikt over directe routes naar Google, die naar China Telecom lekten. Deze gelekte routes verspreidden zich van China Telecom via TransTelecom naar NTT en andere transit-ISP’s. Ook was te zien dat dit lek voornamelijk werd verspreid door zakelijke transitproviders en amper impact had op de ISP-netwerken van consumenten.
Op 13 november 2018 tweette MainOne dat de oorzaak van het probleem lag bij een configuratiefout.
Het incident onderstreept een van de belangrijkste kwetsbaarheden van het internet. BGP is ontworpen om een betrouwbare keten te vormen tussen goed bedoelende ISP’s en universiteiten die blind vertrouwen op de informatie de ze ontvangen. Het heeft zich niet ontwikkeld en aangepast aan de moderne complexe commerciële en geopolitieke relaties tussen ISP’s en landen. Hoewel verificatiemethodes, zoals ROA’s (Route Origin Authorisations), wel bestaan, maken maar weinig ISP’s er gebruik van. Zelfs bedrijven als Google – die over veel resources beschikken – zijn niet immuun voor een dergelijk BGP-lek of kwaadwillende hijacks. Het kostte MainOne 74 minuten om het probleem te ontdekken en op te lossen – en het duurde nog eens drie kwartier voordat de diensten weer live waren. De meeste bedrijven (die dus niet over het bereik en de middelen van Google beschikken) kunnen een vergelijkbaar issue waarschijnlijk niet zo snel oplossen. En dat is van grote invloed op de bedrijfsvoering.
BGP-gerelateerde incidenten komen steeds vaker voor. In april 2018 werd een DNS-provider (Route 53) het slachtoffer van een brutale cryptocurrency-diefstal. Een jaar eerder vond het Rostelecom BGP-routelek plaats, dat een groot aantal e-commerce- en financiële-dienstverleningswebsites benadeelde. Hoewel de ISP-community de ernst van het probleem wel inziet en oplossingen als ROA en IRR-filtering bestaan, voorkomt dit alles bij elkaar niet dat het internet plat komt te liggen.
Vanwege het gebrek aan garanties is het van belang dat bedrijven hun BGP-routes continu monitoren en daardoor incidenten snel opmerken. Zo voorkomen ze dat hun bedrijf en diensten schade oplopen.
