Google-fout met bgp-protocol leidde tot internetproblemen bij veel Japanners

In grote delen van Japan hadden mensen voor het weekend kortstondig geen toegang tot internet of ze hadden last van een slechte verbinding. Het bleek dat de fout was veroorzaakt door Google, dat een verkeerd bgp advertisement had uitgestuurd.

Een Google-woordvoerder verontschuldigde zich namens het bedrijf tegenover de Japanse krant Asahi Shimbun. Het bedrijf zou 'verkeerde informatie het netwerk op hebben gestuurd', waardoor de problemen werden veroorzaakt. Volgens de krant deden die zich vrijdagnacht voor en duurden ze maximaal veertig minuten. Een van de gevolgen was dat klanten van de grootste isp van Japan, OCN, geen verbinding konden maken met internet. Het bedrijf heeft ongeveer zeven miljoen klanten.

De Japanse overheid is een onderzoek naar het incident begonnen, schrijft een andere lokale krant. Deze meldt verder dat de oorzaak wellicht een menselijke fout of een hardwaredefect was. De site Bgpmon publiceerde een uitgebreidere analyse en schrijft dat Google een verkeerde bgp announcement had uitgestuurd, waardoor internetverkeer dat voor andere netwerken was bedoeld, via het netwerk van Google liep. Google zei dat het zijn fout na acht minuten had hersteld.

Bgp, oftewel het border gateway protocol, wordt gebruikt om internetverkeer tussen verschillende providers te faciliteren. Om het verkeer tussen zogenaamde autonomous systems, waarvan Google er een is, mogelijk te maken, wordt een tabel bijhouden met zogenaamde prefixes. Volgens Bgpmon ging het mis toen Google 135.000 prefixes aan Verizon meldde. Japan werd daardoor het zwaarst getroffen, maar de gevolgen waren ook in de rest van de wereld merkbaar, aldus de site.

Reacties (58)

[JackBol]

Iedereen in de BGP community erkent dat dit soort foute announcements pijnlijk zijn voor de Internet community at large, maar initiatieven zoals IRR lockdown komen maar moeilijk van de grond. Schijnbaar heerst er bij de peering operators nog altijd een 'hacker-mentality' die goed documenteren en administreren van van AS'en, inetnums en ip blocks in RIR registries maar lastig of stom vinden.

[SKiLLa]

Dat is helemaal geen hacker-mentaliteit; dat is gewoon amateurisme en/of luiheid. Iedereen weet dat BGP advertisements fout-gevoelig zijn, en niet geschikt voor de manier waarop het hedendaags gebruikt wordt (teveel routes, geen beveiliging ingebouwd) en regelmatig verkeerd gaan en dat de Amerikaanse geheime dienst het zelfs structureel en gericht misbruikt. Google onderkende dit al eerder en is al veel langer van plan om volgend jaar grotendeels van BGP af te stappen op haar eigen netwerk: https://www.bizety.com/20...ll-abandon-bgp-next-year/

Dat kan een goede driver zijn om de meeste heikele BGP issues ook aan te pakken, net zoals het uitfaseren van SSL en de push naar HTTPS gerealiseerd hebben; die massale omslag was een paar jaar geleden nog ondenkbaar ... hopelijk gebeurd met BGP hetzelfde.

[Raindeer]

Sorry, maar daar heeft het niets mee te maken. De reden waarom BGP zo'n gierend succes is, is omdat iedereen mee kan doen. Groot en klein. Als je een route announced, dan neemt iedereen dat over en in een paar minuten is de wereld om. Zou je dat nu willen formaliseren, dan leg je een groot deel van de dynamiek van het netwerk plat. Iedere announcement van een nieuwe route moet door zowel zender als ontvanger geaccordeerd worden en uiteindelijk zullen alle 60K+ netwerken op het Internet dit moeten verwerken. BGP is gewoon de manier waarop je zonder coördinatie 60K+ netwerken kunt laten samenwerken. Alles wat we als alternatief bedacht hebben, brengt zoveel administratie en nieuwe failure modes met zich mee, dat het medicijn erger is dan de kwaal.

De reden dat Google voor zijn interne netwerk hiervan af stapt is een veel praktischere reden. Google heeft intern geen borders en dus ook geen noodzaak voor BGP. Dat Google wel BGP gebruikte gaf aan hoe briljant BGP is. Nu heb ik ook van een Googler begrepen dat de dood van BGP in Google zwaar overdreven is. Er zijn nu andere trucs die ze in hun cloud-omgeving kunnen inzetten, omdat ze de volledige controle erover hebben, maar ook zij zijn zo groot dat ze niet 1 omgeving hebben en tussen die omgevingen blijft BGP de norm.

[SKiLLa]

Natuurlijk kunnen niet zomaar BGP uitwisselingen met externe partners uitzetten, maar - net zoals met TLS en HTTP/2, als het alternatief goed blijkt te werken, dan gaan ze samen met Apple, Facebook en MS (en vermoedelijk Akamai ook), kijken of ze het ook 'extern' het/een alternatief kunnen pushen. De push om prehistorische en onveilige protocollen uit te faseren is al een tijdje bezig.

Dat BGP 'intern' gebruikt werd was gewoon noodzaak ivm bestaande stacks, maar BGP spoofing is gewoon een ernstig security issue, 'niet flexibel en briljant'. En het aantal routes is verduizendvoudigt t.o.v. de introductie en schaalt niet; niet zozeer een protocol fout, maar wel hoe het de afgelopen 15 jaar gebruikt wordt/zich ontwikkeld heeft.

[Verwijderd]

als het alternatief goed blijkt te werken, dan gaan ze samen met Apple, Facebook en MS (en vermoedelijk Akamai ook), kijken of ze het ook 'extern' het/een alternatief kunnen pushen.

Dat lijkt me een conclusie die je vooral zelf hebt verzonnen.
Heb je enige aanleiding om te denken dat andere bedrijven een routing-protocol van Google gaan overnemen ? Link ? Voor zover ik weet, is de implementatie van al die nieuwe routing techniek proprietary. En heeft Google het allemaal zelf geimplementeerd. En zijn er geen specificaties van die protocolen ergens beschikbaar. En ook: als Google iets kan bouwen, dan wil dat niet zeggen dat andere bedrijven dat ook kunnen (niet alleen de prijs, maar zie ook maar eens de mensen te vinden om nieuwe high-tech dingen te bouwen. Die vind je niet zomaar).

De push om prehistorische en onveilige protocollen uit te faseren is al een tijdje bezig.

BGP gaat niet worden uitgefaseerd. Er is niemand die daar over spreekt. Wat veel aannemelijker is dat BGP versie 4 wordt uitgebreid. Zoals al honderden keren is gebeurd. BGP-4 bestaat al sinds 1993. (Volgend jaar 25 jaar BGP !). Maar het probleem met BGP hijacks is niet een probleem van "eventjes een ander protocol implementeren). Je moet eerst een goede oplossing hebben voor het probleem. En dat hebben we niet. Ook RPKI is geen totaal-oplossing.

Stel de FAMGAs gaan Google's IGP gebruiken als EGP onderling. Welk algorithme wordt er dan gebruikt om route-leaks tegen te gaan ? Ik denk dat dat nieuwe protocol er ook geen oplossing voor heeft. En dus, verschuif je het probleem alleen maar. Ipv een configuratie-fout in BGP, zal het nu een configuratie fout in het nieuwe protocol zijn dat problemen veroorzaakt.

[Blokker_1999]

Het interne gebruik van BGP is geen noodzaak, dat is een keuze. Zowat alle routerhardware die je intern op een netwerk kunt gebruiken kan overweg met de bestaande interne protocollen ipv dat je het externe BGP moet gaan gebruiken.

En een omschakeling weg van BGP is echt niet zo simpel. Het zou zijn alsof we morgen beslissen om ipv rechts, allemaal links te gaan rijden op de weg, maar dat straat per straat gaan beginnen uitrollen. Je ziet zo dat dat niet goed komt. Waarom je bijv. een Apple aanhaalt is mij trouwens een raadsel, die hebben heel weinig met het protocol of het internet op zich te maken.

En ja, er worden steeds minder onveilige protocollen gebruikt, maar BGP is er 1 dat je niet zomaar naast een ander protocol kunt draaien en ook niet zomaar snel even kunt aanpassen.

[Verwijderd]

Google gaat helemaal niet van BGP afstappen.

Wat er waarschijnlijk aan de hand is:

BGP is een Exterior Gateway Protocol (een zgn. EGP). Dat wil zeggen, het werd gemaakt om routes te kunnen uitwisselen tussen Autonomous Systems. (Een AS is een netwerk van een enkel bedrijf, zoals KPN, Google, Philips, Ziggo, Telenet, etc). Dit in tegenstelling tot Interior Gateway Protocols (IGPs), zoals IS-IS, OSPF, RIP of EIGRP. IGPs worden gebruikt om routes uit te wisselen binnen in een AS.

De afgelopen tien jaar is er een trend onstaan om BGP voor steeds meer dingen te gebruiken, waar het niet oorspronkelijk voor bedoeld is. Een van die dingen is dat sommige ASs BGP gebruiken niet alleen om routes met andere netwerken uit te wisselen. Maar ook om de routering binnen in hun eigen netwerk te doen. Ze gebruiken BGP dus als IGP. Dat kan, als je het op een bepaalde manier configureert (filmpje). En je hebt dan geen ander IGP meer nodig. Je kunt dan IS-IS of OSPF uitzetten. Microsoft was een van de eerste die dit deden. Facebook doet het ook.

Wat ik vermoed is dat Google geen BGP als IGP meer gaat gebruiken. Natuurlijk hebben ze wel een eigen IGP nodig. Voor zover ik weet gebruiken ze een aangepaste versie van IS-IS als basis voor hun routing (op hun zelf-ontwikkelde hardware, in combinatie met zelf-ontwikkelde software). Met daar weer bovenop hun eigen SDN-routing optimisaties. Maar nogmaals, dat gaat alleen over routering binnen in hun eigen netwerk(en).

Google blijft gewoon BGP doen met hun buren.
Ze hebben geen andere keus.

[SpiceWorm]

Bizar dat je dus even het verkeer wat voor iemand anders bedoeld is zo even lokaal kan routeren. Het wordt zo wel erg makkelijk om een man-in-the-middle attack uit te voeren.

Hoe zit het met dit BGP protocol, wordt het altijd bekend als er een foutje in heeft gezeten zodat achteraf er controle kan plaatsvinden of zoiets met opzet is gebeurd en / of er gevoelige data is onderschept?

Of kan je een BGP aanval ook netjes/goed doen zodat niemand er achter komt?

[Reactie gewijzigd door SpiceWorm op 24 juli 2024 07:30]

[P1nGu1n]

Bizar dat je dus even het verkeer wat voor iemand anders bedoeld is zo even lokaal kan routeren. Het wordt zo wel erg makkelijk om een man-in-the-middle attack uit te voeren.

Daarom is HTTPS zo belangrijk

BGP is een van die stokoude protocollen die niet met security in het achterhoofd ontwikkeld is

[Reactie gewijzigd door P1nGu1n op 24 juli 2024 07:30]

[Dorank]

Aluhoetje op:

Als je:

• toegang kan krijgen tot verkeer tussen derden door een "foutje" te maken met BGP
• controle hebt over een browser met aanzienlijk martkaandeel
• die browser een auto update mechanisme heeft
• die browser ook nog eens een eigen CA store heeft.

Dan is https geen obstakel.

BTW als je controle hebt over de browser is het lekken van data makkelijker dan bovenstaande stappen, kwestie van phone home, dat gemaskeerd in data naar populaire services (mail/search).

[Monochrome]

Het is nog makkelijker dan dat. Als je BGP verkeer kan manipuleren kan je ook een certificate authoritiy man-in-the-middelen als deze probeert vast te stellen of een certificaataanvraag gerechtvaardigd is. Je zou zonder problemen een certificaat kunnen krijgen voor een website die je niet bezit, door de CA een route te laten volgen naar de website via een server die jij beheert. Dus alleen het eerste punt van je lijstje is relevant, de rest is niet per se nodig.

[tweaknico]

Daarvoor is dus Certificate pinning nodig dan is een MITM met een vaag certificaat niet mogelijk omdat de Public Key van een website elders gepubliceerd is.
En die certificering kapen is een andere uitdaging.

https://www.owasp.org/index.php/Pinning_Cheat_Sheet

[MrFax]

Certificering kaping is een van de lastigste dingen. Makkelijk zou zijn is iemand van zo'n CA om te kopen, wat nog steeds gebeurd .

[tweaknico]

Het gaat niet om het certificaat, maar om de PUBLIC key fingerprint die bekend is van een website.
Als je een Rogue website neerzet kun je (als het goed is) niet dezelfde public key finger print maken.

Ergo je wordt geconfronteerd met een website die NIET de juiste public key levert.

[Monochrome]

Je kan inderdaad niet dezelfde public key maken als de originele website, maar dat is geen probleem. Als het certificaat (voor een nieuwe public key) ondertekent is door een erkende CA zal je browser deze public key gewoon accepteren.

[tweaknico]

Niet als je Public Key Pinning hebt. Dat is juist wat met bv. DANE bereikt wordt.
DANE zet een DNSSEC signed item in DNS records.
Ook die onder tekening moet kloppen..., dus voor een high jack moet je dan wel heel veel infrastructuur repliceren waarbij het alleen kan werken als de afgeluisterde/gemonitorde zich binnen dat netwerk blijft bewegen.
Een stap buiten de gouden kooi, en het geheim lekt uit.

[CyBeR]

Als je controle hebt over een browser met een aanzienlijk marktaandeel heb je de rest helemaal niet nodig.

[reneflo]

Tweakers heeft er zelf ook een keer een interessant artikel over geschreven.
reviews: Border gateway protocol: de achilleshiel van internet

[Yariva]

Ik vond dit artikel wel erg neerbuigend tegenover de techniek. Tuurlijk zaten er een aantal goede punten in, maar het trust issue behoud je altijd in dit soort constructies.

[Verwijderd]

Ik heb toen mijn beste gedaan om BGP te verdedigen. (Zie eerste reactie bij dat artikel). Alles wat ik toen schreef geldt nog steeds. Het probleem van foute advertisements is een moeilijk probleem om op te lossen. (RPKI bv is niet genoeg). Er wordt nog steeds aan gewerkt. (Zie bv een draft van 2 maanden geleden over het roles. Roles zijn een concept dat moet helpen om minder snel configuratie fouten te maken, die een route-leak kunnen veroorzaken). Als je denkt te weten hoe dat probleem op te lossen: speak up !

[Reactie gewijzigd door Verwijderd op 24 juli 2024 07:30]

[reneflo]

Kan goed zijn dat het iets te negatief geschreven is en geloof ook zeker niet dat er een beter alternatief is, maar denk nog steeds dat het goed is dat er zo'n artikel geschreven is.
Tweakers.net begint zich meer te richten op de minder technisch onderlegde mensen. Als je ziet hoe vaak er nog gezegd moet worden dat het verbinden met een publiek wifi netwerk niet veilig is geloof ik zeker dat 90% van Nederland denkt dat hun gegevens veilig zijn als ze hun eigen netwerk verlaten hebben. Dat hun data bij sites gehackt wordt weten de meesten ook nog wel, maar dat in theorie en in de praktijk het netwerkverkeer onderschept kan worden ook als je wifi netwerk gewoon netjes is beveiligd is wel goed om even te benoemen.

[Yariva]

Idd, kudo's nog voor uw reactie destijds! Ik sta nog in de kinderschoenen wat betreft BGP, het was een verademing om zo'n mooie reactie te lezen die het andere kant van het verhaal laat zien.

[Verwijderd]

Dankjewel, graag gedaan.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 07:30]

[SpiceWorm]

Voor grote overheidsorganisaties met veel rekenkracht is https niet zo spannend waarschijnlijk. Als ze de juiste gegevens in handen hebben gekregen krijgen ze dat vast wel gekraakt.

Nog even los van mitm attacks die https strippen, die de public key van de server faken etc (ik krijg nooit meldingen in firefox dat de public key opeens veranderd is).

[Monochrome]

Zoals ik hieronder al schrijf, BGP is prima te misbruiken om aan certificaten te komen voor websites die je niet beheert. Iemand met controle over BGP kan dus geldige certificaten aanvragen voor websites (door de route van CA naar de website aan te passen en te laten lopen via een door de aanvaller gecontroleerde server) en daarmee is HTTPS ook geen obstakel meer.

[arjankoole]

dan moet je certificaten hebben die door een geldige CA zijn uitgegeven. Nu is dat voor overheden niet zo lastig ( kijk maar naar de staat der nederlanden Root-CA, die technisch gezien voor zoiets misbruikt kan worden ). Dat was waar bij de diginotar hack zo'n heisa over was. De hacker had geldige certificaten voor google domeinen gemaakt.

Echter, als jij een nieuwe CA optuigt, dan zal de browser deze niet erkennen/herkennen, en krijg je net zo goed een foutmelding. veel mobiele apps erkennen het ook niet, want die doen certificate-pinning. (ze kennen de geldige fingerprints). Met DNSSEC wordt het nog moeilijker

[Monochrome]

Je begrijpt m'n punt niet :-) Vergeet niet dat BGP routing van blokken IP adressen regelt. Stap voor stap scenario voor een hacker die BGP kan manipuleren:

1) kies een erkende CA bij wie je de aanvraag gaat doen
2) Kies een target: de website waarvoor je een certificaat wilt
3) Tuig een man-in-the-middle server op die verkeer doorstuurt naar de
4) stuur een BGP update message zodat het IP blok waarbinnen de CA zit een route neemt naar de target VIA de mitm server
5) Doe een normale certificaat aanvraag bij de CA voor target. De CA geeft een token, en checkt of deze aanwezig is in de webroot van target
6) De request van de CA komt aan bij de MITM server: injecteer de token, zodat het lijkt alsof deze op de webroot van de target staat
7) De CA is overtuigd dat de token op de target staat, en zal je het certificaat verschaffen.

Geen medewerking van CA nodig dus. Certificate pinning is wel een probleem. Vaak erkent de app dan alleen certificaten uitgegeven door een hard-coded CA. Bovenstaande aanval zou (herhaal zou, terms and conditions apply) kunnen werken bij het aanvragen van een certificaat bij dezelfde CA als waar het originele certificaat vandaan komt. DNSSEC, ik zie niet zo goed wat dat in dit scenario oplost.

[MagicTempest]

In principe is het heel eenvoudig om foute advertisements te filteren met bijvoorbeeld prefix lists. Als je met Google hebt afgestemd welke netwerken zij aan mogen kondigen dan kun je alle extra netwerken eruit filteren. De uitdaging hier zit dan alleen in het proces wat er bij komt kijken om dit aan te passen als er iets wijzigt.

Er zijn veel sites die in de gaten houden wie welke netwerken adverteert, dus een dergelijke omschakeling zal zo'n site meestal wel in de gaten hebben, dat wil echter niet zeggen dat de aanval geen schade op zal leveren voordat het aangepakt kan worden.

[SpiceWorm]

dat wil echter niet zeggen dat de aanval geen schade op zal leveren voordat het aangepakt kan worden.

Als je alleen BGP announcements accepteert die op je whitelist staan dan ben je niet gevoelig voor deze begrijp ik uit jouw eerste alinea?

[CyBeR]

Correct, echter dan moet je constant zorgen dat je whitelist up-to-date is, en hoewel dat nog wel te doen is richting een kleine webhoster, is bij een grote partij (zeker een die ook cloud infrastructuur doet zoals Google, Amazon, Microsoft en die constant nieuwe IP-adressen nodig hebben) dat compleet onhoudbaar. Daar zijn systemen voor maar die worden (nog) niet heel uitgebreid ingezet.

[Verwijderd]

In principe is het heel eenvoudig om foute advertisements te filteren met bijvoorbeeld prefix lists.

In principe wel. In de praktijk blijkbaar niet.

Het grootste probleem is dat je er dan voor moet zorgen dat je filter-lists ten alle tijden up-to-date zijn. Dat is lastig. En hoe meer je het automatiseert, hoe groter de kans dat er bij die automatisering ook weer dingen verkeerd gaan.

Een kleiner probleem is dat filtering cpu-tijd kost op de Control Plane van routers. En BGP is al een grote consument van cpu-tijd. Ik weet de precieze tijden niet, maar ik vermoed dat BGP convergence alleen maar trager wordt als alle routers volledige white-listing met prefix-lists zouden doen. Of RPKI.

[Yariva]

BGP steunt hevig op vertrouwen van andere bedrijven. Tja daar lopen ook mensen rond die fouten kunnen maken. Ik denk persoonlijk niet dat een bedrijf met zo'n grote verantwoordelijkheid (BGP full table met meerdere neighbors) ook maar denkt aan een MITM attack. Dan kan je meteen dag zeggen tegen je business

Overigens vindt ik 9 minuten een hele strakke tijd tussen het ontdekken en oplossen. Helaas duurt het dan nog even voordat de wijziging is doorgevoerd over alle BGP routers, tja het is niet anders.

Je zou preventief kunnen handelen dooor bij een x aantal wijzigingen de neighbor als ongeldig te verklaren. Wat ik eerder zou doen is de BGP tabel monitoren en kijken naar drastische wijziging (zoals een ander AS path bij 135.000 prefixes.)

[Reactie gewijzigd door Yariva op 24 juli 2024 07:30]

[majetta]

Tja, Google heeft daarom meerdere mensen daar rondlopen die het een en ander van netwerken afweten. . volgens mij al voordat de alarmbellen afgingen had iemand al in de gaten dat het niet goed ging.

[ShadyNetworker]

Je kan een "aanval" doen, maar de nette manier is om aan beide kanten van een BGP peering te filteren op de prefixes die je van de overkant verwacht te krijgen en niets anders te accepteren.

Als je dat vergeet of daar een foutje in maakt laat je de deur openstaan voor onjuiste announces.

[Reactie gewijzigd door ShadyNetworker op 24 juli 2024 07:30]

[BrammeS]

In dit artikel wordt het goed uitgelegd:

https://bgpmon.net/bgp-leak-causing-internet-outages-in-japan-and-beyond/

Tot mijn grote verassing wordt onze eigen oernederlandse KPN ook genoemd in dit artikel. Ik snap echter niet goed waarom KPN gerelateerd wordt aan een internetoutage aan de andere kant van de wereld.

[Verwijderd]

De topologie van het Internet heeft zo goed als niks te maken met de toplogie van de wereld. Mensen hebben het altijd over: "als je pakketjes van Nederland naar Amerika stuurt", etc. Maar zo werkt het Internet niet. Je stuurt pakketjes van AS (Autonomous System) X naar AS Y. Bv je stuurt pakketjes van het AS van KPN naar het AS van Verizon. Waar die netwerken zich precies bevinden, doet er niet veel toe. Verizon kan een netwerk (een AS) hebben dat meerdere continenten omvat.

Wat dat artikel schrijft is dat:
1) zoals normaal, adverteert Jastel zijn routes aan Google
2) Google gaf die routes door aan Verizon (een hele grote ISP, een van de 10 grootste ter wereld). Dat had Google niet moeten doen.
3) Verizon accepteerde die routes. Dat had Verizon niet moeten doen.
4) Verizon gaf die routes weer door aan zijn klanten, waaronder onze KPN.

Resultaat: als je een klant van KPN was, en je wilde een pakketje naar Jastel sturen, dan ging dat via: KPN -> Verizon -> Google -> Jastel. Terwijl het eigen via een ander pad zou hebben moeten gaan. En ergens op dat pad waren routers die die routes wel hadden, maar toch wisten dat ze traffic moesten droppen. Of werd het traffic ergens bij Google gedropt. In ieder geval: traffic dat via Verizon->Google liep, kwam nooit bij Jastel aan.

[Blokker_1999]

Waarom had Verizon die niet mogen accepteren? Verizon heeft gewoon de paketten die Google op een correcte manier naar hen heeft gestuurd aanvaard en verwerkt zoals het protocol voorschrijft. Het is niet aan hen om die announcements in twijfel te gaan trekken.

[Verwijderd]

Omdat van fatsoenlijke ISPs wordt verwacht dat ze routes zowel ingress als egress filteren tegen een lijst van prefixen waarvan ze weten dat ze die zouden kunnen verwachten.

Het is niet verplicht. Niet iedereen doet dat. Maar het is netjes om te doen. Als de zender een fout maakt, dan kan de ontvanger dat nog corrigeren. Nu, in het geval dat Verizon niks corrigeerde, wordt een fout door Google direct afgestraft. Helaas.

[Tadream]

Op zich niet zo raar dat die in het verhaal vermeld wordt, het is ook best een aardig groot netwerk wat KPN heeeft.
Ben zelf nog anderhalve week geleden bezig geweest met een interne bgp aanpassing (ja bij KPN), zodat alle vestigingen wisten dat er een nieuwe route bijkwam. Dit gaat verdomd handig met bgp zonder dat je in elke router het eea moet gaan configureren.

[jurri@n]

Het hele probleem zou nooit een probleem geweest zijn als iedereen netjes de routes die via BGP ontvangen worden zou filteren op basis van IRR en RPKI.

Voor de zomer was er iemand die een onderzoek gedaan had: slechts 3 netwerken op de wereld hebben RPKI volledig geimplementeerd (Bron: https://ripe74.ripe.net/w...udy-ripe74-plen-final.pdf , slide 57).

[Reactie gewijzigd door jurri@n op 24 juli 2024 07:30]

[Verwijderd]

Ik weet niet zo veel van RPKI. Maar ik heb begrepen dat het ook zijn beperkingen heeft. Bv het beschermt goed tegen een fout waar iemand zelf prefixes uit het niets genereert en in BGP injecteert. Maar het beschermt niet tegen prefixes die je binnenkrijgt ergens, als je die aan de verkeerde peers adverteert.

Ik kon zou gauw niets vinden via google.
Maar ik vond wel dit artikel, dat uitlegt dat eigenlijk eerst iedereen RPKI moet gaan gebruiken voordat het een beetje bruikbaar wordt.

[jurri@n]

Klopt, daarvoor filter je op basis van IRR. Je stelt in dat je alleen prefixes van de andere partij en evt. zijn klanten wilt ontvangen. Mocht er dan een fout gemaakt worden waardoor er andere prefixes gestuurd worden, dan worden deze keurig weggefilterd.

RPKI voorkomt eigenlijk alleen dan iemand anders zonder toestemming jouw prefixes begint te adverteren.

[GrooV]

Dit is helaas iedere dag wel ergens aan de hand, gelukkig niet zo groot als Google nu gedaan heeft.

Het twitter account @bgpstream monitort dit bijna realtime en geeft een melding bij een BGP Hijack

[Sleurhutje]

Tussen Ziggo en Google botert het ook nog steeds niet lekker. Eerdere problemen lijken nog regelmatig de kop op te steken. Timeouts en na een paar keer refreshen of opnieuw opzetten van een verbinding met de andere kant gaat het wel goed. Dezelfde verbinding via T-Mobile gaat in één keer probleemloos.

[tom.cx]

Best slecht,

Maar zoals we weten is dit niet de eerste keer dat er wat fout gaat met dit protocol. Het is namelijk al eerder vermeld dat het misbruikt is: Nieuws: Aanvallers misbruiken border gateway-protocol voor onderscheppen verkeer'

Ook heeft een land een aantal jaren geleden iets fout gedaan. Volgens mij ook met het BGP protocol, maar YouTube raakte hier destijds wel wereldwijd offline: Nieuws: How Pakistan knocked youtube offline and how to make sure it never happens again.

Kortom: Hoe lang kan het nog vertrouwd worden deze technologie.

[Verwijderd]

Eng dat een fout bij een site als google gevolgen kan hebben voor een land.

[MagicTempest]

Het is geen fout bij de site Google, maar bij het netwerk Google. Dat is een aardig onderscheid, want Google is een van de grootste netwerken op deze wereld en de website Google is daar maar een onderdeel van.

Overigens zijn er wel vrij veel grote websites waar de netwerkbeheerders hun eigen BGP doen en die kunnen in theorie een vergelijkbare fout maken. Hoewel de meeste van dat soort sites waarschijnlijk niet de capaciteit hebben om de hoeveelheid verkeer die ze dan te verwerken krijgen op te vangen. Je bent dan feitelijk een soort DoS aanval op jezelf aan het doen.

[CivLord]

Overigens zijn er wel vrij veel grote websites waar de netwerkbeheerders hun eigen BGP doen en die kunnen in theorie een vergelijkbare fout maken. Hoewel de meeste van dat soort sites waarschijnlijk niet de capaciteit hebben om de hoeveelheid verkeer die ze dan te verwerken krijgen op te vangen. Je bent dan feitelijk een soort DoS aanval op jezelf aan het doen.

Dit doet bij mij de vraag rijzen hoe makkelijk het is om BGP-wijzigingen te faken. Hoe makkelijk is het voor een hacker om zich als Google of andere grote netwerkbeheerder voor te doen en het halve internet op één netwerk uit te laten komen? En hoe makkelijk is dat weer terug te draaien?

[zarex]

Dit is geen fout bij de website van google op zich. Google heeft behoorlijk wat eigen netwerk infrastructuur, en dit gaat over het verbinden van het netwerk van Google met andere netwerken, waaronder netwerken van internet providers.

[Verwijderd]

Het woord "site" betekent niet "website". Normaal bedoel je er een locatie of gebouw mee. Ik denk dat zarex gewoon "bedrijf" bedoelt.

[raro007]

Tja als Google uitligt dan gaan mensen googlen voor een oplossing....

[wica]

Tja, dan hadden die Japense website maar Argo van Cloudflare moeten gebruiken, dan waren ze niet offline gegaan.

Argo van Cloudflare zegt, tegen o.a. dit soort ongein te kunnen beschermen

https://blog.cloudflare.com/argo/

In one comical example from 2008, a Pakistani ISP turned a botched censorship order into a global YouTube outage, bringing the fragility of core Internet routing algorithms into the public eye. In the same situation, Argo Smart Routing would detect which transit providers had valid routes to YouTube and which did not, keeping end user experience fast, reliable, and secure.

[The Third Man]

Japanse website? De problemen speelden bij de klanten van een Japanse ISP, oftewel 'hun internet lag eruit'.

Een van de gevolgen was dat klanten van de grootste isp van Japan, OCN, geen verbinding konden maken met internet. Het bedrijf heeft ongeveer zeven miljoen klanten.

[wica]

Als je even het bron artikel had gelezen. Eerste alinea.

https://bgpmon.net/bgp-le...ages-in-japan-and-beyond/

into what caused the large-scale internet disruption that slowed or blocked access to websites and online services for dozens of Japanese companies.

[Sleepkever]

Wel even verder lezen dan de eerste alinea dan he:

The BGPstream alerts were informing us that Google was announcing the peering lan prefixes of a few well known Internet exchanges.

Als Cloudfare dus gebruik maakt van een van de peers op de lijst om hun verkeer te ontvangen van de consumenten zijn ze net zo goed onbereikbaar geweest. Die oplossing van hun is niet iets wat deze fout magisch had kunnen laten verdwijnen, ook al was elke website er op aan gesloten. (plus er is ook nog best wel veel verkeer wat geen web verkeer is)

[wica]

Klopt, maar ik had het ook over de website's.

Wat Cloudflare zegt, is dat als er een "fout" ergens in een BGP sessie zit, dat Argos dit kan detecteren, om vervolgens via een andere route, op te vragen te wel correct is.

Waardoor deze website's zeer waarschijnlijk, wel bereikbaar waren gebleven.

Overigens ben ik heel benieuwd of Argos van CloudFlare dit waar kan maken, maar dat is wat anders

[Sleepkever]

Dat gaat Cloudfare niet lukken als die initiële request niet eens aan kan komen bij Cloudfare. Wat in dit geval dus waarschijnlijk veelal het geval is geweest aangezien het vrij "dichtbij" de ISP fout ging met de routering van die request. Die belande allemaal bij google aan die ze niet meer verder doorzet naar een 3e partij. Alles belande dus in een soort zwart gat daar.

Ik geloof oprecht dat Argos wel zo zijn voordelen kan hebben omdat cloudfare ongetwijfeld meer fixed routes gebruikt maar ik denk dat het in deze situatie helemaal niets had uitgemaakt.

[The Third Man]

Ja, dus er werd voor bepaalde bedrijven (namelijk ISP's), de toegang *naar* websites verhinderd. Dat betekent niet dat specifieke websites eruit lagen:

In the example above we can see how Google accidentally became a transit provider for Jastel by announcing peer prefixes to Verizon. Since verizon would select this path to Jastel it would have sent traffic for this network towards Google. Not only did this happen for Jastel, but thousands of other networks as well.

De transit provider is het punt hier, dat is het 'doorgeefluik' voor internetklanten, niet voor een specifieke website.