Resumo

  • Um PATH_RESPONSE correspondente mostra que quem recebeu um PATH_CHALLENGE imprevisível conseguiu devolver seus oito bytes.
  • Essa evidência não prova identidade criptográfica, pessoa, dispositivo, conta, aplicação, autorização, MTU nem disponibilidade futura do caminho.
  • O registro operacional deve separar retorno do caminho, autenticação, autorização, resultado do negócio e retenção.

O erro começa quando o operador vê um PATH_RESPONSE correspondente e o transforma em uma aprovação permanente. O RFC 9000 não dá esse significado ao evento. A validação de caminho verifica a alcançabilidade de um par por uma rota de rede. Ela é usada durante a migração de conexão e pode sondar um novo endereço local antes da migração, mas não foi desenhada para descobrir quem está do outro lado.

O endpoint envia PATH_CHALLENGE pelo caminho que pretende validar. Os dados precisam ter pelo menos 64 bits de entropia, na forma de um valor imprevisível de oito bytes. O receptor responde com PATH_RESPONSE contendo os mesmos dados. A resposta deve sair pelo caminho em que o desafio chegou. Já o iniciador aceita uma resposta correspondente que chegue por qualquer caminho de rede. A combinação é deliberada: o respondente demonstra que conseguiu devolver o valor pelo caminho de recebimento, enquanto o iniciador não fixa o caminho de chegada da resposta, evitando uma condição que poderia facilitar um ataque de migração.

A validação é bem-sucedida quando a PATH_RESPONSE recebida contém dados de um PATH_CHALLENGE anterior. Um ACK do pacote que carregou o desafio não basta, porque um par malicioso pode falsificá-lo. É possível enviar vários desafios para tolerar perdas, mas não se deve colocar vários no mesmo pacote. Outros pacotes ou quadros que cheguem pelo caminho candidato não substituem a resposta correspondente.

O objeto da validação é uma condição de endereço e caminho em determinado momento. Não é a identidade de uma pessoa, dispositivo, conta ou principal de aplicação. Também não prova identidade criptográfica, autorização, resultado de transação ou disponibilidade futura. Essas são fronteiras operacionais derivadas da condição estreita de sucesso do RFC 9000. Autenticação criptográfica, identidade da aplicação, autorização, resultado e política de retenção precisam permanecer em campos separados.

Validação de caminho também não é validação de MTU. Um desafio bem-sucedido em um datagrama menor que 1200 bytes pode validar o endereço ou caminho sem provar suporte à MTU necessária. Para verificar isso, é preciso um desafio expandido. Datagramas PATH_RESPONSE normalmente são expandidos para pelo menos 1200 bytes, sem ultrapassar o limite antiamplificação. O registro deve separar o resultado de validação do endereço do resultado de MTU e guardar o tamanho do datagrama e o estado antiamplificação.

A ausência de uma resposta não significa falha imediata. O RFC 9000 recomenda um temporizador baseado em três vezes o maior PTO entre o caminho atual e o novo caminho, permitindo vários PTOs para que uma única perda não decida o resultado. A validação falha quando o endpoint abandona a tentativa. Abandonar um caminho não encerra necessariamente a conexão quando outro caminho válido continua utilizável. A falha da sonda significa que aquele caminho candidato não pode ser usado por aquela conexão.

Uma mudança de endereço, incluindo NAT rebinding, exige validação do caminho, salvo quando o endereço já tiver sido validado. Isso não transforma a validação do QUIC em travessia de NAT: o RFC 9000 não fornece os mecanismos de sincronização necessários para uma travessia efetiva. Após a migração, capacidade e temporização podem ser diferentes. Por isso, o QUIC reinicia os estados de controle de congestionamento e RTT, em vez de tratar as medições anteriores como garantias.

O livro-caixa operacional deve registrar identificador de caminho limitado à conexão e resumo do desafio que preserve a privacidade; horários do desafio e da resposta; tupla local/remota testada; tamanho do datagrama; correspondência dos dados e caminho de chegada da resposta. Deve separar validação do endereço do par e validação de MTU, registrar o estado antiamplificação antes e depois, entradas de PTO, motivo do abandono e resultado do temporizador. Também deve identificar o gatilho de NAT rebinding ou migração, evidência de endereço previamente validado e caminhos alternativos utilizáveis.

Resumos protegidos e retenção limitada são recomendações de operação, não exigências do QUIC.

A separação em cinco dimensões continua necessária. TR-039 trata do orçamento antiamplificação antes da validação. TR-033 trata da evidência de retorno de DNS Cookie. TR-043 trata da integridade de Retry. TR-040 separa connection IDs de identidade. TR-061 trata da evidência de validação de endereço por NEW_TOKEN em conexões futuras. Nenhum desses temas deve ser confundido com o PATH_RESPONSE.