Resumen

  • La opción 68 de IPv4 ofrecía un registro finito dentro del paquete para añadir marcas horarias o pares de dirección y hora.
  • Requisitos posteriores conservaron la cooperación, pero la falta de autenticación, los relojes descoordinados, la exposición de información y el filtrado redujeron su utilidad.

Tres maneras de pedir una anotación

Internet Timestamp no era una sola cifra colocada por el emisor. RFC 791 reservó el tipo 68 para una estructura modificable a lo largo del recorrido. Su bit de copia era cero, de modo que una fragmentación la dejaba únicamente en el primer fragmento, y solo podía aparecer una vez por datagrama.

Dentro de la opción, un octeto de longitud imponía un máximo de 40 octetos. El puntero, cuyo mínimo válido era 5, señalaba el siguiente hueco. El último octeto de control se dividía entre un contador de desbordamiento de cuatro bits y una bandera de cuatro bits. Si ya no cabía una entrada, el sistema aumentaba el contador; no podía invadir el resto del encabezado. Si el contador también desbordaba, o la longitud o el puntero eran inválidos, el datagrama se consideraba erróneo y se descartaba, con la posibilidad de responder mediante ICMP Parameter Problem.

La bandera 0 pedía una secuencia de marcas de 32 bits. La 1 pedía que cada máquina registrara primero su dirección Internet y después la hora. La 3 llevaba direcciones preseleccionadas y esperaba una marca solo cuando la siguiente dirección coincidía con la del sistema que procesaba el paquete. El valor preferido eran milisegundos desde la medianoche en tiempo universal. Si una máquina no disponía de esa referencia, podía usar otra únicamente marcando el bit superior para declarar el valor no estándar.

El resultado tenía límites visibles. Cuarenta octetos daban para pocos participantes, sobre todo cuando cada entrada incluía dirección y hora. El desbordamiento contaba oportunidades perdidas, pero solo hasta quince. Y ninguna parte del formato firmaba la identidad del escritor o demostraba que los saltos silenciosos hubieran visto siquiera la solicitud.

La norma exigía conducta, no confianza

RFC 1122 dejó como opcional para los hosts tanto originar como procesar la opción. Sin embargo, al implementarla, el origen debía anotar su propia hora cuando el modo lo permitiera y el destino debía, si era posible, añadir la hora actual antes de entregar la opción a capas superiores. También heredaba las reglas horarias de ICMP: medianoche UT como base preferida y bit de valor no estándar cuando no pudiera darse una hora correcta.

Para los routers, RFC 1812 fijó soporte obligatorio al reenviar. En el modo de direcciones preseleccionadas, la coincidencia podía ser con cualquier dirección del router, no solo con la interfaz de entrada o salida. Un equipo podía ofrecer un interruptor para dejar intactos los modos 0 y 1, pero debía venir desactivado. A la vez, el RFC advertía que la anotación era más útil cuanto más próxima estuviera a la llegada y que los relojes sin sincronizar reducían su valor.

Cuando observar también significa revelar

RFC 7126 evaluó la otra cara del registro. Tiempos de procesamiento y direcciones podían servir al diagnóstico, pero también exponer topología, horas de los sistemas y rasgos de implementación; el sesgo de reloj podía ayudar incluso a identificar dispositivos físicos. La solicitud de observabilidad llevaba dentro un canal de revelación.

Además, la herramienta dependía de que todas las fronteras aceptaran opciones IPv4. El ping común seguía funcionando sin ellas, mientras una prueba basada en la opción podía romperse en cualquier filtro. RFC 7126 afirmó que el descarte generalizado ya había vuelto estas técnicas prácticamente inutilizables y recomendó que routers, pasarelas de seguridad y cortafuegos descartaran los paquetes con Internet Timestamp.

Fuentes