Network Time Protocol

Network Time Protocol (NTP)
Familia Familia de protocolos de Internet
Función Sincronización de relojes de sistemas informáticos
Puertos 123/UDP
Ubicación en la pila de protocolos
Aplicación NTP
Transporte UDP
Red IP
Estándares
RFC 1305 (NTP)
RFC 4330 (SNTP)
RFC 5905 (versión 4, retrocompatible)
[editar datos en Wikidata]

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 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

[editar]

[actualizar]

Evolución de los RFC para NTP
1980 —
–
1985 —
–
1990 —
–
1995 —
–
2000 —
–
2005 —
–
2010 —
–
2015 —
–
2020 —
RFC 958[1]​
RFC 1059[2]​
RFC 1119[3]​
RFC 1305[4]​
RFC 5905[5]​
RFC 7822[6]​
RFC 1361[7]​
RFC 1769[8]​
RFC 2030[9]​
RFC 4330[10]​
←
DCNET Internet Clock Service[11]​
←
SNTP

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.[cita requerida]

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.

Descripción

[editar]

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 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 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 232 segundos (136 años), con una resolución teórica de 2−32 segundos (0.233 nanosegundos). Aunque las escalas de tiempo NTP se redondean cada 232 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 paquete

[editar]

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.

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
LI VN Mode Stratum Poll Precisión
Root Delay
Root Dispersion
Reference Identifier
Reference Timestamp (64)
Originate Timestamp (64)
Receive Timestamp (64)
Transmit Timestamp (64)
Key Identifier (optional) (32)
Message Digest (optional) (128)
Leap Indicator (LI)
código de 2 bits que sirve para indicar que al último minuto del presente día se le añadirá/quitará un segundo.
LI Valor Significado
00 0 sin modificación
01 1 el último minuto tiene 61 segundos
10 2 el último minuto tiene 59 segundos
11 3 condición de alarma (reloj no sincronizado)
Version Number (VN)
Entero de 3 bits que indica el número de versión. La versión 3, indica la versión 3 (solo IPv4) y la 4 para la versión 4 (IPv4, IPv6 y OSI). Si es necesario distinguir entre IPv4, IPv6 y OSI, se debe examinar el contexto encapsulado.
Mode
entero de tres bits que sirve para indicar el modo, definidos de la siguiente manera:
Mode Significado
0 reservado
1 simétrico activo
2 simétrico pasivo
3 cliente
4 servidor
5 broadcast
6 reservado para mensajes de control de NTP
7 reservado para uso privado
Stratum
Es un entero sin signo de 8 bits que indica el nivel (stratum) del servidor local, los valores definidos son los siguientes:
Stratum Significado
0 no especificado o no disponible
1 referencia primaria (ej., radio clock)
2-15 referencia secundaria (vía NTP o SNTP)
16-255 reservado
Poll Interval
es un entero de 8 bits con signo que indica el intervalo máximo de tiempo entre dos mensajes sucesivos, expresado en segundo y como la potencia de 2 más cercana. La mayoría de las aplicaciones usan el rango que va desde 6 bits (64") a 10 (1024")
Precisión
es un entero con signo que indica la precisión del reloj local expresado en segundo a la potencia de 2 más cercana.:

Root Delay

refleja el retardo de ida y vuelta entre el servidor y la fuente primaria de reloj. Proporciona una estimación aproximada del error de transferencia de tiempo en el peor de los casos entre un cliente y un servidor.

Root Dispersion

es una estimación de la cantidad total de error/variación entre un servidor y la hora correcta. La forma en que se calcula es simple: cada servidor NTP obtiene su hora de un reloj externo o de otro servidor NTP.: Si un servidor obtiene su hora de un reloj externo, su dispersión raíz es el error máximo estimado de ese reloj. Si obtiene su tiempo de otro servidor NTP, su dispersión raíz es la dispersión raíz de ese servidor más la dispersión agregada por el enlace de red entre ellos.

Reference Identifier

es una cadena de 4 caracteres que indica el tipo de fuente.: Algunos de los identificadores son:
Código Fuente de referencia externa
LOCL reloj local no calibrado
CESM reloj de cesio calibrado
RBDM reloj de rubidio calibrado
PPS reloj de cuarzo calibrado u otra fuente de pulso por segundo
IRIG Grupo de Instrumentación Inter-Range
ACTS Servicio de módem telefónico NIST
USNO Servicio de módem telefónico USNO
LORC Sistema de radionavegación LORAN-C
OMEG Sistema de radionavegación OMEGA
GPS Servicio de posicionamiento global


Estratos de reloj

[editar]
Esquema estratos NTP.

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:

Estrato 0

[editar]

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.

Estrato 1

[editar]

Son aquellos servidores conectados directamente a un reloj de referencia, recibiendo directamente la señal Tiempo universal coordinado (UTC). Se sincroniza en pocos microsegundos.

Estrato 2

[editar]

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.

Intercambio de mensajes

[editar]

El proceso de intercambio de mensajes que realiza el protocolo NTP es el siguiente:

Esquema intercambio de mensajes NTP.
  • Se envía una petición de sincronización en un instante T0 de parte del cliente para verificar si el tiempo de desfase entre servidor y cliente es mayor de 17 minutos.
  • Esta petición la recibe el servidor en el instante T1. En este momento podemos encontrar dos escenario:
    • Si el desfase es menor que 17 minutos el servidor envía un mensaje en el instante T2.
    • Si el desfase es mayor que 17 minutos se terminará el proceso y no habrá sincronización.
  • En el instante T3 el cliente recibirá el paquete de parte del servidor. En este momento cada minuto se realizará un ajuste del tiempo hasta aproximarse a 128ms del tiempo del servidor. A partir de un desfase mayor a 128ms, cada 17 minutos el desfase se va precisando.
Esquema flujo de mensajes de NTP..


El desfase (θ) entre ambos relojes se calcula mediante la siguiente fórmula:

Fórmula calcular desfase.


Network Time Security

[editar]

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.[13]​

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:

  • Identidad: Se establece la identidad de las partes con las que se comunican mediante una clave pública X.509.
  • Autenticación: verificación criptográfica de los paquetes, para asegurar que su origen está identificado y no han sido modificados en durante la transmisión.
  • Confidencialidad: NTS incluye soporte para encriptar campos de extensión NTP.
  • Prevención de reproducción: detección de los paquetes de sincronización de tiempo duplicados.
  • Consistencia de solicitud-respuesta: verificación por parte del cliente de que un paquete de sincronización de tiempo recibido de parte del servidor corresponde con una solicitud del cliente previa.
  • Escalabilidad: El servidor puede servir a un gran número de clientes.
  • Rendimiento: El cifrado y la autenticación utilizados cuando se transfiere el tiempo deben ser mínimo.

Implementaciones de software

[editar]

Chrony

[editar]
chronyc corriendo en una ventana terminal Ubuntu 16.04, presentación de licencia de uso y ayuda mostrando las opciones de la línea de comandos.

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). 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.[13]​

SNTP

[editar]

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:

  • Equipos en los que la sincronización del tiempo no sea determinante.
  • Dispositivos simples, como microcontroladores y ordenadores pequeños, con poca memoria.

OpenNTPD

[editar]

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:

  • Base de código simple y fácilmente comprensible.
  • Separación de privilegios que aísla el código de red sin privilegios del código de configuración de tiempo privilegiado.
  • Soporte de DNS separado por privilegios que funciona dinámicamente durante el tiempo de ejecución, lo que permite una resolución tardía aunque la red esté inactiva al inicio.

Últimas versiones

[editar]

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.

Comparativa NTPv3 vs NTPv4

[editar]

Las principales diferencias entre estas versiones son:

  • NTPv4 permite, además del direccionamiento IPv4, el direccionamiento IPv6 entre clientes y servidores.
  • Permite incorporar seguridad en las comunicaciones, esto se logra ya que NTPv4 admite criptografía de clave pública y certificados X509 estándar.
  • NTP permite reducir el tamaño de los paquetes y aumentar el rango de valores disponibles, modificando el tipo de datos de 64 bits de formato fijo a 64 bits en coma flotante.
  • Mejora la compatibilidad con DNS, de manera que con NTPv4 si configura un nombre de host para sincronizar, el dispositivo busca el nombre de host almacenándolo en la configuración y también almacena la dirección IP en la configuración. A diferencia de NTPv3 que el nombre de host no era almacenado.

Referencias

[editar]
  1. ↑ RFC 958 Network Time Protocol (NTP), septiembre 1985.
  2. ↑ RFC 1059 Network Time Protocol (Version 1) Specification and Implementation, julio 1988.
  3. ↑ RFC 1119 Network Time Protocol (Version 2) Specification and Implementation, septiembre 1989.
  4. ↑ RFC 1305 Network Time Protocol (Version 3) Specification, Implementation and Analysis, marzo 1992.
  5. ↑ RFC 5905 Network Time Protocol Version 4: Protocol and Algorithms Specification, junio 2010.
  6. ↑ RFC 7822 Network Time Protocol Version 4 (NTPv4) Extension Fields, marzo 2016.
  7. ↑ RFC 1361 Simple Network Time Protocol (SNTP), agosto 1992.
  8. ↑ RFC 1769 Simple Network Time Protocol (SNTP), marzo 1995.
  9. ↑ RFC 2030 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI, octubre 1996.
  10. ↑ RFC 4330 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI, enero 2006
  11. ↑ RFC 778 DCNET Internet Clock Service, abril 1981.
  12. ↑ «¿Qué es un protocolo de tiempo de red NTP?». CAVSI. Archivado desde el original el 18 de marzo de 2015. Consultado el 19 de noviembre de 2017. «NTP es utilizado para sincronizar el tiempo del reloj en los equipos en una red de computadoras. Desarrollado por David Mills en la Universidad de Delaware, NTP se ha convertido en un estándar en Internet.» 
  13. ↑ 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.» 

Referencias: implementaciones de software

[editar]
  1. ↑ Lichvar, Miroslav (20 de julio de 2016). «Combining PTP with NTP to Get the Best of Both Worlds». Red Hat Enterprise Linux Blog (en inglés). Red Hat. Archivado desde el original el 30 de julio de 2017. Consultado el 19 de noviembre de 2017. «Starting with Red Hat Enterprise Linux 7.0 (and now in Red Hat Enterprise Linux 6.8) a more versatile NTP implementation is also provided via the chrony package». 
  2. ↑ Lichtenheld, Frank. «Package: chrony (2.1.1-1) [universe]». Ubuntu Package (en inglés). Ubuntu Package. Archivado desde el original el 19 de noviembre de 2017. Consultado el 19 de noviembre de 2017. «Versatile implementation of the Network Time Protocol». 
  3. ↑ Heiderich, Mario (August 2017). «Pentest-Report Chrony 08.2017» (pdf). Cure53.de Team (en inglés). wiki.mozilla.org, AKA MozillaWiki or WikiMO. Archivado desde el original el 5 de octubre de 2017. Consultado el 19 de noviembre de 2017. «Withstanding eleven full days of on-remote testing in August of 2017 means that Chrony is robust, strong, and developed with security in mind.» 
  4. ↑ «Securing Network Time». Core Infrastructure Initiative, a Linux Foundation Collaborative Project (en inglés). Core Infrastructure Initiative. 27 de septiembre de 2017. Archivado desde el original el 28 de octubre de 2017. Consultado el 19 de noviembre de 2017. «In sum, the Chrony NTP software stands solid and can be seen as trustworthy». 
  5. ↑ «chrony introduction». TuxFamily, a non-profit organization. (en inglés). chrony. Archivado desde el original el 9 de diciembre de 2009. Consultado el 19 de noviembre de 2017. «The software is supported on Linux, FreeBSD, NetBSD, macOS, and Solaris.» 

Véase también

[editar]

Enlaces externos

[editar]
Software relacionado con NTP
Obtenido de «https://es.wikipedia.org/w/index.php?title=Network_Time_Protocol&oldid=162276527»