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

[Douglas Fischer]

Adicionando a lista GTER...
(memória tá fraca)

Em qua., 12 de fev. de 2020 às 15:08, Douglas Fischer <
fischerdouglas at gmail.com> escreveu:

> 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 at 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
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação