Protocolo de tiempo de red

El Network Time Protocol (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 conmutadas por paquetes. En funcionamiento desde antes de 1985, NTP es uno de los protocolos de Internet más antiguos actualmente en uso. NTP fue diseñado por David L. Mills de la Universidad de Delaware.

NTP está diseñado para sincronizar todas las computadoras participantes dentro de unos pocos milisegundos del tiempo universal coordinado (UTC). 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. NTP generalmente puede mantener el tiempo dentro de las decenas de milisegundos en la Internet pública y puede lograr 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 causar errores de 100 ms o más.

El protocolo generalmente se describe en términos de un modelo cliente-servidor, pero también puede usarse fácilmente en relaciones de igual a igual en las que ambos pares consideran que el otro es una posible fuente de tiempo. Las implementaciones envían y reciben marcas de tiempo usando el Protocolo de datagramas de usuario (UDP) en el puerto número 123. También pueden usar transmisió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. NTP proporciona una advertencia de cualquier ajuste de segundo bisiesto inminente, pero no se transmite información sobre las zonas horarias locales o el horario de verano.

El protocolo actual es la versión 4 (NTPv4), que es compatible con la versión 3.

Historia

NTP fue diseñado por David L. Mills.

En 1979, la tecnología de sincronización horaria de la red se utilizó en lo que posiblemente fue la primera demostración pública de los servicios de Internet que se ejecutan en una red satelital 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 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 redes, donde funcionó durante muchos años.

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

En 1985, se implementó la versión 0 de NTP (NTPv0) tanto en Fuzzball como en Unix, y los cálculos de compensación y retraso de ida y vuelta del encabezado del paquete NTP, que han persistido en NTPv4, se documentaron en RFC 958. A pesar de la lentitud computadoras y redes disponibles en ese momento, generalmente se obtenía una precisión de más de 100 milisegundos en los enlaces de expansión del Atlántico, con una precisión de decenas de milisegundos en las redes Ethernet.

En 1988, se publicó en RFC 1059 una especificación mucho más completa del protocolo NTPv1, con algoritmos asociados. Se basó en los resultados experimentales y el algoritmo de filtro de reloj documentado en RFC 956 y fue la primera versión en describir el cliente: modo servidor y peer-to-peer. En 1991, la arquitectura, el protocolo y los algoritmos de NTPv1 atrajeron la atención de una comunidad de ingenieros más amplia con la publicación de un artículo de David L. Mills en IEEE Transactions on Communications.

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, la comunidad DTSS criticó el diseño de NTPv2 por carecer de corrección formal, y el procedimiento de selección de reloj se modificó para incorporar el algoritmo de Marzullo para NTPv3 en adelante.

En 1992, RFC 1305 definió NTPv3. El RFC incluyó un análisis de todas las fuentes de error, desde el reloj de referencia hasta el cliente final, lo que permitió el cálculo de una métrica que ayuda a elegir el mejor servidor donde varios candidatos parecen estar en desacuerdo. Se introdujo el modo de transmisión.

En los años siguientes, a medida que se agregaron nuevas funciones y se realizaron mejoras en los algoritmos, se hizo evidente que se requería una nueva versión del protocolo. En 2010, se publicó RFC 5905 que contenía una especificación propuesta para NTPv4. Tras el retiro 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. Por parte de la IANA, un grupo de trabajo ntp (network time protocol) está a cargo de revisar los borradores propuestos.

El protocolo ha progresado significativamente desde NTPv4. A partir de 2022, se han publicado tres documentos RFC que describen las actualizaciones del protocolo, sin contar los numerosos estándares periféricos como NTS (RFC 8915). Mills había mencionado planes para un "NTPv5" en su página, pero uno nunca fue publicado. Un borrador no relacionado denominado "NTPv5" por M. Lichvar de chrony se inició en 2020 e incluye cambios de seguridad, precisión y escala.

SNTP

Como NTP reemplaza el uso del antiguo Protocolo de tiempo, algunos casos de uso, sin embargo, consideran que el protocolo completo es demasiado complicado. En 1992, se definió el Simple Network Time Protocol (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 largos períodos de tiempo. La topología se vuelve esencialmente la misma que con el Protocolo de tiempo, ya que solo se usa un servidor. En 1995, SNTP se actualizó a SNTPv4 con algunas características del NTPv4 que estaba en desarrollo; la última versión actual es RFC 5905, una revisión de 2010 de SNTPv4, fusionándola con el estándar NTPv4 principal. SNTP es completamente interoperable con NTP ya que no define un nuevo protocolo. Sin embargo, los algoritmos simples brindan tiempos de precisión reducida y, por lo tanto, no es recomendable sincronizar el tiempo desde una fuente SNTP.

Estratos de reloj

El Observatorio Naval de Estados Unidos Reloj Maestro Suplente en Schriever AFB (Colorado) es una fuente estrato 0 para NTP

Las flechas amarillas indican una conexión directa; las flechas rojas indican una conexión de red.

NTP utiliza un sistema jerárquico de semicapas 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 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. Stratum no siempre es una indicación de calidad o confiabilidad; es común encontrar fuentes de tiempo del estrato 3 que son de mayor calidad que otras fuentes de tiempo del estrato 2. A continuación se proporciona una breve descripción de los estratos 0, 1, 2 y 3.

Estrato 0

Estos son dispositivos de control de tiempo de alta precisión, como relojes atómicos, GNSS (incluyendo GPS) u otros relojes de radio, o un reloj sincronizado con PTP. Generan un pulso muy preciso por segunda señal que activa una interrupción y temporizador en un ordenador conectado. Los dispositivos Stratum 0 también se conocen como relojes de referencia. Los servidores NTP no pueden anunciarse como estratos 0. Un campo estrato establecido a 0 en el paquete NTP indica un estrato no especificado.

Estrato 1

Estos son ordenadores cuyo tiempo del sistema se sincroniza dentro de unos pocos microsegundos de sus dispositivos estrato 0 adjuntos. Los servidores Stratum 1 pueden consultar con otros servidores estrato 1 para comprobar y hacer copias de seguridad. También se denominan servidores de tiempo primario.

Estrato 2

Son computadoras sincronizadas sobre una red a servidores estrato 1. A menudo una computadora estrato 2 consultas varios estrato 1 servidores. Las computadoras del Estrecho 2 también pueden compararse con otras computadoras estrato 2 para proporcionar un tiempo más estable y robusto para todos los dispositivos del grupo de pares.

Estrato 3

Son computadoras sincronizadas a servidores estrato 2. Emplean los mismos algoritmos para buscar y muestreo de datos como estrato 2, y pueden actuar como servidores para ordenadores estrato 4, etc.

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 de ida y vuelta acumulado a los servidores de estrato 1 para todos los clientes.

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 del estrato 2 e inferiores, el refid es una forma codificada de la dirección IP del servidor de tiempo ascendente. Para IPv4, esta 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 en primer grado.

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

La IANA mantiene un registro para los nombres de fuente refid y los códigos KoD. Las asignaciones informales todavía pueden aparecer.

Marcas de tiempo

Las marcas de tiempo binarias de punto fijo de 64 bits utilizadas por NTP constan de una parte de 32 bits para segundos y una parte de 32 bits para fracciones de segundo, lo que proporciona una escala de tiempo que se repite cada 2³² segundos (136 años) y una resolución teórica de 2⁻³² segundos (233 picosegundos). NTP usa una época del 1 de enero de 1900. Por lo tanto, el primer traspaso ocurre el 7 de febrero de 2036.

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 del rollover en la mayoría de los casos. Según Mills, "el valor de 64 bits de la fracción es suficiente para determinar la cantidad de tiempo que tarda un fotón en pasar un electrón a la velocidad de la luz". El segundo valor de 64 bits es suficiente para proporcionar una representación temporal inequívoca hasta que el universo se oscurece."

Algoritmo de sincronización del reloj

Tiempo de demora de ida y vuelta δ

Un cliente NTP típico sondea regularmente uno o más servidores NTP. El cliente debe calcular su compensación de tiempo y demora de ida y vuelta. El desplazamiento de tiempo θ es una diferencia positiva o negativa (hora del cliente > hora del servidor) en el tiempo absoluto entre los dos relojes. se define por

Silencio Silencio =()t1− − t0)+()t2− − t3)2,{displaystyle theta ={frac {}-t_{0})+(t_{2}-t_{3}}{2}}}}}

δ δ =()t3− − t0)− − ()t2− − t1),{displaystyle delta ={(t_{3}-t_{0})-(t_{2}-t_{1}}

• t₀ es el horario del cliente de la transmisión del paquete de solicitud,
• t₁ es el horario del servidor de la recepción del paquete de solicitud,
• t₂ es el horario del servidor de la transmisión del paquete de respuesta y
• t₃ es el horario del cliente de la recepción del paquete de respuesta.

Para derivar la expresión del desplazamiento, tenga en cuenta que para el paquete de solicitud,

t0+Silencio Silencio +δ δ /2=t1{displaystyle T_{0}+theta +delta /2=t_{1}

t3+Silencio Silencio − − δ δ /2=t2{displaystyle t_{3}+theta -delta /2=t_{2}

Los valores para θ y δ se pasan a través de filtros y se someten a análisis estadístico ("mitigación"). Los valores atípicos se descartan y se deriva una estimación del desplazamiento de tiempo a partir de los tres mejores candidatos restantes. Luego, la frecuencia del reloj se ajusta para reducir la compensación gradualmente ("disciplina"), creando un circuito de retroalimentación.

La sincronización precisa se logra cuando las rutas entrantes y salientes entre el cliente y el servidor tienen un retraso nominal simétrico. Si las rutas no tienen un retraso nominal común, existe un sesgo sistemático de la mitad de la diferencia entre los tiempos de viaje hacia adelante y hacia atrás. Se han propuesto varios enfoques para medir la asimetría, pero entre las implementaciones prácticas, solo chrony parece tener uno incluido.

Implementaciones de software

La utilidad del protocolo de gestión NTP ntpq se utiliza para consultar el estado de un servidor estrato 2.

Implementación de referencia

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 funciones. Contiene varios algoritmos sensibles, especialmente para disciplinar el reloj, que pueden comportarse mal cuando se sincronizan con servidores que usan diferentes algoritmos. El software ha sido portado a casi todas las plataformas informáticas, incluidas las computadoras personales. Se ejecuta como un demonio llamado ntpd bajo Unix o como un servicio bajo Windows. Los relojes de referencia son compatibles y sus compensaciones se filtran y analizan de la misma manera que los servidores remotos, aunque generalmente se sondean con mayor frecuencia. Esta implementación se auditó en 2017 y se encontraron 14 posibles problemas de seguridad.

Hora de Windows

Todas las versiones de Microsoft Windows desde Windows 2000 incluyen el servicio de hora de Windows (W32Time), 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 el tiempo estuviera dentro de los 5 minutos del valor correcto para evitar ataques de reproducción. La versión de Windows 2000 y Windows XP solo implementa SNTP y viola varios aspectos del estándar NTP versión 3.

A partir de Windows Server 2003 y Windows Vista, W32Time se volvió compatible con un subconjunto importante de NTPv3. Microsoft afirma que W32Time no puede mantener de forma fiable la sincronización horaria con una precisión de un segundo. Si se desea una mayor precisión, Microsoft recomienda utilizar una versión más reciente de Windows o una implementación de NTP diferente.

A partir de Windows 10 versión 1607 y Windows Server 2016, W32Time se puede configurar para alcanzar una precisión de tiempo de 1 s, 50 ms o 1 ms en determinadas condiciones de funcionamiento específicas.

OpenNTPD

En 2004, Henning Brauer de OpenBSD presentó OpenNTPD, una implementación de NTPv3/SNTPv4 centrada en la seguridad y que abarca un diseño separado de privilegios. Si bien está dirigido más de cerca a las necesidades genéricas más simples de los usuarios de OpenBSD, también incluye algunas mejoras en la seguridad del protocolo sin dejar de ser 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. Una versión portátil está disponible en los repositorios de paquetes de Linux.

NTPsec

NTPsec es una bifurcación de la implementación de referencia que se ha reforzado sistemáticamente en materia de seguridad. El punto de bifurcación fue en junio de 2015 y fue en respuesta a una serie de compromisos en 2014. La primera versión de producción se envió en octubre de 2017. Entre la eliminación de características inseguras, la eliminación de soporte para hardware obsoleto y la eliminación de soporte para variantes obsoletas de Unix, NTPsec ha podido eliminar el 75 % del código base original, lo que facilita la auditoría del resto. Una auditoría del código de 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.

Crony

cronic, mostrando fuentes e información de actividad. Ventana terminal bajo Arch Linux

chrony es una implementación de NTP independiente patrocinada principalmente por Red Hat, que lo utiliza como programa de tiempo predeterminado en sus distribuciones. Al estar escrito desde cero, chrony tiene una base de código más simple que permite una mejor seguridad y un menor consumo de recursos. 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.

Chrony ha sido evaluado como "confiable", con solo algunos incidentes. Es capaz de lograr una precisión mejorada en las conexiones LAN, utilizando la marca de tiempo del hardware en el adaptador de red. Se agregó soporte para Network Time Security (NTS) en la versión 4.0. chrony está disponible bajo GNU General Public License versión 2, fue creado por Richard Curnow en 1997 y actualmente lo mantiene Miroslav Lichvar.

Otros

• Ntimed fue iniciado por Poul-Henning Kamp de FreeBSD en 2014 y abandonado en 2015. La implementación fue patrocinada por la Fundación Linux.
• systemd-timesyncd es el cliente SNTP integrado en sistema. Aunque raramente se escribe sobre, esta implementación es utilizada por Debian desde la versión "worm" y el Ubuntu aguas abajo.

Segundos bisiestos

El día de un evento de segundo bisiesto, ntpd recibe una notificación de un archivo de configuración, un reloj de referencia adjunto o un servidor remoto. Aunque el reloj NTP en realidad 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 pequeña cantidad, conservando el orden de los eventos. Si alguna vez fuera necesario un segundo bisiesto negativo, se eliminaría con la secuencia 23:59:58, 00:00:00, omitiendo 23:59:59.

Una implementación alternativa, denominada smearing de salto, 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. Google utiliza esta implementación (tanto internamente como en sus servidores NTP públicos), Amazon AWS y Facebook. Chrony admite el smear de salto en las configuraciones smoothtime y leapsecmode, pero dicho uso no debe mezclarse con un grupo NTP público como smear de salto no es estándar y descartará el cálculo del cliente en una mezcla.

Preocupaciones de seguridad

Solo se han identificado algunos otros problemas de seguridad en la implementación de referencia del código base NTP, pero los que aparecieron en 2009 fueron motivo de gran preocupación. El protocolo ha ido en revisión y revisión a lo largo de su historia. El código base para la implementación de referencia ha sido objeto de auditorías de seguridad de varias fuentes durante varios años.

En 2014 se descubrió y parchó un exploit de desbordamiento del búfer de pila. Apple estaba tan preocupado por esta vulnerabilidad que utilizó su función de actualización automática por primera vez. Algunos errores de implementación son básicos, como la falta de una declaración de retorno en una rutina, que puede dar lugar a un acceso ilimitado a los sistemas que ejecutan algunas versiones de NTP en el demonio raíz. Los sistemas que no utilizan el demonio raíz, como los derivados de Berkeley Software Distribution (BSD), no están sujetos a esta falla.

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 como NTPsec eran más problemáticos que Chrony desde el punto de vista de la seguridad.

Los servidores NTP pueden ser susceptibles a ataques de intermediarios, a menos que los paquetes estén firmados criptográficamente para la autenticación. La sobrecarga computacional involucrada puede hacer que esto no sea práctico en servidores ocupados, particularmente durante ataques de denegación de servicio. La suplantación de mensajes NTP de un ataque man-in-the-middle se puede utilizar para alterar los relojes en las computadoras cliente y permitir una serie de ataques basados en la omisión de la caducidad de la clave criptográfica. Algunos de los servicios afectados por mensajes NTP falsos identificados son TLS, DNSSEC, varios esquemas de almacenamiento en caché (como el caché de DNS), Protocolo de puerta de enlace fronteriza (BGP), Bitcoin y varios esquemas de inicio de sesión persistentes.

NTP se ha utilizado en ataques distribuidos de denegación de servicio. Se envía una pequeña consulta a un servidor NTP con la dirección IP de retorno suplantada para que sea la dirección de destino. Similar al ataque de amplificación de DNS, el servidor responde con una respuesta mucho más grande que permite que un atacante aumente sustancialmente la cantidad de datos que se envían al objetivo. Para evitar participar en un ataque, el software del servidor NTP puede actualizarse o los servidores pueden configurarse para ignorar consultas externas.

Extensiones seguras

NTP en sí mismo 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 autenticación útil, pero no es práctico para un servidor ocupado. Más tarde, también se descubrió que Autokey adolecía de varios defectos de diseño, y no se publicó ninguna corrección, excepto por un cambio en el código de autenticación de mensajes en RFC 8573.

Network Time Security (NTS) es una versión segura de NTPv4 con TLS y AEAD. La principal mejora con respecto a los intentos anteriores es que un "establecimiento clave" El servidor maneja la criptografía asimétrica pesada, que debe hacerse solo una vez. Si el servidor se cae, los usuarios anteriores aún podrían recuperar el tiempo sin temor a MITM. Actualmente, NTS es compatible con varios servidores de tiempo, incluido CloudFlare. Es compatible con NTPSec y chrony.

Microsoft también tiene un enfoque para autenticar paquetes NTPv3/SNTPv4 mediante una identidad de dominio de Windows, conocida como MS-SNTP. Este sistema está implementado en la referencia ntpd y chrony, utilizando samba para la conexión del dominio.