Resumen

  • Kiss-o'-Death reutilizó una respuesta NTP con Stratum 0 para transportar códigos de estado y acceso; sus marcas de recepción y transmisión dejaron de ser evidencia horaria y debían descartarse.
  • La respuesta solo adquiría autoridad tras vincularse a una solicitud pendiente, y cada código autorizaba una reacción concreta; esa obediencia necesitó límites locales porque una señal no autenticada también podía negar el servicio al cliente.

El coste de no poder decir «basta»

El RFC 4330 no presenta Kiss-o'-Death como un adorno semántico. Cuenta que numerosos routers domésticos y de oficina fueron configurados para usar un servidor universitario de tiempo. Bajo ciertos errores, una parte sustancial comenzó a enviar un paquete por segundo. El pico fue dramático y obligó a tomar medidas extremas.

Descartar tráfico protegía recursos inmediatos, pero no corregía a un cliente cooperativo. Un silencio podía parecer una pérdida y provocar otro intento. Hacía falta una respuesta que viajara por el mismo camino de NTP y expresara una condición precisa sin abrir una segunda sesión de control.

La versión 3 había dejado un hueco. El RFC 1305 llamaba «unspecified» al Stratum 0 y no asignaba entonces una función de estado al Reference Identifier. RFC 4330 usó esa combinación: Stratum 0 retiraba la validez temporal; cuatro caracteres ASCII en el Reference ID llevaban un kiss code. El paquete pasó a llamarse Kiss-o'-Death, o KoD.

El nombre sugería una orden terminal. El diseño real era más modesto: una indicación sobre la relación con ese servidor, no una autoridad general sobre el equipo.

La negativa no era una muestra defectuosa

Una respuesta normal aporta los instantes en que el servidor recibió la consulta y emitió la contestación. Esos timestamps participan, junto con los del cliente, en las estimaciones de offset y delay. El KoD conserva el sobre para llegar por la ruta esperada, pero cambia la naturaleza de lo que contiene.

El RFC 5905 dice que Stratum 0 implica un valor no especificado o inválido. En ese estado, el Reference Identifier puede comunicar acceso o situación. Los Receive y Transmit Timestamps fijados por el servidor son indefinidos: no se puede confiar en ellos y deben eliminarse.

La separación evita un error conceptual peligroso. Un RATE no es una lectura de tiempo de baja calidad. No debe entrar en el filtro, la selección de fuentes ni la disciplina del reloj. Es control negativo: puede cambiar el ritmo de las consultas, nunca la hora.

Primero, demostrar que respondía a esta consulta

En modo cliente-servidor, el Origin Timestamp de la respuesta reproduce el Transmit Timestamp de la solicitud. RFC 5905 utiliza la comparación para detectar paquetes falsos o repetidos. El RFC 8633 formula la obligación para KoD: el cliente solo puede aceptarlo si el Origin Timestamp es válido.

Así, la procedencia se construye antes del significado. El cliente vincula el datagrama a una solicitud pendiente; reconoce Stratum 0; aparta los campos temporales indefinidos; interpreta el código y ejecuta únicamente su transición definida.

Ese eco no autentica criptográficamente a una institución. Reduce el poder de un paquete arbitrario, pero un adversario capaz de observar o conocer el estado esperado puede tener otras opciones. La coincidencia prueba relación con una consulta, no honestidad universal del emisor.

Una negativa no tenía un único efecto

DENY comunica que el servidor remoto rechaza el acceso. RSTR lo atribuye a una política local. Para ambos, RFC 5905 exige desmontar las asociaciones y dejar de enviar a ese servidor. RATE significa que el cliente superó un umbral: debe reducir enseguida la frecuencia y retroceder más si el aviso se repite.

La distinción mantiene acotada la delegación. RATE permite volver a medir más adelante; DENY y RSTR cierran esa asociación. Ninguno modifica el reloj. Los valores con prefijo X quedan reservados para experimentación, y un código desconocido no se convierte en una instrucción remota abierta.

El registro de parámetros NTP de IANA conserva los nombres compartidos, entre ellos DENY, RSTR, RATE y NTSN. Registrar una secuencia estabiliza su documentación, pero no certifica el datagrama ni demuestra que la causa alegada sea cierta.

Retroceder con un tope propio

RFC 8633 recomienda respetar KoD, sobre todo en dispositivos embebidos sin una interfaz accesible para corregirlos después. Ante RATE, el cliente debería aumentar el intervalo hasta un máximo razonable de su implementación; el texto aconseja no superar el exponente 13, equivalente a dos horas.

También prohíbe aceptar sin control cualquier poll que venga en el paquete. Un valor enorme puede impedir consultas útiles y convertir la cooperación en denegación de servicio. La defensa del servidor no puede decidir por sí sola cuánto tiempo debe prescindir el cliente de una fuente.

El mecanismo depende además de una conducta que no siempre existe. Algunos clientes ignoran RATE; otros reaccionan mal y elevan el tráfico. El servidor necesita mantener descarte, limitación y vigilancia fuera del protocolo. KoD ofrece una salida coordinada, no sustituye la capacidad operativa.

NTS añadió una unión más fuerte

El RFC 8915 define Network Time Security para cliente-servidor. Una respuesta protegida debe incluir el Unique Identifier de una solicitud pendiente y autenticarse con la clave servidor-a-cliente correspondiente. Si falla cualquiera de las dos pruebas, se descarta sin seguir procesando.

Cuando el servidor no puede validar una cookie o autenticar una petición, puede responder con el código NTSN, un NTS negative acknowledgment. Precisamente por no poder recuperar el estado protegido, el KoD no incluye los campos habituales NTS Cookie ni Authenticator.

La excepción tiene otra frontera. Después de haber recibido respuestas NTS auténticas, el cliente debe rechazar cualquier KoD cuyo Unique Identifier no coincida con una solicitud pendiente. Puede repetir el establecimiento NTS-KE tras una disociación forzada, pero debe limitar los intentos para no crear un bucle. La negativa tampoco permite degradar automáticamente a NTP sin protección.

NTS mejora la evidencia de pertenencia. No convierte los timestamps del KoD en hora ni amplía el efecto del código.

Gobernar el vocabulario sin gobernar al cliente

RFC 5905 creó registros IANA para Reference Identifiers y kiss codes. El RFC 9748 cambió su política a Specification Required, restringió las nuevas cadenas a mayúsculas y dígitos con relleno nulo a la derecha, reservó el prefijo X y exigió la aprobación de dos de tres expertos designados.

Es una gobernanza pequeña para una consecuencia potencialmente grande. Un código de cuatro bytes puede quedar instalado durante años en miles de productos. La especificación pública reduce colisiones y hace revisable la finalidad.

Sin embargo, IANA solo puede gobernar el nombre. En ejecución, la legitimidad depende de una solicitud coincidente, autenticación cuando exista, un significado reconocido y una reacción local limitada. El logro de KoD fue volver útil la negativa sin convertirla en soberana: el servidor puede pedir moderación, pero el cliente conserva el control de su reloj, su disponibilidad y su recuperación.

Fuentes y límites

El hueco histórico está en RFC 1305; el incidente y la primera conducta KoD explícita, en RFC 4330. Las acciones y el descarte temporal proceden de RFC 5905, los límites operativos de RFC 8633, NTS de RFC 8915, y la gobernanza de RFC 9748 e IANA. No miden despliegue, cumplimiento ni ataques en 2026.