Re: Reaching out to ARIN members about their RPKI INVALID prefixes

[Owen DeLong <owen () delong com>]

> On Sep 18, 2018, at 21:29 , Christopher Morrow <morrowc.lists () gmail com> wrote:
>
>
>
> On Tue, Sep 18, 2018 at 6:22 PM Owen DeLong <owen () delong com <mailto:owen () delong com>> wrote:
>
>
> > On Sep 18, 2018, at 15:07 , Job Snijders <job () ntt net <mailto:job () 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 <http://157.130.0.0/16> AS112
>   157.130.0.0/16 <http://157.130.0.0/16> AS113
>   157.130.0.0/16 <http://157.130.0.0/16> AS701

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.

> 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” ?

Except you misunderstood my meaning. Perhaps my fault, but hopefully the above clarification helps you see my point.

> 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)

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.

The ability to do that strikes me as questionable at best in the vast majority of cases.

> > > > 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.

Presuming s/note/not/

I suspect there might be some validity to that viewpoint for supposed “Tier 1” networks.
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.
For the average eyeball network, I bet it’s a complete non-starter.

> > > > 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.

Actually, from my perspective, neither one is practical/useful due to the lack of supporting data to achieve it.

My perspective, however, is closer to the eyeball these days, so YMMV at the core.

Owen