Tijd is een interessant fenomeen; soms verstrijkt hij naar ons gevoel tergend langzaam, terwijl hij op andere momenten voorbijvliegt. Tegelijk tikt het klokje meedogenloos seconde na seconde, met uiterste regelmaat verder. Natuurkundig gezien is tijd dan weer relatief, waardoor datzelfde klokje dankzij gravitationele tijddilatatie in de kelder langzamer tikt dan op zolder.
Het antwoord op de vraag 'Hoe laat is het?' is van nogal wat factoren afhankelijk, zoals waar diegene die de vraag krijgt, zich op aarde bevindt en hoe precies het antwoord moet zijn op de vraag. Anno 2021 is de noodzaak om goede afspraken te hebben over de tijd belangrijker dan ooit. Wereldwijd zijn er namelijk honderden miljoenen systemen die moeten weten hoe laat het is, van pc en smartphones tot servers en internet-of-thingsapparaten.
Bij nadere inspectie is nog wel wat af te dingen op hoe goed alles geregeld isDat al die apparaten over de correcte tijd beschikken, is van belang voor tal van toepassingen. Het kan niet dat een e-mail eerder aankomt dan hij is verzonden omdat de verbonden systemen het niet eens zijn over de juiste tijd. Partijen moeten transacties op precieze tijden kunnen verrichten. Voor beveiliging is correct loggen van cruciaal belang, evenals timestamps voor het ondertekenen van code of SSL-certificaten. IT-toepassingen, telecommunicatie, astronomie, economie, medische apparatuur enzovoort: het aantal toepassingen waarbij de correcte tijd van belang is, is enorm.
In de huidige verbonden wereld zetten al die systemen hun klokken grotendeels gelijk via kloksynchronisatie. Via internet verloopt dat dan weer voornamelijk via het Network Time Protocol of NTP. Dit is een oud protocol dat werkt op basis van servers en clients, en dat tot nu toe best robuust is gebleken. Bij nadere inspectie is nog wel wat af te dingen op hoe goed alles geregeld is en met het toenemende belang van kloksynchronisatie is het de vraag of het NTP kan blijven functioneren zoals het vandaag de dag doet.
Foto: Adam Gault / Getty Images
Elke stad zijn eigen tijd
Al eeuwenlang streeft de mens ernaar dat klokken de juiste tijd weergeven, ongeacht waar ze zich bevinden. Dat was lang onmogelijk, ook na de ontwikkeling van de mechanische tijdmeting. Klokken lopen niet alleen gauw uit de pas, maar pogingen tot standaardisatie liepen op niets uit. Tot zelfs na 1800 had elke stad zo zijn eigen tijd, gebaseerd op de 'ware middag'. Dit is het moment van culminatie, waarbij de zon op zijn hoogste punt staat. De overige uren werden bepaald op basis van de methode voor tijdmeting die plaatselijk gebruikelijk was.
Wat niet meehielp, was dat er zelfs geen consensus was over het moment waarop de dag begon. In Italië liet men bijvoorbeeld de dag beginnen met zonsondergang. De 24 uur waren verdeeld in vier delen van 6 uur. Dit is de reden waarom bij sommige oude Italiaanse klokken de VI bovenaan staat. De middag begon dan zo'n 18 uur na zonsondergang en bij klokken in Venetië staat zo bijvoorbeeld de XVIII bovenaan. Omdat het moment van zonsondergang gedurende het jaar verandert, moesten kerkklokken om de vijf à tien dagen worden gecorrigeerd. Elke stad had daarvoor tabellen die aangaven hoe de wijzers verzet moesten worden.
Naarmate transport met de komst van de stoomtrein sneller verliep, werd het probleem dat de tijd tussen steden flink uiteen kon lopen, steeds groter. Dat is waarom treinmaatschappijen er in Groot-Brittannië in 1847 toe overgingen om Greenwich Mean Time te gebruiken, gebaseerd op de middelbare zonnetijd op de meridiaan van Greenwich, de zogenoemde nulmeridiaan. In België gebruikte men nog een tijd de Ware Plaatselijke Tijd van Brussel en Nederland ging nog wat langer door met de Amsterdamse Tijd als een soort nationale tijdrekening, maar gaandeweg werd GMT de internationale standaard.
Gecoördineerde universele tijd
In de jaren zestig van de vorige eeuw nam Coordinated Universal Time of UTC het stokje over van GMT. De huidige versie van de standaard is gedefinieerd door de International Telecommunication Union. Daarmee leek een mooie, wereldwijde standaard beschikbaar om alle klokken mee te synchroniseren, maar zo gemakkelijk was dat niet. UTC maakt gebruik van de seconde zoals vastgelegd als SI-eenheid, met TAI, temps atomique international, als referentie. Zoals de naam aangeeft, maakt die tijdschaal gebruik van atoomklokken, waarvan de werking op hun beurt gebaseerd is op de frequentie van trillingen van cesium. Om precies te zijn schrijft de SI-definitie van de seconde voor dat het bij die frequentie om 9.192.631.770 stralingscycli, corresponderend met de transitie van twee energieniveaus van cesium-133 gaat.
De eerste atoomklok op basis van cesium-133, UK National Physical Laboratory in 1955. Bron: Wikimedia
Daarmee zouden verschillende atoomklokken wereldwijd als referentiepunt gebruikt kunnen worden voor de 'ware tijd', maar zoals in de inleiding beschreven, is er zoiets als tijddilatatie: onder invloed van snelheid en zwaartekracht verloopt tijd sneller of langzamer. Elke atoomklok zou dus onder dezelfde invloed van de zwaartekracht moeten staan om niet uit de pas te gaan lopen. De tijd van atoomklokken moet daarom gecorrigeerd worden op basis van hun positie ten opzichte van de geoïde, de plekken waar dezelfde hoeveelheid zwaartekracht van toepassing is als op gemiddeld zeeniveau. Om de stabiliteit van TAI verder te vergroten, is de atoomtijd het gewogen gemiddelde van, tegenwoordig, zo'n 420 verschillende klokken wereldwijd. Die wegingsprocedure is opgesteld door het Tijddepartement van het Bureau International des Poids et Mesures. Klokken die last hebben van frequency drift of ouder zijn, worden als slechte klokken beschouwd en hun tijd wordt minder meegewogen.
Met de internationale atoomtijd zijn we er nog steeds niet. TAI werd op 1 januari 1958 om 0.00 uur gesynchroniseerd met UTC. 1.325.376.000 atomische seconden later zou dan zonder ingrijpen 1999 afgelopen zijn en 2000 moeten aanvangen, maar de aarde was toen nog niet op dat punt. Het zou nog 31,3 seconden duren voordat de aarde zijn 15.340e omwenteling sinds begin 1958 zou voltooien. De atoomtijd loopt dus steeds meer uit de pas met de aarde. Om de tijd bruikbaar te maken, moeten we daarom terug naar de zonnetijd en de tijdstandaard die gebaseerd is op de omwentelingen van de aarde: UT1 of Universal Time.
De Coordinated Universal Time is dan ook een compromis. Het is gebaseerd op de internationale atoomtijd vanwege de precisie, maar wordt om de zoveel tijd gecorrigeerd om UT1 zoveel mogelijk te benaderen. Dat gebeurt met schrikkelseconden.
Internetklokdiensten, satellieten en radiogolven
Computers houden zich niet zo bezig met hoe laat en welke datum het is. Ze houden vooral het verstrijken van het aantal seconden vanaf een bepaald moment bij, waar dan de tijd en datum van af te leiden zijn. Dat moment van het begin van het tellen is de epoch en verschilt per systeem. De bekendste is de Unix-tijd, die begon om 00:00:00 UTC op 1 januari 1970. Maar je hebt ook 1 januari 1601, de epoch van Win32/64 en Cobol, 0 januari 1900 van Excel, en 1 januari 1978 van AmigaOS. De computer houdt het verstrijken van de seconden bij met behulp van de real time clock waarvan de werking meestal is gebaseerd op een kristaloscillator zoals kwarts.
Rtc-module voor Arduino
Het probleem is dat de oscillatiefrequentie van die klokken niet erg accuraat is en ook nog eens afhankelijk van bijvoorbeeld de temperatuur. Een foutpercentage van 0,001 procent maakt al dat een klok bijna een seconde per dag achter of voor gaat lopen. Aangezien de verschillen flink kunnen oplopen, is de fouttolerantie niet hoog; frequentiefouten worden gemeten in parts per million. Een ppm staat voor 0,0001 procent en 12ppm is zo'n seconde per dag. Om een computerklok accuraat de tijd weer te laten geven, moet deze dan ook regelmatig gesynchroniseerd worden met een externe referentiebron die wel accuraat UTC aangeeft en daar komt dan het Network Time Protocol om de hoek kijken.
Al snel bij de opkomst van internet werd bedacht dat klokken gelijkgezet konden worden via netwerken. De basis van een protocol voor het via netwerken synchroniseren van de tijd werd al in 1981 beschreven door David L. Mills van Comsat Laboratories en werd in datzelfde jaar uitgewerkt onder de naam Internet Clock Services. In 1985 verscheen de eerste formele specificatie van het Network Time Protocol. In de jaren erna tot nu werd het NTP vier keer grondig bijgewerkt en uitgebreid. We zitten nu dan ook op NTP v4, maar de basis wat packetheaders en het berekenen van vertragingen betreft is nagenoeg hetzelfde gebleven.
Het NTP werkt met clients en servers, en op basis van timestamps. De eerste timestamp T1 is die van de klok van de client, op het moment van zenden van de request, al is dat tegenwoordig iets aangepast vanwege privacy en dataminimalisatie. De server ontvangt de request en registreert dat met timestamp T2. Vervolgens verzendt de server zijn antwoord op moment T3 en ontvangt de client dit op T4. De vertraging wordt vervolgens berekend met de formule (T4-T1) – (T3-T2) en het tijdsverschil wordt verkregen via ((T2-T1) + (T3-T4))/2. In de jaren tachtig was het systeem zo op tienden van milliseconden accuraat via ethernet, aldus grondlegger David L. Mills. De timestamps worden als onderdeel van NTP-packets met UDP via poort 123 verstuurd. Gekozen is voor UDP, of het User Datagram Protocol, vanwege de snelle verbindingsset-up en responstijden.
De NTP-packets bestaan verder uit de header, de extension fields en de message authentication code, maar alleen de header is verplicht. Op basis van het antwoord van de NTP-server wordt de klok van de client aangepast. Die aanpassing gebeurt met het NTP clock discipline algorithm en dat past niet alleen de tijd, maar ook de frequentie van de clientklok aan. Door verbeteringen van het algoritme, is de synchronisatie met steeds meer precisie gaan verlopen.
Satellieten en lange radiogolven
Daarmee hebben we een referentietijd en een methode om daarmee te synchroniseren. Dan ontstaat het volgende probleem: hoe voorkomen we dat de servers die UTC bieden, overbelast raken als zich te veel clients melden die de tijd opvragen? Daarvoor heeft het NTP een hiërarchische structuur met een stratumindeling bedacht. Op stratum 0-niveau staan de apparaten die gegarandeerd de juiste tijd aangeven, zoals de eerder vermelde atoomklokken, maar ook Galileo, GPS en Glonass vallen hieronder, omdat die ook cesiumklokken aan boord hebben die regelmatig worden gecorrigeerd.
Opvallende stratum 0-bronnen zijn enkele radiozenders wereldwijd die via de lange golf tijdpulsen uitzenden, zoals het Duitse DCF77, dat op 77,5kHz werkt. Die zender staat in Mainflingen en geeft in een straal van meer dan 1500 kilometer in Europa de tijd aan. Het begin van elke puls markeert daarbij het begin van een nieuwe seconde en is er een minuut verstreken, dan ontbreekt er één puls om dat aan te geven. Overigens verkrijgt ook DCF77 de juiste tijd van atoomklokken.
Apparaten maken niet direct verbinding met stratum 0, maar met andere stratum-servers. Stratum 1-systemen zijn servers met de hoogste accuraatheid. Ze zijn gesynchroniseerd met stratum 0-bronnen en de afwijking bedraagt hooguit enkele microseconden. Dit zijn de primaire tijdservers en ze zijn ook onderling vaak verbonden voor controle en back-up. Stratum 2-servers zijn clients van stratum 1 en verkrijgen zo UTC. Ze kunnen dat weer doorgeven aan hun clients, die dan weer als stratum 3 kunnen fungeren enzovoort. Hoe lager de plek die de NTP-server in de stratumhiërarchie inneemt, hoe groter de kans is dat je klok niet volledig accuraat op UTC gesynchroniseerd wordt. Het aantal toepassingen dat werkelijk zo nauwkeurig gesynchroniseerd moet worden dat verbinding met stratum 1 vereist is, is echter ook weer niet zo groot.
Er zijn wereldwijd duizenden NTP-servers en een groot deel daarvan is publiek. Iedereen kan verbinding met deze servers maken voor kloksynchronistatie. Een van de partijen die een publieke stratum 1-server aanbieden, is de SIDN met TimeNL. De server synchroniseert met GPS en Galileo, en met DCF77 als back-up. Waarom doet de stichting voor domeinnaamregistratie dit en wat is het belang van de SIDN? We vroegen het Marco Davids, research-engineer bij de SIDN en verantwoordelijk voor het project. "We wilden aandacht geven aan het NTP. Het is zo'n standaard die iedereen gebruikt, maar waarvan onduidelijk is hoe het is geregeld. We zagen ook dat er bedrijven zijn die het intern niet goed geregeld hebben. IT-beheerders moeten nadenken: 'Waar haal ik de tijd op voor mijn servers?' Onder andere voor de validatie van Dnssec is de juiste tijd van belang. We helpen de wereld een stukje verder met een transparante NTP-dienst waarbij we aangeven wat gebruikers kunnen verwachten. Hopelijk inspireert dat anderen om hetzelfde te doen."
Marco Davids bij de ontvanger voor TimeNl op het dak van de SIDN in Arnhem
Die duidelijkheid en transparantie rond het NTP ontbreken immers. Het NTP is meegegroeid met internet. Aanvankelijk draaiden hobbyisten, academische instellingen en andere instituten uit ideële motieven NTP-servers. Een deel doet dat nog steeds, maar enkele partijen zijn gestopt vanwege de toename van het verkeer. Sindsdien is er een soort splitsing ontstaan met aan de ene kant NTP-servers van de bigtechbedrijven en aan de andere kant de NTP Pool. Google heeft time.google.com, Apple biedt met time.apple.com een publieke NTP-dienst aan enzovoort. Davids: "Je vindt er niet zoveel informatie over, maar volgens mij zijn die initieel gemaakt voor de eigen producten. Mijn MacBook praat netjes met time.apple.com en Google heeft natuurlijk ook hardware."
"Wie kun je bellen bij problemen? Er is niets geregeld." Iedereen kan de diensten gebruiken, maar Google meldt bijvoorbeeld nadrukkelijk geen service te bieden met zijn NTP-dienst. Over Apples dienst is nauwelijks informatie te vinden. Volgens Davids geldt dat voor veel publieke NTP-diensten. "Het aanbod van NTP-servers heeft zich op een diffuse manier ontwikkeld. We hebben naast die diensten nog een legacy van enkele universiteiten en meteorologische instituten die nog servers draaien. RIPE heeft er een, Surfnet heeft er een. Er is een mix van servers, maar als je probeert te achterhalen welke service je kunt krijgen en wie je kunt bellen bij problemen: niks. Er is niets geregeld."
Hoe weet je welke NTP-server je kunt gebruiken? Voor 2003 moest je een lijst zien te vinden van publieke servers. Begin dat jaar uitte Adrian von Bidder het idee om een pool van NTP-servers te starten na een discussie die werd aangeslingerd door David L. Mills over het groeiende probleem van misbruik van servers en het stoppen van servers door toenemend dataverkeer. Von Bidder stelde voor een soort round-robin dnsvoor tijdservers op te zetten waarbij clients alleen pool.ntp.org hoefden in te stellen en ze automatisch al roulerend met een server in de pool verbonden zouden worden. Het project werd een groot succes. Inmiddels zijn er volgens het project zelf 2989 actieve IPv4-servers en 1460 IPv6-servers. Hoeveel clients gebruikmaken van de pool, is niet te zeggen vanwege het decentrale karakter van het systeem. Pool.ntp.org krijgt volgens de eigen statistieken dagelijks tussen de 35.000 en 40.000 dns-queries per seconde. De schatting die op de site van de NTP Pool staat, is dat 5 tot 15 miljoen apparaten gebruikmaken van de pool, maar dat aantal staat er al sinds in ieder geval 2018.
Hoe robuust is de pool?
Davids: "Naar mijn idee is dat veel te laag geschat. We vermoeden dat, zeker met de komst van de internet-of-thingsapparaten, het verkeer enorm toeneemt. We zien het omhoogschieten. Het NTP-verkeer verdubbelt op onze apparaten elk jaar. Vanuit de clientkant is er weinig onderzoek gedaan. Daar willen wij ons op richten. We willen weten hoeveel clients er nu eigenlijk zijn die het NTP nodig hebben. Praten die met Apple, Google of de pool? En hoe robuust is de pool nu eigenlijk?" De SIDN alleen al ontvangt op zijn 28 anycastservers wereldwijd 80.000 tot 150.000 NTP-queries per seconde. Het aantal is afhankelijk van het tijdstip, met name China bezorgt any.time.nl, de naam van de ge-anycaste NTP-server, veel verkeer.
NTP-requests per seconde gedurende het jaar bij ntp1.time.nl
Davids: "Al met al valt aan te nemen, op basis van onze statistieken, dat er honderden miljoenen devices wereldwijd zijn die hun tijd betrekken van de NTP-pool. Dat zijn zeker niet alleen laptops en pc's, maar ook telefoons, allerhande embedded devices en iot-apparaten zoals IP-camera's, Amazon- en Sonos-producten, wifilampen en ga zo maar door. In Europa zie ik ook de nodige AVM FritzBox-producten voorbijkomen."
Overzicht van een van de 28 NTP-servers van SIDN's any.time.nl. De servernamen verwijzen naar luchthavens. Nrt1-2 staat voor Narita, Tokio.
De NTP Pool probeert zich enigszins voor te bereiden op problemen. Het project roept leveranciers van producten en applicaties op om zich te melden om een eigen hostname in de vorm van leverancier.pool.ntp.org te claimen. Als clients op hol slaan en een stortvloed aan queries genereren, kunnen die leveranciers makkelijk uitgesloten worden. Davids: "Wij willen graag weten of leveranciers dat ook doen; welke zijn er allemaal?"
Volgens Davids is er nog een wereld te winnen wat de correcte implementatie van het NTP betreft. "Er is nagedacht over een getrapt systeem. Een DHCP-server kan bijvoorbeeld meegeven bij het uitdelen van IP-adressen: 'By the way, dit is de tijdserver die je kunt gebruiken'. We zien dat echter nauwelijks gebeuren. Mijn IP-cameraatje thuis zou dus een melding kunnen krijgen van mijn kabelmodem: 'Ik ben jouw nameserver en jouw timeserver'. De kabelmodem praat dan met de NTP-server. Dat zou een server uit de pool kunnen zijn, maar liefst hebben alle isp's ook een tijdserver. Technisch kan het, maar het komt in het wild niet voor. Negen van de tien iot-apparaatjes die worden aangesloten, praten afzonderlijk met de pool en genereren zo weer meer verkeer." Het kan zelfs om afzonderlijke mobiele apps gaan. In 2016 liet Snapchat op iOS een grote hoeveelheid queries los op de NTP Pool, wat werd verholpen nadat het bedrijf gewaarschuwd werd.
Fabrikanten stellen dus in de firmware in dat apparaten met pool.ntp.org verbinding moeten maken voor de juiste tijd. Dat lijkt ook niet altijd goed te gaan. "We zien soms dat TimeNL benaderd wordt door apparaten die soms wel tien keer per seconde langskomen, terwijl het eigenlijk de bedoeling is dat ze langskomen, van ons de tijd krijgen en dat we ze daarna een kwartier of half uur niet meer zien. Als dat drie keer per seconde gebeurt, geven we al geen antwoord meer, maar ik ben benieuwd waarom dat gebeurt. Is het kwaadaardig, zit er een firewall in de weg of is het een slecht geïmplementeerde NTP-stack? We zien alleen een IP-adres, dus het is lastig onderzoeken. Naarmate dit soort problemen toenemen, wordt het steeds moeilijker de wereld te voorzien van goede tijd."
NTP: gerund door vrijwilligers
De afhankelijkheid en het belang van het virtuele cluster van tijdservers nemen toe door de groei van het aantal apparaten dat de juiste tijd nodig heeft. De NTP Pool draait volledig op vrijwilligers. Sterker nog, de pool wordt grotendeels gerund door een enkele vrijwilliger: Ask Bjørn Hansen. Hij nam in 2005 het stokje over van Von Bidder en beheert en ontwikkelt sindsdien het systeem. Hij is ook de drijvende kracht achter de opensourcesofware voor de pool.
Ask Bjørn Hansen
Wat opvalt, is dat er op Hansen na weinigen echt actief zijn en dat zijn verantwoordelijkheid erg groot lijkt. Zo is hij de enige die als contactpersoon wordt vermeld, met het persoonlijke adres van zijn bedrijf Develooper, bijvoorbeeld voor als leveranciers zich willen melden voor een eigen zone en voor donaties. Ook is hij de enige die nog lijkt te reageren bij issues met de NTP Pool-software. Tegelijk lijkt Hansen niet meer zo nauw betrokken bij het project als voorheen. Hij reageert op het NTP Pool-forum onregelmatig en alleen reactief bij problemen. We hebben contact gelegd met Hansen om hem te vragen naar de huidige stand van zaken en zijn rol rond de pool, maar na een aanvankelijke toezegging reageerde de vrijwilliger niet meer. Daardoor lijkt het onduidelijk of er bijvoorbeeld een back-up is als Hansen om wat voor reden ook wegvalt bij het project. Hoe is de continuïteit van de NTP Pool geregeld?
Hansen beheert bijvoorbeeld ook de monitoringserver. Dat is de server die in de gaten houdt of servers nog wel beschikbaar zijn en met precisie de tijd aangeven. Detecteert de software dat een server niet correct de tijd aangeeft, dan wordt deze uit de pool verwijderd. Er zijn weleens problemen met die monitoring, waarna Hansen software- of hardwarewijzigingen moet doorvoeren. Wie heeft ook die kennis en toegang, en hoe goed is die server eigenlijk beveiligd? Wat als iemand inbreekt op de server en de software zo aanpast dat alle NTP-servers uit de pool geknikkerd worden?
Ook de situatie rond het NTP Project zelf roept vragen op. Dat is het door vrijwilligers gerunde project rond de ontwikkeling van het NTP. De homepage van ntp.org is sinds 2014 niet meer bijgewerkt, tal van links werken niet meer, en als editor en contactpersoon als zodanig wordt nog David L. Mills vernoemd, de 'uitvinder' van het NTP die in 2008 met pensioen is gegaan en nu 83 jaar oud is. Achter het project zit sinds 2011 de stichting Network Time Foundation, opgericht door Harlan Stenn.
Harlan Stenn in 2015
De nu 65-jarige Stenn is al sinds 1992 betrokken bij het NTP Project en sinds 1996 de projectmanager. In 2015 beklaagde hij zich tegenover InformationWeek over het gebrek aan vrijwilligers en de enorme hoeveelheid werk die hij in de ontwikkeling stak. Hij dreigde te stoppen als de financiële situatie niet zou verbeteren, want ook aan geld ontbrak het. Dat werd in dat jaar wel opgelost door een bijdrage van VMware van 60.000 dollar. Dat bedrijf is nog steeds de enige Premier Member. Verder sprak hij de vrees uit dat NTP met een hack te maken zou krijgen of om andere redenen zou stoppen met functioneren. "Als dat gebeurt, gaan alle critici zeggen: 'Zie, je kunt opensourcecode niet vertrouwen'", zei Stenn destijds. In 2017 herhaalde hij tegen The New Stack zijn klacht dat nieuwe vrijwilligers nodig waren. Anno 2021 is de situatie dat als projectleden bij de stichting Mills, Stenn en een andere ontwikkelaar, Juergen Perlinger genoemd worden. Stenn, noch Perlinger, reageerde op vragen over de status van de stichting.
Wat niet meehelpt, is dat Stenn toegaf dat de code van het project erg complex is en dat hij ondanks zijn jarenlange ervaring nog lang sterk op David L. Mills leunde bij veranderingen van de code. "Als je niet precies begrijpt hoe alles werkt en in elkaar past, kunnen verschrikkelijke dingen gebeuren als de dingen gaan lopen. Zelfs een paar jaar is niet voldoende om alles te bevatten." Mills zelf beaamde dit zes jaar geleden. Volgens hem zijn de delen die betrekking hadden op monitoring en controle 'zo complex dat het hele ding uit elkaar valt als je iets aanpast'.
Beveiliging tegen spoofen
De code moet regelmatig bijgewerkt worden, want in de afgelopen jaren zijn er de nodige kwetsbaarheden gevonden. De beveiliging van het NTP is hoe dan ook een belangrijk onderwerp. In 2014 vond een grote NTP-reflectionaanval plaats op Cloudflare. Dat was een ddos-aanval die gebruikmaakte van IP-spoofing. Als een bepaald verzoek vanaf een gespooft IP-adres naar een NTP-server wordt gestuurd, wordt een lijst met de laatste zeshonderd IP-adressen die contact hebben gehad met de server, naar het opgegeven IP-adres gestuurd. Dat krijgt daarop een grote hoeveelheid verkeer te verduren. Belangrijker is dat ook de antwoorden van de NTP-servers gespooft kunnen worden, waardoor die dus de verkeerde tijd uitzenden. Er zijn echter meer manieren om bij aanvallen de tijd aan te passen of de synchronisatie te stoppen. Een onjuiste tijd maakt bijvoorbeeld weer misbruik met certificaten mogelijk. Daarnaast is het NTP vatbaar voor gebruik als covert channel, om bijvoorbeeld heimelijk malware of andere data door te sluizen.
Een belangrijke oorzaak van de kwetsbaarheid ligt bij het gebrek aan authenticatie. Nu bevatten de netwerkpakketjes geen geheimen, maar het is wel zo handig om er zeker van te zijn dat de tijdpakketjes daadwerkelijk van de verwachte NTP-server afkomstig zijn en niet gespooft zijn door een man-in-the-middle. NTP v3 introduceerde daarom cryptografische handtekeningen met symmetrische sleutels om authenticatie mogelijk te maken. Bij NTP v4 verscheen aanvullend de autokeyfunctie op basis van publieke en private sleutels. Deze functie bleek niet zo veilig als gehoopt en werd ook niet veel gebruikt, zodat er inmiddels een opvolger is in de vorm van network time security.
"Hoe ga je bij een paar duizend servers TLS-certificaten verspreiden?"Ook de SIDN experimenteert hier al mee. De stichting biedt als pilot een NTS-server aan. Davids: "NTS werkt initieel met TLS. De client moet eerst via een TLS-verbinding acht cookies ophalen, daarna kan hij met een NTP-server praten en elke keer als hij dat doet, verbruikt hij een cookie. Dit verloopt via de extension fields die het NTP tegenwoordig heeft. De NTP-server controleert of het een cookie is die hij heeft uitgegeven, en als dat zo is, geeft hij in zijn antwoord weer wat nieuwe cookies mee. De client controleert de cookies natuurlijk ook. Je hoeft dus maar één keer een TLS-verbinding op te zetten." Daardoor is het systeem prima schaalbaar, maar er zijn wel technische uitdagingen om NTS bij de NTP Pool te implementeren. "Bij de pool weet je nooit zeker bij wie je met je clients terechtkomt. Bij de tweede sessie kom je misschien bij een andere server terecht dan waarvan je de eerste keer cookies kreeg. Bovendien: hoe ga je bij een paar duizend servers TLS-certificaten verspreiden?"
De werking van Network Time Security. Bron: Weberblog
Inmiddels wordt bij de NTP Working Group van de Internet Engineering Task Force al gediscussieerd over NTP v5. Naast een nog hogere accuraatheid wordt overwogen om de beveiliging verplicht te maken om gebruikers te bewegen authenticatie in te voeren. Als tegenargument wordt aangevoerd dat verplichte beveiliging indruist tegen de flexibiliteit, dat sommige toepassingen geen beveiliging vereisen en dat het afzonderlijk ontwikkelen van de beveiliging het makkelijker maakt om de standaard up-to-date te houden. Hoe dan ook is het goed om te zien dat de werkgroep flink actief is, nadat Mills tot aan NTP v4 flink de kar trok bij de ontwikkeling. De volgende vraag is dan hoe de standaard aan de man gebracht wordt, met goede documentatie, met duidelijke richtlijnen en waarborgen, en met continuïteit.
Tot slot: over vrijwilligers en big tech
Het Network Time Protocol is een van de wat verborgen internettechnieken die toch een zeer belangrijke rol spelen. De huidige werking en inzet zijn organisch gegroeid en behoefte tot regulering is er blijkbaar nooit geweest, ook niet omdat het tot nu toe niet zo'n ramp was als er zaken misliepen. De gevolgen bij dns-problemen zijn bijvoorbeeld groter. Het systeem werkt, maar dat lijkt meer geluk dan wijsheid.
De vraag is of dat zo blijft nu het aantal iot-apparaten dat de tijd opvraagt, flink groeit en beveiliging belangrijker is dan ooit. Ook is het de vraag of het wenselijk is dat de verantwoordelijkheid voor de zo belangrijke NTP Pool en het NTP Project al zo lang op de schouders rust van twee vrijwilligers, die er niet jonger op worden en van wie onduidelijk is hoeveel motivatie en tijd ze nog hebben. Er zijn meer voorbeelden van belangrijke diensten en toepassingen die wel erg afhankelijk zijn van enkele personen, zoals Gnu Privacy Guard, dat ontwikkeld wordt door Werner Koch, of de BASH-shell van Unix, die sinds begin jaren negentig beheerd wordt door Chet Ramney.
De volgende vraag is dan welke instantie de verantwoordelijkheid voor het NTP naar zich toe moet trekken. Weinig partijen lijken er het belang van in te zien dat miljoenen apparaten wereldwijd over de correcte tijd blijven beschikken. Een van de weinige uitzonderingen lijkt Zweden, waar de nationale telecomautoriteit in 2013 bepaalde dat het land een robuuste en betrouwbare publieke tijddienst nodig had. In 2015 begon het Zweedse internetknooppunt Netnod daarom een nationale NTP-dienst. In Nederland benadrukt de SIDN zoals genoemd het belang van NTP met zijn TimeNL-dienst.
Het risico bestaat dat big tech het beheer naar zich toe gaat trekken, al is niet duidelijk welk belang deze bedrijven hierbij hebben. Duidelijk is wel dat het NTP de aandacht van de grote techbedrijven heeft. Google meldt een publieke NTP-dienst te zijn begonnen omdat het voorstander is van het uitsmeren van de tijd om UTC weer in lijn te brengen met UT1, in plaats van de standaardpraktijk om eens in de zoveel tijd een extra seconde of leap second in te voegen, waardoor je 23.59.60 als tijd kunt zien. Dit maakt dat Googles server beter niet geconfigureerd kan worden in combinatie met NTP-servers die wel met leap seconds corrigeren. Ook Facebook gebruikt leap smearing met zijn publieke NTP-dienst time.facebook.com. Facebook werkt aan zijn eigen NTP-libraries, die het open source beschikbaar stelt.
Facebooks mobiele testset-up om accuraat tijdmetingen te verrichten met behulp van gnss en een atoomklok. Bron: Facebook
CloudFlare gebruikt het verbeteren van de beveiliging als argument. Het bedrijf was in 2014 dan ook slachtoffer van een NTP-ddos-aanval. Het biedt net als de SIDN al een Network Time Security-server aan. CloudFlare manifesteert zich flink in de NTP Pool en de kans is groot dat een client praat met een NTP-server van dit bedrijf bij het opvragen van de tijd via pool.ntp.org. Volgens Davids kan het voorkomen dat je van de 100 keer dat je verbinding maakt met de pool, 75 keer bij CloudFlare uitkomt en in sommige zones, is CloudFlare zelfs de enige partij die een NTP-server aanbiedt. Apnic kwam vorig jaar op 15,6 procent uit waarbij met een CloudFlare-server uit de pool verbonden werd, waarmee het bedrijf de dominante partij was.
Misschien zijn alle zorgen ongegrond en mogen we blij zijn met een stukje ongereguleerd internet dat af en toe rommelig oogt, maar waarbij alles uiteindelijk toch weer goed komt dankzij het harde werk van een groep vrijwilligers. Misschien is de groei van het verkeer prima op te vangen, met een combinatie van NTP-servers van instituten, hobbyisten en de grote techbedrijven. De tijd zal het leren.
Mooi verhaal! Ik mis alleen een vermelding voor Poul-Henning Kamp (een Deen, wat is het met Scandinaviërs en NTP?) die zich al een tijd met NTP bezig houdt.
Poul-Henning Kamp is ook de drijvende kracht achter het Ntimed Project, onder andere om de client en server implementaties robuuster te maken. Dit moet onder andere bereikt worden met veel beter onderhoudbare code en een veel modulairder opbouw omdat veel simpele time-clients een hoop van de functionaliteit in de bestaande implementaties helemaal niet nodig hebben. En code die niet in je implementatie zit kan ook geen zwaktes bevatten.
Als je een beetje een "time geek" bent dan is deze Fosdem presentatie van hem erg boeiend. Hier een verslag van een bezoeker van die presentatie: Ntimed: an NTPD replacement om wat meer uitleg rond de presentatie te hebben.
[Reactie gewijzigd door Maurits van Baerle op 22 juli 2024 14:07]
Dat van "DDoS-en" van NTP servers is zeker wel een belangrijk punt.
Na het lezen van dit artikel, realiseer ik me dat "ik" (ontwikkelaar ESPEasy) wellicht evengoed onbewust hier aan meewerk.
In het artikel noemen ze het blokkeren van N requests vanaf hetzelfde IP.
Stel ik heb 10 nodes draaien met mijn software (sommigen hebben er 100+ draaien) die default pool.ntp.org gebruiken. Elke node haalt 1x per uur z'n tijd op (zou op zich al groter interval kunnen zijn). Dan heb je gemiddeld al 1x per 6 minuten een NTP query vanaf hetzelfde publieke IP.
Echter wat gebeurt er na een stroomstoring? Dan hebben alle nodes dezelfde uptime, dus ook ruwweg hetzelfde moment dat ze de tijd opvragen.
Dan heb je al makkelijk 10 requests binnen een paar seconden (misschien zelfs binnen dezelfde seconde) vanaf hetzelfde publieke IP.
Stroomstoringen treffen vaak een groter gebied, dus wellicht is die periodieke piek nog wel groter en kan het heel lang duren voordat die piek een beetje afvlakt doordat nodes in de tussentijd herstart zijn of de interne klok niet zo nauwkeurig is.
Kortom, ik zal zeker al in mijn software een random offset gaan introduceren. Wellicht zelfs een dynamische die kijkt bij het synchroniseren hoe onnauwkeurig de interne klok is en aan de hand daarvan een dynamisch interval bepaalt.
Ook kan het interessant zijn om lokaal te kijken welke node al 'bij de tijd' is, zodat je het veel minder vaak elders hoeft te vragen.
In de praktijk zijn er erg weinig routers die default een NTP service draaien, dus dat is helaas geen optie om standaard vanuit te gaan.
Ja, zoals ik iets verderop al zei, het probleem is dat je meestal een correcte tijd moet hebben om een verbinding met encryptie op te zetten. Je kunt meestal dus niet even vijf minuten wachten na een stroomstoring voordat je de eerste sync doet.
Wat je misschien zou kunnen doen is de eerste sync met een random vertraging van vijf of tien seconden doen (in het ergste geval is een device dus tien seconden later online). Pas bij een tweede sync zet je die random vertraging op tien minuten of zo. Daarmee smeer je de initiële piekbelasting al heel snel uit over een langere periode.
Yep dat random gedrag is precies wat ik bedoelde.
Sowieso heb ik al een beetje random gedrag erin zitten met het verbinden met WiFi, puur om de access points een beetje te ontlasten bij het weer online komen na een stroomstoring.
Maar evengoed, als het langer duurt om de internetverbinding weer online te krijgen dan de access points, dan krijg je nog steeds zo'n burst aan NTP requests die ook periodiek weer terugkomen (in de huidige code base).
Stroomstoringen treffen vaak een groter gebied, dus wellicht is die periodieke piek nog wel groter en kan het heel lang duren voordat die piek een beetje afvlakt doordat nodes in de tussentijd herstart zijn of de interne klok niet zo nauwkeurig is.
Gelukkig heeft de meeste hardware ook een batterij-gevoede hardware-klok om een indicatie van tijd te hebben. Dus alle PC's, laptops, telefoons en dergelijke zullen niet meedoen in de piek. Plus, als je gebruik maakt van de pool dan zal de load door DNS redelijk verdeeld worden. Je kunt eventueel overwegen om de initiële timesync via pool.ntp.org te doen en de daaropvolgende via <landcode>.pool.ntp.org.
Mijn firmware doet alles via pool.ntp.org (tenzij de gebruiker een andere host instelt)
Maar zoals ik al schreef, vermeld het artikel hier dat ze hosts soms blokkeren die frequent requests doen vanaf hetzelfde IP... naar pool.ntp.org dus.
In theorie is dat dus precies wat mijn firmware doet bij units die geen RTC met batterij hebben, zoals een ESP.
Maar goed, ben nu dus gelijk een random distributie aan het inbouwen, deels ook gebaseerd op de nauwkeurigheid van de interne klok.
Punt is alleen dat met een onnauwkeurigheid van 10 ppm (datasheet Espressif, over vereiste nauwkeurigheid kristal) zit je met een marge van 36 msec als je de correctie baseert op 1 uur interval.
Dat is dezelfde orde van grootte als de ping-tijden naar een NTP host.
Moet dus nog even stoeien met die te berekenen afwijking.
Wellicht een idee om contact met ze op te nemen over een eigen subdomein. Dat zal het tenminste makkelijker maken om vanuit NTP.org een oog te houden op wat de ESP-easy apparaten doen.
Heel goed! Je kunt ook nog overwegen om tegen 2.pool.ntp.org aan te gaan praten; de enige met IPv6. Mochten je devices over IPv6 beschikken, dan komen ze allemaal van een uniek source address.
Ze pakken sowieso al random een van de verschillende pools.
Dat zit er dus sowieso al in.
Aanpasing is trouwens verwerkt
Mijn firmware ondersteunt vooralsnog geen IPv6. Zelf heb ik thuis al sinds dat XS4all dual-stack mogelijk maakte een dual-stack verbinding. Maar op de ESP devices zelf heb ik het nog niet gemist.
Is het misschien mogelijk in ESPeasy om via dhcp de lokale ntp-server op de router te leren en pas als dit niet lukt "terug te vallen" op pool.ntp.org? Op mijn AVM router draait bijvoorbeeld chrony, zie ook de ntp wikipedia pagina.
Standaard gebruikt chrony op de router ook de pool als ik me niet vergis.
Ik heb het geprobeerd om de NTP uit een DHCP reply te lezen, maar dat is me niet gelukt.
Ik zou natuurlijk de gateway kunnen proberen voor NTP, maar geen idee hoe vaak dat ook echt een NTP server is.
Op mijn MikroTik moest ik het expliciet aanzetten en door mijn netwerk-layout voor IoT devices is de gateway van nodes niet gelijk aan mijn router.
Maar op de ESP devices zelf heb ik het nog niet gemist.
Misschien niet, maar de implementors die met allerlei creatieve toeters en bellen, zoals NAT, de IPv4-ballen proberen hoog te houden zodat jij door kunt, missen jou ongetwijfeld wel in de IPv6-familie!
Moah dat valt wel mee denk ik hoor
Toegegeven, als ik in de statistics van mijn (Mikrotik) router kijk, dan is zo'n 70 - 75% van mijn traffic over IPv6.
Maar als je je dan realiseert dat de 'grootverbruikers' qua data hier in huis, zoals IP-TV, YouTube, Netflix en Disney en de backups vanaf mijn server naar huis via IPv6 gaan, dan is het eigenlijk maar een fractie van het aantal hosts wat je verder bezoekt.
Ook heb ik nog niet echt van een gebruiker vernomen dat er iemand echt niet verder kan zonder IPv6 ondersteuning.
Daarnaast is het best wel een beetje lastig om te implementeren. Al was het alleen al omdat mijn bestandsformaten geen ruimte hebben voor een IPv6 adres, dus moet je daar weer omheen gaan werken om de zaken compatible te houden.
Raymond Chen heeft een (naar mijn mening) interessant blog met een heleboel artikelen over waarom dingen in Windows zijn zoals ze zijn. Ook over de epoch keuze.
The FILETIME structure records time in the form of 100-nanosecond intervals since January 1, 1601. Why was that date chosen?
The Gregorian calendar operates on a 400-year cycle, and 1601 is the first year of the cycle that was active at the time Windows NT was being designed. In other words, it was chosen to make the math come out nicely
Volgens mij heeft dat meer betrekking op de interne klok van een apparaat die geen rtc op kwartsbasis heeft. Mijn 'domme' magnetron staat geregeld niet juist qua tijd, minuutje verschil.
Er is enorm veel software die net niet overweg kan met een een schrikkelseconde, die software is beter gediend met het uitsmeren van die seconde over een langere periode ipv een extra seconde in de dag te hebben. Het is ook een veel gebruikte techniek om verschillen in tijd, wanneer klokken niet synchroon lopen, weg te werken. Want ook daar zijn weer veel programma's die er niet van houden. Zeker als de klok is beginnen voorop lopen en je dus ineens terug achteruit springt in de tijd.
Google en FB passen dus een principe toe dat veel gebruikt wordt en zorgt voor consistentie. Wanneer nauwkeurigheid iets minder belangrijk is dan consistentie.
Het is maar een minuut en ik zie wel dat er voordelen aan zouden hangen, maar die laatste alinea's brengen wel een belangrijk punt hier naar voren, Big tech kan zich ook gewoon aan de standaarden houden.
Ik geloof namelijk niet dat er zo veel software afhangt van smearing tov. een schrikkelseconden.
En bij software die juist afhangt van het hebben van de exacte tijd houden ze waarschijnlijk juist rekening met de standaard van een schrikkelseconde. En dat gaat dus nu opeens fout als je timeservers van Google of FB gebruikt. (okee... in die ene minuut per 3 a 4 jaar... maar toch ;-))
Er is ontzettend veel software wat niet overweg kan met een schrikkelseconde.
Ze zullen vast niet allemaal crashen , maar er zijn zeker wel situaties denkbaar waarbij de gevolgen erg vervelend kunnen uitpakken, al zal dat vrijwel altijd wel een vrij specifieke samenloop van omstandigheden zijn.
En het gaat niet om die ene minuut in de zoveel tijd, maar die ene extra seconde in de zoveel tijd.
Dat "uitsmeren" wil dus wel zeggen dat de "tijd" van een dergelijke time server tot wel een seconde kan afwijken (of +/- 500 msec, afhankelijk van de implementatie) van de echte tijd.
Voor het registreren van wanneer een bericht gepost is, of een mail binnenkomt maakt dat niet zoveel uit.
Echter voor taken die gelijk moeten lopen, of het bepalen van de duur van een proces kan het een 'eeuwigheid' zijn wanneer beide kanten een verschillende tijdserver gebruiken.
Kortom, hangt helemaal af van de toepassing of het een probleem is.
Heel simpel voorbeeldje.
Stel je schakelt met je domotica-systeem op 2 plekken een lamp aan op een specifieke tijd.
Beide schakelaars zijn met verschillende time-servers gesynchroniseerd.
Dan gaat aan de ene kant van je kamer de lamp merkbaar later aan dan aan de andere kant van de kamer.
Is dat een probleem? Waarschijnlijk niet. Maar merkbaar is het wel.
Again, ik geloof niet dat er ontzettend veel software is wat niet overweg kan met schrikkelsecondes.
Als tijd al belangrijk is in een stuk software dan is dat vooral voor een tijds interval, niet de specifieke tijd.
Mocht de specifieke tijd wel belangrijk zijn dan zit je dus nu met de situatie die jij schets.
Software die wel standaard compliant is, dus met schrikkelsecondes en 1 seconde altijd even lang werkt niet correct als je Google of FB timeservers gebruikt
En je lampen gaan 0.5 secondes te vroeg aan (yeah, I know, we hebben het echt over niks. not the point though ).
Als dev mag je dus voor 2 situaties gaan programmeren. De standaard situatie en de Google/FB situatie. En dan nog maar hopen dar Google en FB het zelfde smear algoritme gebruikt, anders heb je al 3 situaties.
Zie je het probleem met standaarden niet volgen?
Interessant artikel. Ik gebruik NTP services al decennia om mijn de tijd van mijn systemen mee te synchroniseren, maar ik heb me nooit gerealiseerd dat de publieke service als de NTP Pool letterlijk afhangt van één vrijwilliger ... Dit geeft wel te denken ... Op deze manier komt het over als een enorm fragiele operatie en dan komt daar de schijnbare complexiteit van de onderliggende software ook nog eens bij ... Een dienst die wereldwijd gebruikt wordt in ontelbare apparatuur en zeker veel Linux distributies hebben deze als standaard geconfigureerd wanneer NTP in geschakeld wordt. Kudos voor de vrijwilligers die dergelijke services soms al decennia draaiend houden. Waarom er geen grote bedrijven zijn die hier in de vorm van een consortium o.i.d. geld insteken is me een raadsel. De 60k van VMware voelt erg goedkoop ...
Ik vraag me ineens af of er hier geen rol in EU-verband is weggelegd, in het kader van het robuuster maken van de Europese strategische infrastructuur.
Ik zie een pool van 27 fysieke locaties (in iedere EU-lidstaat eentje) met Stratum-1 servers voor die onderling ook hun tijd met elkaar vergelijken. Je zou het geheel onder kunnen brengen bij het Galileo-project waar een flink deel van de expertise toch al aanwezig is en de totale kosten van zo'n projectje in het niet vallen.
Kost je amper 1500 euro, voor de thuisgebruiker nu niet meteen haalbaar maar als je iets of wat van strategische infrastructuur draait maakt dat niet uit. Pluspunt is dat je tijd kan blijven syncen als verbinding met internet wegvalt maar ook de mogelijkheid om een stratum 1 lokaal neer te zetten.
Immers indien je echt op academisch niveau zeer preciese tijd nodig hebt, als de stratum 1 server remote staat is dat NTP pakket enkele milliseleconden onderweg dus tegen dat je het pakket krijgt is de inhoud al verouderd. Bij mijn weten compenseert het NTP protocol hiervoor niet.
Misschien denk ik te simpel, maar wat als je een RasPi opzet met een GPS ontvanger? Je krijgt van het GPS systeem (of Galileo, die ontvangers pakken volgens mij tegenwoordig alles) ook de juiste tijd. Je zou dus via zo'n Pi een lokale NTP server kunnen maken. Is dat niet wat die bak van €1500 ook doet? Zal uiteraard wel wat ingewikkelder zijn dan dat ik zo even snel roep, maar als je thuis tot op de seconde gelijk loopt, is dat toch genoeg?
In principe kun je daarmee een heel eind komen. Alleen zou ik geen Pi nemen want die heeft standaard geen RTC aan boord. Een Pi gaat daarom al vrij rap wat afwijken als ie niet heel vaak zijn tijd synchroon kan houden met het GPS/Galileo signaal.
Voor thuis gebruik is het verder wat onhandig dat je gps/galileo ontvanger vrij zicht op satelieten moet hebben. Binnenshuis gaat dat vaak niet optimaal. Voor enkel de tijd luistert dat minder nauw dan voor positiebepaling, maar zal niet zomaar overal werken.
Een RTC is niet nodig voor een NTP stratum-1 server zo lang hij in de lucht is en als backup kan je natuurlijk externe servers configureren. Een Pi met een referenceclock gaat meestal op het PPS (puls per seconde) signaal synchroniseren en gebruikt de normale timestamps voor de "normale"tijd. YMMV
Dat wordt nu juist in het artikel uitgelegd. Er wordt gecompenseerd voor de tijd dat de pakketten onderweg zijn met (T2-T1) + (T3-T4)/2. Wel met de aanname dat heen en terug even lang duren.
-heen & terug duren even lang
-de reactietijd van de connectie blijft continu hetzelfde
-de pakketen zijn identiek gerouteerd
Als ik dan even Wikipedia erbij haal geeft dat via internet een drift tussen de 10 & 100ms of meer, zeker bij assymetrische verbindingen (zoals de bulk van onze internet verbindingen inclusief 4G/5G). Bijkomstig is dat een drift per stratum dus als je een stratum hebt per lidstaat, dan naar een stratum springt van een provider, dan naar een stratum on premise om dan naar je client te springen dan accumuleert die drift telkens.
Voor zuiver lokaal netwerk is dit afdoende maar over grote en complexe netwerken zoals internet niet bepaald tenzij het niet uitmaakt dat je een drift hebt uitgedrukt in ms. NTP probeert dus wel te compenseren maar het is niet afdoende.
Staat ook wel uitgelegd in het artikel maar met de volgende zin ben ik het niet helemaal eens
Het aantal toepassingen dat werkelijk zo nauwkeurig gesynchroniseerd moet worden dat verbinding met stratum 1 vereist is, is echter ook weer niet zo groot.
Ja & nee, historisch gesproken niet maar we willen morgen wel slimme energie netwerken, warmtenetten, robot gestuurde containerterminals, zelfrijdende wagens en nog veel meer. Om al die automatisatie onder een noemer te noemen hebben we het woord IoT uitgevonden.
De vraag is of dat zo blijft nu het aantal iot-apparaten dat de tijd opvraagt, flink groeit en beveiliging belangrijker is dan ooit.
Het probleem is dat als je inputs/outputs niet meer lokaal zitten dan word tijd een pain in the ass. Bijvoorbeeld de sensoren van een ESP systeem op je auto, die controleert 25 keer per seconde de input en corrigeert bij ofwel die controller heeft een cyclustijd van 40ms.
Nu moet je inbeelden dat je die inputs/outputs gaat verspreiden over een provincie (dan word je ESP een echt IoT systeem), dan moet je aan elke input een timestamp gaan toewijzen waarbij je op die timestamps geen drift uitgedrukt in ms mag hebben, anders ga je inputs vergelijken die niet op hetzelfde moment genomen zijn. Vervang nu ESP met slim energie netwerk.
Dan is NTP over internet niet meer afdoende en heb je continu stratum 1 nauwkeurigheid nodig. Alsook word security dan ook een issue, als je de tijd kan manipuleren kan je heel dat slim energienetwerk onderuit halen.
Het NTP-protocol is natuurlijk al heel oud (ook in Internet termen) en voldoet wonderbaarlijk eigenlijk nog steeds voor 99%, mits er een aantal slimme aanpassingen (evoluties) worden toegepast.
Toen het NTP-protocol in de jaren 80 werd bedacht was er absoluut nog geen sprake van IoT en realtime toepassingen.
Maar er wordt aan gewerkt (achter de schermen) aan een nieuw protocol, wacht maar af!
-heen & terug duren even lang
-de reactietijd van de connectie blijft continu hetzelfde
[...]
De reactietijd maakt op zich niet heel veel uit, aangezien in een NTP pakket staat wanneer het request ontvangen is en wanneer verzonden.
Op mijn ESP's die via WiFi verbonden zijn, is de correctie die toegepast moet worden vrijwel altijd < 6 msec.
Oftewel de correctie tussen wat de interne klok aangeeft en de nieuwe via NTP opgehaalde tijd.
Hierbij maak ik nog geen gebruik van de 2 verschillende tijden in het NTP packet, dus die ruwweg 5 msec is het verschil in tijd tussen heen- en terug-weg van het packet + de verwerkingstijd op de server.
De totale tijd tussen verzenden en ontvangen van een packet ligt dan tussen de 20 en 90 msec.
Kortom, als ik de ontvangst tijd ook zou gebruiken zou de nauwkeurigheid wel eens in de orde van 1 a 2 msec kunnen liggen. Ruim zat voor menig toepassing.
T1 00:00 => verzending volgens klok A
T2 00:05=> ontvangen volgens klok B
T3 00:06=> verzending volgensklok B
T4 00:10 => ontvangen volgens klok A
(T2-T1) + (T3-T4)/2 = offset = 30 seconden heeft het bericht nodig om van A naar B te gaan
timestamp - offset = gecorrigeerde tijd
verbinding is ontstabiel, reactietijd is plots anders in T2 (door bijvoorbeeld ergens een switch die plots even niet kan volgen)
T1 00:00 => verzending volgens klok A
T2 00:20=> ontvangen volgens klok B
T3 00:21=> verzending volgensklok B
T4 00:25 => ontvangen volgens klok A
(T2-T1) + (T3-T4)/2 = 480 seconden heeft het bericht nodig om van A naar B te gaan (offset)
timestamp - offset = gecorrigeerde tijd
In mijn voorbeeld is het signaal minuten lang onderweg waardoor met heel veel seconden in offset zitten, dat is helemaal niet realistisch maar dat maakt het simpel om te rekenen.
Echter de foutenmarge die ontstaan, of je nu in seconden of in milliseconden rekent, is in mijn voorbeeld met 1600% gestegen.
Echter mijn eerste voorbeeld had ook al een fout, het bericht had 5 seconden nodig om van A naar B te gaan maar slechts 4 seconden om van B naar A te gaan ofwel een asynchrone verbinding.
Op een lokaal netwerk met liefst een synchrone verbinding met weinig hops en geen overbelasting ga je niet veel foutenmarge hebben maar over een brak asynchroon ADSL lijntje via internet waar de NTP server 20 landen verder staat (en dus met veel hops en meerdere routing mogelijkheden), dan ga je een extreme foutenmarge krijgen terwijl je nog altijd maar 1 keer de tijd doorstuurd. Immers als ik achter mijn brak ADSL lijntje vervolgens terug NTP server ipv client speel introduceer ik nog meer foutenmarge.
Als je extra nauwkeurigheid nodig hebt, kun je je packet meerdere keren sturen naar een NTP server.
Je kunt ook de tijd volgens jouw systeem meegeven en dan krijg je ook een offset in de packet te zien aldus de NTP server.
Dit kun je als iteratief proces doen, tot die offset onder een bepaald minimum is.
Ik vond ooit een leuk iets op internet om DCF77 ontvanger zelf te solderen en aan USB te hangen. Werkt nog erg goed, lekker robuust. Ook iets budgetvriendelijker dan €1500 moet ik zeggen.
Ook een simpele GPS ontvanger kan werken met de juiste software (die heb ik ook gebruikt), een simpele Galileo ontvanger vast ook. Zal wel wat minder precies en accuraat zijn, maar voor die paar tientjes vind ik dat persoonlijk prima.
Aan de andere kant is die pool natuurlijk ook maar 1 van de onnoemelijk veel diensten die je kunt gebruiken om je klok mee te synchroniseren. En dat is dan ook direct de grote misvatting. Ja, de pool is belangrijk voor vele mensen en diensten, maar er zijn alternatieven en als deze wegvalt zullen de meesten zeer snel overschakelen.
Misschien wordt het daarom ook wel eens tijd om ook de timeservers van andere diensten op te nemen als mogelijke bronnen van tijd in plaats van onszelf afhankelijk te blijven maken van 1 dienst waar mogelijks nog 1 vrijwilliger aan werkt.
NTP is idd een onderbelicht protocol op het internet. Maar ergens is het ook schitterend om te zien hoe het goed blijft werken!
Zelf heb ik mijn eigen devices hier thuis aan m’n eigen stratum 1 server hangen. Die server heeft een GPS ontvanger en synced met TimeNL. Daardoor zie ik dat als betrouwbare tijdsbron.
De hardware die ik gebruik is een Meinberg M300. Het kleine broertje van wat SIDN gebruikt voor TimeNL. Die hebben een Meinberg M3000 staan ervoor. Mijn M300 ondersteund, helaas, geen DCF77. Moet ik nog een keer maken met een RPi oid.
Ik wil deze server wel toevoegen aan de NTP Pool, maar met mijn DSL lijntje thuis lijkt me dat geen goed idee
Heel lang de NTP van XS4ALL gebruikt. Maar is sinds KPN XS4ALL heeft overgenomen (en meer en meer aan het slopen is wie weet op een dag gaat de NTP eraan) overal de NTP aan het omzetten naar die van SIDN.
Synology als NTP server ingesteld (die het bij SIDN ophaalt) al het andere spul haalt intern bij de NAS daar de NTP tijd op .
Ja, dat klinkt als een prima setup. Lekker je NAS tier 2 laten zijn en de rest het daar op laten halen. De latency op je lan zal het probleem verder niet zijn
Ik heb het geluk dat een kennis van me dit ding over had, nadat Meinberg die gesponsord had voor een project. En Meinberg hoefde het ding niet terug. Dus ik heb er veel minder voor betaald dan 3k . Anders had die hier ook echt niet gelegen
Wat ik vooral zie is dat DCF77 een wat mindere precisie heeft. Ik zie mijn stratum 1 server (zo trots op zoiets kleins) vrijwel altijd op de PPS-gps source hangen, maar zelden op de DCF. Alleen als het slecht weer is, of als ik met mijn domme kop de acculader op de antennekabel van de GPS gezet heb. Dat was een feestje van weken voordat ik dat doorhad.
Ja, DCF77 is een leuke fallback. En waar voor mij de uitdaging dan in gaat zitten is om zelf de DCF77 signalen te decoden en dat verder te gaan gebruiken. Er zal vast een library voor zijn al, maar dit zelf bouwen is een leuke hobby.
Ooit, als ik tijd over heb, dan ga ik dit bouwen
Voor de eenvoudige DCF77 ontvangers (welke het aan/uit (amplitude gemoduleerde) signaal ontvangen) zit in de NTP-distributie een reference-driver welke met vrijwel elke ontvanger werkt(e), via de serial (RS232C) dan. Ik heb in 1998 twee ontvangers voor omgerekend nog geen € 20 aangeschaft.
Misschien zit er nu ook een DCF77 driver in welke via USB-serial werkt?
Ja, puur pulsen tellen en dan op de 0-de seconde geen puls hebben kan nooit heel moeilijk zijn
Maar ik wil dan ook de info die verwerkt zit in de pulsen (dus de datum enzo, en of de zender binnenkort in onderhoud gaat ed) gaan verwerken. Dan weet je alleen maar beter hoe laat het is .
Via een huisverbinding, en helemaal als je een KPN verbinding hebt zou ik dat niet doen. KPN heeft vrij harde limieten op ntp verkeer staan waardoor er regelmatig packets worden gedropped en je een nieuwe request moet doen.
Ik heb zelf ook een ntp server in de pool. Met zowel een ipv6 als ip4 adres, in totaal doet die (de laatste 5 minuten iig) zo'n 2200 requests per seconde. Je firewall/router moet dat ook wel aankunnen, want als je aan connection tracking doet is dat al snel zo'n 132.000 entries in je connection table.
[Reactie gewijzigd door Kees op 22 juli 2024 14:07]
KPN levert alleen de fysieke kabel, alles vanaf layer 3 word door Freedom gedaan bij mij thuis. Ik verwacht daar dus weinig issues mee.
Bandbreedte en aantal connecties zal een grotere uitdaging worden. Mijn router gaat een i5 10th gen worden met 16 GB ram. Die zal we beefy genoeg zijn voor zoveel connecties, eventueel na wat tweaken van de kernel
Heel interessant artikel.
Zet je aan t denken:
*hoe staat de NTP bij mij thuis?
*wat als de NTP pool ineens weg valt door kwade bedoelingen?
*wordt de payload van de NTP response op de zaak wel bekeken door de firewall?
NTP staat bij mij thuis wel aan (ntp server op de rpi die ook home assistant afhandelt).
In de Windows wereld en machines in een domein wordt automatisch de DC als NTP ingesteld.
Wat ik wel gemerkt heb is dat bepaalde IOT apparaten idd gewoon de interne NTP negeren en naar buiten gaan. Mijn DNS routeert dan ook nu de NTP pool naar mijn interne NTP.
Vraag mij overigens af wat er met de XS4ALL ntp server is gebeurd. Die gebruikte ik vroeger altijd.
Ik begrijp het ook wel een beetje hoor, van die apparaten die een door de fabrikant ingestelde NTP server prefereren boven die in je lokale netwerk. Je sluit als fabrikant namelijk de oorzaak van vreemde problemen uit als je weet dat het niet aan de lokale NTP implementatie kan liggen. Dat sluit toch net wat lastig te herleiden problemen uit voor je support team.
[Reactie gewijzigd door Maurits van Baerle op 22 juli 2024 14:07]
NTP is hier ook een beetje een uit de hand gelopen hobby.
Begonnen met een simpele GPS hat voor PPS op een raspberry pi.
Maar ondertussen alweer 3 Oscilloquartz rubidium standaarden richting een Meinberg M600 en een cluster aan met OCXO gemodificeerde pi's met GPS/galileo hats.
Binnenkort waarschijnlijk ook een DFC77 backup installeren.
Op den duur hoop ik ook nog een Cesium standaard of een Hydrogen maser in huis te halen maar die zijn wat minder berijkbaar voor de hobbyist
Fijn dat er ook wordt gesproken over de vraagtekens rondom de pool.
[Reactie gewijzigd door koenvds1 op 22 juli 2024 14:07]
Mooi artikel. Duidelijke uitleg en ook mooie punten voor de toekomst.
Heb zelf op mijn router de NTP server draaiende.
Vroeger deed ik inderdaad een adres van de internet NTP stapel gebruiken. Merk op wel dat vooral "simpele" minder goed ondersteunende apparatuur vaak NTP server adressen erin geprogrammeerd krijgen. Dit zijn en of waren niet altijd alleen kleine merken maar heb ook meermaals een Samsung of Netgear apparaat gezien die op dat onderdeel niet veranderd kon worden.
NTP is zoals openssl. Iedereen gebruikt het, maar we willen er niet voor betalen. Tot dat de hell losbreekt. Zoals wel veel meer zaken op internet.
Het idee om om het bij het bij de ISP onder te brengen is opzich geen slecht idee. Maar zoals het in het artikel al aangehaald wordt. Wordt dit door de meeste devices genegeerd. Met o.a. de komst van DoH zal dit nog verder genegeerd worden.
RR DNS kan een oplossing zijn, maar dynamische DNS is denk ik nog beter. Zodat als je pool.ntp.org gebruikt, je de NTP server van je ISP terug krijgt, ten zij je het zelf anders instelt.
Maar andere kant vind ik het wel fijn om de tijd te vergelijken met meerdere NTP servers en niet alleen die van de ISP.
Re de kosten. Vrij weinig mensen weten van het NTP-protocol af. En nog minder wie precies allemaal NTP-servers runnen. Het grotere probleem is dat I(C)T-producenten (hardware en software) graag van zulke diensten gebruikmaken maar er bijna nooit voor betalen. Tijdje terug werd dat ook al bv in het artikel over Linux en de kernel ervan benoemd - men wil wel betalen voor specifieke modules, maar niet bijdragen aan het algemene onderhoud.
Eigenlijk zouden IT/ICT bedrijven die van de diensten gebruik maken verplicht ook per gebruiker een klein bedrag in (contributie)tijd en/of geld moeten bijdragen om alles te kunnen blijven onderhouden, maar zie dat maar voor elkaar te krijgen...
[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:07]
:strip_exif()/i/2004517682.jpeg?f=imagenormal)
:fill(white):strip_exif()/i/2004517730.jpeg?f=thumblarge)
:fill(white):strip_exif()/i/2004517740.jpeg?f=imagemedium)
:strip_exif()/i/2004517742.jpeg?f=imagenormal)
:strip_exif()/i/2004517744.jpeg?f=imagenormal)
/i/2004518838.png?f=imagenormal)
/i/2004517760.png?f=imagearticlefull)
:fill(white):strip_exif()/i/2004517768.jpeg?f=imagemedium)
/i/2004518846.webp?f=imagenormal)
:strip_exif()/i/2004777542.jpeg?f=fpa)
:strip_exif()/i/2004720368.jpeg?f=fpa)
/i/1321548414.png?f=fpa)
:strip_exif()/i/1143502916.gif?f=fpa)
/i/1249634131.png?f=fpa)
/u/23785/crop5dcd5c59e07f9.png?f=community){kind=small}
:strip_exif()/u/2172/crop57acf4ac04e70.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/476616/o.p-dibenzene-tweakers-70.jpg?f=community){kind=small}
:strip_exif()/u/119419/candc-60px.gif?f=community){kind=small}
:strip_exif()/u/284473/crop598caffe294d9.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/78725/train-icon3.jpg?f=community){kind=small}
)./u/85941/crop61dd9b39bb021_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/299339/anonpict.jpg?f=community){kind=small}
:strip_exif()/u/44074/avatar001.gif?f=community){kind=avatar}
:strip_exif()/u/217171/avatar60.gif?f=community){kind=avatar}
/u/49116/crop5ab3aba55abd9_cropped.png?f=community){kind=small}
/u/8/oog3.png?f=community){kind=small}
:strip_icc():strip_exif()/u/215244/crop5fe47915ce321_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/371739/crop5ec0629c56fe0_cropped.jpeg?f=community){kind=small}
/u/15664/crop6881d8a8bb43f_cropped.png?f=community){kind=small}
:strip_exif()/u/47900/baph.gif?f=community){kind=small}
