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

Vie Feb 14 10:43:48 GMT+3 2020

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