[BPF] Prefixos de Black Hole - Validação de Origem - Should i Break RPKI?

[Douglas Fischer]

Como validar se o ASN de Origem de rotas de Black Hole é mesmo autorizado a
originar aquelas rotas?

Atualmente estamos fazendo essa validação através de prefix-lists que monto
para cada ASN em nosso cone.
Eu alimento essas prefix-lists com base nos arquivos "delegated latest" de
cada RIR...

Isso funciona razoavelmente bem em quase todos os casos.
Mas isso gera alguns problemas, pois nem todo Bloco IPv4 ou IPv6 está
necessariamente vinculado a um ASN, ou existem casos em que um Owner de
Prefixo pode Delegar aquele prefixo para outro ASN por algum motivo (Comum
em casos de CDN ou Mitigação).

Já peguei um caso de um Bloco /22 em que havia uma ROA RPKI autorizando
/22-24 para o ASN de uma outra empresa...
Mas meu filtro de BlackHole rejeitou os anuncios /32 porque nas minhas
prefix list (geradas por script com base no NRO), não estava prevista a
autorização para aquele ASN.

Então pensei em "Quebrar um pouco" o protocolo RPKI.
P.S.: O @Job Snijders <job em ntt.net> já me disse que não deveria fazer isso
nessa thread da LACNOG:
https://mail.lacnic.net/pipermail/lacnog/2019-May/007057.html

Porém não consigo achar nenhuma outra solução para eu conseguir entregar o
serviço de BlackHole a todos os meus clientes e ainda assim ter certeza que
não estou aceitando rotas /32 ou /128 que não façam parte de redes que os
ASNs estejam autorizados a anunciar.

Então pensei em:
 -> SOMENTE PARA PREFIXOS /32(v4) e /128(v6) COM COMMUNITY DE BLACKHOLE,
ignorar a máscara na validação de RPKI.

Isso me garantiria que aquele /32 ou /128 está contido em uma rede de
alguém que realmente tem autorização para anunciá-la.


Ainda não entrei na parte de como fazer isso...
 - O ideal é que o algorítimo de verificação do RPKI do próprio Router
entregassem uma resposta específica para:
   "4 Inválido, mas tem uma ROA com um rota de máscara menor que contém
esse prefixo"

 - Outra possibilidade é olhar para o código do Validador, e ver o que pode
ser ajustado por lá para fazer com que haja uma resposta correta.

 - E a última(que é a que eu acho que vou fazer) pegar todas as ROAs
válidas, e injetar elas numa base privada de IRR, e fazer consulta lá.
Assim o tamanho máximo da máscara do prefixo será ignorado.
   E continuar a gerar prefix-list através de Scripts, mas agora a partir
de um IRR modificado.


-- 
Douglas Fernando Fischer
Engº de Controle e Automação
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://listas.brasilpeeringforum.org/pipermail/bpf/attachments/20200212/6370d732/attachment.html>