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

Douglas Fischer fischerdouglas en gmail.com
Vie Feb 14 21:45:04 GMT+3 2020 

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 en 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 en 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 en 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 en 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 en 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 en 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 en 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 en lacnic.net
>>>>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>>>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>>>>
>>>>> _______________________________________________
>>>>> LACNOG mailing list
>>>>> LACNOG en lacnic.net
>>>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>>>
>>>> _______________________________________________
>>>> LACNOG mailing list
>>>> LACNOG en 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 en lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>
> _______________________________________________
> LACNOG mailing list
> LACNOG en 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 ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20200214/3be726a3/attachment-0001.html>

Más información sobre la lista de distribución LACNOG