Resumo

  • A RFC 10078 separa dois fatos que costumam ser cobrados da tabela de encaminhamento: por onde um prefixo é alcançável e quais endereços de origem um cliente conectado pode usar.
  • uRPF estrito pode descartar tráfego legítimo em rotas assimétricas ou com prefixos ocultos. uRPF flexível tira o teste de interface, mas pode aceitar pacotes falsificados quando o prefixo aparece na tabela local.

Um cliente envia um pacote com um endereço que tem autorização para usar. O roteador consulta a base de informações de encaminhamento (FIB), vê o prefixo apontando para outra interface — ou ausente — e descarta o pacote. O roteador respondeu a uma pergunta real. Só escolheu a pergunta errada.

Esse é o problema da RFC 10078, publicada pela IETF em outubro de 2026 como documento informativo. O texto trata da validação de endereços de origem (SAV) dentro de um sistema autônomo, em interfaces externas voltadas a hosts ou redes de clientes que não são AS vizinhos. O cliente nem precisa ter ASN. Pode usar prefixos entregues pela operadora ou trazer seu próprio espaço de endereçamento.

A forma estrita do encaminhamento reverso unicast (uRPF) consulta a FIB para saber se existe uma rota que cubra o endereço de origem e se essa rota aponta para a interface por onde o pacote chegou. A regra é simples; os caminhos de uma rede nem sempre. Um cliente conectado a mais de um ponto pode enviar pelo Roteador 1 enquanto o sistema da operadora espera o retorno daquele prefixo pelo Roteador 2. uRPF estrito transforma a interface inesperada em motivo para rejeitar o pacote. No exemplo da RFC, tráfego legítimo do cliente é descartado.

A variante flexível elimina a comparação de interface: basta uma rota que cubra o endereço na FIB local. Ela recupera parte do tráfego assimétrico, mas abre outra porta. Um pacote falsificado pode passar se usar um prefixo que esteja na tabela. A configuração estrita confunde caminho de retorno com autorização; a flexível confunde alcance geral com autorização.

Prefixos ocultos deixam o remendo ainda mais difícil. Um host ou cliente pode originar tráfego legítimo usando um endereço que o protocolo de roteamento interno da operadora não conhece. A RFC cita Direct Server Return (DSR): a requisição chega a um ponto de serviço anycast e outro servidor de borda responde diretamente com o endereço do serviço como origem. O mesmo descompasso aparece quando um prefixo do cliente não é anunciado dentro da rede da operadora. Sem o prefixo na FIB, uRPF estrito e flexível podem descartar o pacote.

Uma lista de controle de acesso pode indicar os prefixos autorizados, mas alguém precisa detectar a mudança de autorização e atualizar a regra.

A RFC estabelece cinco propriedades para mecanismos futuros: validar com mais precisão; coletar e atualizar informações SAV automaticamente; permitir implantação gradual em parte das interfaces elegíveis; não prejudicar a convergência de rotas ou o fast reroute quando houver distribuição por protocolo; e usar informação autenticada ou confiável. O registro que falta é uma autorização de uso de origem que o roteador possa confiar e manter atualizada. A FIB descreve alcançabilidade. Transformá-la também no livro de permissões do cliente parece econômico até que os dois discordem.

A RFC 10078 não define esse registro, um protocolo para distribuí-lo ou uma solução pronta. Ela apresenta o problema e os requisitos. O teste operacional é direto: enviar tráfego legítimo por um caminho assimétrico e a partir de um prefixo oculto; depois, testar fontes falsificadas com prefixos presentes e ausentes da FIB. Anotar qual regra decidiu, quem forneceu a autorização, como as atualizações chegam à borda e o que ocorre quando a rota muda.

Fontes