NTP-pool: de tijdwaarnemer op het internet

Tijdwaarnemers op het internet

In de VS biedt NIST al tientallen jaren gratis tijddiensten aan. Deze worden geleverd met behulp van publiekelijk toegankelijke stratum-1 servers. Het US Naval Observatory (USNO) is ook een populaire aanbieder van tijddiensten. Inmiddels bieden leveranciers als Apple, Google, CloudFlare, Meta, Microsoft en Ubuntu allemaal tijddiensten aan. Wij (SIDN Labs) leveren ook een gratis tijddienst op https://time.nl.

De NTP-pool is een laag die over NTP-servers heen ligt en biedt een directory met publiekelijk beschikbare NTP-servers die gebruikmaken van DNS; de pool beheert zelf geen NTP-servers. De NTP-servers worden zelf beheerd door vrijwilligers, die variëren van Raspberry Pi-gebruikers tot grote cloudoperators. De pool bevat momenteel meer dan 4.700 NTP-servers.

Aangezien er zoveel tijddiensten zijn om uit te kiezen, wilden we weten welke het meest in trek zijn. Om daar achter te komen, onderzochten we root DNS-query's uit 2017 en 2022 (DITL-datasets). Omdat we geen toegang hebben tot het daadwerkelijke NTP-verkeer van deze diensten, namen we onze toevlucht tot het gebruik van DNS-querynamen om af te leiden hoe populair de verschillende diensten zijn (er zijn enige kanttekeningen bij het gebruik van DNS als maatstaf voor populariteit, die we bespreken in een peerreviewed paper).

De onderstaande afbeelding laat voor elke tijddienst zien hoeveel IP-adressen (DNS-resolvers) query's hebben verzonden naar het root DNS. We zien dat in de dataset voor zowel 2017 als 2022 de NTP-pool verreweg de populairste tijddienst is, zelfs nog populairder dan NIST en grote cloud- en contentproviders.

Figuur 1: Aantal resolvers per tijdserver in DITL root DNS-datasets.

We zagen vergelijkbare resultaten voor de aggregatieniveaus van Autonome Systemen. Het is vrij opmerkelijk dat de community-gedreven NTP-pool de meest populaire tijddienstprovider is, althans bezien vanuit het root DNS.

Figuur 2: Aantal AS'en per tijdserver in DITL Root DNS-datasets.

Hoe wijst de NTP-pool clients toe aan NTP-servers?

De NTP-pool bevat momenteel 4.700 NTP-servers. Hoe wordt bepaald welke NTP-servers aan een client worden toegewezen?

Om die vraag te beantwoorden, stuurden we met behulp van zo'n 10.000 RIPE Atlas probes DNS-query's naar de DNS-servers van de NTP-pool en analyseerden we hoeveel unieke IP-adressen (de NTP-servers zelf) werden geretourneerd. Kort gezegd: clients sturen query's naar pool.ntp.org en wij analyseerden hoeveel unieke antwoorden er waren over een periode van 24 uur.

We constateerden dat 10% van de Atlas probes wordt bediend door maximaal 12 NTP-servers en 30% door meer dan 100 NTP-servers. Waar komt die discrepantie vandaan? Waarom beschikken sommige clients over een meer diverse groep servers dan andere? Waarom zijn sommige clients meer gelijk dan andere?

Figuur 3: Aantal NTP-servers per Atlas probe.

GeoDNS: de toewijzer van tijdservers

GeoDNS is de autoritatieve DNS-server die door de NTP-pool wordt gebruikt om clients aan NTP-servers toe te wijzen en de eindverantwoordelijkheid voor deze toewijzing heeft. We downloadden GeoDNS, configureerden het en voerden een reeks experimenten uit om erachter te komen hoe het precies werkt. Voor meer informatie over onze experimenten kun je onze paper lezen.

In een notendop komt het erop neer dat onze analyse liet zien dat alles afhangt van de geolocatie van de client. Als je je in Japan bevindt, zul je uitsluitend bediend worden door de 21 NTP-servers die gevestigd zijn in Japan. Ben je in Kameroen, dan heb je maar 1 NTP-server tot je beschikking, ook al staan er meer dan 4.700 servers in het bestand van de NTP-pool. En als er in je eigen land geen NTP-servers zijn, word je bediend door NTP-servers op je continent. Clients in Bolivia worden bijvoorbeeld bediend door alle 46 servers in Zuid-Amerika.

Probeer het zelf

GeoDNS gebruikt ofwel het IP-adres van de client ofwel het clientsubnet (ECS) gespecificeerd in het DNS om de gebruiker toe te wijzen aan NTP-servers – ECS heeft een hogere prioriteit. De toewijzing impliceert dat clients gebonden zijn aan het aantal servers dat in hun land beschikbaar is.

Zoals we al zeiden, heeft Kameroen slechts 1 NTP-server, zoals vermeld op de website van de NTP-pool. Om te achterhalen welke NTP-server dit is, kunnen we DNS-query's sturen naar pool.ntp.org door bij de ECS-optie een IP-adres in Kameroen te specificeren. Op die manier zien we hoe de NTP-pool NTP-servers toewijst. (Als jouw apparaat is geconfigureerd voor gebruik van bijvoorbeeld debian.pool.ntp.org of een andere leverancier, verloopt de toewijzing op dezelfde manier.)

Wil je het zelf proberen? Voer dan gewoon de onderstaande Python-code uit.

import dns.message import dns.query import dns.rdatatype import dns.edns ''' Define the ECS parameters (replace ADDRESS with an IP address # geolocated in the country that you are interested in) The client's IP address, I am using an address in Cameroon. Replace with IP addresses located in countries you are interested in ''' ADDRESS = '165.210.33.254'  PREFIX = 24  # Prefix length (typically 24 for IPv4) #we query the default zone (pool.ntp.org) # but we can use any vendor zone, like # debian.pool.ntp.org or android.pool.ntp.org ZONE='pool.ntp.org' # Create an ECS option ecs = dns.edns.ECSOption(ADDRESS, PREFIX) # Make a DNS query for 'pool.ntp.org' q = dns.message.make_query(ZONE, 'A', use_edns=0, options=[ecs]) # Send the query to one of the Pool authoritative servers # In this case, I am using the IP address of c.ntpns.org. auth_server_ip = '50.116.32.247' response = dns.query.udp(q, auth_server_ip) # Extract and process the response (e.g. print the IP addresses) for rrset in response.answer:     for rr in rrset:         if rr.rdtype == dns.rdatatype.A:             print(f'IPv4 Address: {rr.address}')

Met deze code wordt er slechts 1 NTP-server geretourneerd aan alle clients in Kameroen. Naar onze mening is dit een zeer beperkende manier van toewijzen – waarom wordt er slechts 1 server toegewezen aan alle gebruikers in Kameroen? (Kameroen telt 28,28 miljoen inwoners, onder wie 12,89 miljoeninternetgebruikers.)

Deze beperkende toewijzing van clients aan servers roept 2 vragen op:

1. Waarom gebruikt GeoDNS zo'n beperkende manier van toewijzen?

2. Wat zijn de gevolgen voor clients?

Waarom is de toewijzing zo beperkt? Is die beperking noodzakelijk?

We vroegen de beheerders van de NTP-pool naar de manier van toewijzen en kregen te horen dat die dient ter "minimalisering van het risico op asymmetrische routering en gedropte pakketten".

Nou blijken de meeste paden op het internet al asymmetrisch te zijn, dus de NTP-pool is niet de enige met dit probleem. (Er zijn al verschillende onderzoeken gedaan naar NTP en asymmetrische paden.)

Met betrekking tot het pakketverlies voerden we experimenten uit met 132 Atlas probes in 21 landen – allemaal in landen die CloudFlare als hun enige tijdprovider hebben als ze de NTP-pool gebruiken. We vergeleken het pakketverlies en de precisie van elke probe naar elke NTP-server als ze andere tijdservers op andere continenten zouden gebruiken in plaats van alleen CloudFlare – met andere woorden: als GeoDNS ze zou toewijzen aan andere servers ergens anders.

In de afbeelding hieronder zie je de resultaten. Op de -as zien we individuele Atlas probes, die te vergelijken zijn met echte clients. Op de -as zien we alle NTP-servers (1 per continent en, ter referentie, Cloudfare). We zien dat de meeste Atlas VP's probleemloos verbinding maken met NTP-servers op andere continenten – de enige uitzondering zijn de Zuid-Amerikaanse servers, die voor veel VP's moeilijk te bereiken waren. Voor de meeste servers en Atlas VP's konden alle servers op andere continenten nauwkeurige tijdinformatie leveren en was pakketverlies geen probleem. Dit kleine voorbeeld laat zien dat zo'n beperkende toewijzing niet nodig is – in elk geval niet bij ons kleinschalige experiment.

Figuur 4: Verhouding ontbrekende antwoorden per tijdserver en Atlas probe.

Gevolgen voor gebruikers

De implicaties die de toewijzing voor gebruikers heeft, worden duidelijk als we kijken naar het aantal NTP-servers waaraan ze worden toegewezen.

In de onderstaande afbeelding zie je hoeveel NTP-servers alle gebruikers uit een land ter beschikking staan, als ze de pool gebruiken. Gezien het feit dat de NTP-pool uit meer dan 4.700 NTP-servers bestaat, vinden we dit een uitermate scheve verdeling en niet eerlijk jegens de clientpopulatie: Afrikaanse clients worden door veel minder servers bediend dan Amerikaanse of West-Europese clients. Het lijkt erop dat het, onbedoeld, de kloof tussen rijk en arm in stand houdt.

Figuur 5: Aantal NTP-servers voor alle gebruikers in een land.

Maar het echte probleem is dat gebruikers uit 27 landen, met in totaal 767 miljoen inwoners en 465 miljoeninternetgebruikers, worden bediend door slechts 1 Autonoom Systeem als tijdprovider wanneer ze de NTP-pool gebruiken, ook al bestaat de NTP-pool uit meer dan 4.700 servers. Het gaat hierbij om de landen die in de onderstaande afbeelding roodgekleurd zijn en opgenomen zijn in de tabel.

Figuur 6: Aantal AS'en (tijdproviders) waardoor een land wordt bediend.

De onderstaande tabel is een overzicht van alle landen die door slechts 1 AS worden bediend als ze de NTP-pool gebruiken.

Tabel 1: Landen die worden bediend door slechts 1 tijdprovider: CloudFlare en andere AS'en (vetgedrukt).

Vervolgens kunnen we berekenen wat het aantal internetgebruikers per NTP-server is als ze ervoor kiezen om gebruik te maken van de NTP-pool. We zien dat Nigeria, met slechts 2 NTP-servers, 60 miljoen internetgebruikers per server heeft. De VS en West-Europa hebben minder dan 0,47 miljoen gebruikers per NTP-server. (Voor veel Afrikaanse landen gelden vergelijkbare verhoudingen, maar dat is omdat ze zelf geen NTP-servers in hun land hebben en dus terugvallen op de Afrikaanse zone.)

Figuur 7: Verhouding van internetgebruikers per NTP-server.

Implicaties voor de veiligheid

De beperkte toewijzing heeft meerdere implicaties voor de veiligheid. Ten eerste kan al het verkeer van landen zonder servers in hun landzone (die terugvallen op hun continentzone) gemonopoliseerd worden door 1 NTP-server. Daarvoor hoeft er alleen maar een NTP-server aan hun landzone te worden toegevoegd. Als die NTP-server kwaadaardig is — d.w.z. valse tijdinformatie verstuurt, kan hij worden gebruikt om tijdverschuivingsaanvallen uit te voeren. We hebben in onze paper (Sectie 4.3) laten zien hoe dat incidenteel gebeurt met Guernsey.

De NTP-pool heeft zijn eigen toezichthouders, die NTP-servers die zich misdragen opsporen en verwijderen, maar die kunnen ook om de tuin worden geleid. Dezelfde aanvallen kunnen worden toegepast om een deel van het NTP-verkeer uit 1 land te beïnvloeden door een race condition te creëren. Een vastberaden aanvaller kan de klokken van alle NTP-pool-apparaten in een land verzetten, als hij met beleid te werk gaat.

Volgende stappen

In juli 2023 presenteerden we onze bevindingen aan de beheerders van de NTP-pool en ze zijn van plan om het door ons geïdentificeerde probleem op te lossen door "de nieuwe zones een nieuwe DNS-naam te geven en daarna in de loop van de tijd de oude namen te migreren zodat ze verwijzen naar de nieuwe naam (waarschijnlijk land voor land, zodat we kunnen beginnen met het migreren van dingen die nu niet goed werken)". Voor zover wij kunnen vaststellen, zijn deze wijzigingen echter nog niet doorgevoerd.

Ter afsluiting: ook al heeft de huidige opzet van de NTP-pool te kampen met de hier beschreven problemen, we mogen het grote geheel niet uit het oog verliezen, namelijk dat we de vrijwilligers van de NTP-pool, die deze dienst al meer dan 20 jaar runnen, dank verschuldigd zijn. Ze vormen de meest populaire tijddienst op het internet, een van de weinige diensten die (nog) niet zijn vervangen door grote cloud- en contentoperators. Desalniettemin kan het systeem worden verbeterd om de beperkende toewijzing en potentiële veiligheidsincidenten te voorkomen.

(Deze blog bevat een samenvatting van de belangrijkste bevindingen van onze ACM SIGMMETRICS ‘24 paper, die in juni in Venetië zal worden gepresenteerd.)

Marco Davids, Caspar Schutijser, Cristian Hesselman (SIDN Labs), John Heidemann (University of Southern California) en Georgios Smaragdakis (TU Delft) hebben aan dit werk bijgedragen.