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

Sexta Fevereiro 14 22:02:08 -03 2020

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,

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) <mailto: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 <http://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 <mailto: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 <http://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 <mailto: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 <http://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 <http://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 <http://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 <http://200.3.14.184/32>  estar contido em 200.3.12.0/22-24 <http://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 <mailto: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 <http://192.0.2.0/24>  exact

    route-filter 192.0.2.0/24 <http://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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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/1ed35340/attachment-0001.html>