Vroeger waren vaste telefoonnummers gekoppeld aan wijkcentrales en mobiele nummers aan de mobiele operator. Als je dus van de ene kant van de stad naar de andere verhuisde, of van de ene mobiele operator naar de andere, dan kreeg je een nieuw nummer. Telefonie draait nu op een intelligent network (IN): een centrale database helpt de routering van telefoontjes tissen de mobiele en vaste infrastructuren.

Probleem is wel dat het telefoonnetwerk nu afhankelijk is van een klein aantal centrale systemen. (En spraakverkeer over internettechnologieën - VoIP - heeft dit versterkt.) Voorheen kon je nog binnen je eigen stadsdeel bellen zolang de wijkcentrale het deed, ook al lag de rest van het telefoonnetwerk plat.

Internet centralisering

We zien nu dezelfde ontwikkeling op ons af komen in de internetwereld. Van oudsher zijn we op het internet in het voordeel omdat organisaties zich tegelijk via meerdere service providers kunnen aansluiten, zolang zij in staat zijn hun eigen BGP-routering te draaien. Maar nieuwe technologie zoals software-defined networking (SDN) introduceert afhankelijkheid van centrale systemen.

Dit geldt ook voor RPKI, een systeem om de routering op het internet te beveiligen tegen (onder meer) route leaks. Recent zagen we een voorbeeld, toen internetverkeer naar grote Europese telecombedrijven ineens via China Telecom en een Zwitsers hostingbedrijf ging. China Telecom en het hostingbedrijf claimden ten onrechte provider van de betreffende telecombedrijven te zijn.

Momenteel wisselen routers van verschillende organisaties routeringsinformatie uit via BGP, waarbij de routers zelf filters moeten hebben die zorgen dat ze alleen de juiste informatie doorsturen. De Zwitserse en Chinese routers hadden in dit geval hun filters niet op orde, , waardoor internetverkeer van derden zomaar de verkeerde kant opgestuurd werd.

RPKI is een systeem dat dit voorkomt met centrale filters die routerverkeer navigeren. Aan de ene kant maakt het centraliseren van deze complexe taak, op servers met open source software dit een stuk makkelijker en veiliger. Maar als deze filters straks onmisbaar zijn, hebben we internet dan afhankelijk gemaakt van een klein aantal servers die allemaal gebruikmaken van een beperkt aantal softwarevarianten?

Grote verbetering, hoger risico

Deze centralisering van functies tegenhouden zal niet lukken, want ze hebben enorme toegevoegde waarde; en zijn ook veel makkelijker te implementeren dan regelmatig tientallen, honderden of zelfs duizenden routers van nieuwe functionaliteit te voorzien. Maar: maak je voor kritische functies niet afhankelijk van één softwareversie?

Betekent dit nu dat we het risico lopen dat het internet op een kwade dag uitvalt? Ik denk het niet, maar ik weet het ook niet helemaal zeker. Het internet is een beetje te vergelijken met het wegennetwerk. Er kunnen op sommige plekken files staan, of een weg is bijvoorbeeld ondergelopen, maar het komt nooit voor dat alle wegen in Nederland tegelijk onbruikbaar zijn.

In dat opzicht is zo’n beveiligingssysteem als RPKI te vergelijken met stoplichten: als die uitvallen, heeft het verkeer daar flink last van, maar het kan in principe wel verder. Als we echter zouden besluiten om alle stoplichten te vervangen door pollers om zo te zorgen dat niemand meer door rood kan rijden, dan wordt het heel stil op straat als de aansturing daarvan uitvalt en die paaltjes niet meer naar beneden willen…  

Het is makkelijk om op zoek naar de perfecte beveiliging de bruikbaarheid van het systeem uit het oog te verliezen. Een netwerk dat stilvalt, levert geen geld op. De providers zullen dus nooit een beveiligingssysteem invoeren met het risico dat delen van het internet vaker uitvallen omdat het niet goed werkt of de zaken ten onrechte niet vertrouwt.

Vandaar ook dat het loodzware BGPsec-systeem waar bijna 20 jaar aan gewerkt is niet van de grond komt, maar het relatief simpele RPKI-systeem om de internetroutering te beveiligen wel steeds breder gebruikt wordt. Dus: verbeter RPKI, maar schiet niet door met de ambities.

En dan je crisismanagement

Nog een paar laatste woorden over het crisismanagement van KPN bij de 112-storing maandag: dat ging niet bepaald volgens de regelen der kunst. Aan de ene kant begrijpelijk, want je hebt alles dubbel, driedubbel of zelfs vierdubbel uitgevoerd met protocollen om bij uitval automatisch over te schakelen. Wanneer het systeem alsnog uitvalt, moet dit komen door een stomme fout of een totaal niet te voorziene samenloop van omstandigheden.

De communicatie over dit incident maakt pijnlijk duidelijk dat er geen enkele rekening gehouden is met mogelijke 112-uitval. Hopelijk wordt hier de juiste les uit getrokken: geen enkel systeem is onfeilbaar, zelfs niet zoveel dubbel uitgevoerd. Dit geldt vooral voor systemen die afhankelijk zijn van complexe software, zoals we nu zien. Het zou dus beter zijn om uit te gaan van een storing eens in de zoveel jaar, en daarvoor een plan te maken. Van de leverancier eisen dat dit nooit meer voorkomt is tamelijk nutteloos, en een leverancier die dat belooft is niet geloofwaardig.

Waarom 112 alleen via telefoon?

Als je veel diversiteit in een systeem bouwt, dan wordt de volgende bottleneck hoe je keuzes maakt (routeert) tussen die verschillende beschikbare opties/paden. Op dit moment is die routeringsfunctie voor 112 exclusief bij KPN belegd. De les van deze storing moet zijn dat het risico niet zozeer uitval van die routeringsfunctie is, maar foute antwoorden. Het systeem dat de routeringsfunctie raadpleegt in dat geval ook niet een backupsysteem.

Een tweede provider erbij, zoals minister Grapperhaus overweegt, zou kunnen helpen. Zorg dan wel dat alle andere telefoonbedrijven 112 bereiken via die tweede provider, zonder gebruik te maken van de routeringsfunctie van KPN. Mocht dan ditzelfde probleem opnieuw optreden, dan is 112 in elk geval bereikbaar vanaf de overige mobiele netwerken.

En: waarom kunnen we 112 alleen bellen? Voor de meeste gebruikers is hun telefonieaansluiting waarschijnlijk op dit moment (nog) wel betrouwbaarder dan hun internetverbinding, maar als je naast via de telefoon, 112 ook via een website en/of app zou kunnen bereiken, zitten niet langer alle eieren in één mandje.

*) Iljitsch van Beijnum is Internet routing & interconnection architect