[GTER] Communities no IX.br

[Lucenildo Lins Aquino Júnior]

Caros,

A forma de implementação de uma funcionalidade de  blackhole pode ser
feita de diversas maneiras, seja fazer com uso de ASIC em switch ou até
mesmo drop out IXP. Como Moreiras mencionou, a escolha de implementação
deve ponderar desde o comportamento dos ativos no parque até o
comportamento dos participantes, seja no uso de hardware ou consumo de
transporte.

Gostaria de fazer uma adendo nessa discussão que é bem interessante. 

Na Europa temos uma diferença fundamental para implantação da
funcionalidade de blackhole over IXP, uma vez que o RIPE (RIR Registry
da região Européia), usa  uma base autoritativa de IRR alimentada desde
a atribuição do bloco. Digo, ao delegar um bloco para uma instituição, o
RIPE automaticamente cadastra no IRR do próprio RIPE e os ASN europeus
tem como Cultura de operação manter as informações sempre atualizadas.

Uma vez fazendo uso dessa informação confiável, seja o AMS-IX ou o
DE-CIX, usam essas informações para realizar filtros de prefixos na
entrada dos RSs, determinando assim quem pode anunciar um bloco X
qualquer. 

Na minha opinião a validação de prefixo tonar-se necessário por demais e
definir as permissões de anúncio é necessário para que um falso
blackhole não seja propagado. A política 5 visa aumentar o poder do ASN
para elaboração de filtro e controle na entrada das rotas, mas em contra
partida incrementa a segurança do peering via Router Server como um todo. 

Quero ressaltar ainda que a política 5 não visa filtrar bloco na
entrada, apenas informa ao ASN participante os blocos que encontramos
nas bases, o IX.br quer ser o mais transparente possivel e quer que o
operador do AS tome a decisão por si.

Grato,


Em 27/10/16 19:29, Rubens Kuhl escreveu:
> 2016-10-27 19:08 GMT-02:00 Antonio M. Moreiras <moreiras at nic.br>:
>
>> Em 27/10/16 17:30, Rubens Kuhl escreveu:
>>
>>>> O problema é que isto geraria uma inundação de ARP Request para todo
>> mundo.
>>> Você está assumindo que o ARP não esteja sendo controlado de outra
>> forma...
>>> ;-)
>>> Hoje o IX tem toda a informação necessária para manter ARP funcionando na
>>> matrix do IX sem nunca sequer os membros chegarem a receber requisições
>>> ARP... um ambiente L2 sob controle rígido permite soluções diferentes da
>>> operação usual de uma rede Ethernet.
>> O Rubens tem razão quanto aos ARP requests. Dá pra tratar isso. Por
>> exemplo, poderíamos bloquear os ARPs no core do IX, e criar um
>> 'respondedor' de ARPs em cada PIX, que conhece e responde por todos os
>> MACs dos participantes.
>>
>> O que eu não tenho certeza é sobre o comportamento dos switches caso o
>> MAC não seja resolvido na rede. Ele dropa o frame? Ou ele envia o frame
>> para todas as portas? Todos os switches se comportariam do mesmo jeito?
>> Se os switches resolverem usar flood pra tratar o frame com MAC não
>> resolvido isso pode ser um desastre.
>>
> Aliás, o MAC de drop é um candidato a gerador de flood... pois nunca se vê
> nenhum pacote recebido dele, então ele sempre vai ser "Unknown Unicast".  O
> MAC de drop requer drop no primeiro ponto de ingresso, ou então ele pode se
> tornar um veneno pior que o DDoS que tentava ser endereçado.
>
> Rubens
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter

-- 
NIC.br | Lucenildo Aquino Júnior
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações
(Ceptro.br)
+55 11 5509-3537R.: 4122
INOC 22548*552
www.nic.br <http://nic.br>