[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