<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 18, 2018 at 6:22 PM Owen DeLong <<a href="mailto:owen@delong.com">owen@delong.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On Sep 18, 2018, at 15:07 , Job Snijders <<a href="mailto:job@ntt.net" target="_blank">job@ntt.net</a>> wrote:<br>
> <br>
> On Tue, Sep 18, 2018 at 02:44:30PM -0700, Owen DeLong wrote:<br>
>> ROAs are useful for one hop level validation. At the second AS hop<br>
>> they are 100% useless.<br>
> <br>
> This conversation cannot be had without acknowledging there are multiple<br>
> layers of defense in securing BGP. We should also acknowledge that the<br>
> majority of Internet traffic passes over AS_PATHs that are only one hop.<br>
> Networks that exchange significant amounts of traffic, tend to peer<br>
> directly with each other.<br>
<br>
Actually, I don’t buy that at all.<br>
<br>
Without going into too much detail, I know of at least one former employer who is quite<br>
well peered, distributes a great deal of traffic and sends a tremendous amount of it<br>
via multiple ASNs.<br>
<br></blockquote><div><br></div><div>an IP resource holder can sign multiple ROA for a single prefix, it's perfectly valid to have:<br> <a href="http://157.130.0.0/16">157.130.0.0/16</a> AS112</div><div> <a href="http://157.130.0.0/16">157.130.0.0/16</a> AS113</div><div> <a href="http://157.130.0.0/16">157.130.0.0/16</a> AS701</div><div><br></div><div>So 'peered well via multiple ASN isn't really a problem here'. Are you making an argument of the form: "1% of the problems are not solved so this solution can't possibly work" ?</div><div><br></div><div>Using ROA from the RPKI system tied through/to the IRR data and applied as filters on the bgp sessions of a network should provide that ASN with more assurance that they will not accept and propagate a route hijack or mistake. Adding in validation is nice as well, and may allow you to be a little less diligent about route filtering... I think more than 1 protection is a good plan though (OV + filters seems sane to me, especially in a world where you can automate that whole lot)</div><div><br></div><div> > </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>>> In other words, RPKI and the Prefix-to-AS validation procedure give<br>
>>> us much more definitive inputs for routing policies compared to what<br>
>>> can be derived from the IRR.<br>
>> <br>
>> Please explain to me how you distinguish good from bad in the<br>
>> following scenario… You peer with AS6939. You receive routes for<br>
>> 2001:db8:f300::/48 with the following AS Paths<br>
>> <br>
>> 1. 6939 1239 54049 2312 1734<br>
>> 2. 6939 44046 12049 174 1734<br>
>> <br>
>> Which one is valid? Which one is not? How did the ROA tell you this?<br>
> <br>
> Both path 1 and 2 are invalid, because of peerlock we'd never accept<br>
> 1239 behind 6939, or 174 behind 6939. AS_PATH filtering combined with<br>
> Origin Validation is where the magic is.<br>
<br>
OK, poor examples crafted at random. Point is there are plenty of valid AS Paths<br>
out there that you can’t actually validate.<br></blockquote><div><br></div><div>I think Job's point is that there really are note that many... perhaps that's an NTT particular view? I know that my production network's view is similar in 'shorter as paths'. I expect that in large-isp-land it's more prevalent than not.</div><div> </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>>> RPKI is useful in context of a defense in depth strategy. If one<br>
>>> combines "peerlock" AS_PATH filters with origin validation the end<br>
>>> result is bullet proof. Even if NTT is the only one to deploy this<br>
>>> combination, the benefits are notable.<br>
>> <br>
>> Indeed, if peerlock gets wider deployment, it might prove useful. But<br>
>> unless I’m really misunderstanding peerlock, I don’t see that RPKI<br>
>> brings much else to the table in addition.<br>
> <br>
> Wide deployment is not relevant, this is a unilateral defense mechanism,<br>
> so I fear there may indeed be a degree of misunderstanding.<br>
<br>
Point being that there are very very few ASNs using peer lock. Peer lock<br>
alone AIUI pretty well covers the issue. RPKI provides very little (if any)<br>
verification.<br><br></blockquote><div><br></div><div>I suppose if you are happy just doing peer lock on/for your network and customers then cool!</div><div>The RPKI system isn't being forced on you. It seems like a helpful addition to me, but that may not be your outlook.</div><div><br></div><div>-chris </div></div></div>