Summary

  • Em um datagrama candidato de pelo menos 21 bytes, a correspondência dos 16 bytes finais com um token associado à conexão leva o receptor a encerrá-la; ela não autentica quem enviou o datagrama.
  • Ele não informa por que o estado sumiu, qual backend era responsável ou quando ocorreu a perda.
  • A investigação precisa juntar ao pacote a rota, a geração da chave e a última evidência de estado correto.

Um balanceador desloca o tráfego para outro backend. Logo depois, o cliente recebe um pacote cujos últimos 16 bytes correspondem a um token conhecido e abandona a conexão. O sinal determina a ação correta do cliente, mas é estreito demais para concluir que “o servidor perdeu o estado”.

O RFC 9000 §10.3 reserva o Stateless Reset, ou redefinição sem estado, para um endpoint que não consegue acessar o estado da conexão. No QUIC v1, com as funções AEAD definidas, um pacote de cabeçalho curto com menos de 21 bytes nunca é válido e deve ser descartado. A partir de 21 bytes, o receptor compara os últimos 16 bytes com tokens ligados a IDs de conexão ativos. Uma correspondência provoca encerramento imediato, mas não autentica o emissor nem informa motivo, identidade do backend ou horário da perda original.

O pacote é propositalmente difícil de distinguir de um pacote comum de cabeçalho curto. Bytes com aparência aleatória dificultam a identificação por observadores, e limites de tamanho reduzem ciclos de resets. Assim, uma captura passiva não deve classificar todo pacote semelhante como reset confirmado.

A seção 10.3.1 permite derivar o token de uma chave estática e de um ID de conexão. Uma camada de roteamento sem estado completo pode gerar um token correspondente, mas o cliente não descobre a geração da chave, a instância ou a mudança operacional que o produziu.

A seção 10.3.2 impõe uma fronteira crítica: IDs diferentes não devem compartilhar token. Colisão ou reutilização incorreta pode causar falso positivo e encerrar uma conexão saudável. O acerto da comparação no cliente não comprova que emissão, armazenamento e rotação foram corretos em toda a infraestrutura.

As considerações de segurança da seção 21.11 preservam essa cautela. Um token exposto ou mal administrado pode permitir injeção. A correspondência do token, sozinha, não atribui ataque, não exclui falha operacional e não prova que o failover preservou estado.

Como recomendação editorial, o registro do incidente deve reunir horário, tupla de endereços e portas, comprimento e formato do pacote, impressões digitais do CID e do token, sequência correspondente, backend emissor e geração de chave, decisão do balanceador, último pacote correto, eventos de implantação ou failover e evidência independente no armazenamento de estado.

Essa linha do tempo separa reinício, remoção de estado, expiração, rota incorreta, atraso de réplica, rotação incoerente de chave, colisão e injeção. O reset explica por que o cliente encerra agora; a evidência operacional explica por que o estado deixou de estar disponível.