<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 21:29 , Christopher Morrow <<a href="mailto:morrowc.lists@gmail.com" class="">morrowc.lists@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Sep 18, 2018 at 6:22 PM Owen DeLong <<a href="mailto:owen@delong.com" class="">owen@delong.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><br class=""><br class="">> On Sep 18, 2018, at 15:07 , Job Snijders <<a href="mailto:job@ntt.net" target="_blank" class="">job@ntt.net</a>> wrote:<br class="">><span class="Apple-converted-space"> </span><br class="">> On Tue, Sep 18, 2018 at 02:44:30PM -0700, Owen DeLong wrote:<br class="">>> ROAs are useful for one hop level validation. At the second AS hop<br class="">>> they are 100% useless.<br class="">><span class="Apple-converted-space"> </span><br class="">> This conversation cannot be had without acknowledging there are multiple<br class="">> layers of defense in securing BGP. We should also acknowledge that the<br class="">> majority of Internet traffic passes over AS_PATHs that are only one hop.<br class="">> Networks that exchange significant amounts of traffic, tend to peer<br class="">> directly with each other.<br class=""><br class="">Actually, I don’t buy that at all.<br class=""><br class="">Without going into too much detail, I know of at least one former employer who is quite<br class="">well peered, distributes a great deal of traffic and sends a tremendous amount of it<br class="">via multiple ASNs.<br class=""><br class=""></blockquote><div class=""><br class=""></div><div class="">an IP resource holder can sign multiple ROA for a single prefix, it's perfectly valid to have:<br class=""> <span class="Apple-converted-space"> </span><a href="http://157.130.0.0/16" class="">157.130.0.0/16</a><span class="Apple-converted-space"> </span>AS112</div><div class=""> <span class="Apple-converted-space"> </span><a href="http://157.130.0.0/16" class="">157.130.0.0/16</a><span class="Apple-converted-space"> </span>AS113</div><div class=""> <span class="Apple-converted-space"> </span><a href="http://157.130.0.0/16" class="">157.130.0.0/16</a><span class="Apple-converted-space"> </span>AS701</div></div></div></div></blockquote><div><br class=""></div>I did not mean that they originate the traffic from multiple ASNs, I mean that a tremendous amount of their traffic goes origin->ASHOP1->ASHOP2->…->END USER.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_quote"><div class="">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></div></div></blockquote><div><br class=""></div>Except you misunderstood my meaning. Perhaps my fault, but hopefully the above clarification helps you see my point.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_quote"><div class="">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></div></div></blockquote><div><br class=""></div>Again, unless you can trust the data in the IRR to build a complete list of valid AS Paths from the ORIGIN, you can’t safely reject a fake route that has the correct prepend.</div><div><br class=""></div><div>The ability to do that strikes me as questionable at best in the vast majority of cases.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">>>> In other words, RPKI and the Prefix-to-AS validation procedure give<br class="">>>> us much more definitive inputs for routing policies compared to what<br class="">>>> can be derived from the IRR.<br class="">>><span class="Apple-converted-space"> </span><br class="">>> Please explain to me how you distinguish good from bad in the<br class="">>> following scenario… You peer with AS6939. You receive routes for<br class="">>> 2001:db8:f300::/48 with the following AS Paths<br class="">>><span class="Apple-converted-space"> </span><br class="">>> 1. 6939 1239 54049 2312 1734<br class="">>> 2. 6939 44046 12049 174 1734<br class="">>><span class="Apple-converted-space"> </span><br class="">>> Which one is valid? Which one is not? How did the ROA tell you this?<br class="">><span class="Apple-converted-space"> </span><br class="">> Both path 1 and 2 are invalid, because of peerlock we'd never accept<br class="">> 1239 behind 6939, or 174 behind 6939. AS_PATH filtering combined with<br class="">> Origin Validation is where the magic is.<br class=""><br class="">OK, poor examples crafted at random. Point is there are plenty of valid AS Paths<br class="">out there that you can’t actually validate.<br class=""></blockquote><div class=""><br class=""></div><div class="">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></blockquote><div><br class=""></div>Presuming s/note/not/</div><div><br class=""></div><div>I suspect there might be some validity to that viewpoint for supposed “Tier 1” networks.</div><div>Once you hit Tier 2 and consider their subscribers in the mix, it gets a lot fuzzier and less likely that it is a valid perspective.</div><div>For the average eyeball network, I bet it’s a complete non-starter.</div><div><br class=""><blockquote type="cite" class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><br class="">>>> RPKI is useful in context of a defense in depth strategy. If one<br class="">>>> combines "peerlock" AS_PATH filters with origin validation the end<br class="">>>> result is bullet proof. Even if NTT is the only one to deploy this<br class="">>>> combination, the benefits are notable.<br class="">>><span class="Apple-converted-space"> </span><br class="">>> Indeed, if peerlock gets wider deployment, it might prove useful. But<br class="">>> unless I’m really misunderstanding peerlock, I don’t see that RPKI<br class="">>> brings much else to the table in addition.<br class="">><span class="Apple-converted-space"> </span><br class="">> Wide deployment is not relevant, this is a unilateral defense mechanism,<br class="">> so I fear there may indeed be a degree of misunderstanding.<br class=""><br class="">Point being that there are very very few ASNs using peer lock. Peer lock<br class="">alone AIUI pretty well covers the issue. RPKI provides very little (if any)<br class="">verification.<br class=""><br class=""></blockquote><div class=""><br class=""></div><div class="">I suppose if you are happy just doing peer lock on/for your network and customers then cool!</div><div class="">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></div></blockquote><div><br class=""></div></div>Actually, from my perspective, neither one is practical/useful due to the lack of supporting data to achieve it.<div class=""><br class=""></div><div class="">My perspective, however, is closer to the eyeball these days, so YMMV at the core.</div><div class=""><br class=""></div><div class="">Owen</div><div class=""><br class=""></div></body></html>