Alex - Thanks for sharing your observations from RPKI deployment in the RIPE region - it's very helpful for those trying to understand how RPKI might affect their operations. :-)
Thanks again! /John > On Dec 9, 2014, at 10:23 AM, Alex Band <al...@ripe.net> wrote: > > >> On 9 Dec 2014, at 00:31, Baldur Norddahl <baldur.nordd...@gmail.com> wrote: >> >> But that is just my ramblings. I am also warning that the RIPE tool already >> ignores ARIN. Anyone from RIPE will be ignoring you unless they go out of >> their way to fix it. My bet is therefore that ARIN is being ignored by >> many if not most. > > The RIPE NCC RPKI Validator doesn't include the ARIN Trust Anchor Locator > because we're not allowed to include in the package. Even though we > explicitly explain in the readme and UI how to get it, my experience is that > most operators who run the software don't take the steps to download it. > > I've been responsible for running the RPKI service in the RIPE NCC region for > the last five years now. My experience is that education is an extremely > important factor. One thing in particular causes a lot of confusion and this > is the word "invalid", due to the somewhat confusing terminology used in > RPKI, as there are two things that have this term associated with them. They > should be clearly separated in this discussion: > > 1) a certificate or ROA that doesn't pass cryptographic validation for a > particular reason, such as expiration, tampering, overclaiming, etc.: > "Invalid Certificate", "Invalid ROA" > 2) a BGP announcement that is flagged as unauthorised due to a > *cryptographically valid* ROA that covers it: "Invalid BGP Announcement" > > If one of the RIRs make a mistake such as letting the key expire, they cause > an outage, or the repository is unavailable due to a ddos attack, this can > result in invalid or absent certificates and ROAs. Because invalid ROAs are > thrown out by the RPKI Validators, the BGP announcements that are related to > those ROAs will have the state "unknown"; and they should NOT be dropped. So > in these cases, there will be no reachability problem for the affected ISP. > > In order for a BGP announcement to get the state RPKI invalid/unauthorised, > the repository would have to contain a valid ROA issued from a valid > certificate. As ARIN took drastic measures with regards to non-repudiation, > you can be certain that this ROA was put there by the legitimate holder of > the resources. This is provable by ARIN in a court of law. > > There are quite some RPKI invalid/unauthorised BGP announcements as a result > of valid ROAs: 2,898 of them globally, as I write this. All of them exist > because of an explicit, validated statement made by an operator who uses the > system. What's important through is that I can't come up with a single > scenario where an RPKI invalid/unauthorised BGP announcement would appear > because of an *operational mistake* the RIR made. Admittedly though, some ISP > may try to hold ARIN accountable for it anyway. It's the USA, after all. :) > > I'm not trying to downplay the operational complexity of the RPKI system as a > whole, but this stuff doesn't break at the drop of a hat, on the contrary. > When you start bringing in the delegated model, where operators run their own > CA and publish themselves, as well as inter-RIR transfers of resources where > operators may desire to have their BGP announcements RPKI valid in a seamless > manner, it adds complexity. All of this will require careful planning and a > good implementation, but I for one am confident we'll get this sorted as > we've gained lots of operational experience in the last four years. > > In conclusion, the goal is to offer an RPKI service that operators are eager > to use, because they think there is value and they trust the RIRs are doing a > good job operationally. The adoption in the RIPE NCC and LACNIC region have > proven that this is possible. I'm confident the same can be achieved in the > ARIN region... > > Alex Band > Product Manager > RIPE NCC
