[GTER] BlackHole no IX.BR

Fernando Frediani fhfrediani at gmail.com
Tue Jan 7 21:06:14 -03 2020


Hello Job

On 07/01/2020 13:16, Job Snijders wrote:
> A) How do you prevent people from requesting blackholes for IP space
> that is not theirs? We know that normal BGP filtering already is a
> challenge, so introducing a mechanism which can be easily abused is
> tricky.
One thing to note is not only to allow organizations to request 
blackhole for their own assigned address space, but also to their IP 
Transit Customers who eventually are not directlly connected to the 
Internet Exchange, are suffering an attack and have Communities 
available to trigger that which in turn could reach the IX.
> So with the above in mind, I would like to suggest an alternative
> approach:
>
> ALTERNATIVE APPROACH: implement blackholing inside the IXP fabric
> -----------------------------------------------------------------
>
> A safer and more effective way of handling requests for blackholes is to
> set up a special BGP speaker (let's call it the 'blackhole server'),
> which translates received BGP route announcements into combined layer-2
> + layer-3 access-list filters which are automatically applied to
> switch ports.
Undoubtedly this is the best way to implement a blackhole strategy in a 
IX infrastructure, but one thing that is still unclear to me is what 
level of automation is necessary, specially when you have a multi-vendor 
infrastructure where participants are connected as it seems to be the 
case for IX.br. So this BGP translation has to be done for each switch 
depending on the vendor when adding these ACL. Is there anything already 
developed for other IXs that does such job or would the IX.br Team have 
to develop it from scratch.
The closest thing I heard about was some kind of 'Cumulus like software' 
that was able to talk BGP Flowspec and turn that into ACLs that could be 
applied into these white box switches.
>      3) 100% safe. Participants who request a blackhole (either via the
>      special BGP speaker, or via a web interface) can only affect their
>      own ports or traffic flowing to their own MAC address. So if a
>      participant requests to blackhole 1.1.1.1/32 or 8.8.8.8/32 ... the
>      system would only blackhole traffic flowing towards the requester of
>      the blackhole. People can only shoot themselves in the foot, but not
>      distrupt other people's businesses.

One thing mentioned by Rubens which I see in the same way is that both 
strategies are valid, because when Autonomous Systems block de traffic 
at the origin before it hitting the IX fabric it is even more effective 
and cost saving for all.

Fernando

>
>
> On Tue, Jan 07, 2020 at 02:38:36PM +0000, Willian Pires de Souza wrote:
>> Visto os últimos eventos de ataque "extorsão" que alguns provedores
>> vem sofrendo, gostaria de iniciar uma "thread" para que todos possam
>> expor a nossa opinião sobre o IX.BR.
>>
>> Poderia assim como AMS-IX o IX.BR disponibilizar um router-reflector
>> para que os sistemas autônomos possam trocar prefixos de "blackhole"
>> afim de auxiliar na mitigação de eventos que venham pelo próprio IX.BR
>> (China Telecom,Hurricane).
>>
>> Obviamente não anunciar por default os seus prefixos a esses
>> participantes pode ser uma politica individual, mas algo mais refinado
>> como um "blackhole" me parece mais "fino".
>>
>> Dada a relevância do IX.BR no trafego geral nacional dos sistemas
>> autônomos o IX.BR tem alguma estratégia para auxiliar os participantes
>> no que tange DDOS.
>>
>> Posso estar atrasado com relação a informações já posteriormente
>> passadas, quem as tiver de "bate e pronto" poderia re-inserir nesse
>> email ?
>>
>> Feliz ano novo e forte abraço a todos.
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter


More information about the gter mailing list