[176675] in North American Network Operators' Group
Re: Followup: Survey results for the ARIN RPA
daemon@ATHENA.MIT.EDU (John Curran)
Tue Dec 9 11:38:43 2014
X-Original-To: nanog@nanog.org
From: John Curran <jcurran@arin.net>
To: Alex Band <alexb@ripe.net>
Date: Tue, 9 Dec 2014 16:38:26 +0000
In-Reply-To: <70B0BA0E-EFF4-4E6D-9BA5-12E22EDFF845@ripe.net>
Cc: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
Alex -=20
=20
Thanks for sharing your observations from RPKI deployment=20
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 <alexb@ripe.net> wrote:
>=20
>=20
>> On 9 Dec 2014, at 00:31, Baldur Norddahl <baldur.norddahl@gmail.com> wro=
te:
>>=20
>> But that is just my ramblings. I am also warning that the RIPE tool alre=
ady
>> ignores ARIN. Anyone from RIPE will be ignoring you unless they go out o=
f
>> their way to fix it. My bet is therefore that ARIN is being ignored by
>> many if not most.
>=20
> 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 explic=
itly 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.
>=20
> 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 extreme=
ly 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:
>=20
> 1) a certificate or ROA that doesn't pass cryptographic validation for a =
particular reason, such as expiration, tampering, overclaiming, etc.: "Inva=
lid Certificate", "Invalid ROA"
> 2) a BGP announcement that is flagged as unauthorised due to a *cryptogra=
phically valid* ROA that covers it: "Invalid BGP Announcement"
>=20
> If one of the RIRs make a mistake such as letting the key expire, they ca=
use 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 rela=
ted to those ROAs will have the state "unknown"; and they should NOT be dro=
pped. So in these cases, there will be no reachability problem for the affe=
cted ISP.
>=20
> In order for a BGP announcement to get the state RPKI invalid/unauthorise=
d, the repository would have to contain a valid ROA issued from a valid cer=
tificate. As ARIN took drastic measures with regards to non-repudiation, yo=
u can be certain that this ROA was put there by the legitimate holder of th=
e resources. This is provable by ARIN in a court of law.
>=20
> There are quite some RPKI invalid/unauthorised BGP announcements as a res=
ult of valid ROAs: 2,898 of them globally, as I write this. All of them exi=
st 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 I=
SP may try to hold ARIN accountable for it anyway. It's the USA, after all.=
:)
>=20
> 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 contr=
ary. When you start bringing in the delegated model, where operators run th=
eir own CA and publish themselves, as well as inter-RIR transfers of resour=
ces where operators may desire to have their BGP announcements RPKI valid i=
n a seamless manner, it adds complexity. All of this will require careful p=
lanning and a good implementation, but I for one am confident we'll get thi=
s sorted as we've gained lots of operational experience in the last four ye=
ars.
>=20
> In conclusion, the goal is to offer an RPKI service that operators are ea=
ger to use, because they think there is value and they trust the RIRs are d=
oing a good job operationally. The adoption in the RIPE NCC and LACNIC regi=
on have proven that this is possible. I'm confident the same can be achieve=
d in the ARIN region...=20
>=20
> Alex Band
> Product Manager=20
> RIPE NCC
