<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">On Tue, 12 Feb 2019 at 16:05, Nick Hilliard <<a href="mailto:nick@foobar.org">nick@foobar.org</a>> wrote:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Matthew Walster wrote on 12/02/2019 14:50:<br>
> For initial deployment, this can seem attractive, but remember that one <br>
> of the benefits an ROA gives is specifying the maximum prefix length. <br>
> This means that someone can't hijack a /23 with a /24.<br>
<br>
they can if they forge the source ASN.  RPKI helps against misconfigs <br>
rather than intentional hijackings.</blockquote><div><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">As it stands today, RPKI is only useful to prevent fat-fingering of ebgp routing policies, where routes are leaked from a point of "legitimate" re-origination such as a web filter service. It's entirely unsuitable (at present) for anything where someone is re-originating the prefix somewhere else with the same origin ASN present (i.e. maliciously) and it doesn't protect against someone accidentally sending you a prefix they heard elsewhere that is valid.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">My understanding is that part of that problem can be solved with <a href="https://tools.ietf.org/html/draft-ietf-sidrops-rpki-tree-validation-03">https://tools.ietf.org/html/draft-ietf-sidrops-rpki-tree-validation-03</a> but once again it's still only preventing fat-fingering and not malicious intent.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">RPKI provides an additional layer of security, but it stands independent of the need for prefix list and AS_PATH filter generation (likely derived from IRR data). I'm actually of the opinion that the whole "PKI" part of RPKI is the bit that really needs to die. PKI certificates brought no real benefit to the solution. Embedding RFC 3779 (<span style="color:rgb(0,0,0);white-space:pre-wrap;font-family:Arial,Helvetica,sans-serif">X.509 Extensions for IP Addresses and AS Identifiers) makes the data so much less accessible and difficult to process for all but the most technically competent system/network administrators, especially considering most existing tools and libraries for X.509 certificate operations just don't support doing anything reasonable with them in a way that doesn't involve several hours afterwards in a candle-lit bath with a Pink Floyd CD playing in the background.</span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="color:rgb(0,0,0);white-space:pre-wrap;font-family:Arial,Helvetica,sans-serif"><br></span></div><div class="gmail_default"><span style="font-family:Arial,Helvetica,sans-serif;color:rgb(0,0,0);white-space:pre-wrap">Personally, I'd like to see BMP (</span><font color="#000000"><span style="white-space:pre-wrap">RFC 7854, unidirectional flow of information) bolted on to an extended version of the RTR protocol (RFC8210) or a stripped down unidirectional BGP session, and have the whole policy engine offloaded from the border router to some kind of daemon running, potentially on a distributed controller of sorts, that:</span></font></div><div class="gmail_default"><ul><li><span style="white-space:pre-wrap;color:rgb(0,0,0)">Pulled in all this raw data and processed it, using the compute power available in servers after the invention of the Cyrix 200.</span></li><li><span style="white-space:pre-wrap;color:rgb(0,0,0)">Asserted the veracity of the data it has received (real-time updates of prefix-lists, paths, trustworthiness, advertised "directionality" akin to peerlock etc) without having to periodically push new configuration to your routers.</span></li><li><span style="white-space:pre-wrap;color:rgb(0,0,0)">Applied policy decisions, including mapping traffic for that destination into a FEC / MPLS tunnel as appropriate.</span></li><li><span style="white-space:pre-wrap;color:rgb(0,0,0)">Possibly even applying aggregation at the FIB install level if appropriate to reduce total FIB entry size and programming time.</span></li><li><span style="white-space:pre-wrap;color:rgb(0,0,0)">Distributed a final RIB (+FIB if needed) out to each of the BGP routers in the AS, depending on the view they needed.</span></li></ul></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I think I'd have a hard time convincing people of that though, and the RIR policy folk would have a small heart attack at the level of complexity required.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">M</div></div></div></div></div></div>