Hispanopedia Wiki
Articulo de referencia

Network Time Protocol

The Network Time Protocol ( NTP ) is a networking protocol for clock synchronization between computer systems over packet-switched , variable- latency data networks. In operatio...

Hispanopedia WikiContenido en espanolLectura gratuita

The Network Time Protocol (NTP) is a networking protocol for clock synchronization between computer systems over packet-switched, variable-latency data networks. In operation since before 1985, NTP is one of the oldest Internet protocols in current use. NTP was designed by David L. Mills of the University of Delaware.

NTP is intended to synchronize participating computers to within a few milliseconds of Coordinated Universal Time (UTC).[1]:3 It uses the intersection algorithm, a modified version of Marzullo's algorithm, to select accurate time servers and is designed to mitigate the effects of variable network latency. NTP can usually maintain time to within tens of milliseconds over the public Internet, and can achieve better than one millisecond accuracy in local area networks under ideal conditions. Asymmetric routes and network congestion can cause errors of 100 ms or more.[2][3]

The protocol is usually described in terms of a client–server model, but can as easily be used in peer-to-peer relationships where both peers consider the other to be a potential time source.[1]:20 Implementations send and receive timestamps using the User Datagram Protocol (UDP); the service is normally on port number 123, and in some modes both sides use this port number.[4][5]:16 They can also use broadcasting or multicasting, where clients passively listen to time updates after an initial round-trip calibrating exchange.[3] NTP supplies a warning of any impending leap second adjustment, but no information about local time zones or daylight saving time is transmitted.[2][3]

The current protocol is version 4 (NTPv4),[5] which is backward compatible with version 3.[6]

Clock synchronization algorithm

Tiempo de retraso de ida y vuelta δ

Un cliente NTP típico consulta regularmente a uno o más servidores NTP. El cliente debe calcular su desfase horario y el retardo de ida y vuelta . El desfase horario θ es la diferencia positiva o negativa (hora del cliente > hora del servidor) en el tiempo absoluto entre los dos relojes. Se define por

θ=(t1−t0)+(t2−t3)2,{\displaystyle \theta ={\frac {(t_{1}-t_{0})+(t_{2}-t_{3})}{2}},} y el retraso de ida y vuelta δ por δ=(t3−t0)−(t2−t1),{\displaystyle \delta ={(t_{3}-t_{0})-(t_{2}-t_{1})},} dónde

  • t 0 es la marca de tiempo del cliente de la transmisión del paquete de solicitud,
  • t 1 es la marca de tiempo del servidor de la recepción del paquete de solicitud,
  • t 2 es la marca de tiempo del servidor de la transmisión del paquete de respuesta y
  • t 3 es la marca de tiempo del cliente de la recepción del paquete de respuesta. [ 1 ] : 19

Para derivar la expresión para el desplazamiento, tenga en cuenta que para el paquete de solicitud, t0+θ+δ/2=t1{\displaystyle t_{0}+\theta +\delta /2=t_{1}} y para el paquete de respuesta, t3+θ−δ/2=t2{\displaystyle t_{3}+\theta -\delta /2=t_{2}} Al despejar θ se obtiene la definición del desfase temporal.

Los valores de θ y δ se filtran y se someten a un análisis estadístico ("mitigación"). Se descartan los valores atípicos y se obtiene una estimación del desfase temporal a partir de los tres mejores candidatos restantes. A continuación, se ajusta la frecuencia del reloj para reducir gradualmente el desfase ("disciplina"), creando un bucle de retroalimentación . [ 1 ] : 20

La sincronización precisa se logra cuando las rutas de entrada y salida entre el cliente y el servidor tienen un retardo nominal simétrico. Si las rutas no tienen un retardo nominal común, existe un sesgo sistemático equivalente a la mitad de la diferencia entre los tiempos de viaje de ida y vuelta. Se han propuesto varios enfoques para medir la asimetría, [ 7 ] pero entre las implementaciones prácticas, solo chrony parece incluir uno. [ 8 ] [ 9 ]

Historia

El NTP fue diseñado por David L. Mills .

En 1979, la tecnología de sincronización horaria de red se utilizó en lo que posiblemente fue la primera demostración pública de servicios de Internet que funcionaban a través de una red satelital transatlántica, en la Conferencia Nacional de Computación en Nueva York. La tecnología se describió posteriormente en la Nota de Ingeniería de Internet (IEN) 173 de 1981 [ 21 ] y se desarrolló un protocolo público a partir de ella que se documentó en la RFC 778. La tecnología se implementó por primera vez en una red de área local como parte del protocolo de enrutamiento Hello y se implementó en el enrutador Fuzzball , un sistema operativo experimental utilizado en la creación de prototipos de red, donde funcionó durante muchos años. 

Otras herramientas de red relacionadas estaban disponibles tanto entonces como ahora. Estas incluyen los protocolos Daytime y Time para registrar la hora de los eventos, así como los mensajes de marca de tiempo ICMP y la opción de marca de tiempo IP ( RFC 781 ). Los sistemas de sincronización más completos, aunque carecen de los algoritmos de análisis de datos y disciplina del reloj de NTP, incluyen el demonio Unix timed , que utiliza un algoritmo de elección para designar un servidor para todos los clientes; [ 22 ] y el Servicio de Sincronización de Tiempo Digital (DTSS), que utiliza una jerarquía de servidores similar al modelo de estratos de NTP. 

En 1985, la versión 0 del protocolo NTP (NTPv0) se implementó tanto en Fuzzball como en Unix, y los cálculos de la cabecera del paquete NTP, el retardo de ida y vuelta y el desfase, que se han mantenido en NTPv4, se documentaron en el RFC 958. A pesar de la relativa lentitud de los ordenadores y las redes disponibles en aquel momento, se solía obtener una precisión superior a 100 milisegundos en los enlaces transatlánticos, y de decenas de milisegundos en las redes Ethernet . 

En 1988, se publicó en el RFC 1059 una especificación mucho más completa del protocolo NTPv1, con sus algoritmos asociados . Esta especificación se basó en los resultados experimentales y el algoritmo de filtro de reloj documentados en el RFC 956 y fue la primera versión en describir los modos cliente-servidor y punto a punto . En 1991, la arquitectura, el protocolo y los algoritmos de NTPv1 captaron la atención de una comunidad de ingeniería más amplia con la publicación de un artículo de David L. Mills en las IEEE Transactions on Communications . [ 23 ]  

En 1989, se publicó el RFC 1119, que definía NTPv2 mediante una máquina de estados , con pseudocódigo para describir su funcionamiento. Introdujo un protocolo de gestión y un esquema de autenticación criptográfica que se han mantenido en NTPv4, junto con la mayor parte del algoritmo. Sin embargo, el diseño de NTPv2 fue criticado por la comunidad DTSS por carecer de corrección formal , y el procedimiento de selección de reloj se modificó para incorporar el algoritmo de Marzullo a partir de NTPv3. [ 24 ] 

En 1992, el RFC 1305 definió NTPv3. Este RFC incluía un análisis de todas las fuentes de error, desde el reloj de referencia hasta el cliente final, lo que permitió calcular una métrica que ayuda a elegir el mejor servidor cuando varios candidatos parecen no coincidir. Se introdujo el modo de difusión. 

En los años siguientes, a medida que se añadieron nuevas características y se realizaron mejoras en los algoritmos, se hizo evidente que se requería una nueva versión del protocolo. [ 25 ] En 2010, se publicó el RFC 5905 que contenía una especificación propuesta para NTPv4. [ 26 ] Tras la jubilación de Mills de la Universidad de Delaware , la implementación de referencia se mantiene actualmente como un proyecto de código abierto liderado por Harlan Stenn. [ 27 ] [ 28 ] Por parte de la IANA , un grupo de trabajo ntp ( protocolos de tiempo de red ) se encarga de revisar los borradores propuestos. [ 29 ] 

El protocolo ha progresado significativamente desde NTPv4. [ 26 ] A partir de 2022Se han publicado tres documentos RFC que describen actualizaciones del protocolo, [ 18 ] [ 19 ] [ 20 ] sin contar los numerosos estándares periféricos [ 29 ] como Network Time Security. [ 30 ] Mills había mencionado planes para un "NTPv5" en su página, pero nunca se publicó. [ 26 ] Un borrador no relacionado denominado "NTPv5" por M. Lichvar de chrony se inició en 2020 e incluye cambios de seguridad, precisión y escalabilidad. [ 31 ]

SNTP

A medida que NTP reemplazó al antiguo Protocolo de Tiempo , algunos casos de uso consideraron que el protocolo completo era demasiado complicado. En 1992, se definió el Protocolo de Tiempo de Red Simple ( SNTP ) para cubrir esta necesidad. El estándar SNTPv3 describe una forma de usar NTPv3 que no requiere el almacenamiento de estado durante un período prolongado. La topología se vuelve esencialmente la misma que con el Protocolo de Tiempo, ya que solo se utiliza un servidor. [ 13 ] En 1996, SNTP se actualizó a SNTPv4, [ 15 ] con algunas características del entonces en desarrollo NTPv4. SNTPv4 se fusionó con el estándar principal NTPv4 en 2010. [ 5 ]

SNTP es totalmente interoperable con NTP, ya que no define un nuevo protocolo [ 32 ] : §14 , puesto que utiliza el mismo formato de paquete y puerto que NTP, lo que garantiza la compatibilidad con los servidores NTP. Sin embargo, el cliente/servidor carecerá de los algoritmos complejos necesarios para filtrar la fluctuación de la red , analizar la deriva del reloj o realizar referencias cruzadas de múltiples fuentes de tiempo. Esto lo hace adecuado para dispositivos IoT y hardware básico que requieren una hora "suficientemente buena" sin la sobrecarga de una pila de aplicaciones NTP completa. [ 5 ]

Un cliente SNTP normalmente funciona consultando un único servidor y aplicando la hora recibida directamente al reloj local. Sin embargo, los algoritmos simples proporcionan horas con menor precisión, por lo que no es aconsejable sincronizar la hora desde una fuente SNTP. No obstante, el RFC 5905 señala que, dado que la complejidad adicional del protocolo completo en la red es mínima, se recomienda su implementación completa incluso para clientes sencillos. [ 5 ]

estratos del reloj

El reloj maestro alternativo del Observatorio Naval de los Estados Unidos en la Base Aérea Schriever (Colorado) es una fuente de estrato 0 para la hora nacional de tránsito (NTP).
Las flechas amarillas indican una conexión directa; las flechas rojas indican una conexión de red.

NTP utiliza un sistema jerárquico y semicapa de fuentes de tiempo. Cada nivel de esta jerarquía se denomina estrato y se le asigna un número que comienza con cero para el reloj de referencia en la parte superior. Un servidor sincronizado con un servidor de estrato n funciona en el estrato n + 1. El número representa la distancia al reloj de referencia y se utiliza para evitar dependencias cíclicas en la jerarquía. El estrato no siempre indica calidad o fiabilidad; es común encontrar fuentes de tiempo de estrato 3 de mayor calidad que algunas fuentes de tiempo de estrato 2. [ a ] ​​A continuación se proporcionan breves descripciones de los estratos 0, 1, 2 y 3.

Estrato 0
Se trata de dispositivos de cronometraje de alta precisión, como relojes atómicos , GNSS (incluido GPS ) u otros relojes de radio , o relojes sincronizados PTP . [ 33 ] Generan una señal de pulso por segundo muy precisa que activa una interrupción y una marca de tiempo en un ordenador conectado. Los dispositivos de estrato 0 también se conocen como relojes de referencia . Los servidores NTP no pueden anunciarse como de estrato 0; un campo de estrato establecido en 0 en un mensaje NTP indica un estrato no especificado. [ 5 ] : 21
Estrato 1
Se trata de ordenadores cuyo tiempo del sistema está sincronizado con una precisión de unos pocos microsegundos respecto a sus dispositivos de estrato 0 conectados. Los servidores de estrato 1 pueden establecer interconexión con otros servidores de estrato 1 para realizar comprobaciones de coherencia y copias de seguridad. [ 34 ] También se les denomina servidores de tiempo primarios. [ 2 ] [ 3 ]
Estrato 2
Se trata de ordenadores sincronizados a través de una red con servidores de estrato 1. A menudo, un ordenador de estrato 2 consulta a varios servidores de estrato 1. Los ordenadores de estrato 2 también pueden establecer interconexión con otros ordenadores de estrato 2 para proporcionar una sincronización horaria más estable y robusta a todos los dispositivos del grupo.
Estrato 3
These are computers that are synchronized to stratum 2 servers. They employ the same algorithms for peering and data sampling as stratum 2, and can themselves act as servers for stratum 4 computers, and so on.

The upper limit for stratum is 15; stratum 16 is used to indicate that a device is unsynchronized. The NTP algorithms on each computer interact to construct a Bellman–Ford shortest-path spanning tree, to minimize the accumulated round-trip delay to the stratum 1 servers for all the clients.[1]:20

In addition to stratum, the protocol is able to identify the synchronization source for each server in terms of a reference identifier (refid).

For servers on stratum 2 and below, the refid is an encoded form of the upstream time server's IP address. For IPv4, this is simply the 32-bit address; for IPv6, it would be the first 32 bits of the MD5 hash of the source address. Refids serve to detect and prevent timing loops to the first degree.[5]

El campo refid se rellena con palabras de estado en el caso de paquetes kiss-o'-death (KoD), que le indican al cliente que deje de enviar solicitudes para que el servidor pueda descansar. [ 5 ] Algunos ejemplos son INIT (inicialización), STEP (cambio de tiempo de paso) y RATE (cliente solicitando demasiado rápido). [ 38 ] La salida del programa puede utilizar adicionalmente códigos no transmitidos en el paquete para indicar un error, como XFAC para indicar una desconexión de red. [ 35 ]

La IANA mantiene un registro de nombres de fuentes refid y códigos KoD. Aún pueden aparecer asignaciones informales. [ 39 ]

Implementaciones de software

La utilidad del protocolo de administración NTP ntpqen Windows 11 se utiliza para consultar el estado de los servidores de hora de estrato 1 y verificar el correcto funcionamiento del cliente.

Implementación de referencia

La implementación de referencia NTP , junto con el protocolo, se ha desarrollado continuamente durante más de 20 años. Se ha mantenido la compatibilidad con versiones anteriores a medida que se han añadido nuevas funciones. Contiene varios algoritmos sensibles, especialmente para disciplinar el reloj, que pueden comportarse mal cuando se sincronizan con servidores que utilizan algoritmos diferentes. El software se ha portado a casi todas las plataformas informáticas, incluidas las computadoras personales. Se ejecuta como un demonio llamado ntpd en Unix o como un servicio en Windows. Se admiten relojes de referencia y sus desfases se filtran y analizan de la misma manera que los servidores remotos, aunque generalmente se consultan con mayor frecuencia. [ 1 ] : 15–19 Esta implementación fue auditada en 2017, encontrándose 14 posibles problemas de seguridad. [ 40 ]

Hora de Windows

Todas las versiones de Microsoft Windows desde Windows 2000 incluyen el servicio de hora de Windows (W32Time), [ 41 ] que tiene la capacidad de sincronizar el reloj del ordenador con un servidor NTP.

W32Time se implementó originalmente para el protocolo de autenticación Kerberos versión 5, que requería que la hora estuviera dentro de los 5 minutos del valor correcto para evitar ataques de repetición . El servidor de hora de red en Windows 2000 Server (y Windows XP) no implementa la sincronización disciplinada NTP, solo la sincronización disciplinada local con corrección NTP/SNTP. [ 42 ]

Beginning with Windows Server 2003 and Windows Vista, the NTP provider for W32Time became compatible with a significant subset of NTPv3.[43] Microsoft states that W32Time cannot reliably maintain time synchronization with one second accuracy.[44] If higher accuracy is desired, Microsoft recommends using a newer version of Windows or different NTP implementation.[45]

Beginning with Windows 10 version 1607 and Windows Server 2016, W32Time can be configured to reach time accuracy of 1 s, 50 ms or 1 ms under certain specified operating conditions.[46][44][47]

OpenNTPD

In 2004, Henning Brauer of OpenBSD presented OpenNTPD, an NTPv3/SNTPv4[48] implementation with a focus on security and encompassing a privilege-separated design. Whilst it is aimed more closely at the simpler generic needs of OpenBSD users, it also includes some protocol security improvements while still being compatible with existing NTP servers. The simpler code base sacrifices accuracy, deemed unnecessary in this use case.[49] A portable version is available in Linux package repositories.

NTPsec

NTPsec is a fork of the reference implementation that has been systematically security-hardened. The fork point was in June 2015 and was in response to a series of compromises in 2014.[50] The first production release shipped in October 2017.[51] Between removal of unsafe features, removal of support for obsolete hardware, and removal of support for obsolete Unix variants, NTPsec has been able to pare away 75% of the original codebase, making the remainder easier to audit.[52] A 2017 audit of the code showed eight security issues, including two that were not present in the original reference implementation, but NTPsec did not suffer from eight other issues that remained in the reference implementation.[53]

chrony

chronyc, showing Network Time Security (NTS) sources and activity information

chrony es una implementación independiente de NTP patrocinada principalmente por Red Hat , que la utiliza como programa de hora predeterminado en sus distribuciones. [ 54 ] Al haber sido escrita desde cero, chrony tiene un código base más simple que permite una mayor seguridad [ 55 ] y un menor consumo de recursos. [ 56 ] Sin embargo, no compromete la precisión, sino que sincroniza más rápido y mejor que el ntpd de referencia en muchas circunstancias. Es lo suficientemente versátil para ordenadores comunes, que son inestables, entran en modo de suspensión o tienen una conexión intermitente a Internet. También está diseñado para máquinas virtuales, un entorno más inestable. [ 57 ]

chrony ha sido evaluado como "confiable", con solo unos pocos incidentes. [ 58 ] Es capaz de lograr una mayor precisión en las conexiones LAN, utilizando el marcado de tiempo por hardware en el adaptador de red. [ 8 ] Se agregó soporte para Network Time Security (NTS) en la versión 4.0. [ 59 ] chrony está disponible bajo la Licencia Pública General GNU versión 2 , fue creado por Richard Curnow en 1997 y actualmente es mantenido por Miroslav Lichvar . [ 56 ]

ntpd-rs

ntp-ctl (parte de ntpd-rs), que muestra información de sincronización y fuentes NTS.

ntpd-rs es una implementación del protocolo NTP centrada en la seguridad, fundada por el Grupo de Investigación en Seguridad de Internet como parte de su iniciativa Prossimo para la creación de una infraestructura de Internet segura para la memoria. ntpd-rs está implementado en el lenguaje de programación Rust , que ofrece garantías de seguridad de memoria además de las capacidades de computación en tiempo real necesarias para una implementación de NTP. ntpd-rs se utiliza en entornos sensibles a la seguridad, como la Autoridad de Certificación sin fines de lucro Let's Encrypt . [ 60 ] Se ofrece soporte para NTS. [ 61 ] ntpd-rs forma parte del proyecto "Pendulum", que también incluye una implementación del Protocolo de Tiempo de Precisión "statime". Ambos proyectos están disponibles bajo las licencias de software Apache y MIT .

Otros

Segundos intercalares

El día de un evento de segundo intercalar , ntpd recibe una notificación de un archivo de configuración , un reloj de referencia conectado o un servidor remoto. Aunque el reloj NTP se detiene durante el evento, debido al requisito de que el tiempo debe parecer estrictamente creciente , cualquier proceso que consulte la hora del sistema provoca un pequeño incremento, preservando así el orden de los eventos. Si alguna vez fuera necesario un segundo intercalar negativo, se eliminaría con la secuencia 23:59:58, 00:00:00, omitiendo 23:59:59. [ 67 ]

Una implementación alternativa, denominada "salto intercalar", consiste en introducir el segundo intercalar de forma incremental durante un período de 24 horas, desde el mediodía hasta el mediodía en hora UTC. Esta implementación es utilizada por Google (tanto internamente como en sus servidores NTP públicos), Amazon AWS [ 68 ] y Facebook [ 69 ] . chrony admite el salto intercalar en las configuraciones smoothtime y leapsecmode , pero dicho uso no debe combinarse con un grupo NTP público, ya que el salto intercalar no es estándar y alterará el cálculo del cliente en una combinación [ 70 ] .

Preocupaciones de seguridad

Debido a que ajustar la hora del sistema es generalmente una operación privilegiada, parte o la totalidad del código NTP debe ejecutarse con ciertos privilegios para admitir su funcionalidad principal. Solo se han identificado algunos otros problemas de seguridad en la implementación de referencia del código base de NTP, pero aquellos que aparecieron en 2009, como la ejecución de código arbitrario y los ataques de denegación de servicio , fueron motivo de gran preocupación. [ 71 ] [ 72 ] El protocolo ha estado sujeto a revisión y actualización a lo largo de su historia. El código base para la implementación de referencia ha sido sometido a auditorías de seguridad de varias fuentes durante varios años. [ 73 ]

Se descubrió y se corrigió una vulnerabilidad de desbordamiento de búfer de pila en 2014. [ 74 ] Apple estaba tan preocupada por esta vulnerabilidad que utilizó su función de actualización automática por primera vez. [ 75 ] En sistemas que utilizan la implementación de referencia, que se ejecuta con las credenciales del usuario root, esto podría permitir un acceso ilimitado. Algunas otras implementaciones, como OpenNTPD , tienen una base de código más pequeña y adoptaron otras medidas de mitigación, como la separación de privilegios, por lo que no están sujetas a esta falla. [ 76 ]

Una auditoría de seguridad de 2017 de tres implementaciones de NTP, realizada en nombre de la Iniciativa de Infraestructura Central de la Fundación Linux, sugirió que tanto NTP [ 77 ] [ 78 ] como NTPsec [ 79 ] eran más problemáticos que chrony [ 80 ] desde el punto de vista de la seguridad. [ 81 ]

Los servidores NTP pueden ser susceptibles a ataques de intermediario a menos que los paquetes estén firmados criptográficamente para su autenticación. [ 82 ] La sobrecarga computacional involucrada puede hacer que esto sea impracticable en servidores ocupados, particularmente durante ataques de denegación de servicio . [ 83 ] La suplantación de mensajes NTP de un ataque de intermediario puede usarse para alterar los relojes en las computadoras cliente y permitir una serie de ataques basados ​​en la elusión de la expiración de la clave criptográfica. [ 84 ] Algunos de los servicios afectados por mensajes NTP falsos identificados son TLS , DNSSEC , varios esquemas de caché (como la caché DNS), Border Gateway Protocol (BGP), Bitcoin y varios esquemas de inicio de sesión persistente. [ 85 ] [ 86 ]

NTP se ha utilizado en ataques de denegación de servicio distribuidos . [ 87 ] [ 88 ] Se envía una pequeña consulta a un servidor NTP con la dirección IP de respuesta falsificada para que sea la dirección de destino. De forma similar al ataque de amplificación de DNS , el servidor responde con una respuesta mucho mayor que permite a un atacante aumentar sustancialmente la cantidad de datos que se envían al objetivo. Para evitar participar en un ataque, se puede actualizar el software del servidor NTP o configurar los servidores para que ignoren las consultas externas. [ 89 ]

Extensiones seguras

El propio NTP incluye soporte para autenticar servidores a clientes. NTPv3 admite un modo de clave simétrica , que no es útil contra ataques MITM. El sistema de clave pública conocido como "autokey" en NTPv4, adaptado de IPSec, ofrece una autenticación útil, [ 82 ] pero no es práctico para un servidor con mucho tráfico. [ 83 ] Posteriormente se descubrió que Autokey también sufría de varios fallos de diseño, [ 90 ] sin que se publicara ninguna corrección, salvo un cambio en el código de autenticación de mensajes . [ 19 ] Autokey ya no debería utilizarse. [ 91 ]

Network Time Security (NTS) es una versión segura de NTPv4 con TLS y AEAD . [ 92 ] La principal mejora con respecto a intentos anteriores es que un servidor de "establecimiento de claves" independiente maneja la criptografía asimétrica compleja, que solo necesita hacerse una vez. Si el servidor falla, los usuarios anteriores aún podrían obtener la hora sin temor a un ataque de intermediario (MITM). [ 30 ] NTS es compatible con varios servidores NTP, incluidos Cloudflare y Netnod . [ 93 ] [ 94 ] Se puede habilitar en chrony , NTPsec y ntpd-rs. [ 95 ]

Microsoft también tiene un método para autenticar paquetes NTPv3/SNTPv4 utilizando una identidad de dominio de Windows , conocido como MS-SNTP. [ 96 ] Este sistema está implementado en ntpd y chrony de referencia, utilizando samba para la conexión de dominio. [ 97 ]

formato de encabezado de paquete NTP

LI (Indicador de salto) : 2 bits
Advertencia sobre la inserción o eliminación de segundos intercalares:
  • 0 = sin advertencia
  • 1 = el último minuto tiene 61 segundos
  • 2 = el último minuto tiene 59 segundos
  • 3 = desconocido (reloj no sincronizado)
VN (Número de versión) : 3 bits
Número de versión de NTP, normalmente 4.
Modo : 3 bits
Modo de asociación:
  • 0 = reservado
  • 1 = activo simétrico
  • 2 = pasivo simétrico
  • 3 = cliente
  • 4 = servidor
  • 5 = transmisión
  • 6 = control
  • 7 = privado
Estrato : 8 bits
Indica la distancia desde el reloj de referencia.
  • 0 = inválido
  • 1 = servidor principal
  • 2–15 = secundaria
  • 16 = no sincronizado
Encuesta : 8 bits
Intervalo máximo entre mensajes sucesivos, en log₂(segundos). El rango típico es de 6 a 10.
Precisión : 8 bits
Logaritmo con signo de la precisión del reloj del sistema en segundos (por ejemplo, –18 ≈ 1 microsegundo).
Retardo de raíz : 32 bits
Retardo total de ida y vuelta al reloj de referencia, en formato corto NTP.
Dispersión de raíz : 32 bits
Dispersión total respecto al reloj de referencia, en formato corto NTP.
ID de referencia : 32 bits
Identifica el servidor específico o el reloj de referencia; la interpretación depende de Stratum.
Marca de tiempo de referencia : 64 bits
Hora en que se configuró o corrigió por última vez el reloj del sistema, en formato de marca de tiempo NTP.
Marca de tiempo de origen (org) : 64 bits
Hora en la que el cliente envió la solicitud, en formato de marca de tiempo NTP.
Marca de tiempo de recepción (rec) : 64 bits
La hora local, en formato de marca de tiempo, en la que llegó el último mensaje NTP.
Marca de tiempo de transmisión (xmt) : 64 bits
Hora en que el servidor envió la respuesta, en formato de marca de tiempo NTP.
Campo de extensión : variable
Campo(s) opcional(es) para extensiones NTP (ver [ 5 ] , Sección 7.5).
Identificador de clave : 32 bits
Entero sin signo que designa una clave MD5 compartida por el cliente y el servidor.
Resumen del mensaje (MD5) : 128 bits
Hash MD5 que abarca el encabezado del paquete y los campos de extensión, utilizado para la autenticación.

Marcas de tiempo

Las marcas de tiempo de punto fijo binario de 64 bits utilizadas por NTP constan de una parte de 32 bits para los segundos y otra de 32 bits para las fracciones de segundo, lo que da como resultado una escala de tiempo que se reinicia cada 2³² segundos (136 años) y una resolución teórica de 2⁻³² segundos (233 picosegundos). NTP utiliza una época del 1 de enero de 1900. Por lo tanto, el primer reinicio ocurre el 7 de febrero de 2036. [ 98 ] [ 99 ]

NTPv4 introduce un formato de fecha de 128 bits: 64 bits para el segundo y 64 bits para la fracción de segundo. Sin embargo, el formato de 128 bits nunca se transmite, ya que el estándar establece que las eras "no pueden ser producidas directamente por NTP, ni hay necesidad de hacerlo". [ 100 ] Los 32 bits más significativos de este formato son el Número de Era , que resolvería la ambigüedad de desbordamiento en la mayoría de los casos. [ 101 ] Según Mills, "El valor de 64 bits para la fracción es suficiente para resolver la cantidad de tiempo que tarda un fotón en pasar por un electrón a la velocidad de la luz. El valor de 64 bits para el segundo es suficiente para proporcionar una representación de tiempo inequívoca hasta que el universo se atenúe". [ 102 ] [ b ]

Configuración de NTP y zona horaria mediante DHCP

DHCPv4 permite a los clientes obtener automáticamente fuentes de hora como parte de la configuración inicial de la red. Se utiliza habitualmente en redes gestionadas para garantizar la sincronización horaria dinámica sin necesidad de configuración manual.

descubrimiento del servidor NTP

RFC 2132 [ 103 ] define una opción DHCPv4 dedicada para distribuir direcciones de servidor NTP a los clientes.

La opción Servidores de protocolo de tiempo de red (NTP) contiene una lista de direcciones IPv4 que identifican los servidores NTP disponibles para el cliente. Los servidores deben aparecer en orden de preferencia, lo que permite al cliente seleccionar la fuente más adecuada.

  • Código de opción: 42
  • Longitud mínima: 4 octetos
  • Longitud: debe ser un múltiplo de 4.
  • Contenido: una secuencia de direcciones IPv4 de 32 bits, donde cada dirección representa un servidor NTP.
  • Ejemplos: 42|2|192.0.2.1|192.0.2.2

Configuración de la zona horaria mediante DHCP

Si bien el Protocolo de Tiempo de Red (NTP) se encarga de sincronizar los relojes del sistema con el Tiempo Universal Coordinado (UTC), no distribuye información sobre la zona horaria local . La configuración de la zona horaria se gestiona por separado a nivel del sistema operativo.

Esto es especialmente útil para redes donde los dispositivos entran y salen constantemente, como las redes celulares . Reduce la necesidad de definirlo directamente en el dispositivo.

Estas opciones se definen en RFC 4833 [ 104 ] y se aplican tanto a DHCP para IPv4 ( DHCPv4 ) como a IPv6 ( DHCPv6 ).

Opciones de zona horaria DHCPv4

Se definen las siguientes opciones de DHCPv4:

Ambas opciones contienen una cadena de longitud variable y no terminan en nulo.

Cadena de zona horaria POSIX (opción 100)

This option carries a time zone definition using the POSIX TZ environment variable format (as specified in IEEE 1003.1), except that the string must not begin with a colon (:).

Example:

EST5EDT4,M3.2.0/02:00,M11.1.0/02:00

This describes:

  • Standard time: EST (UTC−5)
  • Daylight saving time: EDT (UTC−4)
  • DST starts: second Sunday in March at 02:00
  • DST ends: first Sunday in November at 02:00
Time zone database name (option 101)

For this option to be useful, the client must already have a local copy of the time zone database. If the client recognizes the provided name, it should prefer this option over the POSIX string. If the name is unknown, the option must be ignored.

This option contains the name of a zone from the IANA Time Zone Database , such as:

Europe/Oslo

DHCPv6 time zone options

RFC 4833 defines equivalent options for DHCPv6 with different option codes:

The semantics and string formats are identical to those used in DHCPv4; only the binary encoding differs due to protocol differences between DHCPv4 and DHCPv6.

Relationship to NTP

NTP distributes only absolute time (UTC) and does not include any information about local time zones or daylight saving rules. DHCP time zone options complement NTP by allowing clients to automatically configure their local time representation after their clocks have been synchronised.

In typical deployments:

  • DHCP provides IP configuration and time zone information.
  • NTP synchronises the system clock to UTC.
  • The operating system applies the configured time zone to present local time to users and applications.

This separation keeps NTP simple and avoids embedding region-specific political and legal time rules into the time synchronisation protocol.

See also

  • Allan variance – Measure of frequency stability in clocks and oscillators
  • Clock network – Set of clocks that synchronized to same time
  • International Atomic Time – Time standard based on atomic clocks
  • IRIG timecode – Standard formats for transferring time information
  • NITZ – Mechanism for time synchronisation on mobile devices
  • NTP pool – Networked computers providing time synchronization
  • Ntpdate – Networking protocol for clock synchronizationPages displaying short descriptions of redirect targets
  • Precision Time Protocol – Network time synchronization protocol

Notes

  1. ↑Telecommunication systems use a different definition for clock strata.
  2. ↑2−64 seconds is about 54 zeptoseconds (light would travel 16.26 picometers, or approximately 0.31 × Bohr radius), and 264 seconds is about 585 billion years.

References

  1. 123456David L. Mills (12 December 2010). Computer Network Time Synchronization: The Network Time Protocol. Taylor & Francis. pp. 12–. ISBN 978-0-8493-5805-0. Archived from the original on 18 July 2014. Retrieved 16 October 2016.
  2. 123"Executive Summary: Computer Network Time Synchronization". Archived from the original on 2 November 2011. Retrieved 21 November 2011.
  3. 1234"NTP FAQ". The NTP Project. Archived from the original on 6 September 2011. Retrieved 27 August 2011.
  4. ↑"Port Numbers". The Internet Assigned Numbers Authority (IANA). Archived from the original on 4 June 2001. Retrieved 19 January 2011.
  5. 1234567891011D. Mills; J. Burbank; W. Kasch (August 2010). J. Martin (ed.). Network Time Protocol Version 4: Protocol and Algorithms Specification. Internet Engineering Task Force. doi:10.17487/RFC5905. ISSN 2070-1721. RFC5905.Proposed Standard. Obsoletes RFC 1305, 4330. Updated by RFC 7822, 8573 and 9109.
  6. 12David L. Mills (March 1992). Network Time Protocol (Version 3) - Specification, Implementation and Analysis. Network Working Group. doi:10.17487/RFC1305. RFC1305.Obsolete. Obsoleted by RFC 5905. Obsoletes RFC 958, 1059 and 1119.
  7. ↑Gotoh, T.; Imamura, K.; Kaneko, A. (2002). "Improvement of NTP time offset under the asymmetric network with double packets method". Conference Digest Conference on Precision Electromagnetic Measurements. Conference on Precision Electromagnetic Measurements. pp. 448–449. doi:10.1109/CPEM.2002.1034915. ISBN 0-7803-7242-5.
  8. 12Lichvar, Miroslav (18 September 2018). "chrony – chrony.conf(5)". Chrony project. Retrieved 2 August 2020. This directive enables hardware timestamping of NTP packets sent to and received from the specified network interface.
  9. ↑"sourcestats.c, function estimate_asymmetry()". git.tuxfamily.org (chrony).
  10. ↑D. Mills (September 1985). Network Time Protocol (NTP). Network Working Group. doi:10.17487/RFC0958. RFC958.Obsolete. Obsoleted by RFC 1059, 1119 and 1305.
  11. ↑D. Mills (July 1988). Network Time Protocol (Version 1) Specification and Implementation. Network Working Group. doi:10.17487/RFC1059. RFC1059.Obsolete. Obsoleted by RFC 1119 and 1305.
  12. ↑D. Mills (September 1989). Network Time Protocol (Version 2) Specification and Implementation. Network Working Group. doi:10.17487/RFC1119. RFC1119.Obsolete. Obsoleted by RFC 1305. Obsoletes RFC 958 and 1059.
  13. 12D. Mills (August 1992). Type of Service in the Internet Protocol Suite. Network Working Group. doi:10.17487/RFC1361. RFC1361.Obsolete. Obsoleted by RFC 1769.
  14. ↑D. Mills (March 1995). Simple Network Time Protocol (SNTP). Network Working Group. doi:10.17487/RFC1769. RFC1769.Obsolete. Obsoleted by RFC 2030. Obsoletes RFC 1361.
  15. 12D. Mills (October 1996). Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. Network Working Group. doi:10.17487/RFC2030. RFC2030.Obsolete. Obsoleted by RFC 4330. Obsoletes RFC 1769.
  16. ↑D. Mills (January 2006). Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. Network Working Group. doi:10.17487/RFC4330. RFC4330.Obsolete. Obsoletes RFC 2030 and 1769. Obsoleted by RFC 5905.
  17. ↑D.L. Mills (April 1981). DCNET Internet Clock Service. IETF. doi:10.17487/RFC0778. RFC778.Historic.
  18. 12T. Mizrahi; D. Mayer (March 2016). Network Time Protocol Version 4 (NTPv4) Extension Fields. Internet Engineering Task Force. doi:10.17487/RFC7822. ISSN 2070-1721. RFC7822.Informational. Updates RFC 5905.
  19. 123A. Malhotra; S. Goldberg (June 2019). Message Authentication Code for the Network Time Protocol. Internet Engineering Task Force. doi:10.17487/RFC8573. ISSN 2070-1721. RFC8573.Proposed Standard. Updates RFC 5905.
  20. 12F. Gont; G. Gont; M. Lichvar (August 2021). Network Time Protocol Version 4: Port Randomization. Internet Engineering Task Force. doi:10.17487/RFC9109. ISSN 2070-1721. RFC9109.Proposed Standard. Updates RFC 5905.
  21. ↑D.L. Mills (25 February 1981), Time Synchronization in DCNET Hosts, archived from the original on 30 December 1996
  22. ↑"TIMED(8)", UNIX System Manager's Manual, archived from the original on 22 July 2011, retrieved 12 September 2017
  23. ↑ David L. Mills (octubre de 1991). "Sincronización horaria de Internet: el protocolo de tiempo de red" (PDF) . IEEE Transactions on Communications . 39 (10): 1482–1493 . Bibcode : 1991ITCom..39.1482M . doi : 10.1109/26.103043 . Archivado (PDF) del original el 10 de junio de 2016. Recuperado el 6 de noviembre de 2017 .
  24. ↑ David L. Mills (marzo de 1992). Protocolo de tiempo de red (versión 3): especificación, implementación y análisis . Grupo de trabajo de redes. doi : 10.17487/RFC1305 . RFC 1305 .Obsoleto. El procedimiento de selección de reloj se modificó para eliminar el primero de los dos pasos de clasificación/descarte y reemplazarlo con un algoritmo propuesto inicialmente por Marzullo e incorporado posteriormente al Servicio de Hora Digital. Estos cambios no afectan significativamente el funcionamiento habitual ni la compatibilidad con las distintas versiones de NTP, pero sí proporcionan la base para las declaraciones formales de corrección.
  25. ↑ David L. Mills (15 de noviembre de 2010). Sincronización horaria de redes informáticas: El protocolo de tiempo de red en la Tierra y en el espacio, segunda edición . CRC Press. pág. 377. ISBN  978-1-4398-1464-2.
  26. 1 2 3 "Planes futuros", Proyecto de investigación sobre sincronización horaria de red , archivado del original el 23 de diciembre de 2014 , recuperado el 24 de diciembre de 2014
  27. ↑ "NTP necesita dinero: ¿Es una fundación la solución?" . InformationWeek . 23 de marzo de 2015. Archivado del original el 10 de abril de 2015 . Consultado el 4 de abril de 2015 .
  28. ↑ "El destino de los NTP depende del 'padre tiempo'"" . InformationWeek . 11 de marzo de 2015. Archivado del original el 10 de abril de 2015 . Consultado el 4 de abril de 2015 .
  29. 1 2 "Protocolos de tiempo de red (ntp): Documentos" . datatracker.ietf.org . Consultado el 27 de diciembre de 2022 .
  30. 1 2 D. Franke; D. Sibold; K. Teichel; M. Dansarie; R. Sundblad (septiembre de 2020). Seguridad del tiempo de red para el protocolo de tiempo de red . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC8915 . ISSN 2070-1721 . RFC 8915 . Norma propuesta.
  31. ↑ Lichvar, Miroslav (2 de julio de 2025). "Network Time Protocol Version 5" . www.ietf.org .
  32. ↑ D. Mills ; J. Burbank; W. Kasch (agosto de 2010). J. Martin (ed.). Protocolo de tiempo de red versión 4: especificación de protocolo y algoritmos . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC5905 . ISSN 2070-1721 . RFC 5905 . Los servidores y clientes primarios que cumplen con un subconjunto de NTP, denominado Protocolo de Tiempo de Red Simple (SNTPv4) [...], no necesitan implementar los algoritmos de mitigación [...]. La implementación completa de NTPv4 está destinada a [...] servidores con múltiples servidores ascendentes y múltiples servidores descendentes [...]. Aparte de estas consideraciones, los servidores y clientes NTP y SNTP son completamente interoperables y pueden combinarse [...].
  33. ↑ "Combinando PTP con NTP para obtener lo mejor de ambos mundos" . www.redhat.com . Los programas del paquete linuxptp se pueden usar en combinación con un demonio NTP. Un reloj PTP en una tarjeta de red se sincroniza mediante ptp4l y se usa como reloj de referencia por chronyd o ntpd para la sincronización del reloj del sistema.
  34. ↑ "Protocolo de tiempo de red: Libro blanco sobre mejores prácticas" . Archivado del original el 1 de octubre de 2013. Consultado el 15 de octubre de 2013 .
  35. 1 2 "Salida de 'ntpq -p'" . NLUG.ML1.co.uk. Archivado del original el 12 de noviembre de 2018. Recuperado el 12 de noviembre de 2018 .
  36. ↑ «IMS-PZF: Receptor de Correlación PZF (DCF77) (Eurocard)» . Meinberg Funkuhren GmbH & Co. KG . Consultado el 19 de junio de 2025 .
  37. ↑ "¿Existe alguna señal en una respuesta NTP que indique que la manipulación de segundos intercalares de Google está en efecto?" . Groups.google.com . Consultado el 22 de junio de 2026 .
  38. ↑ "Mensajes de eventos y palabras de estado" . docs.ntpsec.org . Los códigos Refid se utilizan en los paquetes kiss-o'-death (KoD), el campo de identificador de referencia en las pantallas de billboard de ntpq y ntpmon y los mensajes de registro.
  39. ↑ "Parámetros del Protocolo de Tiempo de Red (NTP)" . www.iana.org .
  40. ↑ "Pentest-Report NTP 01.2017" (PDF) . Cure53. 2017. Archivado (PDF) del original el 1 de diciembre de 2018. Recuperado el 3 de julio de 2019 .
  41. ↑ "Referencia técnica del servicio de hora de Windows" . technet.microsoft.com. 17 de agosto de 2011. Archivado del original el 6 de septiembre de 2011. Consultado el 19 de septiembre de 2011 .
  42. ↑ "Página del Servicio de hora de Windows en NTP.org" . Support.NTP.org . 25 de febrero de 2008. Archivado del original el 14 de mayo de 2017. Consultado el 1 de mayo de 2017 .
  43. ↑ "Cómo funciona el servicio de hora de Windows" . technet.microsoft.com. 12 de marzo de 2010. Archivado del original el 24 de septiembre de 2011. Consultado el 19 de septiembre de 2011 .
  44. 1 2 "Compatibilidad con límites para configurar el servicio de hora de Windows para entornos de alta precisión" . Microsoft . 19 de octubre de 2011. Archivado del original el 12 de enero de 2009. Recuperado el 10 de diciembre de 2008 .
  45. ↑ Ned Pyle (23 de octubre de 2007). "Requisitos de alta precisión de W32time" . Microsoft . Archivado del original el 17 de octubre de 2012. Consultado el 26 de agosto de 2012 .
  46. ↑ "Hora precisa de Windows Server 2016" . technet.microsoft.com . Archivado del original el 2 de diciembre de 2016. Consultado el 7 de diciembre de 2016 .
  47. ↑ dahavey. "Compatibilidad con límites para una hora de alta precisión" . docs.microsoft.com . Archivado del original el 2 de mayo de 2021. Consultado el 24 de julio de 2021 .
  48. ↑ "ntpd(8) - Páginas del manual de OpenBSD" . man.openbsd.org . Implementa el Protocolo de tiempo de red simple versión 4, como se describe en RFC 5905, y el Protocolo de tiempo de red versión 3, como se describe en RFC 1305.
  49. ↑The OpenBSD Project (21 August 2006). "FAQ 6.12.1: 'But OpenNTPD isn't as accurate as the ntp.org daemon!'". The OpenBSD Project. Archived from the original on 5 February 2016. Retrieved 14 May 2020.
  50. ↑Raymond, Eric S. (30 March 2017). "NTPsec: a Secure, Hardened NTP Implementation | Linux Journal". Linux Journal. Retrieved 26 January 2024.{{cite web}}: CS1 maint: deprecated archival service (link)
  51. ↑"The Secure Network Time Protocol (NTPsec) Distribution". Archived from the original on 13 January 2019. Retrieved 12 January 2019.
  52. ↑Liska, Allan (10 December 2016). NTP Security: A Quick-Start Guide. Apress. pp. 80–. ISBN 978-1-4842-2412-0.
  53. ↑"Pentest-Report NTPsec 01.2017"(PDF). Cure53. 2017. Archived(PDF) from the original on 4 July 2019. Retrieved 3 July 2019.
  54. ↑Lichvar, Miroslav (20 July 2016). "Combining PTP with NTP to Get the Best of Both Worlds". Red Hat Enterprise Linux Blog. Red Hat. Archived from the original on 30 July 2016. Retrieved 19 November 2017. Starting with Red Hat Enterprise Linux 7.0 (and now in Red Hat Enterprise Linux 6.8) a more versatile NTP implementation is also provided via the chrony package
  55. ↑"Securing Network Time". Core Infrastructure Initiative, a Linux Foundation Collaborative Project. Core Infrastructure Initiative. 27 September 2017. Archived from the original on 28 October 2017. Retrieved 19 November 2017. In sum, the Chrony NTP software stands solid and can be seen as trustworthy
  56. 12"chrony introduction". TuxFamily, a non-profit organization. chrony. Archived from the original on 9 December 2009. Retrieved 19 November 2017. The software is supported on Linux, FreeBSD, NetBSD, macOS, and Solaris.
  57. ↑Both, David. "Manage NTP with Chrony". Opensource.com. Archived from the original on 29 June 2019. Retrieved 29 June 2019.
  58. ↑ Heiderich, Mario (agosto de 2017). "Pentest-Report Chrony 08.2017" (PDF) . Equipo de Cure53.de . wiki.mozilla.org, también conocido como MozillaWiki o WikiMO. Archivado del original (PDF) el 5 de octubre de 2017. Recuperado el 19 de noviembre de 2017. Haber superado once días completos de pruebas remotas en agosto de 2017 significa que Chrony es robusto, fuerte y desarrollado teniendo en cuenta la seguridad.
  59. ↑ "chrony/chrony.git - Repositorio Git oficial del proyecto Chrony" . git.tuxfamily.org . Consultado el 31 de julio de 2021 .
  60. ↑ Aas, Josh. "Mayor seguridad de memoria para Let's Encrypt: Implementación de ntpd-rs" . Let's Encrypt . Let's Encrypt . Consultado el 18 de diciembre de 2024 .
  61. ↑ "Seguridad de tiempo de red - documentación de ntpd-rs" . docs.ntpd-rs.pendulum-project.org . Consultado el 13 de enero de 2025 .
  62. ↑ Poul-Henning, Kamp. "20140926 – Jugando con el tiempo otra vez" . PHK's Bikeshed . Archivado del original el 20 de diciembre de 2019. Recuperado el 4 de junio de 2015 .
  63. ↑ Poul-Henning, Kamp. "Software de sincronización horaria de red, reemplazo de NTPD" . Archivo README del repositorio git de ntimed . Github. Archivado del original el 2 de agosto de 2015. Recuperado el 4 de junio de 2015 .
  64. ↑ "Cambiando de OpenNTPd a Chrony - anarcat" . anarc.at . Así que, en efecto, systemd-timesyncd se convirtió en el demonio NTP predeterminado en Debian en bookworm, lo cual me resulta algo sorprendente.
  65. ↑ "ntpdate(8): establecer fecha/hora mediante NTP - página man de Linux" . linux.die.net . Consultado el 12 de abril de 2020 .
  66. ↑ Harlan Stenn (2 de septiembre de 2012). "NTP.Org — Descontinuación de ntpdate" . Consultado el 30 de octubre de 2012. La combinación de ntpd y sntp ahora implementa las funciones de ntpdate. Tan pronto como se resuelvan algunos problemas pendientes con sntp , el programa ntpdate será retirado.
  67. ↑ David Mills. "La escala horaria del NTP y los segundos intercalares" . Archivado del original el 7 de septiembre de 2013. Consultado el 15 de octubre de 2013 .
  68. ↑ "Google Developers Leap Smear" . Archivado del original el 4 de abril de 2019. Consultado el 4 de abril de 2019 .
  69. ↑ Obleukhov, Oleg (18 de marzo de 2020). "Construyendo un servicio de tiempo más preciso a escala de Facebook" . Ingeniería en Meta .
  70. ↑ "chrony – Preguntas frecuentes" . chrony.tuxfamily.org .
  71. ↑ "Aviso de seguridad" . Support.NTP.org . 10 de diciembre de 2009. Consultado el 12 de enero de 2011 .
  72. ↑ "Vulnerabilidad de paquetes del protocolo de tiempo de red del software Cisco IOS" . Cisco Systems . 23 de septiembre de 2009. Archivado del original el 11 de junio de 2020. Consultado el 11 de junio de 2020 .
  73. ↑ "Auditoría de código" . Support.NTP.org . 13 de junio de 2009. Consultado el 12 de enero de 2011 .
  74. ↑ "Vulnerabilidades del protocolo de tiempo de red (actualización C) | ICS-CERT" . Ics-cert.us-cert.gov. Archivado del original el 20 de diciembre de 2014. Consultado el 15 de abril de 2015 .
  75. ↑ Cunningham, Andrew (23 de diciembre de 2014). "Apple actualiza automáticamente los Mac para corregir una grave vulnerabilidad de seguridad de NTP" . arstechnica. Archivado del original el 15 de abril de 2015. Recuperado el 29 de abril de 2015 .
  76. ↑ Fairhead, Harry (23 de diciembre de 2014). "NTP: El último problema de seguridad de código abierto" . I Programmer. Archivado del original el 24 de diciembre de 2014. Recuperado el 24 de diciembre de 2014 .
  77. ↑ Página de aviso de seguridad de NTP archivada el 19/02/2014 en Wayback Machine
  78. ↑ Búsqueda de productos NVD NIST NTP
  79. ↑ Búsqueda de productos NVD NIST NTPsec Archivado el 26/06/2020 en Wayback Machine
  80. ↑ NVD NIST Product Search Chrony Archivado el 26/06/2020 en Wayback Machine
  81. ↑ "Auditoría de CII identifica la implementación de NTP más segura" . The Linux Foundation. 28 de septiembre de 2017. Archivado del original el 3 de febrero de 2018. Consultado el 3 de julio de 2019 .
  82. 12Network Time Protocol Version 4: Autokey Specification. IETF. June 2010. doi:10.17487/RFC5906. RFC5906.
  83. 12"NTP Security Analysis". Archived from the original on 7 September 2013. Retrieved 11 October 2013.
  84. ↑Jose Selvi (16 October 2014). "Bypassing HTTP Strict Transport Security"(PDF). Archived from the original(PDF) on 18 October 2014. Retrieved 16 October 2014.
  85. ↑Aanchal Malhotra; Isaac E. Cohen; Erik Brakke & Sharon Goldberg (20 October 2015). "Attacking the Network Time Protocol"(PDF). NDSS. Archived from the original(PDF) on 22 October 2015. Retrieved 27 October 2015.
  86. ↑"Attacking the Network Time Protocol". www.cs.bu.edu. Archived from the original on 24 October 2015. Retrieved 27 October 2015.
  87. ↑Goodin, Dan (13 January 2014). "New DoS attacks taking down game sites deliver crippling 100Gbps floods". Ars Technica. Archived from the original on 24 January 2014. Retrieved 25 January 2014.
  88. ↑Lee, Dave (11 February 2014). "Huge Hack 'Ugly Sign of Future' for Internet Threats". BBC. Archived from the original on 11 February 2014. Retrieved 12 February 2014.
  89. ↑"DRDoS / Amplification Attack using ntpdc monlist command". support.NTP.org. 24 April 2010. Archived from the original on 30 March 2014. Retrieved 13 April 2014.
  90. ↑Dieter Sibold; Stephen Röttger (2012). Analysis of NTP's Autokey Protocol(PDF). IETF 83.
  91. ↑H. Stenn; D. Sibold (July 2019). D. Reilly (ed.). Network Time Protocol Best Current Practices. Internet Engineering Task Force. doi:10.17487/RFC8633. ISSN 2070-1721. BCP 223.RFC8633.Best Current Practice 223. sec. 4.2.
  92. ↑ "Página principal de nts.time.nl" . nts.time.nl. Consultado el 19 de agosto de 2021 .
  93. ↑ Langer, Martin (5 de diciembre de 2019). "Configuración de NTP con NTS-Secured y NTPsec" . Weberblog.net . Consultado el 19 de agosto de 2021 .
  94. ↑ "Cómo usar NTS | Netnod" . Netnod . Consultado el 19 de agosto de 2021 .
  95. ↑ "Seguridad del tiempo de red · Documentación de Cloudflare Time Services" . developers.cloudflare.com . 13 de agosto de 2024. Consultado el 12 de enero de 2025 .
  96. ↑ " [ MS-SNTP ] : Extensiones de autenticación del protocolo de tiempo de red (NTP)" . 24 de junio de 2021.
  97. ↑ "Comparación de implementaciones de NTP" . chrony.tuxfamily.org . Consultado el 8 de octubre de 2019 .
  98. ↑ David L. Mills (12 de mayo de 2012). "La era NTP y la numeración de las eras" . Archivado del original el 26 de octubre de 2016. Recuperado el 24 de septiembre de 2016 .
  99. ↑ W. Richard Stevens; Bill Fenner; Andrew M. Rudoff (2004). Programación de redes UNIX . Addison-Wesley Professional. págs. 582–. ISBN  978-0-13-141155-5Archivado del original el 30 de marzo de 2019. Consultado el 16 de octubre de 2016 .
  100. ↑ Martin, Jim; Burbank, Jack; Kasch, William; Mills, Profesor David L. (junio de 2010). Protocolo de tiempo de red versión 4: especificación de protocolo y algoritmos (informe). Grupo de trabajo de ingeniería de Internet. pág. 12. 
  101. ↑ "Una mirada a los problemas del año 2036/2038 y la resistencia al cambio temporal en varios sistemas" . 14 de marzo de 2017. Archivado del original el 21 de julio de 2018. Recuperado el 20 de julio de 2018 .
  102. ↑ Presentación del seminario sobre sistemas digitales de la Universidad de Delaware a cargo de David Mills, 26 de abril de 2006.
  103. ↑ Alexander, Steve (1 de marzo de 1997). "Opciones DHCP y extensiones de proveedores BOOTP" . IETF Datatracker . sección-8.3 . Recuperado el 25 de enero de 2026 .
  104. ↑ Lear, Eliot; Eggert, Paul (1 de abril de 2007). Opciones de zona horaria para DHCP (Informe). Grupo de trabajo de ingeniería de Internet . Recuperado el 26 de enero de 2026 .{{cite report}}: CS1 mantenimiento: estado de la URL ( enlace )

Lecturas adicionales

  • Definiciones de objetos gestionados para el protocolo de tiempo de red versión 4 (NTPv4) . IETF . doi : 10.17487/RFC5907 . RFC 5907 .
  • Opción de servidor del protocolo de tiempo de red (NTP) para DHCPv6 . IETF . doi : 10.17487/RFC5908 . RFC 5908 .
  • borrador-ietf-ntp-data-minimization ID de minimización de datos del cliente NTP
  • Sitio web oficialEdita esto en Wikidata
  • Lista oficial de servidores de Stratum One Time
  • Grupo de trabajo NTP de la IETF
  • Guía de hora precisa de Microsoft Windows y más
  • Documento sobre el tiempo y el NTP
  • Encuesta NTP 2005
  • El archivo actual de segundos intercalares del NIST es compatible con ntpd.
  • David L. Mills, Breve historia del tiempo NTP: Confesiones de un cronometrador de Internet (PDF) , consultado el 7 de febrero de 2021.