Articulo de referencia

Protocolo de tiempo de red

El Protocolo de Tiempo de Red ( NTP ) es un protocolo de red para la sincronización de relojes entre sistemas informáticos a través de redes de datos de latencia variable con co...

El Protocolo de Tiempo de Red ( NTP ) es un protocolo de red para la sincronización de relojes entre sistemas informáticos a través de redes de datos de latencia variable con conmutación de paquetes . En funcionamiento desde antes de 1985, NTP es uno de los protocolos de Internet más antiguos que se utilizan actualmente. NTP fue diseñado por David L. Mills de la Universidad de Delaware .

El NTP tiene como objetivo sincronizar los ordenadores participantes con una precisión de unos pocos milisegundos respecto al Tiempo Universal Coordinado (UTC). [ 1 ] : 3 Utiliza el algoritmo de intersección , una versión modificada del algoritmo de Marzullo , para seleccionar servidores de hora precisos y está diseñado para mitigar los efectos de la latencia variable de la red . El NTP suele mantener la hora con una precisión de decenas de milisegundos en Internet pública y puede alcanzar una precisión superior a un milisegundo en redes de área local en condiciones ideales. Las rutas asimétricas y la congestión de la red pueden provocar errores de 100  ms o más. [ 2 ] [ 3 ]

El protocolo se suele describir en términos de un modelo cliente-servidor , pero también puede utilizarse fácilmente en relaciones punto a punto donde ambos pares consideran al otro como una fuente de tiempo potencial. [ 1 ] : 20 Las implementaciones envían y reciben marcas de tiempo utilizando el Protocolo de Datagramas de Usuario (UDP); el servicio normalmente está en el puerto número 123, y en algunos modos ambos lados utilizan este número de puerto. [ 4 ] [ 5 ] : 16 También pueden utilizar difusión o multidifusión , donde los clientes escuchan pasivamente las actualizaciones de tiempo después de un intercambio de calibración inicial de ida y vuelta. [ 3 ] NTP proporciona una advertencia de cualquier ajuste inminente del segundo intercalar , pero no se transmite información sobre las zonas horarias locales o el horario de verano . [ 2 ] [ 3 ]

El protocolo actual es la versión 4 (NTPv4), [ 5 ] que es compatible con versiones anteriores, como la versión 3. [ 6 ]

Algoritmo de sincronización de reloj

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

θ=(t1t0)+(t2t3)2,{\displaystyle \theta ={\frac {(t_{1}-t_{0})+(t_{2}-t_{3})}{2}},} y el retraso de ida y vuelta δ por δ=(t3t0)(t2t1),{\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 pulso (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
Se trata de ordenadores sincronizados con servidores de estrato 2. Emplean los mismos algoritmos de interconexión y muestreo de datos que los servidores de estrato 2, y pueden actuar como servidores para ordenadores de estrato 4, y así sucesivamente.

El límite superior para el estrato es 15; el estrato 16 se utiliza para indicar que un dispositivo no está sincronizado. Los algoritmos NTP en cada computadora interactúan para construir un árbol de expansión de ruta más corta de Bellman-Ford , para minimizar el retraso acumulado de ida y vuelta a los servidores del estrato 1 para todos los clientes. [ 1 ] : 20

Además del estrato, el protocolo es capaz de identificar la fuente de sincronización para cada servidor en términos de un identificador de referencia (refid).

Para los servidores de estrato 2 e inferiores, el refid es una forma codificada de la dirección IP del servidor de tiempo ascendente. Para IPv4, se trata simplemente de la dirección de 32 bits; para IPv6, serían los primeros 32 bits del hash MD5 de la dirección de origen. Los refids sirven para detectar y prevenir bucles de temporización en primer grado. [ 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 ]

A partir de Windows Server 2003 y Windows Vista , el proveedor NTP para W32Time se volvió compatible con un subconjunto significativo de NTPv3. [ 43 ] Microsoft afirma que W32Time no puede mantener una sincronización horaria fiable con una precisión de un segundo. [ 44 ] Si se desea una mayor precisión, Microsoft recomienda usar una versión más reciente de Windows o una implementación NTP diferente. [ 45 ]

A partir de Windows 10 versión 1607 y Windows Server 2016 , W32Time se puede configurar para alcanzar una precisión horaria de 1 s, 50 ms o 1  ms bajo ciertas condiciones operativas específicas. [ 46 ] [ 44 ] [ 47 ]

OpenNTPD

En 2004, Henning Brauer de OpenBSD presentó OpenNTPD , una implementación de NTPv3/SNTPv4 [ 48 ] centrada en la seguridad y con un diseño de privilegios separados. Si bien está más orientada a las necesidades genéricas de los usuarios de OpenBSD, también incluye mejoras en la seguridad del protocolo, manteniendo la compatibilidad con los servidores NTP existentes. La simplicidad del código base sacrifica la precisión, considerada innecesaria en este caso. [ 49 ] Existe una versión portable disponible en los repositorios de paquetes de Linux.

NTPsec

NTPsec es una bifurcación de la implementación de referencia que ha sido sistemáticamente reforzada en materia de seguridad . El punto de bifurcación se produjo en junio de 2015 y fue en respuesta a una serie de vulnerabilidades en 2014. [ 50 ] La primera versión de producción se lanzó en octubre de 2017. [ 51 ] Mediante la eliminación de características inseguras, la eliminación del soporte para hardware obsoleto y la eliminación del soporte para variantes obsoletas de Unix, NTPsec ha podido reducir el 75 % del código base original, lo que facilita la auditoría del resto . [ 52 ] Una auditoría del código realizada en 2017 mostró ocho problemas de seguridad, incluidos dos que no estaban presentes en la implementación de referencia original, pero NTPsec no sufrió otros ocho problemas que permanecieron en la implementación de referencia. [ 53 ]

crony

chronyc , que muestra información sobre las fuentes y la actividad de Network Time Security (NTS).

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 en cuanto a 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 ánimo 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)

Esta opción incluye una definición de zona horaria utilizando el TZformato de variable de entorno POSIX (como se especifica en IEEE 1003.1), excepto que la cadena no debe comenzar con dos puntos ( :).

Ejemplo:

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

Esto describe:

  • Hora estándar: EST (UTC−5)
  • Horario de verano : EDT (UTC−4)
  • El horario de verano comienza el segundo domingo de marzo a las 02:00.
  • El horario de verano finaliza el primer domingo de noviembre a las 02:00.
Nombre de la base de datos de zona horaria (opción 101)

Para que esta opción sea útil, el cliente debe tener una copia local de la base de datos de zonas horarias. Si el cliente reconoce el nombre proporcionado, debería preferir esta opción a la cadena POSIX. Si el nombre es desconocido, la opción debe ignorarse.

Esta opción contiene el nombre de una zona de la base de datos de zonas horarias de IANA , como por ejemplo:

Europe/Oslo

Opciones de zona horaria DHCPv6

RFC 4833 define opciones equivalentes para DHCPv6 con diferentes códigos de opción:

La semántica y los formatos de cadena son idénticos a los utilizados en DHCPv4; solo difiere la codificación binaria debido a las diferencias de protocolo entre DHCPv4 y DHCPv6.

Relación con el NTP

El protocolo NTP solo distribuye la hora absoluta ( UTC ) y no incluye información sobre zonas horarias locales ni reglas de horario de verano. Las opciones de zona horaria DHCP complementan a NTP al permitir que los clientes configuren automáticamente su representación horaria local una vez que sus relojes se hayan sincronizado.

En despliegues típicos:

  • DHCP proporciona información sobre la configuración de IP y la zona horaria.
  • El protocolo NTP sincroniza el reloj del sistema con la hora UTC.
  • El sistema operativo aplica la zona horaria configurada para mostrar la hora local a los usuarios y las aplicaciones.

Esta separación simplifica el NTP y evita incorporar normas políticas y legales específicas de cada región en el protocolo de sincronización horaria.

Véase también

Notas

  1. Los sistemas de telecomunicaciones utilizan una definición diferente para los estratos de reloj .
  2. 2 −64 segundos son aproximadamente 54 zeptosegundos (la luz viajaría 16,26 picómetros, o aproximadamente 0,31 × radio de Bohr ), y 2 64 segundos son aproximadamente 585 mil millones de años .

Referencias

  1. 1 2 3 4 5 6 David L. Mills (12 de diciembre de 2010). Sincronización horaria de redes informáticas: El protocolo de tiempo de red . Taylor & Francis. págs. 12–. ISBN  978-0-8493-5805-0Archivado del original el 18 de julio de 2014. Consultado el 16 de octubre de 2016 .
  2. 1 2 3 "Resumen ejecutivo: Sincronización horaria de redes informáticas" . Archivado del original el 2 de noviembre de 2011. Recuperado el 21 de noviembre de 2011 .
  3. 1 2 3 4 "Preguntas frecuentes sobre NTP" . El Proyecto NTP. Archivado del original el 6 de septiembre de 2011. Recuperado el 27 de agosto de 2011 .
  4. "Números de puerto" . Autoridad de Números Asignados de Internet (IANA). Archivado del original el 4 de junio de 2001. Consultado el 19 de enero de 2011 .
  5. 1 2 3 4 5 6 7 8 9 10 11 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 . Norma propuesta. Sustituye a RFC 1305 y 4330. Actualizada por RFC 7822 , 8573 y 9109 .  
  6. 1 2 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. Obsoleto según RFC 5905. Obsoleto según RFC 958 , 1059 y 1119 .  
  7. Gotoh, T.; Imamura, K.; Kaneko, A. (2002). "Mejora del desfase horario de NTP en redes asimétricas con el método de paquetes dobles". Resumen de la Conferencia sobre Mediciones Electromagnéticas de Precisión . Conferencia sobre Mediciones Electromagnéticas de Precisión. pp. 448–449 . doi : 10.1109/CPEM.2002.1034915 . ISBN  0-7803-7242-5.
  8. 1 2 Lichvar, Miroslav (18 de septiembre de 2018). "chrony – chrony.conf(5)" . Proyecto Chrony . Recuperado el 2 de agosto de 2020. Esta directiva habilita el sellado de tiempo por hardware de los paquetes NTP enviados a y recibidos desde la interfaz de red especificada.
  9. "sourcestats.c, función estimate_asymmetry()" . git.tuxfamily.org (chrony) .
  10. D. Mills (septiembre de 1985). Protocolo de tiempo de red (NTP) . Grupo de trabajo de redes. doi : 10.17487/RFC0958 . RFC 958 .Obsoleto. Obsoleto según los RFC 1059 , 1119 y 1305 . 
  11. D. Mills (julio de 1988). Especificación e implementación del protocolo de tiempo de red (versión 1) . Grupo de trabajo de redes. doi : 10.17487/RFC1059 . RFC 1059 .Obsoleto. Obsoleto según los RFC 1119 y 1305 . 
  12. D. Mills (septiembre de 1989). Especificación e implementación del protocolo de tiempo de red (versión 2) . Grupo de trabajo de redes. doi : 10.17487/RFC1119 . RFC 1119 .Obsoleto. Obsoleto según RFC 1305. Obsoleto según RFC 958 y 1059 .  
  13. 1 2 D. Mills (agosto de 1992). Tipo de servicio en el conjunto de protocolos de Internet . Grupo de trabajo de redes. doi : 10.17487/RFC1361 . RFC 1361 .Obsoleto. Obsoleto según RFC 1769 . 
  14. D. Mills (marzo de 1995). Protocolo de tiempo de red simple (SNTP) . Grupo de trabajo de redes. doi : 10.17487/RFC1769 . RFC 1769 .Obsoleto. Obsoleto según RFC 2030. Obsoleto según RFC 1361 .  
  15. 1 2 D. Mills (octubre de 1996). Protocolo de tiempo de red simple (SNTP) versión 4 para IPv4, IPv6 y OSI . Grupo de trabajo de redes. doi : 10.17487/RFC2030 . RFC 2030 .Obsoleto. Obsoleto según RFC 4330. Obsoleto según RFC 1769 .  
  16. D. Mills (enero de 2006). Protocolo de tiempo de red simple (SNTP) versión 4 para IPv4, IPv6 y OSI . Grupo de trabajo de redes. doi : 10.17487/RFC4330 . RFC 4330 .Obsoleto. Deja obsoletos los RFC 2030 y 1769. Obsoleto según el RFC 5905 .  
  17. DL Mills (abril de 1981). Servicio de reloj de Internet DCNET . IETF . doi : 10.17487/RFC0778 . RFC 778 .Histórico.
  18. 1 2 T. Mizrahi; D. Mayer (marzo de 2016). Campos de extensión del protocolo de tiempo de red versión 4 (NTPv4) . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7822 . ISSN 2070-1721 . RFC 7822 . Informativo. Actualizaciones RFC 5905 . 
  19. 1 2 3 A. Malhotra; S. Goldberg (junio de 2019). Código de autenticación de mensajes para el protocolo de tiempo de red . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC8573 . ISSN 2070-1721 . RFC 8573 . Norma propuesta. Actualiza la RFC 5905 . 
  20. 1 2 F. Gont; G. Gont; M. Lichvar (agosto de 2021). Protocolo de tiempo de red versión 4: aleatorización de puertos . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC9109 . ISSN 2070-1721 . RFC 9109 . Norma propuesta. Actualiza la RFC 5905 . 
  21. DL Mills (25 de febrero de 1981), Sincronización horaria en hosts de DCNET , archivado del original el 30 de diciembre de 1996.
  22. "TIMED(8)" , Manual del administrador del sistema UNIX , archivado del original el 22 de julio de 2011 , recuperado el 12 de septiembre de 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. El proyecto OpenBSD (21 de agosto de 2006). "Pregunta frecuente 6.12.1: '¡Pero OpenNTPD no es tan preciso como el demonio ntp.org!'"" . El proyecto OpenBSD . Archivado del original el 5 de febrero de 2016 . Recuperado el 14 de mayo de 2020 .
  50. Raymond, Eric S. (30 de marzo de 2017). "NTPsec: una implementación segura y reforzada de NTP | Linux Journal" . Linux Journal . Consultado el 26 de enero de 2024 .{{cite web}}: CS1 maint: servicio de archivado obsoleto ( enlace )
  51. "Distribución del Protocolo de Tiempo de Red Segura (NTPsec)" . Archivado del original el 13 de enero de 2019. Consultado el 12 de enero de 2019 .
  52. ^ Liska, Allan (10 de diciembre de 2016). Seguridad NTP: una guía de inicio rápido . Presione. págs.80– . ISBN  978-1-4842-2412-0.
  53. "Pentest-Report NTPsec 01.2017" (PDF) . Cure53. 2017. Archivado (PDF) del original el 4 de julio de 2019. Recuperado el 3 de julio de 2019 .
  54. Lichvar, Miroslav (20 de julio de 2016). "Combinando PTP con NTP para obtener lo mejor de ambos mundos" . Blog de Red Hat Enterprise Linux . Red Hat . Archivado del original el 30 de julio de 2016. Recuperado el 19 de noviembre de 2017. A partir de Red Hat Enterprise Linux 7.0 (y ahora en Red Hat Enterprise Linux 6.8) también se proporciona una implementación de NTP más versátil a través del paquete chrony.
  55. "Protegiendo la hora de la red" . Iniciativa de infraestructura central, un proyecto colaborativo de la Fundación Linux . Iniciativa de infraestructura central. 27 de septiembre de 2017. Archivado del original el 28 de octubre de 2017. Recuperado el 19 de noviembre de 2017. En resumen, el software Chrony NTP es sólido y puede considerarse confiable .
  56. 1 2 "Introducción a chrony" . TuxFamily, una organización sin fines de lucro . chrony. Archivado del original el 9 de diciembre de 2009. Recuperado el 19 de noviembre de 2017. El software es compatible con Linux, FreeBSD, NetBSD, macOS y Solaris.
  57. Ambos, David. "Gestionar NTP con Chrony" . Opensource.com . Archivado del original el 29 de junio de 2019. Consultado el 29 de junio de 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. 1 2 Protocolo de tiempo de red versión 4: Especificación de clave automática . IETF. Junio ​​de 2010. doi : 10.17487/RFC5906 . RFC 5906 .
  83. 1 2 "Análisis de seguridad NTP" . Archivado del original el 7 de septiembre de 2013. Recuperado el 11 de octubre de 2013 .
  84. Jose Selvi (16 de octubre de 2014). "Evitando la seguridad de transporte estricta HTTP" (PDF) . Archivado del original (PDF) el 18 de octubre de 2014. Recuperado el 16 de octubre de 2014 .
  85. Aanchal Malhotra; Isaac E. Cohen; Erik Brakke y Sharon Goldberg (20 de octubre de 2015). "Atacando el Protocolo de Tiempo de Red" (PDF) . NDSS . Archivado del original (PDF) el 22 de octubre de 2015. Recuperado el 27 de octubre de 2015 .
  86. "Atacando el protocolo de tiempo de red" . www.cs.bu.edu . Archivado del original el 24 de octubre de 2015. Consultado el 27 de octubre de 2015 .
  87. Goodin, Dan (13 de enero de 2014). "Nuevos ataques DoS que derriban sitios de juegos provocan inundaciones paralizantes de 100 Gbps" . Ars Technica . Archivado del original el 24 de enero de 2014. Recuperado el 25 de enero de 2014 .
  88. Lee, Dave (11 de febrero de 2014). "Un ciberataque masivo es una señal preocupante del futuro de las amenazas en Internet" . BBC. Archivado del original el 11 de febrero de 2014. Recuperado el 12 de febrero de 2014 .
  89. "DRDoS / Ataque de amplificación usando el comando ntpdc monlist" . support.NTP.org . 24 de abril de 2010. Archivado del original el 30 de marzo de 2014. Consultado el 13 de abril de 2014 .
  90. Dieter Sibold; Stephen Röttger (2012). Análisis del protocolo Autokey de NTP (PDF) . IETF 83.
  91. H. Stenn; D. Sibold (julio de 2019). D. Reilly (ed.). Network Time Protocol Best Current Practices . Internet Engineering Task Force . doi : 10.17487/RFC8633 . ISSN 2070-1721 . BCP 223. RFC 8633 . Mejores prácticas actuales 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.