Resumo
- O RPF estrito compara a interface de chegada com a que a melhor rota usaria para alcançar o endereço de origem. Quando elas divergem, até um pacote legítimo pode ser descartado, como mostra a RFC 3704.
- O RPF de caminho viável aceita alternativas conhecidas se forem propagadas de forma consistente; o RPF flexível tolera assimetria, mas abre mão de boa parte da evidência direcional.
O roteador julgou o caminho de volta
Uma rede com dois provedores envia um pacote pelo provedor B. O endereço de origem pertence a um prefixo que ela pode usar. Um roteador mais distante recebe o pacote pela interface de B, consulta sua tabela e encontra a melhor rota de volta para aquele prefixo via provedor A. Com RPF estrito, o pacote não passa. O teste não identificou o emissor: comparou a interface de entrada com a visão local do roteamento.
Publicada em março de 2004 como Best Current Practice 84, a RFC 3704 atualizou a RFC 2827, a recomendação anterior de filtragem de tráfego na entrada da rede. O objetivo de reduzir a falsificação de endereços permaneceu. A complicação era que redes multihomed e caminhos assimétricos fazem a rota efetivamente percorrida em um sentido diferir daquela que o roteador escolheria para voltar.
A RFC 3704 distingue métodos. Uma lista de acesso por interface compara a origem com os prefixos permitidos; é previsível, mas uma lista manual pode ficar defasada após mudanças de prefixo ou provedor. O RPF estrito automatiza o teste: consulta o endereço de origem na FIB e só aceita o pacote se ele chegou pela interface da melhor rota. É simples em uma borda simétrica, mas pode eliminar tráfego legítimo quando a rota é assimétrica, ausente ou rejeitada pela política do provedor.
Alternativas precisam chegar a todos
O RPF de caminho viável mantém rotas alternativas disponíveis para a verificação, em vez de considerar apenas a melhor rota da FIB. Em uma rede multihomed, isso pode impedir que um pacote legítimo seja descartado só porque outra rota está momentaneamente preferida.
Essa lista, porém, não contém automaticamente todos os caminhos possíveis. A RFC 3704 depende de anúncios consistentes chegarem a cada roteador que verifica os pacotes. Uma política ou route-map pode fazer um provedor conhecer o prefixo e outro não. Se o anúncio não atravessa um filtro, os pacotes também podem ser barrados. Assim, uma regra aparentemente local depende de decisões de roteamento entre domínios administrativos.
O RPF flexível pergunta apenas se existe alguma rota para a origem; não verifica se ela aponta para a interface de chegada. Com isso, tolera assimetria, mas pode aceitar um endereço falsificado que seja roteável. A rota padrão torna o critério ainda mais fraco se a implementação não a tratar à parte. Por isso, a RFC 3704 não recomenda esse uso como principal filtro entre cliente e provedor; ele pode ser útil para descartar origens não roteadas na rede upstream ou verificar se outra rede aplica algum filtro.
As outras alternativas mostram onde fica a coordenação: garantir que cada provedor conheça os prefixos do cliente, possivelmente com endereços independentes do provedor e BGP; encaminhar cada prefixo atribuído por um provedor somente a ele; ou gerar listas a partir de bases de clientes. Cada método distribui o trabalho entre redes, roteadores e operadores. Nenhum transforma estado de rota em prova de identidade.
A filtragem mais precisa ocorre perto do sistema de origem. Mais adiante, o roteador só consegue confirmar que o endereço pode pertencer a um prefixo alcançável. Vários níveis de filtro podem melhorar a rastreabilidade, mas não identificam um atacante nem comprovam implantação ampla. A RFC 8704, de 2020, atualizou a RFC 3704 com técnicas de RPF de caminho viável aprimorado. Isso mostra que o compromisso continuou em evolução, não que todos os operadores adotaram o método.
A pergunta prática não é qual modo vence sempre. É qual evidência ele usa: a melhor rota de retorno, um conjunto de rotas alternativas ou apenas a existência de qualquer rota. A resposta muda conforme a tabela e o ponto onde se verifica o pacote. A RFC 3704 tornou a completude das rotas uma responsabilidade operacional compartilhada.
Fontes
- RFC 3704: Ingress Filtering for Multihomed Networks
- Registro RFC 3704 — RFC Editor
- RFC 3704 — IETF Datatracker
- Histórico da RFC 3704 — IETF Datatracker
- RFC 2827: Network Ingress Filtering
- Registro RFC 2827 — RFC Editor
- RFC 8704: Enhanced Feasible-Path uRPF
- Registro RFC 8704 — RFC Editor
- RFC 2260: conectividade multihomed e multiprovedor
- RFC 8028: seleção do roteador de primeiro salto
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
