<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 18, 2018, at 10:35 AM, Job Snijders <<a href="mailto:job@ntt.net" class="">job@ntt.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Owen,<br class=""><br class="">On Tue, Sep 18, 2018 at 10:23:42AM -0700, Owen DeLong wrote:<br class=""><blockquote type="cite" class="">Personally, since all RPKI accomplishes is providing a<br class="">cryptographically signed notation of origin ASNs that hijackers should<br class="">prepend to their announcements in order to create an aura of<br class="">credibility, I think we should stop throwing resources down this<br class="">rathole.<br class=""></blockquote><br class="">1/ You may be overlooking the fact that many networks peer directly with<br class="">what (for them) are the important sources/destinations. The semantics of<br class="">RPKI ROAs help block illegitimate more-specifics, and the short AS_PATH<br class="">between players prevents a hijacker from inserting themself. In other<br class="">words - the most important AS_PATHs are 1 hop. The Internet's dense<br class="">interconnectedness is saving its bacon.<br class=""></div></div></blockquote><div><br class=""></div>While this may be true for a handful of well peered ASNs, it’s certainly not common</div><div>around the wider internet.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class="">2/ Another approach to achieve path validation for 1 hop is through<br class="">mechanisms such what NTT calls 'peerlock'.<br class=""><a href="https://www.youtube.com/watch?v=CSLpWBrHy10" class="">https://www.youtube.com/watch?v=CSLpWBrHy10</a><br class=""></div></div></blockquote><div><br class=""></div>Single hop is relatively easy. It’s 2+ hop where things get far more interesting.</div><div><br class=""></div><div>It’s convenient to reduce the problem set to the one you can easily solve, but ignoring</div><div>the rest of the problem set smacks of hand-waving and “insert magic here”.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">3/ Lastly, some folks are innovating in this space to help automate<br class="">concepts such as peerlock through what is called ASPA. ASPA is intended<br class="">as an out-of-band, deployable alternative to BGPSec.<br class=""></div></div></blockquote><div><br class=""></div>OK, but IIRC, it’s rather orthogonal to RPKI.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><a href="https://tools.ietf.org/html/draft-azimov-sidrops-aspa-profile" class="">https://tools.ietf.org/html/draft-azimov-sidrops-aspa-profile</a><br class="">https://tools.ietf.org/html/draft-azimov-sidrops-aspa-verification<br class=""><br class="">I think you underestimate how valuable RPKI based Origin Validation<br class="">(even just by itself) is in today's Internet landscape.<br class=""></div></div></blockquote><div><br class=""></div>I think you overestimate it.</div><div><br class=""></div><div>Owen</div><div><br class=""></div></body></html>