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 y 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 está diseñado para sincronizar las computadoras participantes con una precisión de unos pocos milisegundos respecto del Tiempo Universal Coordinado (UTC). [1] : 3 Utiliza el algoritmo de intersección , una versión modificada del algoritmo de Marzullo , para seleccionar servidores de tiempo precisos y está diseñado para mitigar los efectos de la latencia variable de la red . El NTP generalmente puede mantener el tiempo con una precisión de decenas de milisegundos en Internet pública y puede lograr una precisión mejor que un milisegundo en redes de área local en condiciones ideales. Las rutas asimétricas y la congestión de la red pueden causar errores de 100 ms o más. [2] [3]
El protocolo se describe generalmente en términos de un modelo cliente-servidor , pero se puede utilizar con la misma facilidad en relaciones peer-to-peer donde ambos peers 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) en el puerto número 123. [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 de ida y vuelta inicial. [3] NTP proporciona una advertencia de cualquier ajuste de segundo intercalar inminente , 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 la versión 3. [6]
En 1979, la tecnología de sincronización de tiempo de red se utilizó en lo que posiblemente fue la primera demostración pública de servicios de Internet que se ejecutaban sobre una red de satélites transatlántica, en la Conferencia Nacional de Computación en Nueva York. La tecnología se describió más tarde en la Nota de Ingeniería de Internet (IEN) 173 de 1981 [18] y se desarrolló un protocolo público a partir de ella que se documentó en 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.
En aquel momento y en la actualidad existían otras herramientas de red relacionadas, entre ellas 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 de disciplina de reloj de NTP, incluyen el demonio Unix timed , que utiliza un algoritmo de elección para designar un servidor para todos los clientes; [19] 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 de NTP (NTPv0) se implementó tanto en Fuzzball como en Unix, y los cálculos de encabezado de paquete NTP y de retardo y desplazamiento de ida y vuelta , que persistieron en NTPv4, se documentaron en RFC 958. A pesar de las computadoras y redes relativamente lentas disponibles en ese momento, generalmente se obtenía una precisión mejor que 100 milisegundos en enlaces que abarcaban el Atlántico, con una precisión de decenas de milisegundos en redes Ethernet .
En 1988, se publicó una especificación mucho más completa del protocolo NTPv1, con algoritmos asociados, en el RFC 1059. 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 llamaron 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 IEEE Transactions on Communications . [20]
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 han sobrevivido en NTPv4, junto con la mayor parte del algoritmo. Sin embargo, el diseño de NTPv2 fue criticado por su falta de corrección formal por parte de la comunidad DTSS, y el procedimiento de selección de reloj se modificó para incorporar el algoritmo de Marzullo para NTPv3 en adelante. [21]
En 1992, la RFC 1305 definió NTPv3. La 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 estar en desacuerdo. Se introdujo el modo de transmisió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 necesitaba una nueva versión del protocolo. [22] En 2010, se publicó el RFC 5905 que contenía una especificación propuesta para NTPv4. [23] 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 dirigido por Harlan Stenn. [24] [25] Del lado de la IANA, un grupo de trabajo de ntp ( protocolos de tiempo de red ) está a cargo de revisar los borradores propuestos. [26]
El protocolo ha progresado significativamente desde NTPv4. [23] A partir de 2022 [update], se han publicado tres documentos RFC que describen actualizaciones del protocolo, [5] sin contar los numerosos estándares periféricos como NTS ( RFC 8915). [26] Mills había mencionado planes para un "NTPv5" en su página, pero uno nunca se publicó. [23] Un borrador no relacionado denominado "NTPv5" por M. Lichvar de chrony se inició en 2020 e incluye cambios de seguridad, precisión y escala. [27]
A medida que NTP reemplazó el uso del antiguo Protocolo de Tiempo , algunos casos de uso encontraron que el protocolo completo era demasiado complicado. En 1992, se definió el Protocolo Simple de Tiempo de Red ( SNTP ) para llenar este nicho. El estándar SNTPv3 describe una forma de usar NTPv3, de modo que no se necesita almacenar el 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. [10] En 1996, SNTP se actualizó a SNTPv4 [12] con algunas características del entonces en desarrollo NTPv4. La versión actual de SNTPv4 se fusionó con el estándar principal NTPv4 en 2010. [5] SNTP es completamente interoperable con NTP ya que no define un nuevo protocolo. [28] : §14 Sin embargo, los algoritmos simples proporcionan tiempos de precisión reducida y, por lo tanto, no es aconsejable sincronizar el tiempo desde una fuente SNTP. [13]
NTP utiliza un sistema jerárquico de fuentes de tiempo en capas. 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 se ejecuta en el estrato n + 1. El número representa la distancia desde el reloj de referencia y se utiliza para evitar dependencias cíclicas en la jerarquía. El estrato no siempre es una indicación de calidad o confiabilidad; es común encontrar fuentes de tiempo de estrato 3 que son de mayor calidad que otras fuentes de tiempo de estrato 2. [a] A continuación se proporciona una breve descripción de los estratos 0, 1, 2 y 3.
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 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 puede identificar la fuente de sincronización para cada servidor en términos de un identificador de referencia (refid).
Para los servidores de estrato 2 y inferiores, el refid es una forma codificada de la dirección IP del servidor de tiempo ascendente. Para IPv4, es simplemente 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 tiempo de primer grado. [5]
El campo refid se llena con palabras de estado en el caso de paquetes de beso de muerte (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 que solicita demasiado rápido). [33] La salida del programa puede usar adicionalmente códigos no transmitidos en el paquete para indicar un error, como XFAC para indicar una desconexión de la red. [32]
La IANA mantiene un registro de nombres de origen refid y códigos KoD. Aún pueden aparecer asignaciones informales. [34]
Las marcas de tiempo de punto fijo binario de 64 bits que utiliza NTP consisten en una parte de 32 bits para segundos y una parte de 32 bits para fracciones de segundo, lo que da una escala de tiempo que se renueva cada 2 32 segundos (136 años) y una resolución teórica de 2 −32 segundos (233 picosegundos). NTP utiliza una época del 1 de enero de 1900. Por lo tanto, la primera renovación ocurre el 7 de febrero de 2036. [35] [36]
NTPv4 introduce un formato de fecha de 128 bits: 64 bits para el segundo y 64 bits para la fracción de segundo. Los 32 bits más significativos de este formato son el Número de Era , que resuelve la ambigüedad de la rotación en la mayoría de los casos. [37] 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 temporal inequívoca hasta que el universo se oscurezca". [38] [b]
Un cliente NTP típico consulta periódicamente a uno o más servidores NTP. El cliente debe calcular su diferencia horaria y el retraso de ida y vuelta . La diferencia horaria θ es la diferencia positiva o negativa (hora del cliente > hora del servidor) en tiempo absoluto entre los dos relojes. Se define por
y el retraso de ida y vuelta δ por donde
Para derivar la expresión para el desplazamiento, tenga en cuenta que para el paquete de solicitud y para el paquete de respuesta, al resolver θ se obtiene la definición del desplazamiento temporal.
Los valores de θ y δ pasan por filtros y se someten a un análisis estadístico ("mitigación"). Los valores atípicos se descartan 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 el desfase gradualmente ("disciplina"), creando un bucle de retroalimentación . [1] : 20
Se logra una sincronización precisa 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 de la mitad de la diferencia entre los tiempos de viaje de ida y vuelta. Se han propuesto varios enfoques para medir la asimetría, [39] pero entre las implementaciones prácticas, solo chrony parece tener uno incluido. [40] [41]
La implementación de referencia de 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 agregado nuevas características. Contiene varios algoritmos sensibles, especialmente para disciplinar el reloj, que puede comportarse mal cuando se sincroniza con servidores que usan 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 compensaciones se filtran y analizan de la misma manera que los servidores remotos, aunque generalmente se sondean con mayor frecuencia. [1] : 15–19 Esta implementación fue auditada en 2017, encontrando 14 posibles problemas de seguridad. [42]
Todas las versiones de Microsoft Windows desde Windows 2000 incluyen el servicio de hora de Windows (W32Time), [43] que tiene la capacidad de sincronizar el reloj de la computadora con un servidor NTP.
W32Time se implementó originalmente con el propósito del 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 sincronización disciplinada NTP, solo sincronización disciplinada localmente con corrección NTP/SNTP. [44]
A partir de Windows Server 2003 y Windows Vista , el proveedor NTP para W32Time se volvió compatible con un subconjunto significativo de NTPv3. [45] Microsoft afirma que W32Time no puede mantener de manera confiable la sincronización horaria con una precisión de un segundo. [46] Si se desea una mayor precisión, Microsoft recomienda usar una versión más nueva de Windows o una implementación NTP diferente. [47]
A partir de la versión 1607 de Windows 10 y Windows Server 2016 , W32Time se puede configurar para alcanzar una precisión temporal de 1 s, 50 ms o 1 ms en determinadas condiciones operativas especificadas. [48] [46] [49]
En 2004, Henning Brauer de OpenBSD presentó OpenNTPD , una implementación de NTPv3/SNTPv4 [50] centrada en la seguridad y que abarca un diseño con privilegios separados. Si bien está orientada más a las necesidades genéricas más simples de los usuarios de OpenBSD, también incluye algunas mejoras de seguridad de protocolo y sigue siendo compatible con los servidores NTP existentes. La base de código más simple sacrifica la precisión, que se considera innecesaria en este caso de uso. [51] Hay una versión portátil disponible en los repositorios de paquetes de Linux.
NTPsec es una bifurcación de la implementación de referencia que ha sido sistemáticamente reforzada en seguridad . El punto de bifurcación fue en junio de 2015 y fue en respuesta a una serie de compromisos en 2014. [52] La primera versión de producción se envió en octubre de 2017. [53] Entre 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% de la base de código original, lo que hace que el resto sea más fácil de auditar . [54] Una auditoría de 2017 del código 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. [55]
chrony es una implementación independiente de NTP patrocinada principalmente por Red Hat , que la utiliza como el programa de tiempo predeterminado en sus distribuciones. [56] Al estar escrito desde cero, chrony tiene una base de código más simple que permite una mejor seguridad [57] y un menor consumo de recursos. [58] Sin embargo, no compromete la precisión, sino que se sincroniza más rápido y mejor que el ntpd de referencia en muchas circunstancias. Es lo suficientemente versátil para computadoras 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. [59]
Chrony ha sido evaluado como "confiable", con solo unos pocos incidentes. [60] Es capaz de lograr una precisión mejorada en las conexiones LAN, utilizando la marca de tiempo de hardware en el adaptador de red. [40] Se agregó soporte para Network Time Security (NTS) en la versión 4.0. [61] 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. [58]
El día en que se produce un segundo intercalar , ntpd recibe una notificación de un archivo de configuración , un reloj de referencia adjunto 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 el tiempo del sistema hace que aumente en una cantidad mínima, lo que preserva 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. [65]
Una implementación alternativa, llamada leap smearing, consiste en introducir el segundo intercalar de forma incremental durante un período de 24 horas, de mediodía a mediodía en horario UTC. Esta implementación la utilizan Google (tanto internamente como en sus servidores NTP públicos), Amazon AWS, [66] y Facebook. [67] Chrony admite leap smear en configuraciones smoothtime y leapsecmode , pero dicho uso no debe combinarse con un pool NTP público, ya que leap smear no es estándar y alterará el cálculo del cliente en caso de mezcla. [68]
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 algunos privilegios para poder soportar su funcionalidad principal. Solo se han identificado unos pocos problemas de seguridad más en la implementación de referencia de la base de código NTP, pero los que aparecieron en 2009 [ ¿cuáles? ] fueron motivo de gran preocupación. [69] [70] El protocolo ha estado siendo revisado y revisado a lo largo de su historia. La base de código para la implementación de referencia ha sido objeto de auditorías de seguridad de varias fuentes durante varios años. [71]
En 2014 se descubrió y se parchó un exploit de desbordamiento de búfer de pila. [72] Apple estaba tan preocupada por esta vulnerabilidad que utilizó su capacidad de actualización automática por primera vez. [73] En los sistemas que utilizan la implementación de referencia, que se ejecuta con la credencial 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, no están sujetas a esta falla. [74]
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 [75] [76] como NTPsec [77] eran más problemáticos que Chrony [78] desde un punto de vista de seguridad. [79]
Los servidores NTP pueden ser susceptibles a ataques de intermediarios a menos que los paquetes estén firmados criptográficamente para su autenticación. [80] La sobrecarga computacional involucrada puede hacer que esto sea poco práctico en servidores ocupados, particularmente durante ataques de denegación de servicio . [81] La suplantación de mensajes NTP de un ataque de intermediario se puede utilizar para alterar los relojes en las computadoras cliente y permitir una serie de ataques basados en la evasión de la expiración de la clave criptográfica. [82] Algunos de los servicios afectados por mensajes NTP falsos identificados son TLS , DNSSEC , varios esquemas de almacenamiento en caché (como el caché DNS), Border Gateway Protocol (BGP), Bitcoin [ cita requerida ] y una serie de esquemas de inicio de sesión persistente. [83] [84]
El protocolo NTP se ha utilizado en ataques distribuidos de denegación de servicio . [85] [86] Se envía una pequeña consulta a un servidor NTP con la dirección IP de retorno falsificada para que sea la dirección de destino. De manera similar al ataque de amplificación de DNS , el servidor responde con una respuesta mucho más grande que permite a un atacante aumentar sustancialmente la cantidad de datos que se envían al destino. Para evitar participar en un ataque, se puede actualizar el software del servidor NTP o se pueden configurar los servidores para que ignoren las consultas externas. [87]
El propio NTP incluye soporte para autenticar servidores a clientes. NTPv3 admite un modo de clave simétrica , que no es útil contra MITM. El sistema de clave pública conocido como "autokey" en NTPv4 adaptado de IPSec ofrece una autenticación útil, [80] pero no es práctico para un servidor ocupado. [81] Más tarde se descubrió que Autokey también sufría varios fallos de diseño, [88] sin que se publicara ninguna corrección, salvo un cambio en el código de autenticación de mensajes . [16] Autokey ya no debería utilizarse. [89]
Network Time Security (NTS) es una versión segura de NTPv4 con TLS y AEAD . [90] La principal mejora con respecto a los intentos anteriores es que un servidor de "establecimiento de claves" independiente se encarga de la criptografía asimétrica pesada, que solo debe realizarse una vez. Si el servidor deja de funcionar, los usuarios anteriores aún podrían obtener la hora sin temor a un MITM. [91] NTS actualmente es compatible con varios servidores de hora, [92] [93] incluido Cloudflare . Es compatible con NTPSec y chrony. [94]
Microsoft también tiene un enfoque para autenticar paquetes NTPv3/SNTPv4 utilizando una identidad de dominio de Windows , conocida como MS-SNTP. [95] Este sistema está implementado en la referencia ntpd y chrony, utilizando samba para la conexión de dominio. [96]
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 y posteriormente incorporado al Servicio de Tiempo Digital. Estos cambios no afectan significativamente el funcionamiento normal ni la compatibilidad con varias versiones de NTP, pero sí proporcionan la base para declaraciones formales de corrección.
Los servidores y clientes primarios que cumplen con un subconjunto de NTP, llamado Protocolo simple de tiempo de red (SNTPv4) [...], no necesitan implementar los algoritmos de mitigación [...] La implementación de NTPv4 completamente desarrollada 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 [...]
Los programas del paquete linuxptp se pueden utilizar en combinación con un demonio NTP. Un reloj PTP en una NIC se sincroniza mediante ptp4l y se utiliza como reloj de referencia mediante chronyd o ntpd para sincronizar el reloj del sistema.
Los códigos Refid se utilizan en paquetes de tipo Kiss-o'-Death (KoD), el campo de identificador de referencia en las pantallas de visualización de ntpq y ntpmon y en los mensajes de registro.
Esta directiva permite el marcado de tiempo de hardware de los paquetes NTP enviados y recibidos desde la interfaz de red especificada.
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.
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
En resumen, el software NTP de Chrony es sólido y puede considerarse confiable.
El software es compatible con Linux, FreeBSD, NetBSD, macOS y Solaris.
El hecho de haber soportado once días completos de pruebas remotas en agosto de 2017 significa que Chrony es robusto, fuerte y desarrollado teniendo en cuenta la seguridad.
De hecho, systemd-timesyncd se convirtió en el demonio NTP predeterminado en Debian en bookworm, lo que me parece un tanto sorprendente.
