Summary

  • Uma conexão QUIC possui um conjunto de referências emitidas pelos endpoints; nenhum CID é identidade permanente.
  • Prontidão para migração depende de estoque não usado, limites negociados e retiradas concluídas.
  • Um registro bidirecional separa falha de roteamento, falta de estoque e rotação por privacidade.

Considere um celular saindo do Wi-Fi para a rede móvel. As chaves continuam válidas e os fluxos seguem abertos, mas o cliente não consegue sondar o novo caminho em direção ao servidor porque não há mais um CID não utilizado emitido por ele. No sentido inverso, o servidor também precisa de um ID não utilizado emitido pelo cliente. A conexão continua estabelecida, porém uma condição de continuidade se esgotou.

O RFC 9000 §5.1 define um conjunto de IDs para cada conexão. Cada endpoint escolhe independentemente os valores que o par usará. A função principal é encaminhar pacotes ao estado correto da conexão apesar de mudanças nos endereços de camadas inferiores.

A direção importa. Um endpoint emite os IDs usados em pacotes destinados a ele e consome os IDs emitidos pelo par ao enviar. Um CID de destino numa captura é uma referência atual em uma direção, não um nome universal nem identidade autenticada de usuário, aparelho ou sessão de aplicação.

A seção 5.1.1 dá números de sequência aos CIDs emitidos. Novos valores chegam em NEW_CONNECTION_ID com sequência crescente. Ela reconcilia o ciclo de vida; não é relógio nem identificador global.

active_connection_id_limit informa quantos IDs ativos o par aceita manter. Exceder o limite após adições e retiradas exige CONNECTION_ID_LIMIT_ERROR. Mas limite não é estoque: mesmo abaixo dele, todos os valores podem estar consumidos ou aguardando reposição.

A seção 9.5 registra a consequência. Sem CIDs disponíveis, um endpoint não pode sondar novos caminhos, migrar ou responder à migração do par. Conexão aberta não comprova mobilidade disponível.

O estoque também serve à privacidade. Reutilizar um CID estável em caminhos diferentes permite correlação. O protocolo proíbe reutilizá-lo ao enviar de mais de um endereço local ou para mais de um destino. A rotação remove um sinal óbvio, mas tempo e tamanho de pacotes ainda podem correlacionar tráfego.

Segundo a seção 5.1.2, RETIRE_CONNECTION_ID declara que o valor não será usado de novo e pede reposição. Retire Prior To pode retirar sequências antigas. Até mensagens e confirmações convergirem, os endpoints podem manter visões diferentes.

Esses frames são criptografados. O observador passivo pode notar uma troca de CID sem ver sequência, estoque ou retirada. O RFC 9312 ressalta essa limitação. E quem escolhe CID de comprimento zero não pode emitir novos valores, abrindo mão da migração apoiada por CID.

Como recomendação editorial, o registro completo deve preservar: ID e horário da observação; papel do endpoint; tupla de endereços local e remoto; direção de emissão; sequência e impressão digital do CID; estados ativo, não utilizado, alocado, com retirada solicitada e retirado; active_connection_id_limit; maior Retire Prior To; horário de recebimento de NEW_CONNECTION_ID; envio e confirmação de RETIRE_CONNECTION_ID; impressão digital do token de reinicialização sem estado associado; primeiro e último caminho; negociação de comprimento zero; quantidade não utilizada em cada direção; demanda de migração ou sondagem; resultado de roteamento no backend; e ressalvas de privacidade. As impressões digitais evitam expor valores brutos.

Um CID isolado comprova pouco. Estado criptográfico associa o pacote à conexão; inventário e caminho demonstram capacidade de migração. O valor não autentica identidade humana ou de aplicação.