Financial services BGP hijack last week?

Tue May 2 23:43:52 UTC 2017

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