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

[Douglas Fischer]

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
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20200213/47a26d3f/attachment.html>