Resumo

  • Um KoD não oferece uma amostra ruim de tempo: seus timestamps de recepção e transmissão são indefinidos, o stratum zero invalida a sincronização e o Reference Identifier passa a carregar um código curto.
  • DENY, RSTR e RATE eram transições propostas ao cliente. Correspondência com uma solicitação pendente, autenticação quando disponível, teto local e filtragem do servidor continuavam necessários.

O custo de uma configuração padrão nem sempre fica com quem a escolheu. No caso registrado pelo RFC 4330, muitos roteadores residenciais e de escritório foram configurados para consultar um único servidor universitário de tempo. Alguns enviavam uma solicitação por segundo. A frota cresceu, o tráfego disparou e o operador precisou adotar medidas extremas.

Cada caixa funcionava como programada. O sistema, no entanto, transformava uma decisão industrial em obrigação permanente para um terceiro. O usuário não negociara o serviço, o operador não controlava o firmware e o fabricante podia já estar distante quando a carga aparecesse. O Kiss-o’-Death, ou KoD, surgiu como uma forma de o servidor explicar que não entregaria tempo e que o cliente deveria mudar de comportamento.

O espaço no pacote veio antes do acordo

O formato necessário já estava no NTP. O RFC 1305, de 1992, definiu o campo Stratum de oito bits e um Reference Identifier de quatro octetos. Stratum zero era “não especificado”; nos strata zero e um, o identificador aparecia como quatro caracteres ASCII. O RFC 2030 preservou essa forma no SNTPv4 de 1996.

Nenhum dos dois, porém, definiu o KoD. Um campo disponível não tem autoridade sem semântica compartilhada. O RFC 4330, publicado em 2006, reconheceu essa ausência e destinou o Reference Identifier de uma resposta stratum zero a códigos de estado, controle de acesso e pressão de taxa.

DENY passou a expressar recusa; RSTR, uma restrição administrativa; RATE, excesso de consultas. INIT e STEP indicavam condições temporárias do servidor. Era um vocabulário pequeno, adequado a um problema pequeno: explicar por que aquele pacote não trazia a hora e qual recuo o servidor esperava.

A resposta saía do plano de medição

No RFC 5905, um pacote stratum zero é inválido para sincronização, e o Reference Identifier é lido como kiss code. Os campos Receive Timestamp e Transmit Timestamp do KoD são indefinidos e precisam ser descartados.

Isso impede uma interpretação comum, mas errada: KoD não é um servidor impreciso que deve receber peso menor. Não há offset nem delay a calcular com a resposta. O pacote deixa o plano de medição e entra no plano de relacionamento.

A separação também limita a alegação. DENY não prova que a política é justa. RATE não informa o UTC. O código não autentica quem o enviou. Ele nomeia uma mudança de estado prevista pela especificação, cuja legitimidade ainda depende do contexto da associação.

RATE mostrou como uma palavra pode inverter o sistema

Para DENY e RSTR, o cliente deve desmobilizar a associação e parar de enviar ao servidor. Para RATE, deve aumentar o intervalo de poll e reduzir a frequência.

O texto publicado do RFC 5905 dizia originalmente o contrário: reduzir o intervalo. A consequência seria perguntar mais vezes em resposta a uma queixa de excesso. O Errata 3007 verificado corrigiu a direção para aumentar o intervalo.

Esse detalhe coloca a execução acima da aparência de conformidade. Uma implementação pode reconhecer o código e registrar a RFC, mas, se o próximo pacote sai mais cedo, o controle falhou. O teste relevante é causal: o temporizador mudou no sentido correto e a carga observada caiu?

O servidor não consegue executar essa alteração no dispositivo remoto. Um cliente antigo pode ignorar KoD; um cliente defeituoso pode acelerar. O mecanismo é cooperação padronizada, não polícia distribuída.

Uma solicitação pendente dava alcance, não identidade

O RFC 8633 exige que o cliente aceite KoD apenas com Origin Timestamp válido, correspondente a uma solicitação ainda pendente. Assim, uma resposta velha ou sem pergunta atual não ganha acesso ao estado da associação.

Essa correlação é necessária, mas não equivale a autenticação. Ela responde “este pacote parece responder ao que enviei agora”, não necessariamente “foi escrito pelo servidor legítimo”. Sem proteção criptográfica, um adversário capaz de observar ou inferir dados da troca pode tentar falsificar a resposta.

O ataque não precisa adiantar ou atrasar o relógio. Um DENY falso remove uma fonte útil. Um RATE falso posterga a próxima coleta. O alvo é a agenda de evidências do cliente.

Por isso, a trilha operacional deve distinguir pacote recebido, solicitação correspondente, autenticação, aceitação e efeito. Um painel que mostra apenas “KoD” converte quatro caracteres em prova de identidade e de execução que eles não fornecem.

O teto local impedia uma cessão completa do temporizador

Mesmo um RATE autêntico pode sugerir um poll excessivo por erro. Aceitá-lo sem limite entregaria ao servidor a capacidade de silenciar o cliente por muito tempo. O RFC 8633 cita como máximo razoável um expoente de poll não superior a 13, aproximadamente duas horas.

O número pode ser ajustado ao ambiente; a distribuição de controle não muda. O servidor relata sua pressão. O cliente decide até onde pode recuar, preservando continuidade e alternativas.

Clientes que não cooperam continuam existindo. O próprio RFC 8633 recomenda que o servidor descarte pacotes ou use controles fora do intercâmbio. Filtros e proteção de filas não são uma admissão de derrota: são a fronteira onde o conselho termina e a defesa local começa.

NTSN tratou uma falha que não podia ser autenticada normalmente

Network Time Security protege respostas comuns, mas há um impasse quando o servidor já não valida o cookie ou o autenticador do cliente. Ele não consegue criar a resposta NTS normal que explicaria a perda de estado.

O RFC 8915 criou NTSN para essa situação. O servidor deve omitir NTS Cookie e NTS Authenticator and Encrypted Extension Fields. Se o cliente já recebeu respostas autênticas daquele servidor, exige um Unique Identifier correspondente a uma solicitação pendente; sem correspondência, descarta.

A correspondência não dispara uma tempestade de chaves. O cliente espera o próximo poll normal. Se não receber resposta protegida válida, refaz NTS-KE com tentativas limitadas e mantém os parâmetros antigos até o novo estabelecimento funcionar.

É uma exceção estreita: mensagem não autenticada, contexto correlacionado e consequência adiada. NTSN não transforma todo KoD em resposta autenticada. Ele permite recuperar autenticação sem dar à falha uma autoridade maior que a necessária.

O registro coordenava nomes, não pagava servidores

O RFC 5905 criou um registro IANA para evitar colisões entre códigos. Em 2025, o RFC 9748 atualizou as regras: até quatro caracteres ASCII, preenchimento com octetos zero, prefixo X reservado a experiências, letras maiúsculas e dígitos para novas entradas sob Specification Required.

Registrar torna o significado pesquisável. Não autentica o pacote, não certifica firmware e não obriga uma instituição a servir a frota de outra. O registro governa o vocabulário; servidor, cliente e operador governam a execução.

Essa divisão evitou que um incidente de carga produzisse uma autoridade global de sondagem. A IETF descreveu a mensagem comum. O servidor escolheu responder ou filtrar. O cliente reteve sua associação, limites e fontes alternativas. A instituição que sofria o tráfego continuou livre para negar o serviço.

O artigo anterior de BTW sobre NTP explicou quatro timestamps, fontes divergentes e disciplina do relógio local. Aqui a medição não é recontada. O ponto de partida é a ausência deliberada de uma amostra: como um servidor tornou o recuo compreensível sem adquirir comando sobre o cliente.