Network Time Protocol (NTP) es un protocolo de Internet para sincronizar los relojes de los sistemas informáticos a través del enrutamiento de paquetes en redes con latencia variable. NTP utiliza UDP como su capa de transporte, usando el puerto "Puerto (computación)") 123. Está diseñado para resistir los efectos de la latencia variable.
Se basa en el envío de mensajes unicast de Network Time Protocol (NTP) y también funciona en multicast. Se recomienda en un entorno donde el servidor es raíz y el cliente es un nodo hoja. El nodo del cliente envía un mensaje de solicitud en el momento 𝑡1 al nodo del servidor y al servidor envíe el valor de tiempo actual en el mensaje de respuesta en el momento 𝑡3.
Historia
NTP es uno de los protocolos de internet más antiguos que siguen en uso, desarrollado en 1981 y descrito por primera vez en RFC 778. NTP fue diseñado originalmente por David L. Mills") de la Universidad de Delaware,[12] el cual lo sigue manteniendo, en conjunto con un equipo de voluntarios.[13].
Los detalles operacionales de NTP se encuentran ilustrados en el RFC 778, RFC 891, RFC 956, RFC 958, RFC 1305, RFC 4330 y RFC 5905.
NTP no debe ser confundido con el protocolo daytime (RFC 867) o el Time Protocol (RFC 868).
La versión actual de NTP es la versión 4; hasta el 2005, solo las versiones superiores a la versión 3 han sido documentadas en los RFCs. El grupo de trabajo de NTP IETF ha sido formado para estandarizar el trabajo de la comunidad de NTP desde RFC 1305.
Hay una forma menos compleja de NTP que no requiere almacenar la información respecto a las comunicaciones previas que se conoce como Protocolo Simple de Tiempo de Red' o SNTP, que ha ganado popularidad en dispositivos incrustados y en aplicaciones en las que no se necesita una gran precisión y está regido por las normas RFC 1361, RFC 1769, y RFC 2030.
NTP utiliza el algoritmo de Marzullo con la escala de tiempo Tiempo universal coordinado (UTC), incluyendo soporte para características como segundos intercalares. NTPv4 puede mantenerse sincronizado con una diferencia máxima de 10 milisegundos (1/100 segundos) a través de Internet, y puede llegar a acercarse hasta 200 microsegundos (1/5000 segundos) o más en redes de área local sobre condiciones ideales.
El demonio "Demonio (informática)") NTP de Unix es un proceso de nivel de usuario que se ejecuta continuamente en la máquina que soporta NTP, y la mayor parte del protocolo está implementado en este proceso de usuario. Para obtener el mejor rendimiento de NTP, es importante tener un reloj NTP estándar con lazo de seguimiento de fase implementado en el kernel del Sistema operativo, en vez de solo usar la intervención de un demonio NTP externo: todas las versiones actuales de GNU/Linux y Solaris "Solaris (sistema operativo)") soportan esta característica.
Servidores NTP
Introducción
Network Time Protocol (NTP) es un protocolo de Internet para sincronizar los relojes de los sistemas informáticos a través del enrutamiento de paquetes en redes con latencia variable. NTP utiliza UDP como su capa de transporte, usando el puerto "Puerto (computación)") 123. Está diseñado para resistir los efectos de la latencia variable.
Se basa en el envío de mensajes unicast de Network Time Protocol (NTP) y también funciona en multicast. Se recomienda en un entorno donde el servidor es raíz y el cliente es un nodo hoja. El nodo del cliente envía un mensaje de solicitud en el momento 𝑡1 al nodo del servidor y al servidor envíe el valor de tiempo actual en el mensaje de respuesta en el momento 𝑡3.
Historia
NTP es uno de los protocolos de internet más antiguos que siguen en uso, desarrollado en 1981 y descrito por primera vez en RFC 778. NTP fue diseñado originalmente por David L. Mills") de la Universidad de Delaware,[12] el cual lo sigue manteniendo, en conjunto con un equipo de voluntarios.[13].
Los detalles operacionales de NTP se encuentran ilustrados en el RFC 778, RFC 891, RFC 956, RFC 958, RFC 1305, RFC 4330 y RFC 5905.
NTP no debe ser confundido con el protocolo daytime (RFC 867) o el Time Protocol (RFC 868).
La versión actual de NTP es la versión 4; hasta el 2005, solo las versiones superiores a la versión 3 han sido documentadas en los RFCs. El grupo de trabajo de NTP IETF ha sido formado para estandarizar el trabajo de la comunidad de NTP desde RFC 1305.
Hay una forma menos compleja de NTP que no requiere almacenar la información respecto a las comunicaciones previas que se conoce como Protocolo Simple de Tiempo de Red' o SNTP, que ha ganado popularidad en dispositivos incrustados y en aplicaciones en las que no se necesita una gran precisión y está regido por las normas RFC 1361, RFC 1769, y RFC 2030.
NTP utiliza el algoritmo de Marzullo con la escala de tiempo Tiempo universal coordinado (UTC), incluyendo soporte para características como segundos intercalares. NTPv4 puede mantenerse sincronizado con una diferencia máxima de 10 milisegundos (1/100 segundos) a través de Internet, y puede llegar a acercarse hasta 200 microsegundos (1/5000 segundos) o más en redes de área local sobre condiciones ideales.
También los sistemas operativos macOS y Windows utilizan actualmente este protocolo para obtener el Tiempo universal coordinado (UTC) mediante procesos de sistema simples que funcionan vía internet.
NTP utiliza un sistema de jerarquía de estratos de reloj, en donde los sistemas de estrato 1 están sincronizados con un reloj externo tal como un reloj GPS o algún reloj atómico. Los sistemas de estrato 2 de NTP derivan su tiempo de uno o más de los sistemas de estrato 1, y así consecutivamente (cabe mencionar que esto es diferente de los estrato de reloj utilizados en los sistemas de telecomunicaciones).
Las estampas de tiempo utilizadas por NTP consisten en un segundo de 32-bit y una parte fraccional de 32-bit, dando con esto una escala de 2 segundos (136 años), con una resolución teórica de 2 segundos (0.233 nanosegundos). Aunque las escalas de tiempo NTP se redondean cada 2 segundos, las implementaciones deberían desambiguar el tiempo NTP utilizando el tiempo aproximado de otras fuentes. Esto no es un problema en la utilización general ya que esto solamente requiere un tiempo cercano a unas cuantas décadas.
Descripción del formato del paquete de la versión 4 de NTP/SNTP, que sigue después de las cabeceras de IP y de UDP.
Root Delay.
Root Dispersion.
Reference Identifier.
NTP tiene una estructura jerárquica por niveles, cada uno de estos niveles recibe el nombre de estrato. Estos niveles determinan la distancia desde el reloj de referencia.
El reloj de referencia es el dispositivo superior de la jerarquía, este se encuentra en el estrato cero, veremos a continuación este estrato de forma más detallada.
Existe un máximo de niveles de estrato, concretamente hasta 15 estratos, a medida que aumenta en número de estrato los dispositivos se vuelven menos precisos. Los servidores de un estrato pueden conectarse entre sí para mejorar la sincronización interna. También para combatir inexactitudes, y hacer el sistema de estrato más fiable, cada cliente puede consultar varios servidores del estrato superior.
A continuación se detallan los estratos superiores:.
Los dispositivos de este estrato también se conocen como relojes de referencia, estos tienen muy poco o ningún tiempo de retardo. Distribuyen Tiempo universal coordinado (UTC) a otros dispositivos a través de una red. Todos los dispositivos que reciben hora de un servidor 0 estrato se conocen como clientes.
Como ejemplos podemos destacar los relojes atómicos o los relojes de radio.
Son aquellos servidores conectados directamente a un reloj de referencia, recibiendo directamente la señal Tiempo universal coordinado (UTC). Se sincroniza en pocos microsegundos.
Corresponde a aquellos servidores que están sincronizados con uno o más servidores del estrato 1, por lo que es de estos servidores de los que reciben su tiempo.
Posteriormente estos servidores del estrato 2 actuarán como servidores para el estrato 3, y así sucesivamente hasta llegar al estrato final.
El proceso de intercambio de mensajes que realiza el protocolo NTP es el siguiente:.
El desfase (θ) entre ambos relojes se calcula mediante la siguiente fórmula:.
Network Time Security (NTS for NTP) está especificado en la norma RFC 8915 y utiliza el puerto 4460 para el intercambio de claves de cifrado.[14].
Es un mecanismo de seguridad criptográfico para la sincronización de tiempo de red. Se proporciona una especificación completa para la aplicación de NTS al modo cliente-servidor del Network Time Protocol (NTP) [RFC 5905].
Los objetivos de NTS son:.
Chrony viene por defecto en las distribuciones de Red Hat[impl_soft 1] y está disponible en los repositorios de Ubuntu[impl_soft 2] Chrony está orientado a los ordenadores comunes y corrientes, los cuales son inestables, entran en modo de suspensión o tienen conexión de manera intermitente con internet. Chrony está pensado también para máquinas virtuales, un ambiente mucho más inestable. Se caracteriza por su bajo consumo de recursos (costo) y soporta ambos protocolos muy bien (NTP y PTP&action=edit&redlink=1 "PTP(Precision Time Protocol) (aún no redactado)")). Tiene dos componentes principales: chronyd un demonio que se ejecuta al iniciar la computadora y chronyc una interfaz por línea de comandos al usuario para su configuración. Ha sido evaluado como muy seguro y con apenas unas cuantas incidencias.[impl_soft 3] su ventaja es la versatilidad de su código, escrito desde cero para evitar la complejidad de código,[impl_soft 4] Chrony está escrito bajo licencia Licencia Pública General de GNU, versión 2 y fue escrito por Richard Curnow") en 1997 con otros colaboradores y actualmente es mantenido por Miroslav Lichvar") y el desarrollo y mantenimiento está patrocinado por Red Hat.[impl_soft 5].
Desde octubre de 2020 chrony utiliza el protocolo NTS para NTP.[14].
El método SNTP fue desarrollado para computadoras más pequeñas y menos poderosas y necesita menos memoria y recursos de CPU que NTP. También es parte de TCP/IP y usa el puerto UDP 123. Aunque sirve para lo mismo, es más simple que el NTP debido a que tiene menos pasos y solo ajusta el tiempo periódicamente, lo que conlleva a una menor precisión. El contenido del paquete con el que se comunica con el servidor omite muchas de las funcionalidades del procedimiento NTP. La mayor desventaja de este protocolo es su vulnerabilidad ante posibles ataques, ya que no utiliza método de cifrado, proporcionando una baja seguridad.
En los siguientes casos sí es interesante el uso del SNTP:.
Es una implementación de NTP desarrollada principalmente por Henning Brauer en 2004 como una parte del proyecto de OpenBSD. Es fácil de utilizar, y ofrece la capacidad de sincronizar el reloj local con servidores NTP remotos.
A pesar de estar más enfocado a las necesidades genéricas más sencillas de los usuarios de OpenBSD , también proporciona algunas mejoras de seguridad de protocolo.
Algunas características de esta implementación son:.
La versión actual es la NTPv4 (versión 4) esta se introdujo en 2010 en el RFC 5905. Surgió como evolución de la versión 3. Esta versión es compatible versiones anteriores, entre ellas la versión NTPv3 basada en el RFC 1305.
Esta última versión mejoró los algoritmos de mitigación y disciplina que mejoran la precisión a decenas de microsegundos en soporte de estaciones de trabajo, computadoras portátiles, dispositivos de mano y LAN. NTPv4 también tiene una función de descubrimiento de servidores que simplifica la identificación de la configuración de un servidor.
Las principales diferencias entre estas versiones son:.
Encuentra más de "Servidores NTP", en los siguientes países:
[13] ↑ José María Campos Lahoz (13 de enero de 2013): Planificación y gestión activa de proyectos en GNU/LINUX con REDMINE, memoria final de la UOC.
[14] ↑ a b Ladd, Watson (1 de octubre de 2020). «NTS is now an RFC». Cloudflare (en inglés). Archivado desde el original el 3 de octubre de 2020. Consultado el 3 de octubre de 2020. «Earlier today the document describing Network Time Security for NTP officially became RFC 8915. This means that Network Time Security (NTS) is officially part of the collection of protocols that makes the Internet work. We’ve changed our time service to use the officially assigned port of 4460 for NTS key exchange, so you can use our service with ease.».: https://web.archive.org/web/20201003050955/https://blog.cloudflare.com/nts-is-now-rfc/
El demonio "Demonio (informática)") NTP de Unix es un proceso de nivel de usuario que se ejecuta continuamente en la máquina que soporta NTP, y la mayor parte del protocolo está implementado en este proceso de usuario. Para obtener el mejor rendimiento de NTP, es importante tener un reloj NTP estándar con lazo de seguimiento de fase implementado en el kernel del Sistema operativo, en vez de solo usar la intervención de un demonio NTP externo: todas las versiones actuales de GNU/Linux y Solaris "Solaris (sistema operativo)") soportan esta característica.
También los sistemas operativos macOS y Windows utilizan actualmente este protocolo para obtener el Tiempo universal coordinado (UTC) mediante procesos de sistema simples que funcionan vía internet.
NTP utiliza un sistema de jerarquía de estratos de reloj, en donde los sistemas de estrato 1 están sincronizados con un reloj externo tal como un reloj GPS o algún reloj atómico. Los sistemas de estrato 2 de NTP derivan su tiempo de uno o más de los sistemas de estrato 1, y así consecutivamente (cabe mencionar que esto es diferente de los estrato de reloj utilizados en los sistemas de telecomunicaciones).
Las estampas de tiempo utilizadas por NTP consisten en un segundo de 32-bit y una parte fraccional de 32-bit, dando con esto una escala de 2 segundos (136 años), con una resolución teórica de 2 segundos (0.233 nanosegundos). Aunque las escalas de tiempo NTP se redondean cada 2 segundos, las implementaciones deberían desambiguar el tiempo NTP utilizando el tiempo aproximado de otras fuentes. Esto no es un problema en la utilización general ya que esto solamente requiere un tiempo cercano a unas cuantas décadas.
Descripción del formato del paquete de la versión 4 de NTP/SNTP, que sigue después de las cabeceras de IP y de UDP.
Root Delay.
Root Dispersion.
Reference Identifier.
NTP tiene una estructura jerárquica por niveles, cada uno de estos niveles recibe el nombre de estrato. Estos niveles determinan la distancia desde el reloj de referencia.
El reloj de referencia es el dispositivo superior de la jerarquía, este se encuentra en el estrato cero, veremos a continuación este estrato de forma más detallada.
Existe un máximo de niveles de estrato, concretamente hasta 15 estratos, a medida que aumenta en número de estrato los dispositivos se vuelven menos precisos. Los servidores de un estrato pueden conectarse entre sí para mejorar la sincronización interna. También para combatir inexactitudes, y hacer el sistema de estrato más fiable, cada cliente puede consultar varios servidores del estrato superior.
A continuación se detallan los estratos superiores:.
Los dispositivos de este estrato también se conocen como relojes de referencia, estos tienen muy poco o ningún tiempo de retardo. Distribuyen Tiempo universal coordinado (UTC) a otros dispositivos a través de una red. Todos los dispositivos que reciben hora de un servidor 0 estrato se conocen como clientes.
Como ejemplos podemos destacar los relojes atómicos o los relojes de radio.
Son aquellos servidores conectados directamente a un reloj de referencia, recibiendo directamente la señal Tiempo universal coordinado (UTC). Se sincroniza en pocos microsegundos.
Corresponde a aquellos servidores que están sincronizados con uno o más servidores del estrato 1, por lo que es de estos servidores de los que reciben su tiempo.
Posteriormente estos servidores del estrato 2 actuarán como servidores para el estrato 3, y así sucesivamente hasta llegar al estrato final.
El proceso de intercambio de mensajes que realiza el protocolo NTP es el siguiente:.
El desfase (θ) entre ambos relojes se calcula mediante la siguiente fórmula:.
Network Time Security (NTS for NTP) está especificado en la norma RFC 8915 y utiliza el puerto 4460 para el intercambio de claves de cifrado.[14].
Es un mecanismo de seguridad criptográfico para la sincronización de tiempo de red. Se proporciona una especificación completa para la aplicación de NTS al modo cliente-servidor del Network Time Protocol (NTP) [RFC 5905].
Los objetivos de NTS son:.
Chrony viene por defecto en las distribuciones de Red Hat[impl_soft 1] y está disponible en los repositorios de Ubuntu[impl_soft 2] Chrony está orientado a los ordenadores comunes y corrientes, los cuales son inestables, entran en modo de suspensión o tienen conexión de manera intermitente con internet. Chrony está pensado también para máquinas virtuales, un ambiente mucho más inestable. Se caracteriza por su bajo consumo de recursos (costo) y soporta ambos protocolos muy bien (NTP y PTP&action=edit&redlink=1 "PTP(Precision Time Protocol) (aún no redactado)")). Tiene dos componentes principales: chronyd un demonio que se ejecuta al iniciar la computadora y chronyc una interfaz por línea de comandos al usuario para su configuración. Ha sido evaluado como muy seguro y con apenas unas cuantas incidencias.[impl_soft 3] su ventaja es la versatilidad de su código, escrito desde cero para evitar la complejidad de código,[impl_soft 4] Chrony está escrito bajo licencia Licencia Pública General de GNU, versión 2 y fue escrito por Richard Curnow") en 1997 con otros colaboradores y actualmente es mantenido por Miroslav Lichvar") y el desarrollo y mantenimiento está patrocinado por Red Hat.[impl_soft 5].
Desde octubre de 2020 chrony utiliza el protocolo NTS para NTP.[14].
El método SNTP fue desarrollado para computadoras más pequeñas y menos poderosas y necesita menos memoria y recursos de CPU que NTP. También es parte de TCP/IP y usa el puerto UDP 123. Aunque sirve para lo mismo, es más simple que el NTP debido a que tiene menos pasos y solo ajusta el tiempo periódicamente, lo que conlleva a una menor precisión. El contenido del paquete con el que se comunica con el servidor omite muchas de las funcionalidades del procedimiento NTP. La mayor desventaja de este protocolo es su vulnerabilidad ante posibles ataques, ya que no utiliza método de cifrado, proporcionando una baja seguridad.
En los siguientes casos sí es interesante el uso del SNTP:.
Es una implementación de NTP desarrollada principalmente por Henning Brauer en 2004 como una parte del proyecto de OpenBSD. Es fácil de utilizar, y ofrece la capacidad de sincronizar el reloj local con servidores NTP remotos.
A pesar de estar más enfocado a las necesidades genéricas más sencillas de los usuarios de OpenBSD , también proporciona algunas mejoras de seguridad de protocolo.
Algunas características de esta implementación son:.
La versión actual es la NTPv4 (versión 4) esta se introdujo en 2010 en el RFC 5905. Surgió como evolución de la versión 3. Esta versión es compatible versiones anteriores, entre ellas la versión NTPv3 basada en el RFC 1305.
Esta última versión mejoró los algoritmos de mitigación y disciplina que mejoran la precisión a decenas de microsegundos en soporte de estaciones de trabajo, computadoras portátiles, dispositivos de mano y LAN. NTPv4 también tiene una función de descubrimiento de servidores que simplifica la identificación de la configuración de un servidor.
Las principales diferencias entre estas versiones son:.
Encuentra más de "Servidores NTP", en los siguientes países:
[13] ↑ José María Campos Lahoz (13 de enero de 2013): Planificación y gestión activa de proyectos en GNU/LINUX con REDMINE, memoria final de la UOC.
[14] ↑ a b Ladd, Watson (1 de octubre de 2020). «NTS is now an RFC». Cloudflare (en inglés). Archivado desde el original el 3 de octubre de 2020. Consultado el 3 de octubre de 2020. «Earlier today the document describing Network Time Security for NTP officially became RFC 8915. This means that Network Time Security (NTS) is officially part of the collection of protocols that makes the Internet work. We’ve changed our time service to use the officially assigned port of 4460 for NTS key exchange, so you can use our service with ease.».: https://web.archive.org/web/20201003050955/https://blog.cloudflare.com/nts-is-now-rfc/