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

[Owen DeLong <owen () delong com>]

> On Sep 18, 2018, at 15:07 , Job Snijders <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.

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

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

Owen