[lacnog] Hijack de prefixo em IRR
Carlos M. Martinez
carlosm3011 en gmail.com
Mie Sep 11 10:01:44 -03 2019
Hola,
Creo que lo que comenta Arturo es clave. Un IRR que no verifique la
autoridad de crear objetos está condenado a, mas tarde o mas temprano,
contener información como mínimo de mala calidad cuando no
directamente maliciosa.
El IRR de RIPE por ejemplo permitió durante muchos años la creación
de objetos sin verificación, hasta que ellos mismos definieron que no
podían continuar ofreciendo esa posibilidad.
Sobre este último punto les recomiendo leer la justificación de este
cambio:
https://labs.ripe.net/Members/denis/out-of-region-route-6-and-aut-num-objects-in-the-ripe-database
LACNIC emitió un breve comunicado en su momento llamando la atención
sobre este cambio:
https://www.lacnic.net/3100/1/lacnic/cambio-de-politica-de-ripe-sobre-su-registro-de-rutas
El desarrollo que estamos llevando adelante en LACNIC consiste a grosso
modo en tomar la información que ya tenemos de RPKI y exportarla de
forma compatible para que sea consumida y replicada por otros IRRs
ademas del nuestro. Cuando vean “origin: lacnic” en un route-object
podrán estar seguros que ese route object esta respaldado por la base
de datos de registro.
S2
Carlos
On 11 Sep 2019, at 6:16, Arturo Servin wrote:
> Creo que esto demuestra que es importante que el IRR sea operador por
> la
> entidad que pueda "asegurar" la "autoridad" sobre un prefijo (entre
> comillas porque no pude encontrar un termino mejor.)
>
> RADB (o cualquier otro IRR) no tiene forma de validar la relación
> "prefijo
> - autoridad" y por eso existen estos problemas.
>
> En el momento que RPKI además del origen pueda atestar quien puede
> anunciar
> un prefijo y quizás otras semánticas, estaremos cerca de olvidar el
> uso de
> IRR. Por ahora no nos queda mucho más que tratar de identificar
> anomalias y
> ver como las evitamos.
>
> Saludos
> as
>
>
>
>
> On Wed, Sep 11, 2019 at 12:44 AM Rubens Kuhl <rubensk en gmail.com>
> wrote:
>
>>
>> O que eu achei curioso é que eu imaginava que só os upstreams
>> estariam
>> nessa shame-list de proxy, mas o maior deles parece ser um caso de
>> peering.
>>
>> Algo a notar no caso de upstreams é que eles tinham a opção de
>> cadastrar o
>> AS do cliente sob sua administração, mas cadastram só os blocos do
>> do
>> cliente.
>> Isso é um problema self-inflicted, e o ponto é como a comunidade
>> pode
>> amplificar essa dor para mudar esse comportamento.
>>
>>
>> Rubens
>>
>>
>>
>>
>> On Tue, Sep 10, 2019 at 1:37 PM Douglas Fischer
>> <fischerdouglas en gmail.com>
>> wrote:
>>
>>> TL-DR;
>>> ------
>>> - Vários ASNs registrando em IRRs prefixos de seus clientes como se
>>> fosse
>>> de seus ASNs.
>>> - Principalmente no RADB.
>>> - Está gerando sujeira nas bases de IRR.
>>> - Prefix-lists geradas automaticamente estão ficando muito longas,
>>> consumindo recurso do routers.
>>> - Impossibilita a validação de AS-Path.
>>>
>>> Fizemos uma consulta nos IRR dos prefixos delegados pelo NIC.BR que
>>> estavam registrados para outros ASNs.
>>> Agrupamos esses prefixos pelo campo maintainer e contamos a
>>> quantidade.
>>> Segue a lista dos mais significativos:
>>> Quantidade - Maintainer
>>> 2686 - MAINT-AS8966
>>> 865 - MAINT-AS18678
>>> 604 - MAINT-AS28283
>>> 494 - MAINT-AS28329
>>> 453 - MAINT-AS20473
>>>
>>> Este é o Link para a planilha com as informações.
>>>
>>> https://drive.google.com/file/d/1KFUfptAnZsAmbSVvVFyHK8bPH7yrOOhr/view?usp=sharing
>>> Lá consta uma planilha dinâmica, e também planilhas com o
>>> detalhado dos 5
>>> Mantainers com mais registro errados.
>>>
>>>
>>> Contando a historinha do problema
>>> -----------------------------------
>>> Há cerca de uns 4 meses, um amigo identificou que algumas empresas
>>> brasileiras estavam fazendo registros ERRADOS nos IRRs.
>>> Ele me passou a informação e eu fiquei bastante triste com o que
>>> vi.
>>>
>>> O procedimento deles era:
>>> - Listar todos os prefixos do cone de AS do cliente deles
>>> - Registrar como sendo de seu próprio ASN.
>>>
>>> Eu pessoalmente entrei em contato por telefone com algumas dessas
>>> empresas, e questionei o porque de eles fazerem isso.
>>>
>>> A resposta deles foi:
>>> "Muitos desses prefixos já estão registrados como proxyed por
>>> outros
>>> ASNs, e quando tentamos registrar esses prefixos, não
>>> conseguimos... Então
>>> registramos como nossos."
>>> - Eu expliquei a eles porque fazer esse registro como seu próprio
>>> ASN
>>> era errado, que era uma solução grosseira e de força bruta.
>>> - Mencionei que dependendo de como as empresas consultem as bases
>>> de IRR
>>> isso iria fazer com que os as prefix-Lists geradas automaticamente
>>> ficassem
>>> com entradas duplicadas, muito longas, aumentando os recursos de
>>> processamento dos routers para processar as mensagens de anúncio de
>>> rotas.
>>> - E expliquei também que isso iria prejudicar os próximos passos
>>> de
>>> segurança de roteamento, que é a validação de caminho(além da
>>> de origem).
>>>
>>> Felizmente por algumas empresas essa informação foi muito bem
>>> recebida.
>>> Inclusive desenvolvi relação de amizade por conta disso com um
>>> técnico
>>> dessas empresas.
>>> Tive a oportunidade de sugerir que no script de automação deles
>>> incluíssem o teste:
>>> (Se prefixo já existe registrado, usa registro atual.
>>> Se prefixo não existe registrado, cria registro como
>>> proxyed.)
>>>
>>> Infelizmente, algumas poucas empresas encararam a crítica
>>> negativamente.
>>> - Alguns me atenderam, fizeram mil elogios por telefone, se
>>> comprometeram
>>> a corrigir, e não fizeram nada.
>>> - Alguns se sentiram ofendidos com a crítica(se sentiram ofendidos,
>>> e me
>>> ofenderam).
>>> - Alguns nem se deram ao trabalho de responder.
>>>
>>>
>>> O problema só está aumentando!
>>> ------------------------------
>>> Observando a lista dos TOP-5, podemos ver que o MAINT-AS8966 - Emix
>>> -
>>> Emirates Telecommunications - está no topo da lista, com mais do
>>> que 3
>>> vezes mais prefixos errados que o segundo colocado.
>>>
>>> Bom, eu confesso que não entendi direito qual é o objetivo desses
>>> registros...
>>> Mas a grande maioria(talvez até a totalidade) dos prefixos estão
>>> com a
>>> "descr: ChinaTel via EMIX".
>>>
>>> Outra coisa que só aumentou as minhas dúvidas é que existem casos
>>> em que
>>> o MAINT-AS8966 registrou um prefixos para vários Origin.
>>> Como é o caso do prefixo 45.70.72.0/22, que está registrado pela
>>> EMIX
>>> para AS266319, AS52965, AS53144.
>>>
>>> https://www.radb.net/query?advanced_query=&keywords=45.70.72.0%2F22&-T+option=&ip_option=&-i+option=
>>>
>>> Segue uma lista dos Prefixos Brasileiros registrados pelo
>>> MAINT-AS8966.
>>> Quantidade AS-Origin IRR
>>> 773 AS61832 RADB
>>> 475 AS53144 RADB
>>> 450 AS52965 RADB
>>> 313 AS52551 RADB
>>> 154 AS52720 RADB
>>>
>>> Alguém conseguiu entender a lógica disso?
>>> Isso está correto?
>>> Se não está correto, quem deve ser acionado para corrigir?
>>>
>>> Porque estou cutucando isso agora?
>>> ----------------------------------
>>> O Google, em seus GGCs e PNIs, começou a fazer filtrar prefixos
>>> baseado
>>> em registros de IRR.
>>> Isso foi informado em maio [1][2] deste ano no Lacnic 31 pelo Sr.
>>> Arturo.
>>> E os triangulozinhos de alerta nos prefixos mostrados em
>>> https://peering.google.com/ estão gerando um alvoroço entre os
>>> ISPs.
>>> E eu estou feliz por isso!
>>> Depois de 20 anos de RPSL, os ASNs estão se preocupando em
>>> cadastrar seus
>>> prefixos corretamente nos IRRs.
>>>
>>> Eu acredito que o medo de ficar sem acesso ao ASN do Google é que
>>> está
>>> desencadeando essas ações um pouco desesperadas...
>>>
>>> P.S.1: Tenham calma!
>>> Segundo informações do próprio Google, por enquanto esses
>>> prefixos estão
>>> apenas sendo tageados.
>>> Apenas no futuro, depois de ter uma melhor referência de qual o
>>> tamanho
>>> do dragão com que terão que lutar, é que decidirão como esses
>>> prefixos
>>> serão descartados.
>>>
>>> P.S.2: Reitero meu agradecimento ao Google por isso!
>>> E aproveito para provocar Facebook, Cloudflare, Netflix, e até o
>>> ICCAN, a
>>> fazerem o mesmo.
>>>
>>> [1]
>>> https://www.lacnic.net/innovaportal/file/3635/1/26-route-filtering-at-the-edge-as15169.pdf
>>> [2] https://youtu.be/OT9at07N7qM
>>>
>>> --
>>> 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
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20190911/5fb5612f/attachment-0001.html>
Más información sobre la lista de distribución LACNOG