[lacnog] RPKI ROAs - Blackhole - Maximum prefix length

[Job Snijders]

Hi Fernando,

On Fri, May 17, 2019 at 12:39:22PM -0300, Fernando Frediani wrote:
> On 17/05/2019 02:44, Job Snijders wrote:
> > 3) If you are an IXP and want to offer blackhole related services,
> > implemented it like proposed here
> > https://mailman.nanog.org/pipermail/nanog/2014-October/070310.html
> > United IX implemented a trick where the route server listens for
> > blackholing requests, but does not redistribute them to other route
> > server participants, instead the blackhole routes are converted into
> > ACLs and applied *inside* the layer-2 fabric. This way the blackholing
> > does not require coordination, cooperation, validation, and is always
> > 100% effective
> > https://www.unitedix.net/tech/tech/#incoming-bgp-community-actions
>
> Well, that's a beautiful way of doing, actually pretty smart and
> effective in my opinion, but I guess that may not always be available
> to any IXP out-of-the-box. Specially for smaller ISPs that are still
> sorting technology used and bringing up the bare minimal to operate or
> that may not have all pieces necessary to automate and apply these
> filters in Layer 2 fabric. For example there are switches that may
> have limits on the Layer 2 ACL size or even doesn't have enough
> automation available in order to integrate the route servers to do
> this layer-2 magic.

I agree with all the above you say.

When setting up an IXP it may be in one's best interest to research
whether the selected hardware complies with the current best practises.
For instance, (unrelated to blackholing), an IXP may want to use BCP 214
BGP Session Culling to reduce downtime https://tools.ietf.org/html/bcp214

In not all cases there is free choice of hardware, and we have to make
do with what we are given. Luckily many cheap whitebox switches have
quite advanced ACL capabilities these days.

> That's where probably a router server doing a all-in-one job would
> still be the point.
> 
> I am thinking here if a separate route server exclusively for this
> propose with different filters would be a middle-term for those who
> still cannot implement such filters in layer-2.

In this case I'd argue that is better to not do something, than half-ass
it (pardon my language). This "in between" option is unfortunately
harmful, and not effective.

No IXP can point to an actual success story of blackhole route
redistribution through route servers. I am aware that some IXPs have
gone above and beyond to spin a marketing story that shows that
'blackholing via route servers' is useful, but if you closely analyse
the data you'll notice that none of those metrics actually matter, nor
that there are firm claims about the effectiveness.

There are numerous security issues with redistributing blackhole routes
via route servers, and also issues related to cooperation, coordination
and change management requirements within each participant's
organisation.

If an IXP cannot perform "in-fabric" blackholing, they are best off to
simply not offer a poor surrogate service under the name "blackholing".
Blackhole route redistribution via route servers is *not* an adequate
replacement for actual "in-fabric" blackholing.

In any regard, route servers should never redistribute RPKI Invalid
announcements. I'd appreciate that this principle is also upheld in
context of different service offerings such as blackholing. This to me
means: either apply the blackholes inside the switching fabric as
combined layer-2 + layer-3 ACLs, or simply not offer the service.

Kind regards,

Job