Resumo

  • Connection ID é um identificador de roteamento e associação escolhido pelo destino. Uma conexão possui vários, permitindo encontrar o mesmo estado depois que IP ou porta UDP mudam.
  • O identificador conhecido não valida um novo caminho. PATH_CHALLENGE e PATH_RESPONSE usam dados imprevisíveis, e o limite antiamplificação restringe o envio antes da resposta.
  • Fluxos podem continuar, mas medições de capacidade ficam na rota anterior. Novos IDs reduzem correlação entre redes, e Stateless Reset só cabe quando o receptor perdeu o estado da conexão.

O endereço terminou antes da conversa

Uma mudança de interface altera o endereço. Um NAT pode atribuir outra porta externa. Mesmo assim, cliente e servidor ainda mantêm chaves, streams, reconhecimentos e dados pendentes que pertencem ao mesmo trabalho.

Recomeçar tudo daria ao endereço de rede poder para destruir esse estado. RFC 8999 define uma propriedade invariável entre versões do QUIC: o Connection ID é um campo opaco usado para encaminhar o pacote à instância certa e, dentro dela, à conexão correta, apesar de mudanças em UDP, IP ou abaixo.

RFC 9000 não entrega uma etiqueta eterna. Cada conexão tem um conjunto de IDs, e cada lado escolhe os valores que o par usa para enviar tráfego em sua direção. O receptor emite a referência que faz o pacote voltar ao seu estado.

Uma reserva que pode girar

Cabeçalhos longos carregam identificadores de origem e destino durante o estabelecimento. Depois, NEW_CONNECTION_ID fornece valores e RETIRE_CONNECTION_ID tira os antigos de uso. Números de sequência coordenam a troca e active_connection_id_limit limita o conjunto ativo.

Vários IDs também evitam uma marca estável. Valores da mesma conexão não podem expor informação que permita a um observador externo correlacioná-los, e um valor não pode ser emitido duas vezes naquela conexão.

Comprimento zero é possível quando IP e porta bastam para o roteamento local. A economia fica frágil com migração, rebinding NAT e reutilização de porta. Quem escolhe zero no handshake não consegue depois fornecer a reserva normal de novos IDs. A obrigação de distinguir conexões apenas mudou de lugar.

Os primeiros valores são confirmados pelos parâmetros de transporte dentro do handshake criptográfico. RFC 9001 define a integração TLS 1.3 e a proteção de pacotes. Um invasor não pode injetar seu ID em uma conexão que termina com sucesso, mas o campo isolado não vira senha, certificado ou identidade de pessoa.

Preservar a conexão não aprova a rota

Migração ativa espera a confirmação do handshake. Um novo endereço também pode surgir sem intenção, quando o NAT muda sua associação. Se o endereço do par ainda não foi validado, o extremo precisa testá-lo.

PATH_CHALLENGE leva dados imprevisíveis, e o par os devolve em PATH_RESPONSE no caminho em que recebeu o desafio. A resposta prova somente que a mensagem enviada àquele par IP-porta chegou a uma entidade capaz de responder. Não demonstra propriedade jurídica do endereço, boa intenção, melhor rota nem disponibilidade futura.

Cada direção constrói sua própria evidência; um ACK comum não tem imprevisibilidade suficiente. O mecanismo tampouco é uma solução geral de travessia NAT.

Antes da validação, a regra antiamplificação limita dados para a nova origem. Assim, um endereço forjado não transforma o servidor em amplificador contra outra pessoa. Se o novo caminho falha e existe uma rota validada, o QUIC volta a ela sem destruir a conexão inteira.

O fluxo muda de rota, a capacidade não viaja

Largura de banda, atraso, perda e ECN podem ser outros. Depois de confirmar a nova origem, RFC 9000 normalmente reinicia o controle de congestionamento e a estimativa RTT. Tráfego da rota antiga não serve de amostra para a nova.

Uma troca somente de porta, comum no rebinding NAT, pode conservar esse estado com cautela. Se o trajeto também mudou, a herança pode levar a envio agressivo. Continuidade criptográfica não transforma medição local em verdade portátil.

Mobilidade sem uma etiqueta de rastreamento

Usar o mesmo ID no Wi-Fi e na rede móvel permitiria ligar as duas atividades. Por isso um extremo não reutiliza um Connection ID ao enviar de mais de um endereço local ou para mais de um destino.

Trocar o valor retira a correlação direta e a proteção de cabeçalho esconde números de pacote. Tempo, tamanho e infraestrutura cooperante continuam oferecendo pistas. O objetivo é reduzir vínculo, não garantir anonimato.

A reserva vazia impede sondagem e resposta no caminho novo. Os identificadores necessários à privacidade e à migração precisam existir antes da mudança.

A última resposta de quem perdeu a memória

Depois de uma falha, o servidor pode receber tráfego de uma conexão que já não consegue reconstruir. Sem estado não há CONNECTION_CLOSE normal. Stateless Reset é o recurso final.

Um token imprevisível de 16 bytes fica associado a um ID e é entregue em contexto protegido. Um datagrama terminado no token correto faz o par abandonar a conexão; aposentar o ID invalida o token.

O próprio pacote de reset não possui proteção criptográfica e imita um pacote de cabeçalho curto. Se o segredo vaza, terceiros ganham poder de término. Reutilizar ID ou token é perigoso. Stateless Reset não relata erro de conexão ativa; encerra o estado que só o outro lado ainda recorda.

Fontes e limites

O conjunto fechado reúne RFC 8999, RFC 9000 e RFC 9001. Não mede adoção, comportamento de fornecedor, frequência de migração ou ganho de desempenho. ID não é identidade global, e validação de caminho não é prova de propriedade do endereço.