Network Time Protocol (NTP)

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 y conmutación de 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á destinado a 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 fuente de tiempo potencial. 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 un estándar propuesto como se documenta en RFC 5905. Es compatible con la versión 3, especificada en RFC 1305.

Network Time Security (NTS), una versión segura de NTP con TLS y AEAD es un estándar propuesto y documentado en RFC 8915.

Historia

Evolución de RFC para NTP
1980 —–1985 —–1990 —–1995 —–2000 —–2005 —–2010 —–2015 —–2020 —	RFC 958RFC 1059RFC 1119RFC 1305RFC 5905RFC 7822RFC 1361RFC 1769RFC 2030RFC 4330	←Servicio de reloj de Internet DCNET←SNTP

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 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 los algoritmos de disciplina de reloj y análisis de datos de NTP, 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 de tiempo digital (DTSS), que utiliza una jerarquía de servidores similar al modelo de estrato NTP.

En 1985, NTP versión 0 (NTPv0) se implementó tanto en Fuzzball como en Unix, y el encabezado del paquete NTP y los cálculos de retraso y compensación de ida y vuelta, que han persistido en NTPv4, se documentaron en RFC 958. A pesar de las computadoras y redes relativamente lentas disponible 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 protocolo cliente-servidor y peer. -Modos a pares. 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 definiendo 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. El protocolo ha progresado significativamente desde entonces y, a partir de 2014, aún no se ha publicado un RFC actualizado. 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.

Estratos de reloj

NTP utiliza un sistema jerárquico de semi-capas 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 0Estos son dispositivos de cronometraje de alta precisión, como relojes atómicos, GNSS (incluido GPS) u otros relojes de radio. Generan una señal de pulso por segundo muy precisa que activa una interrupción y marca de tiempo en una computadora conectada. Los dispositivos Stratum 0 también se conocen como relojes de referencia. Los servidores NTP no pueden anunciarse como estrato 0. Un campo de estrato establecido en 0 en el paquete NTP indica un estrato no especificado.Estrato 1Estas son computadoras cuya hora del sistema se sincroniza dentro de unos pocos microsegundos de sus dispositivos de estrato 0 adjuntos. Los servidores del estrato 1 pueden emparejarse con otros servidores del estrato 1 para realizar comprobaciones y copias de seguridad. También se conocen como servidores de tiempo primarios.Estrato 2Estas son computadoras que están sincronizadas a través de una red con servidores de estrato 1. A menudo, una computadora de estrato 2 consulta varios servidores de estrato 1. Las computadoras del estrato 2 también pueden emparejarse con otras computadoras del estrato 2 para proporcionar un tiempo más estable y sólido para todos los dispositivos en el grupo de pares.Estrato 3Estas son computadoras que están sincronizadas con servidores de estrato 2. Emplean los mismos algoritmos para emparejamiento y muestreo de datos que el estrato 2, y pueden actuar como servidores para las computadoras del 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 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).

Recargar	Fuente de reloj
VA	Satélite de entorno de órbita geosincrónica
GPS	Sistema de Posicionamiento Global
GALÓN	Sistema de posicionamiento Galileo
PPS	Pulso por segundo genérico
IRIG	Grupo de Instrumentación Inter-Range
WWVB	LF Radio WWVB Fort Collins, Colorado 60 kHz
FCD	Radio LF DCF77 Mainflingen, Alemania 77,5 kHz
HBG	LF Radio HBG Prangins, HB 75 kHz (operación interrumpida)
MSF	LF Radio MSF Anthorn, Reino Unido 60 kHz
JJY	LF Radio JJY Fukushima, JP 40 kHz, Saga, JP 60 kHz
LORC	Emisora ​​MF Radio Loran-C, 100
TDF	MF Radio Allouis, FR 162 kHz
CHU	HF Radio CHU Ottawa, Ontario
WWV	HF Radio WWV Fort Collins, Colorado
WWVH	HF Radio WWVH Kauai, Hawái
NIST	módem telefónico NIST
HECHOS	módem telefónico NIST
USNO	Módem telefónico USNO
PTB	Módem telefónico estándar de tiempo PTB alemán
SRA	Fuentes de referencia múltiple
XFAC	Inter Face Association Changed (dirección IP cambiada o perdida)
PASO	Cambio de tiempo de paso, el desplazamiento es menor que el umbral de pánico (1000 s) pero mayor que el umbral de paso (125 ms)
GOOG	Google Refid no oficial utilizado por los servidores NTP de Google como time4.google.com

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 renueva 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 de la transferencia en la mayoría de los casos. Según Mills, "el valor de 64 bits para 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 el universo se oscurece".

Algoritmo de sincronización de reloj

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

y el retardo de ida y vuelta δ por

dónde

• t ₀ es la marca de tiempo del cliente de la transmisión del paquete de solicitud,
• t ₁ es la marca de tiempo del servidor de la recepción del paquete de solicitud,
• t ₂ es la marca de tiempo del servidor de la transmisión del paquete de respuesta y
• t3 es la marca de tiempo 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,

y para el paquete de respuesta,

Resolviendo para θ se obtiene la definición del desplazamiento de tiempo.

Los valores de θ y δ se pasan a través de filtros y se someten a análisis estadístico. 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 el desplazamiento gradualmente, creando un bucle 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.

Implementaciones de software

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 numerosos problemas de seguridad potenciales.

SNTP

El protocolo simple de tiempo de red (SNTP) es una implementación menos compleja de NTP, que utiliza el mismo protocolo pero sin requerir el almacenamiento de estado durante largos períodos de tiempo. Se utiliza en algunos sistemas integrados y en aplicaciones donde no se requiere la capacidad total de NTP.

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 de la versión 5 de Kerberos, que requería que el tiempo estuviera dentro de los 5 minutos del valor correcto para evitar ataques de repetició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 hizo 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.

AbrirNTPD

En 2004, Henning Brauer presentó OpenNTPD, una implementación de NTP 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. Una versión portátil está disponible en los repositorios de paquetes de Linux.

Ntimed

Ntimed fue iniciado por Poul-Henning Kamp en 2014 y abandonado en 2015. La implementación fue patrocinada por la Fundación 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 funciones 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.

Cronista

chrony viene por defecto en las distribuciones de Red Hat y está disponible en los repositorios de Ubuntu. chrony está dirigido a computadoras comunes, que son inestables, entran en modo de suspensión o tienen una conexión intermitente a Internet. chrony también está diseñado para máquinas virtuales, un entorno mucho más inestable. Se caracteriza por un bajo consumo de recursos (costo) y es compatible con hardware de protocolo de tiempo de precisión para una mayor precisión de marca de tiempo. Tiene dos componentes principales: chronyd, un demonio que se ejecuta cuando se inicia la computadora, y chronyc, una interfaz de línea de comandos al usuario para su configuración. Ha sido evaluado como muy seguro y con pocas incidencias, su ventaja es la versatilidad de su código, escrito desde cero para evitar complejidades innecesarias.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.

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) y Amazon AWS.

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 de búfer de pila. Apple estaba lo suficientemente preocupado por esta vulnerabilidad que utilizó su capacidad 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 man-in-the-middle 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.

Para mejorar la seguridad de NTP, se desarrolló una versión segura llamada Network Time Security (NTS) y actualmente es compatible con varios servidores de tiempo.