[176674] in North American Network Operators' Group
Re: Followup: Survey results for the ARIN RPA
daemon@ATHENA.MIT.EDU (Alex Band)
Tue Dec 9 10:23:19 2014
X-Original-To: nanog@nanog.org
From: Alex Band <alexb@ripe.net>
In-Reply-To: <CAPkb-7CpZK2BL1SWD29O3wUwbsOkeVRynHR2NsbgETNhdLQENw@mail.gmail.com>
Date: Tue, 9 Dec 2014 16:23:09 +0100
To: Baldur Norddahl <baldur.norddahl@gmail.com>
Cc: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
> On 9 Dec 2014, at 00:31, Baldur Norddahl <baldur.norddahl@gmail.com> =
wrote:
>=20
> 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...=20
Alex Band
Product Manager=20
RIPE NCC
