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

[Owen DeLong <owen () delong com>]

> On Sep 18, 2018, at 14:58 , Job Snijders <job () ntt net> wrote:
>
> On Tue, Sep 18, 2018 at 02:35:44PM -0700, Owen DeLong wrote:
> > > "rir says owen can originate route FOO"
> > > "ROA for 157.130.1.0/24 says OWEN can originate"
> >
> > Nope… ROA says (e.g.) AS1734 (or anyone willing to impersonate AS1734)
> > can originate 192.159.10.0/24.
>
> I'd phrase slightly different (assuming there is only one ROA): the ROA
> says ONLY AS1734 (or anyone willing to impersonate AS1734) can originate
> 192.159.10.0/24.
>
> With IRR, the crucial addition of the word "ONLY" in the above sentence
> is not possible.

That depends. If you ONLY allow the maintainer of NET-192.159.10.0/24 to
update the route objects for it, then the word ONLY is effectively present by
the lack of any other route objects.

> > > those seem like valuable pieces of information. Especially since I
> > > can know this through some machine parseable fashion.
> >
> > I would agree if you had some way to distinguish AS1734 originating
> > FOO from AS174 originating FOO with a prepend of AS1734.
>
> In the common scenario you can distinguish those with today's
> technology. As mentioned before - dense peering (having the shortest
> AS_PATH) or the peerlock approach for all *practical* intents solve the
> issue of path validation. You can try spoofing AS 7018 - you'll notice
> that your announcements won't make it into NTT. Having just that
> validated path (which is only one hop) is a very strong defense
> mechanism.

You chopped out my example, which had equal AS Path lengths.

Sure, I might not be able to announce something to you for an AS that you’re directly
peered with, but I can still spoof pretty much anything that’s more than one hop away
as long as I can get one of your peers to pass it along.

> Let's take another example: Google offers access to one of the world's
> largest DNS resolver services, Cloudflare hosts lots of authoritative
> DNS. According to PeeringDB they have quite some locations in common
> with each other so let's assume they directly peer with each other. If
> both sides create ROAs for their prefixes, and ROAs for the prefixes
> that host the auth side, and both sides perform RPKI Origin Validation;
> an attacker cannot inject itself between the two. 

Again, you’re reducing the problem set to single hop which I admit RPKI solves
(though I’d argue that if someone has access to insert themselves between
the two physically, RPKI does little to help)

> One can argue "this only helped google and cloudflare" - but on the
> other hand anno 2018 the Internet experience for the average end user is
> composed from services hosted by a relatively small number of providers.
> Preventing disruptions of communication between just those few players
> has significant implications for all of us.

So RPKI is great if we can just reduce the internet diameter to 1, in which
case MD5 passwords on your BGP sessions pretty much accomplishes the
same thing with a lot less kerfuffle.

Owen