[GTER] #JumboFrameNoIX.BR #BlackHoleNoIX.BR

[Douglas Fischer]

Hello Job!

I Agree with you on several points that you brought:
 - FIB Exhaustion could kill participant routers
 - No correct treatment to Blackhole Prefixes could generate an even
worst effect than removing announces to IXP.
But I believe that with some extra effort, could be possible to mitigate
those downsides.


I have two lines of arguments for you. So I will Split it...



The 1st is corroborative
------------------------

OK, L3 filtering is the right way to deploy Blackhole on IXPs! But(there is
always a but)
The most feasible way to deploy L3 filtering on Fabric is based on FlowSpec.
And... Switchs with support for FlowSpec are very expensive!

Considering that, on a brainstorm with a friend, we talked about a crazy
idea to deploy Dynamic L3 Filtering on Switchs without Flowspec.

Maybe reinventing the wheel, but in a crude way the idea would be:

 a - ExaBGP as a peer of route-servers, receiving the blackhole prefixes.
     On every change on those prefixes export then to txt.
 b - Aggregate that txt with the prefixes to be blackholed
 c - Convert those aggregated prefixes to a yang access-list format
 d- Ansible(or equivalent) push that yang ACL via netconf/ssh to
the Switchs of IXP.

Off course this is an alpha idea, and must consider a lot of other
limitations:
- ACL-L3 Limits of L2 devices of the fabric.
  What would implicate on:
   - Max Blackhole prefix by participant.
   - Methodology to define what prefixes will not be filtered case the ACL
limit get exceeded.




Em ter., 11 de ago. de 2020 às 12:11, Job Snijders <job at ntt.net> escreveu:

> Dear Rubens,
>
> On Tue, Aug 11, 2020 at 11:51:23AM -0300, Rubens Kuhl wrote:
> > The L2 solution can be made not to be dependent on member
> > configuration. The IX can have an ARP responder for the blackholed IP
> > that answers with a specific MAC address, and the IX matrix can drop
> > all traffic destined to that MAC address. So if a member null routes
> > the blackhole IP address, great; the member saves bandwidth in its
> > connection to the IX. But if not, the ingress filter in the IX drops
> > it and the traffic doesn't traverse the IX matrix.
>
> This still requires all participants to accept the blackhole hostroutes
> to begin with (open up filters to /32 + /128, disable RPKI), and accept
> the discard NEXT_HOP (which is not the same as the BGP speaker) which
> has a special MAC address on the platform.
>
> Special configuration that goes against all current BCPs is required
> regardless of the ARP responder. Whether an IXP uses an ARP responder
> with a special IP address (or not) does not change the fundamental flaws
> of the approach.
>
> I repeat my recommendation: please work to invest in an actual solution
> that benefits all participants. L3 ACLS (optionally combined with L2)
> deployed on the participant ports or somewhere in the IX fabric is a
> better solution. An example of a L3-based in-fabric IXP blackholing
> solution was deployed at https://unitedix.net/tech/ - this is not new.
>
> Redistribution the blackhole routes via a route server to all route
> server participants is a 'marketing' solution, it looks interesting on
> paper but is unsafe and ineffective in practise.
>
> Kind regards,
>
> Job
>
> ps. The 'solution' via route servers can easily be replicated via
> bilateral direct peering sessions across the fabric. How many people
> have actually worked together to allow each other to perform blackholing
> inside each others network? Would you feel comfortable getting a BGP
> session from a random ASN with potentially random blackhole requests and
> blindly automatically honor those requests? I wouldn't. I would not
> recommend this to anyone.
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação