Resumo

  • O Kiss-o'-Death colocou Stratum 0 numa resposta NTP e transformou o Reference Identifier em código de estado; os timestamps do servidor ficaram fora da evidência usada para disciplinar o relógio.
  • A reação só era legítima depois de associar o pacote à consulta pendente e dependia do código recebido; como o aviso frequentemente não era autenticado, o cliente também precisava limitar a própria obediência.

A sobrecarga que exigiu uma frase curta

O RFC 4330 registra a experiência que deu urgência ao mecanismo. Muitos roteadores residenciais e de escritório foram configurados para um servidor universitário de tempo. Em certas condições de erro, uma parcela substancial passou a enviar um pacote por segundo. O pico foi dramático e exigiu medidas extremas para diagnóstico e controle.

Um servidor sob pressão pode descartar. Para o cliente, porém, a ausência de resposta parece perda e pode acionar nova tentativa. Faltava uma forma de dizer, dentro do próprio NTP, que a relação havia sido recusada ou que a frequência precisava cair.

O espaço vinha de uma indefinição anterior. O RFC 1305 chamava Stratum 0 de unspecified, sem dar ao Reference Identifier uma semântica de status nessa condição. RFC 4330 reuniu os dois campos: Stratum 0 retirava o valor temporal, e quatro caracteres ASCII no Reference ID carregavam um kiss code. O pacote recebeu o nome Kiss-o'-Death, ou KoD.

Não surgiu uma sessão administrativa à parte. A negativa viajou pelo caminho da resposta que o cliente já sabia receber. Essa simplicidade também exigiu uma fronteira: o mesmo envelope não podia ser interpretado como tempo e como ordem ao mesmo tempo.

Antes da ação, a retirada da evidência

Uma resposta NTP comum oferece os instantes de recepção e transmissão observados pelo servidor. Somados aos timestamps do cliente, eles participam da estimativa de offset e atraso. O KoD preserva os campos, mas não a promessa de que contêm uma medição utilizável.

O RFC 5905 define Stratum 0 como unspecified ou invalid e permite que o Reference Identifier comunique status e controle de acesso. Os Receive e Transmit Timestamps do servidor são indefinidos nesse pacote. Não podem ser usados e devem ser descartados.

O resultado não é uma amostra ruim. É outro tipo de entrada. RATE pode alterar a agenda de consultas; jamais deve alimentar filtro, seleção de fontes ou correção do relógio. Essa separação impede que um mecanismo criado para salvar o servidor introduza uma hora inventada no cliente.

A resposta tinha de pertencer à pergunta

No modo cliente-servidor, o Origin Timestamp da resposta ecoa o Transmit Timestamp da consulta. RFC 5905 usa a comparação contra pacote falso ou repetido. O RFC 8633 exige que o cliente só aceite KoD com Origin Timestamp válido.

Primeiro vem o vínculo à requisição pendente. Depois, o reconhecimento de Stratum 0, a exclusão dos timestamps indefinidos e a leitura do código. Por fim, o cliente concede apenas a mudança de estado definida para aquele código.

Esse eco não é autenticação criptográfica. Ele dificulta que um datagrama aleatório seja obedecido, mas não prova identidade institucional ou veracidade do motivo. A força da ligação depende também do que um atacante consegue observar sobre o fluxo.

O código delimitava a consequência

DENY indica acesso negado pelo servidor remoto e RSTR, restrição por política local. Nos dois casos, RFC 5905 manda desmobilizar as associações e parar de enviar ao servidor. RATE informa que o limiar foi excedido: o cliente reduz imediatamente a taxa e continua recuando se novos RATE chegarem.

RATE preserva a possibilidade de medir mais tarde; DENY e RSTR encerram a associação. Nenhum altera o relógio. Códigos iniciados por X são reservados para experiência privada, e um valor desconhecido não abre uma linguagem de comandos sem limite.

O registro atual de parâmetros NTP da IANA inclui DENY, RSTR, RATE e o posterior NTSN. O registro estabiliza o nome e a referência, mas não autentica o pacote nem confirma a situação declarada pelo remetente.

A obediência ganhou um teto

RFC 8633 recomenda respeitar KoD, especialmente em equipamentos embarcados que podem não ter interface de controle acessível depois da instalação. Para RATE, o poll interval deve subir até um máximo razoável definido pela implementação; a recomendação é não ultrapassar expoente 13, equivalente a duas horas.

O cliente não deve copiar qualquer valor enviado pelo servidor. Um intervalo enorme pode fazê-lo parar de consultar e produzir negação de serviço. A mensagem que defende capacidade alheia não pode decidir sozinha quanto tempo o receptor ficará sem a função de que precisa.

O outro extremo também falha. Alguns clientes ignoram RATE; outros podem reagir de modo defeituoso e aumentar tráfego. O servidor continua precisando de descarte, limitação e monitoramento fora do protocolo. KoD é cooperação disponível, não controle garantido.

NTS amarrou a negativa a um estado mais forte

O RFC 8915 define Network Time Security no modo cliente-servidor. Uma resposta protegida precisa trazer o Unique Identifier de uma requisição pendente e ser autenticada com a chave servidor-para-cliente correspondente. Qualquer falha leva ao descarte sem processamento adicional.

Se o servidor não consegue validar o cookie ou autenticar a solicitação, pode devolver um KoD NTSN, o NTS negative acknowledgment. Como não recuperou o estado protegido, essa resposta não inclui NTS Cookie nem Authenticator.

A exceção não autoriza uma negativa solta. Depois de respostas NTS autênticas, o cliente deve rejeitar um KoD cujo Unique Identifier não corresponda a uma solicitação pendente. Pode reiniciar NTS-KE após dissociação forçada, mas limita tentativas para evitar um novo laço. Também não faz downgrade automático para NTP desprotegido.

NTS reforça a pergunta “esta resposta pertence à minha consulta?”. Não transforma o KoD em amostra de tempo nem amplia a ação do código.

O registro governa palavras, não decisões locais

RFC 5905 criou registros para Reference Identifiers e kiss codes. O RFC 9748 alterou o procedimento para Specification Required, restringiu novos valores a maiúsculas e dígitos com zeros à direita, reservou o prefixo X e exigiu aprovação de dois entre três especialistas designados.

Quatro bytes podem sobreviver em equipamentos por muitos anos. Especificação pública e análise especializada reduzem colisões e tornam a finalidade passível de revisão. Ainda assim, a IANA não vê o datagrama em execução, não valida a política do servidor e não escolhe o limite seguro do cliente.

A recusa ficou acionável porque sua autoridade foi dividida. O servidor descreve a condição; o estado da consulta decide pertencimento; o código delimita a reação; o cliente conserva teto, fontes alternativas e recuperação. O pacote que não trazia tempo tornou o silêncio mais informativo sem entregar a um único aviso o controle do relógio e da disponibilidade.

Fontes e limites

A lacuna inicial vem do RFC 1305, e o incidente e o KoD explícito do RFC 4330. Ações e descarte dos timestamps estão no RFC 5905; limites operacionais no RFC 8633; NTS no RFC 8915; governança no RFC 9748 e na IANA. As fontes não medem adoção, conformidade ou ataques em 2026.