Network Time Protocol

Ej att förväxla med Daytime Protocol , Time Protocol eller NNTP .
Network Time Protocol
Network Time Protocol servers and clients.svg
Internationell standard   RFC 5905
Utvecklad av David L. Mills , Network Time Foundation
Introducerad 1985 ( 1985 )
Internetprotokollsvit
Applikationslager
Transportlager
Internetlager
Länklager

Network Time Protocol ( NTP ) är ett nätverksprotokoll för klocksynkronisering mellan datorsystem över paketkopplade datanätverk med variabel latens . I drift sedan före 1985 är NTP ett av de äldsta internetprotokollen som används för närvarande. NTP designades av David L. Mills vid University of Delaware .

NTP är avsett att synkronisera alla deltagande datorer till inom några millisekunder av Coordinated Universal Time ( UTC). Den använder korsningsalgoritmen , en modifierad version av Marzullos algoritm , för att välja korrekta tidsservrar och är utformad för att mildra effekterna av variabel nätverkslatens . NTP kan vanligtvis hålla tiden inom tiotals millisekunder över det offentliga Internet och kan uppnå bättre än en millisekunds noggrannhet i lokala nätverk under idealiska förhållanden. Asymmetriska rutter och nätverksstockningar kan orsaka fel på 100 ms eller mer.

Protokollet beskrivs vanligtvis i termer av en klient-server-modell , men kan lika gärna användas i peer-to-peer- relationer där båda peers anser den andra vara en potentiell tidskälla. Implementeringar skickar och tar emot tidsstämplar med hjälp av User Datagram Protocol (UDP) på portnummer 123. De kan också använda broadcasting eller multicasting , där klienter passivt lyssnar på tidsuppdateringar efter ett första kalibreringsutbyte tur och retur. NTP ger en varning för eventuella förestående skottsekundsjusteringar , men ingen information om lokala tidszoner eller sommartid sänds.

Det nuvarande protokollet är version 4 (NTPv4), vilket är bakåtkompatibelt med version 3.

Historia

NTP designades av David L. Mills .

  1979 användes teknik för nätverkstidsynkronisering i vad som möjligen var den första offentliga demonstrationen av internettjänster som körde över ett transatlantiskt satellitnätverk, vid National Computer Conference i New York. Tekniken beskrevs senare i 1981 Internet Engineering Note (IEN) 173 och ett offentligt protokoll utvecklades från den som dokumenterades i RFC 778 . Tekniken distribuerades först i ett lokalt nätverk som en del av Hello-routingprotokollet och implementerades i Fuzzball-routern , ett experimentellt operativsystem som används i nätverksprototyper, där den kördes i många år.

  Andra relaterade nätverksverktyg var tillgängliga både då och nu. De inkluderar dagtid och tid för att registrera tidpunkten för händelser, såväl som ICMP-tidsstämpelmeddelanden och alternativet IP-tidsstämpel ( RFC 781 ). Mer kompletta synkroniseringssystem, även om de saknar NTP:s dataanalys och klockdisciplineringsalgoritmer, inkluderar Unix- demonen timed , som använder en valalgoritm för att utse en server för alla klienter; och Digital Time Synchronization Service (DTSS), som använder en hierarki av servrar som liknar NTP-stratummodellen.

  År 1985 implementerades NTP version 0 (NTPv0) i både Fuzzball och Unix, och NTP-pakethuvudet och beräkningar av fördröjning och offset för tur och retur, som har kvarstått i NTPv4, dokumenterades i RFC 958 . Trots de relativt långsamma datorer och nätverk som var tillgängliga vid den tiden , erhölls vanligen en noggrannhet på bättre än 100 millisekunder på Atlantic spaning-länkar, med en noggrannhet på tiotals millisekunder på Ethernet -nätverk.

   1988 publicerades en mycket mer komplett specifikation av NTPv1-protokollet, med tillhörande algoritmer, i RFC 1059 . Den byggde på experimentresultaten och klockfilteralgoritmen dokumenterad i RFC 956 och var den första versionen som beskrev klient-server- och peer-to-peer- lägena. 1991 uppmärksammades en bredare ingenjörsgemenskap på NTPv1-arkitekturen, protokollet och algoritmerna genom publiceringen av en artikel av David L. Mills i IEEE Transactions on Communications .

  1989 publicerades RFC 1119 som definierar NTPv2 med hjälp av en tillståndsmaskin, med pseudokod för att beskriva dess funktion. Det introducerade ett hanteringsprotokoll och kryptografiskt autentiseringssystem som båda har överlevt i NTPv4, tillsammans med huvuddelen av algoritmen. Utformningen av NTPv2 kritiserades dock för att sakna formell korrekthet av DTSS-gemenskapen, och klockvalsproceduren modifierades för att införliva Marzullos algoritm för NTPv3 och framåt.

  1992 definierade RFC 1305 NTPv3. RFC inkluderade en analys av alla felkällor, från referensklockan ner till den slutliga klienten, vilket möjliggjorde beräkningen av ett mått som hjälper till att välja den bästa servern där flera kandidater verkar vara oense. Sändningsläge introducerades.

  Under de följande åren, när nya funktioner lades till och algoritmförbättringar gjordes, blev det uppenbart att en ny protokollversion krävdes. 2010 publicerades RFC 5905 som innehåller en föreslagen specifikation för NTPv4. Efter pensioneringen av Mills från University of Delaware upprätthålls referensimplementeringen för närvarande som ett öppen källkodsprojekt som leds av Harlan Stenn. På IANA-sidan ansvarar en ntp-arbetsgrupp (nätverkstidsprotokoll) för att granska föreslagna utkast .

Protokollet har gjort betydande framsteg sedan NTPv4. Från och med 2022 har tre RFC-dokument som beskriver uppdateringar av protokollet publicerats, utan att räkna med de många perifera standarderna som NTS (RFC 8915). Mills hade nämnt planer på en "NTPv5" på sin sida, men en sådan publicerades aldrig. Ett icke-relaterat utkast kallat "NTPv5" av M. Lichvar av chrony initierades 2020 och inkluderar ändringar av säkerhet, noggrannhet och skalning.

SNTP

Eftersom NTP ersätter användningen av det gamla Time Protocol , finner vissa användningsfall ändå det fullständiga protokollet för komplicerat. 1992 definierades Simple Network Time Protocol ( SNTP ) för att fylla denna nisch. SNTPv3-standarden beskriver ett sätt att använda NTPv3, så att ingen lagring av tillstånd över längre tidsperioder behövs. Topologin blir i huvudsak densamma som med Time Protocol, eftersom endast en server används. 1995 uppdaterades SNTP till SNTPv4 med några funktioner i den då under utveckling NTPv4; den aktuella senaste versionen är RFC 5905, en 2010 års revision av SNTPv4, som slår ihop den med den huvudsakliga NTPv4-standarden. SNTP är helt interoperabelt med NTP eftersom det inte definierar ett nytt protokoll. De enkla algoritmerna ger dock tider med minskad noggrannhet och därför är det olämpligt att synkronisera tid från en SNTP-källa.

Klockskikt

US Naval Observatory Alternate Master Clock vid Schriever AFB (Colorado) är en stratum 0-källa för NTP
Gula pilar indikerar en direkt anslutning; röda pilar indikerar en nätverksanslutning.

NTP använder ett hierarkiskt, halvskiktat system av tidskällor. Varje nivå i denna hierarki kallas ett stratum och tilldelas ett nummer som börjar med noll för referensklockan överst. En server synkroniserad med en stratum n -server körs på stratum n + 1. Siffran representerar avståndet från referensklockan och används för att förhindra cykliska beroenden i hierarkin. Stratum är inte alltid en indikation på kvalitet eller tillförlitlighet; det är vanligt att hitta stratum 3-tidskällor som är av högre kvalitet än andra stratum 2-tidskällor. En kort beskrivning av strata 0, 1, 2 och 3 ges nedan.

Stratum 0
Dessa är högprecisions tidtagningsenheter som atomklockor , GNSS (inklusive GPS ) eller andra radioklockor , eller en PTP -synkroniserad klocka. De genererar en mycket exakt puls per sekund signal som utlöser ett avbrott och tidsstämpel på en ansluten dator. Stratum 0-enheter är också kända som referensklockor. NTP-servrar kan inte annonsera sig själva som stratum 0. Ett stratumfält satt till 0 i NTP-paket indikerar ett ospecificerat stratum.
Stratum 1
Dessa är datorer vars systemtid synkroniseras till inom några mikrosekunder från deras anslutna stratum 0-enheter. Stratum 1-servrar kan peer med andra stratum 1-servrar för förnuftskontroll och säkerhetskopiering. De kallas också för primära tidsservrar.
Stratum 2
Dessa är datorer som är synkroniserade över ett nätverk till stratum 1-servrar. Ofta frågar en stratum 2-dator flera stratum 1-servrar. Stratum 2-datorer kan också peer med andra stratum 2-datorer för att ge mer stabil och robust tid för alla enheter i peer-gruppen.
Stratum 3
Dessa är datorer som är synkroniserade med stratum 2-servrar. De använder samma algoritmer för peering och datasampling som stratum 2, och kan själva fungera som servrar för stratum 4-datorer och så vidare.

Den övre gränsen för stratum är 15; stratum 16 används för att indikera att en anordning är osynkroniserad. NTP-algoritmerna på varje dator samverkar för att konstruera ett Bellman-Fords kortaste spåröverskridande träd , för att minimera den ackumulerade tur och returfördröjningen till stratum 1-servrarna för alla klienter.

Förutom stratum kan protokollet identifiera synkroniseringskällan för varje server i termer av en referensidentifierare (refid).

Vanliga tidsreferensidentifierare (refid) koder
Refid Klockkälla
GÅR Geosynkron Orbit Environment Satellite
GPS Global Positioning System
TJEJ Galileo positioneringssystem
PPS Generisk puls per sekund
IRIG Inter-Range Instrumentation Group
WWVB LF Radio WWVB Fort Collins, Colorado 60 kHz
DCF LF Radio DCF77 Mainflingen, DE 77,5 kHz
HBG LF Radio HBG Prangins, HB 75 kHz (upphört att fungera)
Läkare Utan Gränser LF Radio MSF Anthorn, Storbritannien 60 kHz
JJY LF Radio JJY Fukushima, JP 40 kHz, Saga, JP 60 kHz
LORC MF Radio Loran-C station, 100 kHz
TDF MF Radio Allouis, FR 162 kHz
CHU HF Radio CHU Ottawa, Ontario
WWV HF-radio WWV Fort Collins, Colorado
WWVH HF-radio WWVH Kauai, Hawaii
NIST NIST telefonmodem
ACTS NIST telefonmodem
USNO USNO telefonmodem
PTB Tyskt PTB-tidsstandard telefonmodem
FRU (Informella) Flera referenskällor
GOOG (Inofficiell) Google Refid används av Googles NTP-servrar som time4.google.com

För servrar på stratum 2 och nedan är refid en kodad form av uppströms tidsserverns IP-adress. För IPv4 är detta helt enkelt 32-bitars adressen; för IPv6 skulle det vara de första 32 bitarna av MD5-hash för källadressen. Refids tjänar till att upptäcka och förhindra tidsslingor till första graden.

refid-fältet är fyllt med statusord i fallet med kiss-o'-death (KoD)-paket, som säger åt klienten att sluta skicka förfrågningar så att servern kan vila. Några exempel är INIT (initiering), STEP (stegtidsändring) och RATE (klient begär för snabbt). Programutgången kan dessutom använda koder som inte överförs i paketet för att indikera fel, såsom XFAC för att indikera en nätverksavbrott.

IANA upprätthåller ett register för refid-källnamn och KoD-koder. Informella uppdrag kan fortfarande dyka upp.

Tidsstämplar

De 64-bitars binära fixpunkttidsstämplarna som används av NTP består av en 32-bitarsdel för sekunder och en 32-bitarsdel för bråkdelssekunder, vilket ger en tidsskala som rullar över var 2:e 32 :e sekund (136 år) och en teoretisk upplösning på 2 −32 sekunder (233 pikosekunder). NTP använder en epok från 1 januari 1900. Därför sker den första rollover den 7 februari 2036.

NTPv4 introducerar ett 128-bitars datumformat: 64 bitar för andra och 64 bitar för bråkdelssekund. De mest betydelsefulla 32-bitarna i detta format är Era Number som i de flesta fall löser tvetydighet om överrullning. Enligt Mills, "64-bitarsvärdet för fraktionen är tillräckligt för att lösa hur lång tid det tar för en foton att passera en elektron med ljusets hastighet. Det 64-bitars andra värdet är tillräckligt för att ge en entydig tidsrepresentation tills universum blir mörkt."

Klocksynkroniseringsalgoritm

Rundtursfördröjningstid δ

En typisk NTP-klient frågar regelbundet en eller flera NTP-servrar. Klienten måste beräkna sin tidsförskjutning och fördröjning tur och retur . Tidsoffset θ är positiv eller negativ (klienttid > servertid) skillnad i absolut tid mellan de två klockorna. Den definieras av

och tur och retur fördröjningen δ med
var
  • 0 t är klientens tidsstämpel för begäran om paketöverföring,
  • t 1 är serverns tidsstämpel för begäran om paketmottagning,
  • t 2 är serverns tidsstämpel för svarspaketöverföringen och
  • t 3 är klientens tidsstämpel för mottagningen av svarspaketet.

För att härleda uttrycket för offset, notera att för begäran paketet,

och för svarspaketet,
Att lösa för θ ger definitionen av tidsförskjutningen.

Värdena för θ och δ passeras genom filter och utsätts för statistisk analys ("mitigation"). Outliers kasseras och en uppskattning av tidsförskjutning härleds från de tre bästa återstående kandidaterna. Klockfrekvensen justeras sedan för att minska offseten gradvis ("disciplin"), vilket skapar en återkopplingsslinga .

Exakt synkronisering uppnås när både de inkommande och utgående vägarna mellan klienten och servern har symmetrisk nominell fördröjning. Om sträckorna inte har en gemensam nominell fördröjning föreligger en systematisk bias på halva skillnaden mellan restiden framåt och bakåt. Ett antal tillvägagångssätt har föreslagits för att mäta asymmetri, men bland praktiska implementeringar verkar endast chrony ha en inkluderad.

Mjukvaruimplementationer

Ytterligare information: ntpd § Genomföranden
NTP-hanteringsprotokollverktyget ntpq används för att fråga tillståndet för en stratum 2-server.

Referensimplementering

NTP- referensimplementeringen , tillsammans med protokollet, har kontinuerligt utvecklats i över 20 år. Bakåtkompatibilitet har bibehållits eftersom nya funktioner har lagts till. Den innehåller flera känsliga algoritmer, särskilt för att disciplinera klockan, som kan uppträda fel när de synkroniseras med servrar som använder olika algoritmer. Programvaran har porterats till nästan alla datorplattformar, inklusive persondatorer. Den körs som en demon som heter ntpd under Unix eller som en tjänst under Windows. Referensklockor stöds och deras förskjutningar filtreras och analyseras på samma sätt som fjärrservrar, även om de vanligtvis pollas oftare. Denna implementering granskades 2017 och hittade 14 potentiella säkerhetsproblem.

Windows tid

Alla Microsoft Windows- versioner sedan Windows 2000 inkluderar Windows Time-tjänsten (W32Time), som har möjlighet att synkronisera datorklockan till en NTP-server.

W32Time implementerades ursprungligen för Kerberos version 5-autentiseringsprotokoll, vilket krävde att tiden var inom 5 minuter från det korrekta värdet för att förhindra replay-attacker . Versionen i Windows 2000 och Windows XP implementerar endast SNTP och bryter mot flera aspekter av NTP version 3-standarden.

Från och med Windows Server 2003 och Windows Vista blev W32Time kompatibel med en betydande delmängd av NTPv3. Microsoft uppger att W32Time inte tillförlitligt kan upprätthålla tidssynkronisering med en sekunds noggrannhet. Om högre noggrannhet önskas rekommenderar Microsoft att du använder en nyare version av Windows eller en annan NTP-implementering.

Från och med Windows 10 version 1607 och Windows Server 2016 kan W32Time konfigureras för att nå en tidsnoggrannhet på 1 s, 50 ms eller 1 ms under vissa specificerade driftsförhållanden.

Öppna NTPD

2004 presenterade Henning Brauer från OpenBSD OpenNTPD , en NTPv3/SNTPv4-implementering med fokus på säkerhet och som omfattar en privilegieavgränsad design. Även om det är mer inriktat på de enklare generiska behoven hos OpenBSD-användare, innehåller det också vissa protokollsäkerhetsförbättringar samtidigt som det fortfarande är kompatibelt med befintliga NTP-servrar. Den enklare kodbasen offrar noggrannhet, som anses onödig i detta användningsfall. En bärbar version är tillgänglig i Linux-paketförråd.

NTPsec

NTPsec är en del av referensimplementationen som systematiskt säkerhetshärdats . Gaffelpunkten var i juni 2015 och var ett svar på en rad kompromisser 2014. [ specificera ] Den första produktionsversionen skickades i oktober 2017. Mellan borttagning av osäkra funktioner, borttagning av stöd för föråldrad hårdvara och borttagning av stöd för föråldrad hårdvara Unix-varianter, NTPsec har kunnat parera bort 75% av den ursprungliga kodbasen, vilket gör resten lättare att granska . En revision av koden 2017 visade åtta säkerhetsproblem, inklusive två som inte fanns i den ursprungliga referensimplementeringen, men NTPsec led inte av åtta andra problem som fanns kvar i referensimplementeringen.

chrony

Huvudartikel: chrony
chronyc, visar källor och aktivitetsinformation. Terminalfönster under Arch Linux

chrony är en oberoende NTP-implementering huvudsakligen sponsrad av Red Hat , som använder det som standardtidsprogram i sina distributioner. Chrony är skrivet från grunden och har en enklare kodbas som möjliggör bättre säkerhet och lägre resursförbrukning. Det kompromissar dock inte med noggrannheten, utan synkroniserar istället snabbare och bättre än referens-ntpd under många omständigheter. Den är mångsidig nog för vanliga datorer, som är instabila, går i viloläge eller har intermittent anslutning till Internet. Den är också designad för virtuella maskiner, en mer instabil miljö.

Chrony har utvärderats som "pålitlig", med endast ett fåtal incidenter. Den kan uppnå förbättrad precision på LAN-anslutningar genom att använda hårdvarutidsstämpling på nätverksadaptern. Stöd för Network Time Security (NTS) lades till i version 4.0. chrony är tillgänglig under GNU General Public License version 2, skapades av Richard Curnow 1997 och underhålls för närvarande av Miroslav Lichvar.

Andra

  • Ntimed startades av Poul-Henning Kamp från FreeBSD 2014 och övergavs 2015. Implementeringen sponsrades av Linux Foundation .
  • systemd-timesyncd är SNTP-klienten inbyggd i systemd . Även om det sällan skrivits om, används denna implementering av Debian sedan version "bokmask" och nedströms Ubuntu.

Hoppa sekunder

På dagen för en skottsekundhändelse får ntpd meddelande från antingen en konfigurationsfil , en bifogad referensklocka eller en fjärrserver. Även om NTP-klockan faktiskt stoppas under händelsen, på grund av kravet att tiden måste verka strikt ökande , får alla processer som frågar efter systemtiden att den ökar med en liten mängd, vilket bevarar händelseordningen. Om en negativ skottsekund någonsin skulle bli nödvändig, skulle den raderas med sekvensen 23:59:58, 00:00:00, hoppar över 23:59:59.

En alternativ implementering, kallad leap smearing, består i att introducera språngsekunden stegvis under en period av 24 timmar, från middag till middag i UTC-tid. Denna implementering används av Google (både internt och på deras offentliga NTP-servrar), Amazon AWS och Facebook. Chrony stöder leap smear i smoothtime och leapsecmode -konfigurationer, men sådan användning ska inte blandas med en offentlig NTP-pool eftersom leap smear är icke-standard och kommer att kasta bort klientberäkningar i en mix.

Säkerhetsproblem

Se även: NTP-server missbruk och missbruk

Endast ett fåtal andra säkerhetsproblem har identifierats i referensimplementeringen av NTP-kodbasen, men de som dök upp 2009 [ vilken ? ] gav anledning till betydande oro. Protokollet har genomgått revidering och översyn under hela dess historia. Kodbasen för referensimplementeringen har under flera år genomgått säkerhetsrevisioner från flera källor.

Ett stackbuffertspill upptäcktes och korrigerades 2014. Apple var tillräckligt oroad över denna sårbarhet för att använda sin automatiska uppdateringsfunktion för första gången. Vissa implementeringsfel är grundläggande, till exempel en saknad retursats i en rutin, som kan leda till obegränsad åtkomst till system som kör vissa versioner av NTP i rotdemonen. System som inte använder rotdemonen, såsom de som härrör från Berkeley Software Distribution (BSD), är inte föremål för detta fel. [ tveksamt – diskutera ]

En säkerhetsrevision 2017 av tre NTP-implementeringar, utförd på uppdrag av Linux Foundations Core Infrastructure Initiative, antydde att både NTP och NTPsec var mer problematiska än Chrony ur säkerhetssynpunkt.

NTP-servrar kan vara mottagliga för man-in-the-middle-attacker om inte paket är kryptografiskt signerade för autentisering. Den inblandade beräkningskostnaden kan göra detta opraktiskt på upptagna servrar, särskilt under överbelastningsattacker . NTP-meddelandeförfalskning från en man-in-the-middle-attack kan användas för att ändra klockor på klientdatorer och tillåta ett antal attacker baserat på att förbigå kryptografiska nyckelförfall. Några av tjänsterna som påverkas av falska NTP-meddelanden som identifierats är TLS , DNSSEC , olika cachingscheman (som DNS-cache), Border Gateway Protocol (BGP), Bitcoin [ citat behövs ] och ett antal beständiga inloggningsscheman.

NTP har använts i distribuerade överbelastningsattacker . En liten fråga skickas till en NTP-server med retur- IP-adressen förfalskad att vara måladressen. I likhet med DNS-förstärkningsattacken svarar servern med ett mycket större svar som gör det möjligt för en angripare att avsevärt öka mängden data som skickas till målet. För att undvika att delta i en attack kan NTP-serverprogramvara uppgraderas eller servrar kan konfigureras för att ignorera externa frågor.

Säkra tillägg

NTP i sig inkluderar stöd för autentisering av servrar till klienter. NTPv3 stöder ett symmetriskt nyckelläge, vilket inte är användbart mot MITM. Det offentliga nyckelsystemet som kallas "autokey" i NTPv4 anpassat från IPSec erbjuder användbar autentisering, men är inte praktiskt för en upptagen server. Autokey visade sig också senare lida av flera designfel, utan någon korrigering publicerad, förutom en ändring av meddelandeautentiseringskoden i RFC 8573.

Network Time Security (NTS) är en säker version av NTPv4 med TLS och AEAD . Den största förbättringen jämfört med tidigare försök är att en separat "nyckeletablering"-server hanterar den tunga asymmetriska kryptografin, som bara behöver göras en gång. Om servern går ner skulle tidigare användare fortfarande kunna hämta tid utan rädsla för MITM. NTS stöds för närvarande av flera tidsservrar, inklusive CloudFlare . Det stöds av NTPSec och chrony.

Microsoft har också en metod för att autentisera NTPv3/SNTPv4-paket med en Windows-domänidentitet, känd som MS-SNTP. Detta system är implementerat i referensen ntpd och chrony, med hjälp av samba för domänanslutningen.

Se även

Anteckningar

Vidare läsning

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=Network_Time_Protocol&oldid=1142930911 "