> 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

Reply via email to