<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">Hello Job and everyone else!<br><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">After a night with that suggestions in mind, I was thinking on some alternatives...<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">About de Orign-Validation of /32 or /128<br>----------------------------------------<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">Couldn't be possible a "partial" RPKI validation on prefixes that comes with the community of black-hole?</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">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.</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">P.S.: I remember to read something like this with IRR announces.<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">A Simple(stupid) example:<br>"If community==blackhole and prefix-mask=32 (or 128) and\<br> origin-validation=conteined_inside_the_mask_announced_in_RPKI then\<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">accept the prefix and put it on Blackhole action"<br><br><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">Could it be considered an acceptable solution?<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br><br><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">About IXPs and Route-Server BlackHole redistribution<br>----------------------------------------------------</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">I was thinking about a mixed approach with:<br> 1 - Distributed BlackHole(on the participants) and<br> 2 - Layer 2 filtering on the ingress directions of the participants ports<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"> - Based on a dummy/spoofed MAC<br><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">P.S.: Why I thought in this alternative?</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">Some <span class="gmail_default" style="font-family:courier new,monospace;font-size:small">big IXPs today does not have the necessary automation tools to apply L2/L3 ACLs on their switchs.<br></span></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><span class="gmail_default" style="font-family:courier new,monospace;font-size:small">But some static configuration on switchs + conditioned adjusts on Route-servers can give a similar result.<br></span></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><span class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></span></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><span class="gmail_default" style="font-family:courier new,monospace;font-size:small">I will try to exemplify:<br></span></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">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.<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">On the participant side, prefixes received with this predefined community (as in UTRS for example) the router should send that traffic to /dev/null.<br><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">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.<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"> - In this case that traffic will die even before the link to IXP. (Beautiful)<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">B) Those that does not fit on the first characteristic will "forget" adjust their configurations. And it will dive their-selves in two possibilities:</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"> B.1) Those participants that are completely careless, that will receive all the prefixes and put on their FIBs without any type of filters...</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"> 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.</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"> With this trap, the traffic will die in the first contact with the IXP fabric.(good!)</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"> P.S.: A "plus" that can be done in this case</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"> is watch the counters of that access-list.</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"> If there is any increment on the counter of</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"> that mac-address, it can triggers some alert,</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"> mail, or even an electroshock to that specific</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"> participant.<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"> B.2) Those participants that made the basic on the filters, rejecting the prefixes longer than /32 or /48, but stoped in there.</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"> In this case, the traffic will not die in any place before or during the fabric of the IXP.</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"> THIS IS NOT GOOD! But I believe that the percentage of this case can be smaller then 5%.</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"> And a partial solution is better than no solution at all.</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"> 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.<br><br><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">Well... What do you think about this "middle-way-cominned" alternative?<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em sex, 17 de mai de 2019 às 12:56, Job Snijders <<a href="mailto:job@ntt.net">job@ntt.net</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Fernando,<br>
<br>
On Fri, May 17, 2019 at 12:39:22PM -0300, Fernando Frediani wrote:<br>
> On 17/05/2019 02:44, Job Snijders wrote:<br>
> > 3) If you are an IXP and want to offer blackhole related services,<br>
> > implemented it like proposed here<br>
> > <a href="https://mailman.nanog.org/pipermail/nanog/2014-October/070310.html" rel="noreferrer" target="_blank">https://mailman.nanog.org/pipermail/nanog/2014-October/070310.html</a><br>
> > United IX implemented a trick where the route server listens for<br>
> > blackholing requests, but does not redistribute them to other route<br>
> > server participants, instead the blackhole routes are converted into<br>
> > ACLs and applied *inside* the layer-2 fabric. This way the blackholing<br>
> > does not require coordination, cooperation, validation, and is always<br>
> > 100% effective<br>
> > <a href="https://www.unitedix.net/tech/tech/#incoming-bgp-community-actions" rel="noreferrer" target="_blank">https://www.unitedix.net/tech/tech/#incoming-bgp-community-actions</a><br>
><br>
> Well, that's a beautiful way of doing, actually pretty smart and<br>
> effective in my opinion, but I guess that may not always be available<br>
> to any IXP out-of-the-box. Specially for smaller ISPs that are still<br>
> sorting technology used and bringing up the bare minimal to operate or<br>
> that may not have all pieces necessary to automate and apply these<br>
> filters in Layer 2 fabric. For example there are switches that may<br>
> have limits on the Layer 2 ACL size or even doesn't have enough<br>
> automation available in order to integrate the route servers to do<br>
> this layer-2 magic.<br>
<br>
I agree with all the above you say.<br>
<br>
When setting up an IXP it may be in one's best interest to research<br>
whether the selected hardware complies with the current best practises.<br>
For instance, (unrelated to blackholing), an IXP may want to use BCP 214<br>
BGP Session Culling to reduce downtime <a href="https://tools.ietf.org/html/bcp214" rel="noreferrer" target="_blank">https://tools.ietf.org/html/bcp214</a><br>
<br>
In not all cases there is free choice of hardware, and we have to make<br>
do with what we are given. Luckily many cheap whitebox switches have<br>
quite advanced ACL capabilities these days.<br>
<br>
> That's where probably a router server doing a all-in-one job would<br>
> still be the point.<br>
> <br>
> I am thinking here if a separate route server exclusively for this<br>
> propose with different filters would be a middle-term for those who<br>
> still cannot implement such filters in layer-2.<br>
<br>
In this case I'd argue that is better to not do something, than half-ass<br>
it (pardon my language). This "in between" option is unfortunately<br>
harmful, and not effective.<br>
<br>
No IXP can point to an actual success story of blackhole route<br>
redistribution through route servers. I am aware that some IXPs have<br>
gone above and beyond to spin a marketing story that shows that<br>
'blackholing via route servers' is useful, but if you closely analyse<br>
the data you'll notice that none of those metrics actually matter, nor<br>
that there are firm claims about the effectiveness.<br>
<br>
There are numerous security issues with redistributing blackhole routes<br>
via route servers, and also issues related to cooperation, coordination<br>
and change management requirements within each participant's<br>
organisation.<br>
<br>
If an IXP cannot perform "in-fabric" blackholing, they are best off to<br>
simply not offer a poor surrogate service under the name "blackholing".<br>
Blackhole route redistribution via route servers is *not* an adequate<br>
replacement for actual "in-fabric" blackholing.<br>
<br>
In any regard, route servers should never redistribute RPKI Invalid<br>
announcements. I'd appreciate that this principle is also upheld in<br>
context of different service offerings such as blackholing. This to me<br>
means: either apply the blackholes inside the switching fabric as<br>
combined layer-2 + layer-3 ACLs, or simply not offer the service.<br>
<br>
Kind regards,<br>
<br>
Job<br>
_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" target="_blank">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><font size="2"><span style="font-family:courier new,monospace">Douglas Fernando Fischer</span><br style="font-family:courier new,monospace"><span style="font-family:courier new,monospace">Engº de Controle e Automação</span></font><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;color:black;text-align:left;line-height:130%;font-family:courier new,monospace"></div></div>