On 9 Dec 2014, at 00:31, Baldur Norddahl <baldur.norddahl@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