Roteadores BGP de verdade, três validadores RPKI, uma CA e um registro simulado, tudo em contêineres. Uma história guiada mostra o que a validação de origem pega, o que escapa dela e o que o ASPA acrescenta.
Tudo é software de verdade, não simulação. Três observadores recebem os mesmos anúncios e objetos RPKI, cada um combinando um roteador e um validador do seu jeito, então dá para comparar três implementações em cada passo.
O roteiro é uma história só: três ataques, e qual verificação barra cada um. O AS64500 é multihomed e prefere o Provedor B; para o Provedor A, o backup, ele faz prepend duas vezes. Três observadores recebem o prefixo dele pelos dois provedores. As capturas abaixo são o painel em cada passo.
Os três observadores recebem 203.0.113.0/24 pelos dois provedores e escolhem o caminho mais curto, pelo Provedor B. Ninguém valida nada ainda: as peças do RPKI existem, mas nenhum roteador conversa com um validador.
O AS666 anuncia o prefixo da origem como se fosse dele. O caminho, 666, tem um salto contra dois e quatro, e nada mais distingue as rotas. Os links do atacante ficam laranja: os observadores estão usando a rota dele.
Sem validação, o BGP não tem como distinguir um sequestro da rota verdadeira.
A origem cria as suas ROAs no Krill, e os observadores implantam a validação de origem na sua primeira forma, segura: as rotas inválidas só são marcadas e rebaixadas. O sequestro fica Invalid com local_pref 10, e o caminho do Provedor B volta a ser o selecionado.
Implantar ROV exige três peças em qualquer roteador: uma sessão RTR, um teste em cada rota e uma ação sobre o resultado.
O AS666 agora anuncia 666 64500, escrevendo a origem verdadeira no fim do caminho. O ROV só confere o último AS, então diz Valid, e a rota forjada ganha o desempate com a do Provedor B.
A validação de origem não consegue distinguir dois caminhos quando a origem é a mesma.
A origem publica um objeto ASPA que lista só o Provedor A, e os observadores implantam a verificação ASPA. O caminho forjado fica Invalid: o salto 64500→666 nunca foi autorizado. Mas o caminho legítimo do Provedor B também fica, e os observadores recorrem ao backup.
Um objeto ASPA precisa listar todos os provedores. Esquecer um desvia o tráfego da própria origem.
Acrescentar o Provedor B ao objeto resolve: os dois caminhos legítimos voltam a ser Valid e o Provedor B é selecionado, enquanto o forjado continua rebaixado. A correção chega aos roteadores só por republicação e revalidação.
Um peer legítimo repassa ao Provedor A as rotas da origem que aprendeu no peering privado. Nada é forjado: 64501 64499 64500 é Valid para o ROV e Invalid para o ASPA, porque o 64499 não é um dos provedores da origem.
Num vazamento ninguém mente sobre a origem; o que está errado é por onde a rota passou. O ROV não enxerga, o ASPA sim.
As duas verificações passam de marcar para descartar, do jeito que um roteador de produção é configurado. As rotas forjada e vazada somem. Mas o caminho próprio do Provedor A continua ausente: o Provedor A segue anunciando o vazamento no lugar dele, e nenhuma política nos observadores muda isso.
Marcar só ajuda enquanto existe uma alternativa válida. É o descarte que protege a rede.
O peer corrige a sua política de exportação e o caminho próprio do Provedor A volta. Os observadores continuam totalmente implantados, com ROV e ASPA descartando.
| Ataque | AS_PATH | ROV | ASPA |
|---|---|---|---|
| Sequestro ingênuo | 666 | pega | nada a conferir |
| Caminho forjado | 666 64500 | enganado | pega |
| Vazamento de rota | 64501 64499 64500 | não enxerga | pega |
Pensado para cursos práticos de RPKI, e útil para quem quer estudar por conta própria.
Português, espanhol e inglês. Cada bloco de comandos diz onde roda e abre o terminal certo.
Alguns passos escondem a solução atrás de dicas e de um cronômetro; "Conferir meu laboratório" olha o estado real do lab.
Eles se marcam sozinhos quando o lab chega a cada passo, e qualquer comando de passo põe o lab de volta nos trilhos.
Crie a CA no Krill e faça os dois lados da delegação com o registro simulado.
Uma pasta work/ para escrever a sua configuração de ROV e ASPA e carregá-la nos roteadores.
Upstream × downstream (e onde BIRD e OpenBGPD discordam), maxLength, um olhar por dentro do RTR e o rpki-client servido pelo RTR.
git clone https://github.com/moreiras/rpki-selflab.git cd rpki-selflabou baixe o código-fonte na versão mais recente.
./scripts/lab.sh up
Cada versão também traz uma máquina virtual com tudo dentro (amd64 e arm64), com área de trabalho, navegador e terminal próprios. Detalhes em vm/README.pt.md.
O roteiro completo também pode ser lido no GitHub: guide/GUIDE.pt.md.