[lacnog] RPKI ROAs - Blackhole - Maximum prefix length

[Douglas Fischer]

Hello Job and everyone else!

After a night with that suggestions in mind, I was thinking on some
alternatives...


About de Orign-Validation of /32 or /128
----------------------------------------
Couldn't be possible a "partial" RPKI validation on prefixes that comes
with the community of black-hole?

When i say "partial", I mean disregard LE of the mask, and only look to
ASN<-> prefix authorization made by the owner of the prefix.
P.S.: I remember to read something like this with IRR announces.

A Simple(stupid) example:
"If community==blackhole and prefix-mask=32 (or 128) and\
origin-validation=conteined_inside_the_mask_announced_in_RPKI then\
accept the prefix and put it on Blackhole action"


Could it be considered an acceptable solution?




About IXPs and Route-Server BlackHole redistribution
----------------------------------------------------
I was thinking about a mixed approach with:
  1 - Distributed BlackHole(on the participants) and
  2 - Layer 2 filtering on the ingress directions of the participants ports
      - Based on a dummy/spoofed MAC

P.S.: Why I thought in this alternative?
Some big IXPs today does not have the necessary automation tools to apply
L2/L3 ACLs on their switchs.
But some static configuration on switchs + conditioned adjusts on
Route-servers can give a similar result.

I will try to exemplify:
Route-servers receives Black-Hole Announces, Validate origin, and if it is
"correct", re-announce it with no-export community, with a pre-defined
community meaning "black-hole", and with next-hope with a Dummy IP address
of the MLPA network.
On the participant side, prefixes received with this predefined community
(as in UTRS for example) the router should send that traffic to /dev/null.

A) Well, some participants (those with necessary skills to "drive" an ASN)
will correctly adjust the configurations of their routers to accomplish the
rules of the IXP where they are connected.
 - In this case that traffic will die even before the link to IXP.
(Beautiful)

B) Those that does not fit on the first characteristic will "forget" adjust
their configurations. And it will dive their-selves in two possibilities:
  B.1) Those participants that are completely careless, that will receive
all the prefixes and put on their FIBs without any type of filters...
      In this case, they will receive the routes with the next-hop pointed
to a dummy IP address, and a special server will respond with Mac-Address
that will be blocked on Layer2 Access-list statically configured on all the
participant ports.
      With this trap, the traffic will die in the first contact with the
IXP fabric.(good!)
           P.S.: A "plus" that can be done in this case
           is watch the counters of that access-list.
           If there is any increment on the counter of
           that mac-address, it can triggers some alert,
           mail, or even an electroshock to that specific
           participant.
  B.2) Those participants that made the basic on the filters, rejecting the
prefixes longer than /32 or /48, but stoped in there.
      In this case, the traffic will not die in any place before or during
the fabric of the IXP.
      THIS IS NOT GOOD! But I believe that the percentage of this case can
be smaller then 5%.
      And a partial solution is better than no solution at all.
           P.S.: If the participant that receives that traffic can analyze
with IPFIX, is possible to discover the MAC of the source, and report it
requiring that the filter get adjusted.


Well... What do you think about this "middle-way-cominned" alternative?


Em sex, 17 de mai de 2019 às 12:56, Job Snijders <job en ntt.net> escreveu:

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


-- 
Douglas Fernando Fischer
Engº de Controle e Automação
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20190517/565d8fbe/attachment.html>