<div>On Fri, May 17, 2019 at 20:26 Douglas Fischer <<a href="mailto:fischerdouglas@gmail.com">fischerdouglas@gmail.com</a>> wrote:<br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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?</div></div></div></div></div></div></blockquote><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">I’d say this is not a complete or acceptable solution. What happens here is that the RPKI ROAs I publishes, are modified without my permission.</div><div dir="auto"><br></div><div dir="auto">Anyone can add my ASN to their AS-SET. Now if the route server also ignores parts of my ROA publication (by pretending maxlength is set to 32), anyone can attempt to blackhole my IP space.</div><div dir="auto"><br></div><div dir="auto">In addition to the above trivial workaround, the surrogate blackholing method still has issues:</div><div dir="auto"><br></div><div dir="auto">- for 100% effectiveness, 100% of IX participants must apply custom configuration to that specific IX.</div><div dir="auto"><br></div><div dir="auto">- a misconfiguration in one ASN can still negatively impact lots of other ASNs (think blackholing of 8.8.8.8)</div><div dir="auto"><br></div><div dir="auto">- IX participants expect blackholing to work when the service is advertised as “blackholing”, but since you never achieve 100% cooperation, the service will never be effective, which is somewhat misleading.</div><div dir="auto"><br></div><div dir="auto">The technique you describe was first thought up in a marketing department because they wanted to tick the boxes “rpki” and “blackholing”, and ended up doing neither properly. They are mangling rpki based VRPs, and the blackholing only works if all traffic sources participate in the insecure scheme.</div><div dir="auto"><br></div><div dir="auto">I maintain that in this situation it is better to do it correctly, or not do it at all. With “in-fabric” blackholing there is no need for validation, rpki checks, and the participant can only impact their own network, they have no influence over other people’s blackhole routes. </div><div dir="auto"><br></div><div dir="auto">Kind regards,</div><div dir="auto"><br></div><div dir="auto">Job</div></div></div>