On Tue, Sep 18, 2018 at 6:22 PM Owen DeLong <o...@delong.com> wrote: > > > > On Sep 18, 2018, at 15:07 , Job Snijders <j...@ntt.net> wrote: > > > > On Tue, Sep 18, 2018 at 02:44:30PM -0700, Owen DeLong wrote: > >> ROAs are useful for one hop level validation. At the second AS hop > >> they are 100% useless. > > > > This conversation cannot be had without acknowledging there are multiple > > layers of defense in securing BGP. We should also acknowledge that the > > majority of Internet traffic passes over AS_PATHs that are only one hop. > > Networks that exchange significant amounts of traffic, tend to peer > > directly with each other. > > Actually, I don’t buy that at all. > > Without going into too much detail, I know of at least one former employer > who is quite > well peered, distributes a great deal of traffic and sends a tremendous > amount of it > via multiple ASNs. > > an IP resource holder can sign multiple ROA for a single prefix, it's perfectly valid to have: 157.130.0.0/16 AS112 157.130.0.0/16 AS113 157.130.0.0/16 AS701
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" ? 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) > > >>> In other words, RPKI and the Prefix-to-AS validation procedure give > >>> us much more definitive inputs for routing policies compared to what > >>> can be derived from the IRR. > >> > >> Please explain to me how you distinguish good from bad in the > >> following scenario… You peer with AS6939. You receive routes for > >> 2001:db8:f300::/48 with the following AS Paths > >> > >> 1. 6939 1239 54049 2312 1734 > >> 2. 6939 44046 12049 174 1734 > >> > >> Which one is valid? Which one is not? How did the ROA tell you this? > > > > Both path 1 and 2 are invalid, because of peerlock we'd never accept > > 1239 behind 6939, or 174 behind 6939. AS_PATH filtering combined with > > Origin Validation is where the magic is. > > OK, poor examples crafted at random. Point is there are plenty of valid AS > Paths > out there that you can’t actually validate. > 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. > >>> RPKI is useful in context of a defense in depth strategy. If one > >>> combines "peerlock" AS_PATH filters with origin validation the end > >>> result is bullet proof. Even if NTT is the only one to deploy this > >>> combination, the benefits are notable. > >> > >> Indeed, if peerlock gets wider deployment, it might prove useful. But > >> unless I’m really misunderstanding peerlock, I don’t see that RPKI > >> brings much else to the table in addition. > > > > Wide deployment is not relevant, this is a unilateral defense mechanism, > > so I fear there may indeed be a degree of misunderstanding. > > Point being that there are very very few ASNs using peer lock. Peer lock > alone AIUI pretty well covers the issue. RPKI provides very little (if any) > verification. > > I suppose if you are happy just doing peer lock on/for your network and customers then cool! The RPKI system isn't being forced on you. It seems like a helpful addition to me, but that may not be your outlook. -chris
