Re: Followup: Survey results for the ARIN RPA

[Alex Band <alexb () ripe net>]

> 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