[lacnog] RPKI ROAs - Blackhole - Maximum prefix length

[Fernando Frediani]

Thanks Job, very clarifying.

Fernando

On 17/05/2019 12:56, Job Snijders wrote:
> 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
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog