TimeNL wordt volwassen

TimeNL versie 1: het probleem van een diffuus ecosysteem

Voordat we ingaan op TimeNL versie 2, gaan we eerst even terug naar de aanleiding voor TimeNL.

Het probleem dat TimeNL versie 1 aanpakte is dat het NTP-ecosysteem diffuus is. Dit betekent dat NTP-aanbieders dikwijls onvoldoende transparant zijn over de eigenschappen van hun tijddienst. Bijvoorbeeld wat hun tijdsbron is (zoals een atoomklok of GPS of DCF77). Ze laten niet veel los over beschikbaarheid, betrouwbaarheid en redundantie van hun dienst en of deze bijvoorbeeld ISO27001-gecertificeerd is. Daarnaast is het vaak onduidelijk hoe goed de NTP-servers worden beheerd en gemonitord. Ook ontbreekt het dikwijls aan duidelijke servicelevels die nagestreefd worden (SLA) en ontbreekt het aan goede support en mogelijkheden om contact op te nemen met de aanbieder.

Deze ondoorzichtigheden maken het lastig om een betrouwbare, weloverwogen keuze te maken voor een bepaalde publieke NTP-dienst. Dat brengt risico’s mee voor de gebruikers van tijddiensten. Voor sommige toepassingen is besef van de juiste tijd, soms zelfs tot op de microseconde of nóg nauwkeuriger, namelijk van groot belang. En onjuiste tijdstempels kunnen tot juridische consequenties leiden (als zogenaamde ‘legally traceable time’ een vereiste is, zoals in de bancaire wereld). Kloppende tijdstempels zijn van belang bij (forensisch) onderzoek van logbestanden. Dichter bij huis kun je dan denken aan het ‘first come first served’-principe bij domeinnaamregistraties. Andere toepassingen waarbij tijd in meer of mindere mate van belang is, zijn: TLS-certificaten, ‘High Frequency Trading’ (op de beurs, dat moet ‘MiFID II compliant’ zijn), digitale ondertekeningen (waaronder DNSSEC), ‘power grids’, OAuth tokens en Kerberos, maar ook: SCADA-systemen, CCTV-bewaking, of ‘broadcasting’ (mixing, mastering in studios e.d.). En cryptocurrency’s vereisen eveneens een correct besef van tijd. En dan hebben we het nog niet eens gehad over triviale toepassingen zoals een simpele agenda-applicatie of het gelijk laten lopen van een wandklok. Kortom, de lijst is lang.

Met TimeNL wilden we het belang van tijd onder de aandacht brengen en tegelijk wat aan doen aan de nadelen die aan veel bestaande publieke NTP-diensten kleven. Daarom ontwikkelden we zelf een publieke NTP-dienst die tegemoetkomt aan bovenstaande tekortkomingen. TimeNL is transparant en weldoordacht, beheren we zorgvuldig (met inachtneming van je privacy) en baseerden we op moderne standaarden, courante software en ‘state-of-the-art’-apparatuur.

Zo leunen we bijvoorbeeld niet alleen op het Amerikaanse GPS als referentieklok, maar gebruiken we ook het Europese Galileo. Daarnaast hebben we een back-up via DCF77. En TimeNL is bijvoorbeeld bereikbaar via IPv6.

Op onze site lees je het uitgebreide verhaal achter deze eerste versie van TimeNL.

TimeNL versie 2: hogere betrouwbaarheidseisen

Gaandeweg concludeerden we dat TimeNL met versie 1 niet ‘af’ was, omdat het gevoelig zou kunnen zijn voor bepaalde verstoringen. We stelden daarom 2 nieuwe eisen aan versie 2.

De eerste was dat we verstoringen van radiosignalen op wilden kunnen vangen. GNSS- (en DCF77-)signalen kunnen namelijk soms onnauwkeurigheden vertonen. Bijvoorbeeld vanwege reflecties (door gebouwen), door uitzonderlijke (atmosferische) omstandigheden, of doordat ze gejammed of gespoofed worden. Maar ook -en dat is minstens zo waarschijnlijk- als gevolg van stormschade of ander onheil.

Onze tweede eis was de beschikbaarheid van de TimeNL-servers te verhogen. We wilden de enkele NTP-server waarmee we startten ‘horizontaal’ schaalbaar maken, om plotselinge pieken in het NTP-verkeer beter te kunnen opvangen. Zo’n piek kan voorkomen door onbedoelde fouten aan de gebruikerszijde, maar in principe ook door kwade opzet. Zo hebben we een paar momenten gehad waarbij we het aantal NTP-verzoeken zagen stijgen van gemiddeld 2.000 per seconde tot wel 75.000 per seconde (zie figuur 1), wat fors is.

Figuur 1: Plotselinge stijging in NTP-verzoeken.

Ontwerp van TimeNL versie 2

Figuur 2 toont het schematisch ontwerp van TimeNL versie 2 op basis van onze 2 hogere betrouwbaarheidseisen. De belangrijkste componenten zijn:

• 2 kernklokken: de primaire kernklok (TimeNL versie 1) levert een zeer nauwkeurig tijdsignaal op basis van GNSS- en DCF77-referentieklokken en bijbehorende antennes. Deze antennes staan in ons geval op het dak van het SIDN-gebouw in Arnhem. De secundaire kernklok levert ook een nauwkeurig tijdsignaal, maar dan via een aangekoppelde Rubidium atomaire ‘holdover-klok’. Die wordt normaal gesproken steeds vanuit de primaire klok gelijkgesteld. Maar kan bij verstoringen van de GNSS- en DCF77-signalen ook de rol van referentieklok overnemen voor zowel de primaire- als de secundaire kernklok en dit langere tijd kan volhouden.

• Meerdere frontend-klokken: halen via het Precision Time Protocol (PTP) de tijd op van een van de 2 kernklokken. Het idee van zo’n frontend-systeem is dat dit qua capaciteit snel kan groeien, door simpelweg meer systemen toe te voegen. Bijkomend voordeel is dat de frontend-klokken de mogelijkheid hebben om NTS (Network Time Security) aan te bieden en ze kunnen zelfs dienen voor het aanbieden van PTP aan externe afnemers.

• Een PTP-backbone: een netwerk op basis van het Precision Time Protocol, dat al onze kloksystemen met elkaar verbindt en synchroniseert op basis van het PTP-protocol. Met PTP kan een zeer hoge nauwkeurigheid worden verkregen.

De primaire- en secundaire kernklokken zijn respectievelijk een Meinberg M3000 en een Meinberg M1000. Deze functioneren als stratum 1 NTP-servers en als PTP GM (grandmaster). De frontend-klokken zijn op Linux gebaseerde servers.

Figuur 2: Ontwerp van TimeNL versie 2.

Hieronder bespreken we hoe we deze componenten hebben gerealiseerd.

PTP-backbone

De verbinding tussen de tijdservers van TimeNL versie 2 (kernklokken en frontend-klokken) bestaat uit een IEEE1588 PTPv2-verbinding. Dat staat voor ‘Precision Time Protocol’, een uitermate nauwkeurig synchronisatie-protocol met een ander toepassingsgebied dan NTP. En dat bleek bij uitstek geschikt voor ons doel, namelijk om via een PTP-netwerk de frontend-klokken zeer nauwkeurig aan de kernklokken te synchroniseren.

Een van de redenen waarom PTP zo accuraat kan zijn, is omdat het gebruik maakt van ‘hardware timestamping’ op de fysieke netwerkinterfaces (de PHY-laag in figuur 3). Door de tijdstempel zo laag mogelijk in de protocol-stack te genereren, worden variaties vermeden die hogerop kunnen optreden.

Figuur 3: Hardware timestamping op PHY-laag, voorkomt protocol stack vertraging.

Rubidium atomaire holdover-klok

Voor de secundaire kernklok gebruiken we een Meinberg M1000, die we koppelden aan een Meinberg XHERb-chassis. De kernklok communiceert via de PTP-backbone met de hardware (2) van TimeNL versie 1, een Meinberg M3000 (de primaire kernklok). Maar hun rollen kunnen ook worden omgedraaid. Bijvoorbeeld als de M3000 niet meer beschikt over betrouwbare referentiekloksignalen uit het GNSS- of het DCF77-signaal.

Figuur 4 laat de opstelling zien in ons serverrack ten tijde van het opbouwen en testen.

Figuur 4: Testopstelling van TimeNL v2.

Met behulp van de zeer precieze PRS10 Rubidium Oscillator van de M1000 en de ‘Multi Reference Source’ (MRS) en ‘Intelligent Reference Switching Algorithm’ (IRSA)-technologieën van Meinberg, kan steeds worden bepaald of de GPS/Galileo- en DCF77-referentieklokken nog betrouwbaar zijn. Zo niet, dan schakelt het systeem automatisch over op de holdover-klok, die steeds als ‘Trusted Source’ (TRS) stand-by is.

Via de PTP-backbone houden de M3000 de M1000 kernklokken elkaar ‘in sync’ (of, als dat beter is, andersom). Het ‘Best Master Clock Algorithm’ (BMCA) dat onderdeel is van de PTP-standaard, bepaalt welk van de 2 de uiteindelijke zogenaamde PTP-grandmasterklok (GM) is. Die wordt vervolgens gebruikt door de stratum 1 NTP frontend-klokken voor tijdsynchronisatie.

Stratum 1 NTP frontend-klokken

Zoals te zien is in figuur 2 komt verkeer dat we vanaf het internet via de NTP-pool ontvangen nu binnen op 2 frontend-klokken, die allebei optreden als stratum 1 NTP-servers. Deze functionele splitsing stelt ons in staat om de capaciteit van de PTP-backbone en van de NTP-servers los van elkaar te evolueren. Dit is voor onze implementatie van belang, onder meer omdat de M1000 werd geleverd met een minder krachtige CPU-module vanwege wereldwijde tekorten op de FPGA-chipmarkt (3), terwijl we soms behoorlijk wat verkeer binnenkrijgen via de NTP-pool. De beide NTP frontend-klokken kunnen dat echter gemakkelijk aan.

Hierna kunnen we eenvoudig nog meer NTP frontend-klokken toevoegen (een van onze eisen was ook een opstelling neer te zetten die eenvoudig ‘horizontaal schaalbaar’ is, zie eerder). Dit realiseerden we door de NTP frontend-klokken te implementeren met ‘off-the-shelf’ Linux-servers en deze te koppelen in de ‘PTP-wolk’. Overigens hebben we de Linux-servers wel geoptimaliseerd voor hun specifieke taak.

De Linux-NTP-servers bieden ons daarnaast ook de mogelijkheid om NTS (Network Time Security) aan te bieden. We draaiden hier al eerder een pilot van (nts.time.nl), maar nu is NTS dus ook productiewaardig beschikbaar.

Eerste ervaringen met TimeNL versie 2

Inmiddels draait de vernieuwde opzet alweer ruim 2 maanden zonder verstoring. De frontend-klokken (Linux-systemen) presteren uitstekend, vangen piekverkeer prima op (zelfs beter dan de Meinbergs) en bieden ook extra flexibiliteit. Denk daarbij aan het kunnen ‘compartimenteren’ van functionaliteit. Dus bijvoorbeeld een interface aan ‘Netwerk A’ en een andere interface aan ‘Netwerk B’, die elk worden bediend door eigen, autonoom draaiende instanties van NTP-software. We gebruiken daarvoor overigens Chrony (Meinberg gebruikt een eigen versie van de klassieke NTP-software) en integreren dat met LinuxPTP als stratum 0 tijdbron.

Naast het beveiligen (‘hardening’) van de 2 frontend-klokken, had het optimaliseren ervan ook onze aandacht (elke nanoseconde verbetering telt ten slotte bij PTP). Dus met Chrony zetten we ook hardware-tijdstempels. We draaien een ‘low latency’-kernel en we configureerden met tools zoals ‘chrt’ real-time scheduling attributen en meer van dat soort zaken. Bij wijze van uitzondering schakelden we EEE (Energy-Efficient Ethernet) op een aantal netwerkkaarten uit, want EEE kan nadelig werken op de nauwkeurigheid, vooral als de interface weinig te doen heeft (en in slaap valt).

PTP was nieuw voor ons en we volgden een steile leercurve. De PTP-standaard komt uit de IEEE-koker, terwijl het NTP-protocol binnen de ons zo vertrouwde IETF wordt onderhouden en dat was even wennen. Het toepassingsgebied van PTP is van origine besloten en gericht op lokale en vertrouwde netwerkomgevingen. Aan de beveiliging van PTP valt daarom nog wel het nodige te verbeteren. Je wil bijvoorbeeld kunnen voorkomen dat een ‘rogue’-klok, die het BMCA fopt, ten onrechte als grandmaster (GM) kan gaan fungeren (al dan niet met kwade opzet). Dat is niet in alle gevallen triviaal. Aan dergelijke verbeteringen wordt overigens gewerkt binnen de PTP-werkgroep. En, naarmate PTP langzaam terrein wint, ook al door sommige leveranciers van PTP-hardware. Wij hebben het vooralsnog opgelost door een soort dichtgetimmerde zogenaamde PTP Boundary-Clock (BC) te bouwen, maar willen nog goed onderzoeken of dit voldoet in de praktijk.

Daarnaast waren er nog praktische zaken, zoals het opnieuw inrichten van onze monitoring en een traject voor het borgen van kennis en adequaat operationeel beheer van onze nieuwe opzet.

Next up: Pilots met netwerkoperators

Verschillende partijen uitten belangstelling voor kennisuitwisseling en/of samenwerking op basis van TimeNL. Denk bij dat laatste aan een netwerkoperator die ‘time-as-a-service’ aan klanten wil aanbieden op hun netwerk, waarbij TimeNL een van de onderliggende tijdleveranciers zou kunnen zijn. Het aanbieden van NTP is voor ons nu triviaal. En aanbieden van PTP zou op termijn ook kunnen. Hiervoor is ook belangstelling. We zien overigens ook dat andere bedrijven recent dit soort stappen, wat laat zien dat er veel belangstelling is voor dit soort diensten.

De komende tijd verkennen we of we met netwerkoperators pilots uit kunnen voeren om te leren of we hiermee bij kunnen dragen aan onze doelstelling van een veilig en stabiel internet voor iedereen.

Als deze eerste kleine stappen succesvol zijn, willen we ook nog groter denken. Wat we uiteindelijk voor ons zien is een pan-Europese ‘time-backbone’ waarover verschillende Europese tijdaanbieders hun tijd aanbieden via een wide-area-netwerk. Het multi-providerkarakter van de backbone draagt bij aan meer diversiteit in het NTP- en PTP-ecosysteem, wat de ‘resilience’ ervan verhoogt. Het voordeel van deze aanpak is dat netwerkoperators zelf geen infrastructuur (antennes, timesevers, PTP-netwerk, holdover-klokken) hoeven aan te schaffen en te beheren.

We zien deze inspanningen als een investering in de internetgemeenschap en -infrastructuur en als onze rol als aanjager van dit soort ontwikkelingen, die hopelijk door anderen worden opgepikt.

Feedback welkom

Heb jij zelf ideeën of suggesties over hoe we TimeNL kunnen blijven verbeteren, over NTP/PTP-gerelateerde onderzoeksvragen, of als je anderszins met ons van gedachten wil wisselen – neem dan vooral contact op.

1. Inmiddels teruggebracht naar 27 nodes, verdeeld over 19 locaties, waar we in totaal 100.000-175.000 NTP-qps afhandelen.

2. Los van de hardware die we gebruiken voor ‘any.time.nl’, onze anycast-pilot en ‘nts.time.nl’, onze NTS-pilot.

3. We zijn een omruil/upgrade-procedure overeengekomen en zodra de krachtiger CPU-module weer leverbaar is, plannen we die in.