>> it only proves the need for wider RPKI adoption.... > How can we actually encourage RPKI adoption?
http://certification-stats.ripe.net/ tim, oleg, alex, ..., the ripe/ncc team, and the ripe community have worked very hard to make it easy, and the numbers show their success. lacnic even more so when looked at as a percentage (not shown at the above url); i.e. they have approximately 25% coverage; also due to solid policy, community, and technical work. arin has made it very difficult for a large and important segment of their membeship, and the numbers show their negative success. the other regions are asleep. but the rpki is only part of the equation. to be pedantic, The RPKI is the X.509 based hierarchy [rfc 6481] with is congruent with the internet IP address allocation administration, the IANA, RIRS, ISPs, ... It is the substrate on which the next two are based. It is currently deployed in all five administrative regions. RPKI-based Origin Validation [rfc 6811] uses the RPKI data to allow a router to verify that the autonomous system announcing an IP address prefix is in fact authorized to do so. This is not crypto checked so can be violated. But it should prevent the vast majority of accidental 'hijackings' on the internet today, e.g. the famous Pakistani accidental announcement of YouTube's address space. RPKI-based origin validation is in shipping code from many vendors. Path validation, a downstream technology just finishing standardisation, uses the full crypto information of the RPKI to make up for the embarrassing mistake that, like much of the internet BGP was designed with no thought to securing the BGP protocol itself from being gamed/violated. It allows a receiver of a BGP announcement to formally cryptographically validate that the originating autonomous system was truly authorized to announce the IP address prefix, and that the systems through which the announcement passed were indeed those which the sender/forwarder at each hop intended. one blocker for origin validation deployment today is lack of solid testing of vendors' implementations; and one is known to be sorely mis-implemented. there is work to be done. as stephane pointed out, if you want to be overwhelmed with tweets or email, subscribe to the feed of mis- originations at andree's http://bgpmon.net/. as the sea level rises, maybe we'll do more about this problem. randy