[GTER] #JumboFrameNoIX.BR #BlackHoleNoIX.BR

Tue Aug 11 22:51:37 -03 2020

The 2nd is counter-argumentative
--------------------------------
You mentioned:
"It requires all participants to adjust (set 'wide open') their filters"
Not Exactly!
It will depend of positive/negative reinforcement.
Let me explain...

Well... In matters of keeping IXP Routing Filter up-to-date, I would say
that exist 3 types of Guys.
1 - The fully-hog guy.
That one that does not filter anything, and accept all the information that
receives...
(those are the câncer of internet routing security)

2 - The almost committed but always in hurry guy.
That one that follows the instructions of how to do good filtering, but
does it just at the deploy. And never review anything.
On our matter here, he probably will apply a "refuse" to prefixes longer
than /24 and /48.

3 - The lunatic-dedicated guy that do a day-by-day review on the
routing-filters.
That is the one that probably will apply the policy to blackhole the
prefixes with de defined bgp-community 3 hours after the paper release.

Well...

-> The 3rd guy is not a problem!
On the contrary! He should be laureate.
Beyond adjusting his filters to accept /32 or /128 prefixes with the
blackhole community, he certainly will set next-hop to blackhole still
inside his network.
But even if he would forget to /dev/null the packets locally, it would be
dropped the L2 filter(ARP Responder, ACL-L2 to drop dead.dead.dead, and
bla-bla-bla).

-> The 1st guy is a pig!
And will receive the blackhole routes, accept the next-hop, and the packet
his router send will be dropped by the  ACL-L2 to drop dead.dead.dead.
So, in this case, he is not a problem.

-> The 2nd guy...
Normally he is not the problem. But in this situation he is.
His filter won't accept the /32 /128 prefixes, but will still accept the
/24 or /48 routes.
And because of the packet sent from his network to the ASN that doesn't
want packets to a specific destination will continue flowing.

And all that the 2nd guy needs act as the 1st guy is just a bit
reinforcement.

An to help him, my suggestion is:

A tool that would validate if his routing policies are in compliance with
what is demanded by IXP, and:
1 - Notify him
2 - Make this information public on a central portal.

How would be this Tool?
A synthetic participant that would announce an /24 and a /48, and
randomly announce some /32 and /128 as Blackhole and do some pings to each
participant.
(This has yet to be better thought out.)

Getting the information about being in compliance with this Black Hole
routing policy would solve several problems....
A - That 3rd nerd guy that dedicates beyond the limits and almost never has
his effort recognize, will now be on the green list.
B - The Pig guys will be always on the red list.
C - The 2nd, always in a hurry guy, will receive the incentive to do the
right thing.
D - This kind of information could be used to feed MANRS.

Em ter., 11 de ago. de 2020 às 22:51, Douglas Fischer <
fischerdouglas at gmail.com> escreveu:

> 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
>

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