Um teste de retorno DTLS não é um comprovante de migração

Resumo

• O RFC 9853 acrescenta ao DTLS 1.2 e 1.3 uma verificação de retorno autenticada e cifrada. Uma resposta vinculada ao desafio pode sustentar a atualização do endereço associado ao CID; o vencimento mantém a associação anterior.
• Esse resultado não é identidade, autorização ou migração concluída. Um comprovante auditável separa gatilho, ameaça, orçamento de sondagem, resposta, mudança de contexto, aceitação da aplicação, observação e reversão.

O primeiro registro vindo do endereço B é válido. Seu CID aponta para uma associação criada quando o par estava em A; epoch e número de sequência são aceitáveis; a decriptação autenticada funciona. Ainda assim, nada disso decide se a próxima resposta da aplicação deve ser enviada a B.

O CID impede que endereço e porta UDP sejam o nome permanente da conexão. Dispositivos móveis, redes com NAT e sistemas restritos ganham continuidade após uma troca de endereço. O mesmo recurso abre uma superfície de redirecionamento: uma cópia de registro autêntico pode chegar primeiro por outra rota; uma origem alterada pode induzir um servidor a amplificar tráfego contra uma vítima.

O RFC 9146 já exigia, antes de trocar o endereço, verificação criptográfica do registro, novidade em epoch e sequência e uma estratégia para confirmar que o novo endereço recebe e processa registros DTLS. A estratégia concreta ficou em aberto.

Publicado no IETF Standards Track em março de 2026, o RFC 9853 preenche essa lacuna para DTLS 1.2 e 1.3 e atualiza o RFC 9146 e o RFC 9147. O Return Routability Check, RRC, testa o caminho antes que o vínculo local entre CID e endereço seja alterado.

A ordem é parte do controle. O CID encontra estado; a camada de registro autentica o datagrama; o RRC testa um caminho; só depois o receptor modifica seu vínculo. Cada predicado é necessário, nenhum assume a autoridade do próximo.

Capacidade negociada antes da mudança

O RRC é negociado pela extensão vazia rrc, código 61. O cliente também precisa oferecer connection_id; o servidor aceita no ServerHello. As partes não podem usar o subprotocolo sem a troca bem-sucedida da extensão.

Mesmo negociado, RRC não é a única escolha. O receptor deveria usá-lo ao ver um registro CID de novo endereço, salvo se puder acionar um mecanismo da aplicação. O Echo do CoAP, no RFC 9175, pode exigir frescor ou alcance conforme recurso, método e política. Um caminho que funciona e uma operação que ainda deve ocorrer são fatos diferentes.

O content type 27, return_routability_check, carrega path_challenge, path_response e path_drop. Cada mensagem possui cookie de oito octetos, 64 bits de entropia, autenticado e cifrado sob o contexto DTLS atual.

O cookie não identifica o dono do endereço nem concede permissão. Ele vincula uma resposta a um desafio específico. Um log que conserva apenas “RRC passou” perde conexão, tentativa, destino, início e expiração da evidência.

O limite vem antes da confiança

Quando detecta a mudança, o receptor suspende dados pendentes da aplicação ou limita toda saída ao endereço não validado pelo teto antiamplificação: três vezes os bytes recebidos dali, descontados os registros descartados.

Esse teto é orçamento de exposição, não capacidade. Uma pequena entrada falsificada não deve liberar uma resposta grande. O desafio protegido é pequeno; a vítima sem o estado DTLS não consegue decriptá-lo e devolver a resposta associada, então o vínculo continua em A.

No procedimento básico, o iniciador envia um cookie imprevisível em path_challenge ao novo endereço e inicia T. O par verifica e repete o valor em path_response. Só uma resposta correspondente autoriza a atualização; o vencimento deixa o endereço inalterado.

Perdas admitem desafios extras, mas com disciplina: pacotes distintos, ritmo e dados aleatórios em todos. Sem exigência da aplicação, um por RTT até o teto é a referência. Para cada desafio válido, o par responde exatamente uma vez, sem atraso, ao endereço de origem. O processo não mede PMTU do caminho inverso.

O valor de T também precisa ser conhecido. Com RTT externo do caminho ativo, recomenda-se três RTT; sem informação, um segundo, salvo perfil próprio. O vencimento afirma ausência de evidência naquela janela, não desaparecimento permanente.

Perguntar primeiro ao caminho antigo

O método básico reduz amplificação, mas um atacante fora do caminho pode observar registros válidos e correr com cópias por uma rota mais rápida. Se a cópia chega antes, parece migração; validar apenas o novo caminho pode colocar o atacante no trajeto.

O método avançado testa primeiro o endereço anterior. path_response pelo caminho ainda preferido preserva o vínculo. path_drop informa que o caminho funciona, mas não é mais preferido, e conduz ao teste básico de B. O silêncio até T também conduz a esse teste; nunca produz migração automática.

Silêncio, abandono explícito e preferência confirmada ficam separados. A defesa é imperfeita. Uma rota adversária sempre mais rápida pode ser indistinguível de uma melhora legítima. Tráfego recente no caminho antigo e duplicatas podem orientar heurísticas locais, mas não ampliam o significado do cookie.

Rebindings aninhados também estão fora do algoritmo. Se o endereço muda de novo durante uma validação, a resposta desatualizada é descartada, a tentativa vence, o vínculo permanece e novos dados iniciam outro teste. Sem identidade de tentativa não se sabe qual candidato foi efetivamente validado.

Retorno não é identidade

RRC bem-sucedido mostra que uma parte usando o contexto DTLS atual recebeu um desafio protegido no caminho testado e devolveu o valor dentro da janela. Não prova propriedade jurídica do endereço, identidade humana ou do aparelho, autoridade de mudança, localização, permanência ou ausência de observação.

Também não decide pela aplicação. Uma operação CoAP pode precisar de frescor adicional; uma tarefa pendente pode ter vencido, uma solicitação pode não ser mais idempotente ou uma permissão pode ter mudado. Retomar bytes é continuidade de transporte. Preservar o sentido do trabalho é continuidade de aplicação.

O princípio de Lu Heng sobre especificação inicial mínima, decisão futura localizada e adoção voluntária mantém no plano comum apenas provas determinísticas de segurança e interoperabilidade. Ameaça, alternativa da aplicação, momento e efeito pertencem aos participantes que executam o código. O Policy Mirror aponta para a superfície real: a transição local que troca o endereço e libera saída, não o código IANA.

O que um indicador verde esconde

O RFC recomenda registrar falhas, várias respostas a um desafio e sondagens frequentes. Podem representar, respectivamente, falsificação ou retorno quebrado, corrida fora do caminho e instabilidade da conectividade.

DTLS 1.3 oculta o tipo do registro de observadores no caminho. Em DTLS 1.2, RRC fora de tls12_cid deixa o tipo visível a middleboxes; CID nas duas direções reduz interferência. DTLS 1.3 pode pedir novos CIDs para caminhos diferentes. DTLS 1.2 não os repõe durante a sessão e é inadequado para multihoming quando correlação é risco relevante.

Um atacante já no caminho ainda pode prejudicar a conexão ou redirecionar a prova ao par real. O registro TLS da IANA coordena tipo 27, extensão 61 e três mensagens iniciais; não certifica implementação, identidade, autoridade ou conclusão.

Fontes e limites

As fontes são RFC 9853 e sua página de estado e errata, RFC 9146, RFC 9147, RFC 9175, RFC 9000, o registro IANA e RFC 8126. Definem contratos técnicos, não adoção, desempenho, padrão de fornecedor, incidentes ou política de operador.

O registro separado de erratas do RFC 9853 preserva o histórico de correções conferido na data-limite da pesquisa.