<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 13 Feb 2019 at 00:24, Job Snijders <<a href="mailto:job@instituut.net">job@instituut.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>On Tue, Feb 12, 2019 at 7:30 PM Matthew Walster <<a href="mailto:matthew@walster.org" target="_blank">matthew@walster.org</a>> wrote:<br>
> 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.<br>
<br></div><div>
This simply isn't true. I'm willing to argue a bit about to what degree and in what circumstances RPKI Origin Validation technology is useful or not, but the use of the word "only" in this context is incorrect.</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I have massively oversimplified the situation, true, but essentially the vast majority of the pie chart of "why a prefix would be originated from another ASN and/or of a different prefix length" is:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><ul><li>Leaking from within the originator's borders where the border acts as a point of aggregation (atomic or otherwise). Mostly harmless.</li><li>Someone else leaking out the prefix when they generate it to assist with traffic engineering, including through a proxy/filter (Pakistan/YouTube)</li><li>Someone maliciously acting, so as to steal that traffic (predominantly Bitcoin mining pools, but could be ACME TLS etc)</li></ul></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Have I missed anything (that has substantial real-life relevance to any incident seen so far) or would you say that was a far summary?</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>
> 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.<br>
<br></div><div>
This also is not true. It is not as black and white as you make it out to be.</div><div><br></div><div>1/ For instance AT&T does not accept BGP UPDATES with 2914 anywhere in the AS_PATH except on the direct EBGP sessions between 7018 and 2914. This means that you can craft BGP UPDATES with 2914 all you want, but 7018 won't accept them. You can't inject yourself between AT&T and NTT using spoofing.</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Not relevant to RPKI as it currently stands, which is unrelated to the current mechanism being used: origin validation. Path filtering and IRR prefix list filtering are much more important tools that should be used first -- RPKI can only supplement those tools and should not be used in isolation, unlike the others which do a "good enough" job for most non-transit networks.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>2/ Many networks give all their peering partners the same LOCAL_PREFERENCE, so you'll have to not only spoof the BGP Origin ASN but also compete & win for the shortest path in order for your hijack to arrive at the intended location.</div><div><br></div><div>We as industry essentially already have path validation for paths of length 1. This may not seem much, but since people in this industry tend to peer directly with networks that matter to them. The majority of Internet traffic flows over paths that have an AS_PATH length of 1.</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">We do? I beg to differ. Much of Europe does, national networks in North America generally do, but those in the LACNIC / AfriNIC / APNIC regions? Of course there are exceptions (HKIX et al) but your average path length is going to be generally longer in those regions, and all it takes is for someone at a local IX to forge a couple of path attributes, and suddenly a bunch of traffic shifts.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>
> 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" rel="noreferrer" target="_blank">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 dir="auto"><br></div><div>Uh... that draft is about something else entirely. :-)</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Oh whooops! Copied the URL from the wrong tab! I of course meant the draft you and Massimiliano Stucchi have at <a href="https://tools.ietf.org/html/draft-ss-grow-rpki-as-cones-00">https://tools.ietf.org/html/draft-ss-grow-rpki-as-cones-00</a> -- my bad!!</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>
> 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.<br>
<br></div><div>
you are probably right about that, I'd prefer to stick to a technology that actually exists and is deployable! :-) <br></div></div></blockquote><div><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">My idea is deployable today (for some values of today). Mark all the received NLRIs as not to be installed in the FIB, replicate the data via BMP or BGP with add-paths to a collector, process it, and ship out the results via a BGP session that sets the correct next-hops. I wrote a simple BGP speaker that had 4 byte ASN capability advertisement and graceful restart, literally in a day. Sure, it only supported IPv4 unicast, but with the wide array of open source BGP engines out there, it wouldn't be so hard to put something together that offloaded the entire policy phase from the router to a control plane.</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">You could easily add modules in (just a chain of OOP interfaces) so that you could compare across prefixes, apply aggregation and damping, near real-time mirroring of IRR data to use as filter sets, maybe even read interface stats via SNMP / streaming telemetry / sFlow to start moving traffic around when ports get hot. Oh dear, I've re-invented SDN haven't I? :S</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">However, just because you *could* deploy it today, doesn't mean you should =)</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>