Kennisbank

Routeringsfout

Bijgewerkt: 4 september 2026 · 6 min leestijd

Stel je het internet voor als een wereldwijd postnetwerk zonder centrale sorteercentrale. Elk pakketje (jouw data) reist van het ene knooppunt naar het andere, en elk knooppunt beslist zelf naar welke buur het pakketje doorstuurt. Een routeringsfout is dan te vergelijken met een sorteerkantoor dat per ongeluk claimt "alle post voor Amsterdam moet voortaan via mij" — terwijl dat helemaal niet klopt. Het gevolg: brieven voor Amsterdam belanden in Moskou, Lagos of nergens, en de rechtmatige ontvangers krijgen niets meer binnen.

Op het echte internet gebeurt dit met dataverkeer in plaats van brieven. Een netwerk (bijvoorbeeld van een provider, bedrijf of overheid) kondigt per ongeluk of soms met kwade bedoelingen aan dat het bepaalde stukjes internetadresruimte "bezit", terwijl dat niet zo is. Andere netwerken geloven die aankondiging en sturen verkeer die kant op. Zo kan het gebeuren dat het verkeer voor een grote website plotseling wereldwijd via een klein, onbekend netwerk loopt — met uitval, vertraging of zelfs afluistermogelijkheden tot gevolg.

Wat is het precies?

Het internet bestaat uit tienduizenden losse netwerken, elk met een eigen nummer: een Autonoom Systeem (AS). Denk aan elk AS als een eigen postbedrijf — KPN, Google, een universiteit, een overheidsinstelling — dat verantwoordelijk is voor een stukje internetadresruimte (een blok IP-adressen).

Om te weten hoe data van het ene AS naar het andere moet reizen, gebruiken deze netwerken een protocol genaamd BGP (Border Gateway Protocol). Via BGP kondigt elk netwerk aan zijn buren aan: "ik ben verantwoordelijk voor dit blok adressen, stuur verkeer daarvoor naar mij." Die aankondigingen worden van buur tot buur doorverteld, tot vrijwel het hele internet weet welke route naar welk adresblok leidt.

Het probleem: BGP is dertig jaar geleden ontworpen op basis van vertrouwen, niet op verificatie. Een netwerk kan in principe aankondigen verantwoordelijk te zijn voor adresruimte die eigenlijk van een ander is, en de meeste buurnetwerken accepteren die aankondiging zonder die te controleren. Er zijn twee hoofdvormen van routeringsfouten:

  • Route-hijack (kaping): een netwerk kondigt bewust of per ongeluk aan de eigenaar te zijn van adresruimte die het niet bezit, waardoor verkeer daarheen wordt omgeleid.
  • Route-leak (lek): een netwerk geeft een routeaankondiging door aan partijen die deze eigenlijk niet hadden mogen ontvangen — vaak per ongeluk door een verkeerd geconfigureerde router — waardoor verkeer een omweg maakt die het niet zou moeten maken.

Het verschil zit dus vooral in opzet: een hijack is meestal een onterechte eigendomsclaim, een leak is meestal een verkeerd doorgegeven, op zich legitieme route. Beide kunnen dezelfde schade aanrichten: uitval, vertraging, of in het ergste geval de mogelijkheid voor een kwaadwillende partij om verkeer te onderscheppen voordat het alsnog wordt doorgestuurd.

Wat wil men ermee bereiken?

Niemand "wil" routeringsfouten — het doel van onderzoek en beleid op dit gebied is juist om ze te voorkomen of onschadelijk te maken. Er zijn drie belangrijke redenen waarom dit onderwerp steeds meer aandacht krijgt.

Ten eerste is beschikbaarheid in het geding: banken, ziekenhuizen, energiebedrijven en overheidsdiensten zijn afhankelijk van een internet dat blijft werken. Eén verkeerd geconfigureerde router kan grote delen van het net offline halen.

Ten tweede speelt vertrouwelijkheid: als verkeer via een onbedoeld netwerk loopt, kan dat netwerk in theorie meelezen — zeker bij onversleuteld verkeer, maar zelfs versleuteld verkeer geeft metadata prijs (wie communiceert met wie, hoe vaak, hoeveel data).

Ten derde is er een geopolitieke dimensie: routeringsfouten worden soms gebruikt, of worden ten minste vermoed te worden gebruikt, om verkeer via specifieke landen te leiden — met mogelijkheden voor surveillance of censuur als bijeffect.

De sector werkt daarom aan technische oplossingen die routeaankondigingen controleerbaar maken in plaats van louter op vertrouwen gebaseerd, zodat fouten en misbruik sneller opvallen en automatisch geweigerd kunnen worden.

Voorbeelden uit de praktijk

Routeringsfouten zijn geen theoretisch risico; de geschiedenis van het internet kent diverse goed gedocumenteerde incidenten.

  • Pakistan Telecom en YouTube (2008): Pakistan Telecom probeerde YouTube binnen het eigen land te blokkeren door een BGP-aankondiging te doen voor YouTube's adresblok. Door een configuratiefout werd deze aankondiging doorgegeven aan de rest van het internet, waardoor YouTube wereldwijd enkele uren onbereikbaar was.
  • Google en Japan (2017): Een verkeerd geconfigureerde routeraankondiging vanuit Google zorgde ervoor dat een deel van het Japanse internetverkeer via India werd geleid. Grote Japanse providers ondervonden hierdoor forse vertragingen en uitval.
  • MyEtherWallet-hack via Amazon Route 53 (2018): Aanvallers kaapten tijdelijk een deel van Amazons DNS-routeringsdienst Route 53 via een BGP-hijack, leidden gebruikers van de cryptowallet-dienst MyEtherWallet naar een nepwebsite en buitten daarmee slachtoffers voor naar schatting enkele tonnen aan cryptovaluta. Dit is een van de bekendste voorbeelden waarbij een routeringsfout direct tot financiële schade leidde.
  • Facebook-uitval (2021): Tijdens het grote, uren durende uitval van Facebook, Instagram en WhatsApp in oktober 2021 trok Facebook per ongeluk de eigen BGP-routeaankondigingen in tijdens onderhoudswerk, waardoor de diensten voor de rest van het internet feitelijk "onvindbaar" werden. Dit was geen kaping door een derde partij, maar toont wel hoe cruciaal correcte BGP-aankondigingen zijn.
  • Verschillende incidenten rond Rostelecom (2020–2022): Het Russische netwerk Rostelecom was meermaals betrokken bij BGP-leaks en -hijacks die verkeer van grote westerse techbedrijven tijdelijk omleidden. Of dit steeds ging om opzet, technische fouten, of een combinatie is niet in alle gevallen met zekerheid vastgesteld; onderzoekers spreken doorgaans voorzichtig van "vermoedelijke" of "mogelijke" hijacks, tenzij er hard bewijs is.

Hoe ver is de techniek?

De belangrijkste technische oplossing heet RPKI (Resource Public Key Infrastructure). Hiermee kunnen eigenaren van adresruimte digitaal ondertekende verklaringen publiceren — Route Origin Authorizations (ROA's) — die vastleggen welk AS-nummer gerechtigd is een bepaald adresblok aan te kondigen. Netwerken die RPKI-validatie toepassen, kunnen zo automatisch onterechte aankondigingen herkennen en weigeren.

RPKI-adoptie groeit gestaag maar is nog niet compleet: wereldwijd heeft een aanzienlijk deel van de routes inmiddels een geldige ROA, met duidelijke regionale verschillen — Europa loopt doorgaans voorop, andere regio's achter. Een deel van de grote netwerkoperators (waaronder grote cloud- en contentbedrijven) valideert en weigert inmiddels actief ongeldige routes, wat de praktische impact van hijacks vermindert, maar zolang niet alle netwerken meedoen, blijft het systeem kwetsbaar.

Een verdergaande standaard, BGPsec, zou de hele routeringsketen cryptografisch kunnen beveiligen in plaats van alleen de oorsprong. Deze standaard bestaat al jaren op papier (vastgelegd door de IETF), maar wordt in de praktijk nauwelijks toegepast vanwege de rekenkracht die het vergt en omdat het pas werkt als vrijwel alle netwerken wereldwijd meedoen — een klassiek coördinatieprobleem.

Belangrijkste obstakels blijven: geen enkele partij kan andere netwerken dwingen mee te doen, deelname is vrijwillig, en veel kleinere netwerkbeheerders missen kennis, tijd of prioriteit om hun configuratie op orde te brengen.

Wie werken eraan?

Verschillende organisaties dragen bij aan het veiliger maken van internetroutering, elk vanuit een andere rol.

De IETF (Internet Engineering Task Force) ontwikkelt en beheert de technische standaarden achter BGP, RPKI en BGPsec, vastgelegd in openbare RFC-documenten.

De regionale internetregistries — zoals RIPE NCC voor Europa, het Midden-Oosten en delen van Centraal-Azië, ARIN voor Noord-Amerika en APNIC voor Azië-Pacific — beheren de uitgifte van IP-adresruimte en bieden de infrastructuur waarmee netwerkbeheerders RPKI-certificaten en ROA's kunnen aanmaken.

De Internet Society is initiatiefnemer van MANRS (Mutually Agreed Norms for Routing Security), een vrijwillig samenwerkingsverband waarbij netwerkoperators, internet exchanges en cloudproviders zich committeren aan een reeks concrete beveiligingsmaatregelen rond routering.

Daarnaast spelen grote netwerkoperators en cloudbedrijven zoals Cloudflare, Google, Amazon en Microsoft een praktische rol: zij passen RPKI-validatie toe op grote schaal en publiceren regelmatig onderzoek en tools die routeringsfouten sneller zichtbaar maken voor de rest van de internetgemeenschap.

Verder lezen