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

Sexta Fevereiro 14 22:22:59 -03 2020

Sim meu caro!

E se o teu downstream te enviar 8.8.8.8/32 como BlackHole? Você aceita?

E você testa isso como?

Em sex, 14 de fev de 2020 22:02, Bruno DataFibra Telecom <
bruno em datafibra.com.br> escreveu:

> Boa noite a todos
>
>
>
> O fish kkkk
>
> Para usar blackhole  você vai ter que receber o /32 via community  e não
> realizar a validação do RPKI ou se quiser validar  basta não descartar o
> invalido ou desconhecido
>
> Hoje eu faço assim
>
> Cliente que quer me anunciar um /32 na minha blackhole ele me anunciar com
> uma community   ai no IN do bgp eu não valido  o RPKI simplesmente pego o
> que recebo na community e mando pra blackhole
>
>
>
>
>
>
>
> *Atenciosamente,*
>
>
> [image: logo-n]
>
> *Bruno Benatto Adacheski*
> CIO Diretor TI
> Rua Professor Amálio Pinheiro , 20 – Guarapuava/PR - 85015-440
> http://www.datafibra.com.br
> (42) 3036-6151 - (42) 3622-8199
>
>
>
>
>
> *De:* bpf <bpf-bounces em listas.brasilpeeringforum.org> *Em nome de *Douglas
> Fischer
> *Enviada em:* sexta-feira, 14 de fevereiro de 2020 21:45
> *Para:* Latin America and Caribbean Region Network Operators Group <
> lacnog em lacnic.net>; Grupo de Trabalho de Engenharia e Operacao de Redes <
> gter em eng.registro.br>; bpf em listas.brasilpeeringforum.org; Renato Ornelas
> (Open X) <renato em openx.com.br>
> *Assunto:* Re: [BPF] [lacnog] Prefixos de Black Hole - Validação de
> Origem - Should i Break RPKI?
>
>
>
> Olá Bernardo!
>
> Grato pela resposta.
>
>
>
> Considerando os momentos de desespero que se vive em uma situação de
> ataques avançados, e a velocidade necessária para ação de resposta para
> isso (Ex.: Um carpet bomb com variação de 5 minutos), a ideia de esperar a
> propagação de um novo ROA de um /32 ou /128 acaba sendo descartada...
>
>
>
> Sim, estou ciente da existência de somente 3 possíveis respostas:
> 4300:0:0 Valid - Unknow 4300:0:1 - Invalid 4300:0:2.
>
> A minha ideia nesse comentário foi ventilar uma proposição de revisão do
> protocolo, onde seria informado também a motivação de se ter classificado
> como Invalid determinada rota.
>
>   Exemplos: - Validade expirada,
>
>             - ASN de Origem divergente,
>
>             - Mascara muito longa,
>
>             - Mascara muito curta.
>
> Sim, sei que é uma ideia ousada... E já coloquei ela de lado.
>
> Mas tenho certeza que assim como eu, outros possam estar também
> preocupados em como fazer uma filtragens de prefixos de BlackHole com
> responsabilidade e segurança.
>
> E essa talvez teria sido uma solução viável.
>
>
>
>
> Com relação a se utilizar a base de prefixos de IRRs está perto do
> inconcebível!
>
> No último IX-Fórum em São Paulo eu e o @Renato Ornelas (Open X)
> <renato em openx.com.br> fizemos uma apresentação[1] sobre quão suja e
> reduntante(no sentido RUIM da palavra) estão essas bases de IRR públicas de
> prefixos.
> Foram analisados somente os prefixos delegados pelo NIC.BR.
>
> O Renato mantém um script fazendo essa mesma análise e gerando um CSV
> diáriamente[2] do resumo da análise.
> É REVOLTANTE e ENTRISTECEDOR ver as quantidade de sujeira e bagunça que
> empresas como as listadas abaixo estão fazendo com as bases de IRR:
>  - EMIX-AS8966(by China Telecom)
>
>  - NEUSTAR-AS7786
>
>  - INTERNEXA-AS18678
>
>  - NEXUSGUARD-AS45474
>
>  - G8-AS28329
>
> [1] https://youtu.be/riax2Yxhhpo
>
> [2] https://irr.openx.com.br/csv/ox-irr-check-latest.csv
>
> [3]
> https://docs.google.com/spreadsheets/d/1XxUI2_JcKgkg5CniRi1E3ieEu9HgRJCfYfaH3hTIaHg/edit?usp=sharing
>
>
>
>
>
>
>
> Como vou validar origem de prefixos de BlackHole?
>
> -------------------------------------------------
>
> Estou decidido a usar as ROA do RPKI como base de validação.
>
>
>
> Ainda não temos certeza de como vamos proceder... Mas já achei um outro
> maluco para trabalharmos juntos.
>
> O Mais provável que desenvolvamos alguma ferramenta(conjunto de scripts)
> que usará um RTR client para ler algum Validador de RPKI, e injetar isso de
> alguma forma numa Engine de IRR (provável IRRd4).
>
>
>
> A princípio o objetivo é que cada um tenha sua própria base RPKI-to-IRR
> privada, considerando que essa ferramenta(Scripts) será OpenSource.
>
> Mas a ideia de criar um repositório público disso não está descartada.
>
>
>
> Em sex., 14 de fev. de 2020 às 09:44, Bernardo Soares <
> bsoares.it em gmail.com> escreveu:
>
> Douglas, bom dia.
>
>
>
> Um prefixo pode ter apenas 3 estados de validacao:
>
>
>
> Invalid: Anunciado por outro AS, ou um prefixo mais especifico do que o
> permitido.
>
> Valid: Anuncio valido
>
> Unknown: Anuncio nao esta coberto por um ROA valido
>
>
>
> Caso seu cliente tenha registrado o ROA para o bloco 200.3.12.0/22-24,
> qualquer /32 anunciado sera INVALIDO (como voce mesmo disse).
>
> Neste caso, *acredito* que somente duas alternativas sao possiveis:
>
>
>
> - efetuar uma tratativa deste especifico + community, validacao IRR, etc
> (o que pode nao ser a melhor forma, pelos motivos que foram mencionados)
>
> - solicitar ao cliente o registro de um ROA para cobrir estes especificos.
> Seja com max-length 32/128 em um ROA existente ou criar um ROA para cada
> /32 ou /128.
>
>
>
> Neste segundo metodo, a validacao vai se aplicar normalmente e os prefixos
> serao validos do ponto de vista de BOV.
>
>
>
> Att,
>
>
> *Bernardo*
>
>
>
>
>
> On Thu, Feb 13, 2020 at 11:44 PM Tomas Lynch <tomas.lynch em gmail.com>
> wrote:
>
> Entonces el script deberia ser:
>
>
>
> if /32 then
>
>     prefix = search_less_specific(/32)
>
>     if asn(prefix) == asn(/32) then
>
>         if validate(prefix) then
>
>             propagate(/32)
>
>         else call_the_fbi()
>
>
>
> Dime si sigo sin comprender!! Soy un novato con RPKI!
>
>
>
> On Thu, Feb 13, 2020 at 6:50 PM Douglas Fischer <fischerdouglas em gmail.com>
> wrote:
>
> Olá Tomas.
> Antes de mais nada, obrigado pela resposta!
>
> Bem, eu acho que na verdade fui eu que não consegui me expressar
> adequadamente.
> Então vou tentar com exemplos práticos.
>
> - Imagine que o Lacnic é meu cliente trânsito(😎)...
>
> - E que por algum motivo, algum de meus Peers ou outros Downstreams esteja
> originando um ataque volumétrico para o www.lacnic.net [200.3.14.184].
> - E depois de já terem esgotado as outras possibilidades com scrubing ou
> FlowSpec eles resolvam meter um BlackHole 200.3.14.184/32 na sessão com
> meu ISP.
> - Eu quero ser o tipo de cara que faz o trabalho de casa corretamente.
>
> - A primeira coisa vou fazer é verificar se o prefixo que estou recebendo
> passa nas validações
>
> A máscara estará em /32 Então -> OK
>
> E e o ASN de Origem, como eu valido?
>
>   As bases de IRRs estão VERGONHOSAMENTE sujas. -> Não dá para confiar!
>
>
>
>   Qual a MELHOR base de dados para validação de Origem? -> RPKI!
>
>   Só que se eu tentar mandar o prefixo 200.3.14.184/32 para validar
>
>   contra a ROA do LACNIC[1], vou receber a resposta INVALID.
>
>   Apesar de 200.3.14.184/32 estar contido em 200.3.12.0/22-24,
>
>   a resposta será somente "INVALID".
>
>
>
>   Se existisse uma esposta complementar do estilo
>
>   "INVALID BY MASK", eu poderia considerar que:
>
>   IF Black-Hole AND /32 AND "INVALID BY MASK" -> Accept
>
>
>
>
>
>
>
> Estou considerando criar uma base de IRR privada, e injetar nela todas as
> ROAs de todos os RIRs.
>
> Mas ainda estou amadurecendo a ideia.
>
>
>
>
>
>
>
>
>
> [1] rsync://
> repository.lacnic.net/rpki/lacnic/622c0c28-cc7d-421d-b45b-9ac2b7ced209/626e2d6316910390610ef5e3a9058a3b17a1b0b7.roa
>
>
>
> Em qui., 13 de fev. de 2020 às 11:53, Tomas Lynch <tomas.lynch em gmail.com>
> escreveu:
>
> Douglas,
>
>
>
> Puede ser que no entienda bien el problema pero ¿por qué no agregar
> "orlonger" o similar en los prefix-list? Si bien el ROA no tendrá nada
> mayor a /24, tu puedes agregar el keyword indicado y aceptar los
> (/32|/128). Incluso podrías hacer algo como por ejemplo (Juniper style):
>
>
>
> from {
>
>     route-filter 192.0.2.0/24 exact
>
>     route-filter 192.0.2.0/24 prefix-length-range /32-/32
>
>     }
>
> then { accept }
>
>
>
> ¿Es esto lo que buscas?
>
>
>
> Tomas
>
>
>
> On Wed, Feb 12, 2020 at 5:32 PM Douglas Fischer <fischerdouglas em gmail.com>
> wrote:
>
> Como?
>
> Vou tirar as informações de onde?
>
>
>
> A ideia de uma base estática de prefixos aceitos está proibida dentro da
> empresa!
>
> Nada que não seja dinâmico e alterável pelo próprio cliente.
>
>
>
>
>
> A base do NRO não contempla todas as possíveis origens válidas.
>
>
>
> A Base do RPKi seria perfeita para validar origem(a mais segura de todas),
> mas quebra a análise por causa da máscara muito longa.
>
>
>
>
>
> Em qua, 12 de fev de 2020 16:48, Luis Balbinot <luis em luisbalbinot.com>
> escreveu:
>
> Então pensei em "Quebrar um pouco" o protocolo RPKI.
>
>
>
> Talvez o melhor seja tu quebrar um pouco teu script e tratar exceções nele.
>
>
>
> Luis
>
> _______________________________________________
> LACNOG mailing list
> LACNOG em lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
> _______________________________________________
> LACNOG mailing list
> LACNOG em lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
> _______________________________________________
> LACNOG mailing list
> LACNOG em lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
>
>
> --
>
> Douglas Fernando Fischer
> Engº de Controle e Automação
>
> _______________________________________________
> LACNOG mailing list
> LACNOG em lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
> _______________________________________________
> LACNOG mailing list
> LACNOG em lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
> _______________________________________________
> LACNOG mailing list
> LACNOG em lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
>
>
> --
>
> 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/20200214/9ca2edc9/attachment-0001.html>