Telstra-uitval: De nacht dat een netwerk besloot dat het jaar 2006 was

Soms krijgen we bij Netnod de vraag waarom tijd zo belangrijk is. Netnod distribueert de Zweedse nationale tijd, en het kan klinken alsof dit alleen een zorg is voor zeer gespecialiseerde ingenieurs.

Het tegendeel is echter waar. Als we geen gemeenschappelijk begrip hebben van wat "nu" is, zullen veel zaken die we als vanzelfsprekend beschouwen, ophouden met werken.

Deze zomer heeft Australië dit op harde wijze ervaren. Ik maak graag van deze gelegenheid gebruik om een voorbeeld te geven van waarom tijd essentieel is voor een moderne samenleving, wat er in dit specifieke geval is gebeurd en wat de belangrijkste lessen zijn.

Op 8 juli 2026 stopte een groot deel van het mobiele netwerk van Telstra, de grootste mobiele operator van Australië, met werken. Spraakoproepen kwamen niet door en tekstberichten arriveerden niet. Er waren zelfs oproepen naar het Australische noodnummer die niet doorkwamen. De uitval beïnvloedde echter ook systemen die verder uit elkaar lagen; zo raakten treinen, betalingsterminals, ticketingsystemen en EV-laders verstoord.

Er waren geen netwerken aangevallen. Niemand had per ongeluk een glasvezelkabel doorgesneden. Alle systemen hadden elektrische stroom. De schuldige? Een enkele GPS-ontvanger in één chassis in Melbourne die, na gepland onderhoud, terugkeerde met de overtuiging dat het jaar 2006 was, en de rest van het netwerk overtuigde om dat ook te geloven.

Telstra heeft een onafhankelijk onderzoek laten uitvoeren door het bedrijf Technology Audit Partners (TAP). Het rapport is zeer interessant, omdat hetzelfde type fout zou kunnen optreden in veel kritieke diensten, inclusief diensten waarvan we afhankelijk zijn om mensen in leven te houden.

Om veel van deze systemen te laten functioneren, is het cruciaal dat de tijd correct is, of in ieder geval overal hetzelfde. En zoals iedereen in de sector weet, is "correct" een relatieve term. Er bestaat geen exacte tijd, alleen tijd die binnen een bepaalde marge van een referentie wordt gehouden. Hoe breed die marge is, hangt volledig af van wat je doet of in welke sector je opereert.

Het beheren van een mobiel netwerk, zoals dat van Telstra, is een van de meest tijdsafhankelijke activiteiten die er zijn.

Waarom tijd essentieel is voor moderne mobiele communicatie

Moderne mobiele protocollen werken niet zonder precisietijd. Mobiele netwerken scheiden uplink-data van downlink-data via FDD (Frequency Division Duplex) of TDD (Time Division Duplex).

• FDD geeft elke richting zijn eigen deel van het spectrum, zodat beide continu kunnen werken zonder te botsen.
• TDD gebruikt daarentegen één enkel blok spectrum voor beide richtingen, waarbij in zeer korte intervallen wordt gewisseld tussen verzenden en ontvangen.

Omdat er meestal veel meer data naar beneden (downlink) stroomt dan omhoog (uplink), laten de vaste ratio's van FDD veel van het uplink-spectrum onbenut. TDD kan de ratio echter verschuiven om aan het werkelijke verkeer te voldoen. Dat is de reden waarom het meeste moderne 5G-spectrum, inclusief de belangrijkste 5G-band van Zweden op 3,5 GHz, TDD is.

Dit is ook waarom TDD afhankelijk is van accurate tijd: elke cel op dezelfde frequentie moet synchroon met elke andere cel van richting wisselen. Een cel waarvan de klok afwijkt, zal data verzenden in het ontvangstvenster van zijn buurcel, met als resultaat dat het netwerk zichzelf gaat storen (jamming).

In plaats van spectrum toe te wijzen om de twee richtingen gescheiden te houden, heeft de industrie ervoor gekozen te vertrouwen op tijdnauwkeurigheid en een harde afhankelijkheid geaccepteerd van het feit dat elke cel het eens moet zijn over wanneer "nu" is. Het afhankelijk zijn van tijd is dus een bewuste ontwerpkeuze.

Gezien hoe afhankelijk we allemaal zijn van systemen die het eens moeten worden over "nu", is het echter verbazingwekkend dat er niet zoveel aandacht aan tijd wordt besteed als het verdient. Dat is een les die zeer duidelijk naar voren komt uit het gepubliceerde rapport.

Wat is er precies gebeurd?

De architectuur van tijdverspreiding

Om te beginnen is het essentieel om de architectuur van tijdverspreiding te begrijpen. Protocollen voor tijdverspreiding bouwen hiërarchieën op; het Network Time Protocol (NTP), dat Telstra heeft geïmplementeerd volgens het rapport, drukt deze hiërarchie uit in strata.

• Stratum 0: De referentie zelf, bijvoorbeeld een GPS-ontvanger of de atoomklokken van Netnod.
• Stratum 1: Een machine die direct is gesynchroniseerd met een stratum 0-referentie, bijvoorbeeld de NTP-servers die Netnod levert.
• Stratum 2: Synchroniseert van een stratum 1-server.
• Stratum 3: Synchroniseert van een stratum 2-server, enzovoort.

In het geval van Telstra had die hiërarchie, in ieder geval aanvankelijk, een specifieke vorm. Dit ontwerp uit 2010 had aan de top stratum 1-bronnen bij het National Measurement Institute (NMI) van Australië, dat de nationale tijdschaal van het land beheert. Telstra haalde tijd van deze externe referenties naar twee eigen stratum 2-servers in Sydney en Melbourne, die op hun beurt drie stratum 3-servers voedden in Sydney, Melbourne en Perth.

Daaronder bevonden zich de clients. In deze context betekent dat niet laptops of telefoons, maar de gehele mobiele netwerkinfrastructuur, zoals nodes die hand-overs tussen cell-sites afhandelen. Er waren duizenden nodes verspreid over een enorm geografisch gebied en elke node moest hetzelfde idee hebben van wat "nu" is, met een nauwkeurigheid van enkele miljoenen delen van een seconde.

Het TAP-rapport beschrijft deze opzet als "geschikt voor het doel" en stelt dat het Telstra een "zeer betrouwbare en gezaghebbende referentietijdbron van NMI" gaf.

Een stratum zegt op zichzelf niet of de tijd accuraat is, alleen het aantal stappen van een server naar zijn referentie. Een stratum 1-server met een slechte tijdreferentie is nog steeds een stratum 1-server.

Bescherming tegen foutieve tijdbronnen

NTP heeft daarom verdedigingsmechanismen nodig tegen slechte tijdbronnen. In feite zijn er twee verschillende mechanismen, die verschillende dingen doen en waarvan wordt aangenomen dat ze onafhankelijk van elkaar werken:

1. Gewicht van de stratum: Tussen vergelijkbare kandidaten weegt de lagere stratum zwaarder. Dit is het mechanisme dat bepaalt op welke bron een client besluit te vertrouwen.
2. Uitsluiting van uitschieters: NTP vergelijkt verschillende bronnen en verwijdert diegene die afwijken van de rest. Een enkele bron die een onwaarschijnlijke tijd claimt, wordt weggestemd en gedropt, ongeacht hoe gezaghebbend deze beweert te zijn.

Geen van deze verdedigingen is specifiek voor een bepaalde verstoring; samen beschermen ze tegen een kapotte ontvanger, een verkeerd geconfigureerde server of een externe aanval. Maar deze beschermende maatregelen werken alleen als de tijdbronnen waar de clients naar luisteren, werkelijk onafhankelijk van elkaar zijn.

Twee manieren om NTP te implementeren

NTP kan op twee manieren worden geïmplementeerd:

• Client/server-modus: De relatie is verklaard en directioneel: een node haalt tijd van specifieke servers en van niets anders. De opzet van Telstra uit 2010 was in feite een dergelijk client/server-model. Peering was toegestaan, maar alleen op hetzelfde stratum-niveau.
• Symmetrische (peering) modus: Nodes wisselen wederzijds tijd uit en beslissen op basis van welke bron de algoritmen op dat moment voorrang geven.

Peering is flexibel en overleeft het verlies van een bron op een elegante manier. Maar het betekent ook dat de topologie in productie emergent is in plaats van ontworpen. Wat je documenteert is een opzet die zich stilletjes kan herschikken in een vorm die nooit is goedgekeurd.

De upgrade van Telstra in 2020

In 2020 werd het timing-systeem van de mobiele core geüpgraded en werd er nieuwe hardware geïnstalleerd, waaronder een nieuw NTP-timingchassis. Die installatie introduceerde een aantal wijzigingen.

De eerste wijziging was noodzakelijk. Het nieuwe chassis stond niet toe dat een stratum 2-server een stratum 3-server in hetzelfde chassis voedde, waardoor ze kruislings verbonden moesten worden: de stratum 3 van Sydney haalde zijn tijd van de stratum 2 van Melbourne, en de stratum 3 van Melbourne van die van Sydney.

In de praktijk hield elke locatie in plaats van twee stratum 2-bronnen slechts één over. Het TAP-rapport merkt op dat deze vermindering in redundantie bekend was en werd geaccepteerd. Een tweede wijziging was het verlaten van het client/server-model ten gunste van het peering-model. Hoewel het rapport niet duidelijk is over de motivatie, is het aannemelijk dat men hiermee het verlies aan redundantie wilde compenseren. Door servers hun eigen vervangers te laten vinden, kon de indruk worden gewekt dat de veerkracht beter was.

Het TAP-rapport stelt duidelijk dat het verlies van veerkracht bekend was. Het stelt echter dat er geen bewijs is dat het resulterende risico op zogenaamde "timing loops" was geïdentificeerd.

Wat is een timing loop?

Een timing loop is het netwerkequivalent van het geloven dat een gerucht waar is door drie mensen te vragen die het allemaal van elkaar hebben gehoord. Iedereen is het met elkaar eens, dus het moet wel waar zijn. NTP werkt in feite hetzelfde: het vergelijkt verschillende bronnen en verwijdert degene die afwijkt van de rest.

Zoals eerder vermeld, heeft NTP twee verdedigingen tegen slechte tijdbronnen. De tweede beschermt tegen timing loops, maar alleen als de bronnen onafhankelijk van elkaar zijn. In zo'n loop zijn bronnen die onafhankelijk lijken, in feite tijd aan het overnemen van elkaar, direct of indirect via een gedeelde referentie.

Zodra er een verkeerde waarde circuleert, zullen de bronnen het met elkaar eens worden en zal de stem uitvallen in het voordeel van de mening van de meerderheid, zelfs als die waarde onjuist is.

Het protocol werkte, de architectuur niet

Beide typen NTP-verdedigingen werden in Melbourne uitgeschakeld, met vijf jaar tussenbeide. Niet opzettelijk, maar door keuzes die op zichzelf verdedigbaar waren: een hardwarebeperking moest worden omzeild en later moest een terugkerend defect worden gestopt. Elke beslissing loste het probleem waar men op dat moment voor stond op. Niemand werd gevraagd naar de som van alle acties te kijken.

De tweede verdediging was de eerste die werd uitgeschakeld. De introductie van peering in 2020 maakte timing loops mogelijk, en vijf jaar later verscheen er zo'n loop. In Melbourne begon een server tijd te halen van een node onder zich in de hiërarchie. Dit had alarmbellen moeten doen afgaan. Echter, omdat accurate tijd nog steeds via andere paden het netwerk bereikte, werd er geen echte schade aangericht. Het onderliggende probleem, de circulaire afhankelijkheid, was aanwezig, maar er werd geen ticket voor aangemaakt.

De werkelijke klacht was echter overduidelijk: Melbourne verloor voortdurend het contact met zijn enige stratum 2-bron in Sydney. Omdat er geen fallback-configuratie was, gebruikte de server peering om een vervanger te vinden, soms een node onder zich in de hiërarchie.

In oktober 2025 activeerden ingenieurs de GPS-ontvanger die sinds 2020 ongebruikt in het Melbourne-chassis zat en verbonden deze met de stratum 3-server, als vervanging voor de onbetrouwbare Sydney-bron.

Op alle zichtbare vlakken leek dit te werken. Melbourne had nu een eigen betrouwbare bron en de alarmen stopten. Maar de oplossing pakte alleen het symptoom aan, niet de bronoorzaak. Niemand stelde vast waarom Melbourne in de eerste plaats het contact met de Sydney-bron verloor. Het onderliggende probleem was in juli 2026 nog steeds aanwezig in het netwerk.

Om het erger te maken, lijkt niemand te hebben begrepen wat het activeren van de GPS-kaart deed met de architectuur. Door de GPS-kaart toe te voegen, veranderde de Melbourne-server van een stratum 3-server in een stratum 1-server. De ingenieurs voegden geen bron toe naast de andere; door een server te promoveren naar dezelfde rang als de nationale referentie, werd er een nieuwe bron gecreëerd aan de absolute top. Voor zover NTP dit betreft, wegen ze even zwaar.

Plotseling werd deze GPS-kaart in een chassis in Melbourne, geïnstalleerd als een tijdelijke oplossing en door niemand beoordeeld, de meest gezaghebbende server in de hiërarchie voor het grootste mobiele netwerk van Australië. Er bleef vrijwel niets over van het ontwerp uit 2010.

Tegen juli 2026 had het netwerk één enkele bron die zowel de meest gezaghebbende kandidaat was als onbetwist, omdat de bronnen die het hadden kunnen tegenspreken, zich stroomafwaarts daarvan bevonden.

Dit gedrag was zeer moeilijk op te merken. Het netwerk leverde jarenlang elke dag accurate tijd. Architecturen als deze verslechteren meestal niet geleidelijk. Ze werken, en ze blijven werken, totdat ze plotseling stoppen.

GPS-weeknummer rollover

Het tweede ingrediënt is een bekende eigenschap van GPS.

GPS verzendt tijd als een weeknummer plus de seconden-in-die-week, geteld vanaf een epoch die begon in begin januari 1980. In het belangrijkste civiele GPS-signaal is het veld voor het weeknummer 10 bits, wat een maximum van 1.023 weken betekent. Elke 1.024 weken, of 19,6 jaar, begint de teller opnieuw. Dit is tweemaal gebeurd: in augustus 1999 en in april 2019.

Het bepalen van welk epoch-nummer het is en het toevoegen van het juiste veelvoud van 1.024 weken, is de taak van de ontvanger. Deze informatie moet in de firmware staan.

Het probleem in Australië was geen laat gevolg van een van de GPS-rollovers. De kaart in Melbourne was zonder problemen door de tweede rollover in 2019 gegaan, omdat een ontvanger die blijft draaien, ook blijft tellen. Elke nieuwe week wordt simpelweg toegevoegd aan de vorige en de vraag naar welk epoch deze behoort, komt niet op.

Zodra je het apparaat echter uitzet, is die kennis weg. Wanneer het opnieuw wordt ingeschakeld, moet de ontvanger het epoch vanaf nul bepalen, en hij heeft alleen de aannames van zijn firmware om op terug te vallen. De firmware op de Melbourne-kaart was niet bijgewerkt. Bij het opstarten viel deze terug op het eerdere epoch en stelde de datum 1.024 weken in het verleden.

Wat daarna gebeurde, is het beste te begrijpen als het uitschakelen van de twee verdedigingen op het moment dat ze het hardst nodig waren.

1. De eerste verdediging (lagere stratum weegt zwaarder): De Melbourne-server werd het hoogst gerangschikt, omdat de gekoppelde GPS-kaart hem promoveerde tot stratum 1-server. Dit gebeurde volgens het NTP-protocol en stuurde clients dus naar de ene bron die 1.024 weken onjuist was.
2. De tweede verdediging (uitschieters worden weggestemd): Deze werd nooit geactiveerd, omdat er niets overbleef om Melbourne als uitschieter te identificeren. NTP vraagt niet of een datum aannemelijk is; het vraagt of een bron afwijkt van de anderen. In de opzet uit 2010 waren er twee stratum 2-servers. Als één daarvan het jaar 2006 had gaan aankondigen, zou de andere 2026 zijn gebleven en zou er geen consensus worden bereikt. Dat zou niet ideaal zijn, maar in ieder geval zou de verkeerde datum zich niet hebben verspreid.

Maar de stratum 2-tegenhanger van Melbourne was uitgeschakeld door dezelfde chassisvervanging, en de overige bronnen bevonden zich stroomafwaarts van Melbourne. Naarmate de verkeerde datum zich verspreidde, begonnen zij deze terug te rapporteren. De overeenstemming groeide, en overeenstemming is precies waar het algoritme naar zoekt.

De clients deden dus waar ze voor gebouwd waren. Zodra een meerderheid van de bronnen van een client het eens was over november 2006, accepteerde de client de datum. En hoe verder de datum reisde, hoe overtuigender het werd.

Geen van beide verdedigingen vertoonde een defect. Beiden waren simpelweg beroofd van waar ze afhankelijk van zijn: de een had een bron nodig die het waard was om hoogst gerangschikt te worden, de ander had bronnen nodig die in staat waren om het oneens te zijn. Twee beslissingen, vijf jaar uit elkaar, hadden ze na elkaar verwijderd.

Belangrijkste lessen van het incident

• Prioriteer en classificeer tijd- en frequentiedistributie als kritieke infrastructuur. Beheer dit dienovereenkomstig. Documenteer alle functies die het hele netwerk kunnen meesleuren en zet timing op die lijst. Classificatie is geen papierwerk; het bepaalt de risicocategorie van wijzigingen, de diepte van de review, personeelsbezetting, monitoringdekking en budgetprioriteit. Het rapport van Telstra is in essentie het verhaal van één ontbrekende vermelding op die lijst en alles wat daarop volgde.
• Documenteer de gehele infrastructuur en elke wijziging daarin. Er was geen centraal register van NTP-configuraties, geen "golden configuration" en geen gedocumenteerd overzicht van de servers behalve de apparaten zelf. Zonder verslagen kun je geen zinvolle pre-checks uitvoeren, kun je de impact niet inschatten en kun je tijdens een incident niet vaststellen hoe "correct" eruitziet.
• Bouw redundantie in competentie. Twee ingenieurs voerden de wijziging uit en beiden waren in verplicht verlof voordat de gevolgen van de reboot van de GPS-kaart werden begrepen. Diepte van expertise is een veerkrachteigenschap, net als een redundante stroomvoeding. Eén specialist, of een paar, betekent dat er geen tweede mening is en niemand is om te vragen in het midden van de nacht, wanneer onderhoud gewoonlijk wordt uitgevoerd.
• Voer een beveiligingsanalyse uit van de tijd- en frequentie-infrastructuur. Behandel timing als een aanvalsoppervlak zoals elk ander.
• Begin bij waar tijd de organisatie binnenkomt. Een GNSS-signaal uit de ruimte is zwak en niet-geauthenticeerd; het kan worden gestoord (jammed) of gespooft door goedkope apparatuur.
• Kijk vervolgens naar hoe het reist. Tijd die over een gedeeld netwerk wordt gedistribueerd, kan worden onderschept en gemanipuleerd.
• Kijk daarna wie er mag spreken. Welke servers mogen je clients accepteren als tijdbron, en wie heeft dat besloten? Een bron die niemand heeft geautoriseerd, is een bron die niemand controleert.
• Stop niet bij bewuste aanvallen. Een timing loop produceert vrijwel hetzelfde effect als een succesvolle spoofing-aanval: een bron die het netwerk vertrouwt, leverend een waarde die niemand kan tegenspreken.
• Gebruik point-to-point verbindingen. De aantrekkingskracht van peering is duidelijk: het voelt als veerkracht waarbij bronnen elkaar ondersteunen. Maar redundantie die zichzelf regelt, is geen redundantie waar je op kunt vertrouwen. Er zijn veiligere manieren. Netnod gebruikt dedicated point-to-point verbindingen: elke relatie is bekend en gedocumenteerd. De topologie blijft zoals we deze ontworpen hebben.
• Bouw een effectieve alarmorganisatie. Alarmen van het timingplatform zaten niet in de standaard monitoringtools en werden alleen tijdens kantooruren door een handvol mensen bekeken. Client-side alarmen hadden noch de ernst, noch het detail om onmiddellijke actie te stimuleren. Alarmen moeten 24x7 monitoring bereiken, de ernst moet de werkelijke consequentie weerspiegelen en iemand moet eigenaar zijn van de respons. Een alarm waar niemand voor stand-by staat, is hooguit documentatie, geen detectie.
• Gebruik "golden installations". Houd voor elke klasse timing-apparatuur een bekende, goede referentiebuild en configuratie onder versiebeheer, en controleer regelmatig en automatisch of wat is geïmplementeerd hiermee overeenstemt. Telstra had niets dergelijks. De ontbrekende firmware-update op de Melbourne GPS-kaart was zes jaar lang in het volle zicht aanwezig; er was simpelweg geen geautomatiseerd proces dat dit zou hebben gesignaleerd.
• Upgrade en evalueer software continu. De firmware-fix voor het rollover-gedrag bestond en de leverancier had hier bulletins over gepubliceerd. Vendor-notificaties hebben een gedefinieerde eigenaar en een gevolgd pad naar actie nodig. Update software volgens een schema, in plaats van wanneer iets je daartoe dwingt. Evalueer voor implementatie in een lab tegen het gedrag waar je daadwerkelijk op vertrouwt.
• Redundantie. Redundantie in timing betekent niet alleen meerdere bronnen, maar onafhankelijke bronnen die niet kunnen convergeren naar een gemeenschappelijke fout. Twee servers gevoed door dezelfde GNSS-ontvanger is nog steeds één bron, maar dan twee keer geteld.
• Vervang apparatuur continu. Timing-infrastructuur veroudert meestal stilletjes. Plan vervanging op een rollende cyclus en ontwerp eerst de doelarchitectuur, in plaats van te accepteren wat nieuwe hardware-installaties opleggen.

Slotopmerkingen

De manier waarop Telstra met de nasleep is omgegaan, verdient lof. Het in opdracht geven van en publiceren van de onafhankelijke review is prijzenswaardig. Alle providers van kritieke diensten, inclusief Netnod, zijn hier beter van geworden.

Het meest onrustbare is misschien dat de uitval plaatsvond terwijl NTP precies werkte zoals het bedoeld was.

Het probleem was alles eromheen. Architecturale keuzes, budgetkortingen, een laag personeelsniveau, gebrek aan goede monitoring, eigenaarschap of documentatie; het gebeurde allemaal omdat niemand echt besefte hoe vitaal tijdservices kunnen zijn.

Laten we proberen dat te veranderen.