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. > > 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. 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. 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. Kind regards, Job
