[GTER] #JumboFrameNoIX.BR #BlackHoleNoIX.BR

[Job Snijders]

Dear group,

On Tue, Aug 11, 2020 at 09:14:39AM -0300, Douglas Fischer wrote:
> Mas agora vem as perguntas:
> 
> 1 - E o Black Hole no IX.BR vai sair?
> 1.1 - Pelo menos no modo de redistribuição de rotas para:
> 1.1.1 - Possibilitar que cada um aplique a ação de Blackhole na sua
> respectiva caixa.
> 1.1.2 - Redistribuir com um IP de destino da Lan do ATM que resolva para um
> MAC DEAD.DEAD.DEAD, possibilitando que isso seja filtrado ACL-L2 na portas
> de entrada do fabric das localidade.
> (É o ideal? NÃO! Mas já vai ajudar BASTANTE!)

The above method is not just 'not ideal', but actively dangerous. It
requires all participants to adjust (set 'wide open') their filters,
assume a risk about FIB exhaustion, and require changes on thousands of
devices to be effective.

The method of 'blackholing' by redistributing the to-be-blackholed IP
address as a BGP NLRI to each participant, and asking each participant
to accept the faux next-hop has proven to NOT BE EFFECTIVE.

DE-CIX and other internet exchanges have tried this cheap shortcut and
were never able to prove that the 'feature' actually helped. It turns
out that participants generally are unwilling to make too many
configuration changes, especially if it creates an insecure situation.

The large IXPs tried very hard to produce whitepapers to prove that the
blackholing method is effective, but when you look close at the numbers
you can see that the measured metrics make no sense, and at the scale of
DE-CIX one has to conclude that the feature does not help at all in
dampening the negative effects of DDoS.

Having a route server distribute blackholes to all participants is a
symbolic, ineffective, dangerous facility that I strongly recommend is
not wasted any time on. Don't do it, there are no success stories.

> 1.2 - Quem sabe, aplicar essa filtragem em ACL-L3.
> (Seria o melhor dos mundos, mas depende de capacidade dos devices, e também
> de altíssimo nível de automação.)

Now, *THIS* is the best method.

Yes, it may require additional engineering and perhaps hardware upgrades,
but hardware is upgraded all the time, and knowing that the community
wants this feature, the IX.BR team can make sure that the next
generation of the platform supports combined L2+L3 ACLs which can be
automatically programmed via some API.

The upside of the combined L2/L3 ACL approach are:

    - 100% safe: participants can only impact their own traffic and not damage other networks

    - 100% no trust required: ACLs only affect the port of the requester of the ACL

    - 100% no changes required on the side of the participant, every
      participant can benefit from this platform feature regardless of
      their router type

    - 100% effective for each port on which the feature becomes available

Before dismissing the L2/L3 ACL solution as 'too expensive', 'too much
work' or 'we need something sooner'. One has to consider whether
deploying an ineffective, dangerous, and useless mechanism really is
worth the effort compared to either not offering blackholing (safe), or
engineering a proper in-fabric IX platform based blackholing solution
which uses L2/L3 ACLs (also safe).

Kind regards,

Job