Followup: Survey results for the ARIN RPA

Mailman List Mirror (Read Only)
1

There have been 28 response to the survey I put out last week.

The key numbers are:
We have read and will not sign the agreement 10 36%
We are considering signing the agreement 1 4%
We haven't yet read it 5 18%

and
Our legal staff has reviewed and rejected the agreement. 7 25%
We have provided specific legal feedback to ARIN on the agreement. 2 7%

I'll draw the obvious conclusion:
While not scientific, these numbers, combined with the, well, lively,
discussion the past few days show some serious dissatisfaction with the
agreement required in order to access, and therefore validate, ROAs in the
ARIN region.

And there in lies my interest in all of this- there is little value in
signing my org's routes if no one is going to validate them. It's a bit of
an odd position in that I have a very high interest in what the rest of the
community thinks of and how they act with respect to the RPA. In other
words, your relationship with ARIN is now of concern to me.

Maybe I'm being naively optimistic in thinking that these are solvable
problems.

2

And there in lies my interest in all of this- there is little value in
signing my org's routes if no one is going to validate them. It's a bit of
an odd position in that I have a very high interest in what the rest of the
community thinks of and how they act with respect to the RPA. In other
words, your relationship with ARIN is now of concern to me.

Maybe I'm being naively optimistic in thinking that these are solvable
problems.

there is the rest of the world, it is a global internet. the north
american influence decreases continuously, some because of growth of the
global internet, which is a good thing. some because of noam making
itself less and less relevant, as you point out.

take a look at

   http://archive.psg.com://rpki-rollout.jpg

kinda tells you what's happening, eh? lacnic has more roll-out than
arin, and proportionally it is even more impressive; over 20% of lacnic
allocations have roas. and there is ripe, with the sheer numbers.

randy

3

One could easily presume the ARIN region RPKI deployment statistics are
lower as a result of the RPA situation (and no doubt that it part of the
issue), but as noted earlier, it's unlikely to be the full story since
we also have a region (APNIC) where RPKI deployment also rather low that
and yet does not have these RPA legal entanglements.

It was suggested earlier that this may be due to a combination of factors
(education, promotion) beyond the RPA legal issues that are now being
worked - so that will also need to be addressed once the RPA is resolved.

/John

John Curran
President and CEO
ARIN

4

One could easily presume the ARIN region RPKI deployment statistics
are lower as a result of the RPA situation (and no doubt that it part
of the issue), but as noted earlier, it's unlikely to be the full
story since we also have a region (APNIC) where RPKI deployment also
rather low that and yet does not have these RPA legal entanglements.

It was suggested earlier that this may be due to a combination of
factors (education, promotion) beyond the RPA legal issues that are
now being worked - so that will also need to be addressed once the RPA
is resolved.

definitely agree. lacnic and ripe have put effort in their respective
communities (yay alex!). heck, ripe even resolved the PI and legacy
policy issues so everyone can play (speaking of sick arin legal
documents).

randy

5

We signed our ROAs but we wont be validating anything from the ARIN region.
I believe you will find this to be the norm. The tool provided by RIPE also
ignores ARIN by default.

Someone will probably tell me that I am being arrogant again, but basically
you are asking me to help protect your routes. And you want me to sign
something first. I am not going to even read that agreement. I do not
believe I am alone in this.

Regards

Baldur

6

One could easily presume the ARIN region RPKI deployment statistics are
lower as a result of the RPA situation (and no doubt that it part of the
issue), but as noted earlier, it's unlikely to be the full story since
we also have a region (APNIC) where RPKI deployment also rather low that
and yet does not have these RPA legal entanglements.

It was suggested earlier that this may be due to a combination of factors
(education, promotion) beyond the RPA legal issues that are now being
worked - so that will also need to be addressed once the RPA is resolved.

Are the US litigation risks that much higher than other jurisdictions so
that ARIN needs to take a different approach than other RIRs ? If they are,
perhaps a confederation design instead of centralized one would help
scatter those risks ?

Rubens

7

One could easily presume the ARIN region RPKI deployment statistics are
lower as a result of the RPA situation (and no doubt that it part of the
issue), but as noted earlier, it's unlikely to be the full story since
we also have a region (APNIC) where RPKI deployment also rather low that
and yet does not have these RPA legal entanglements.

It was suggested earlier that this may be due to a combination of factors
(education, promotion) beyond the RPA legal issues that are now being
worked - so that will also need to be addressed once the RPA is resolved.

Are the US litigation risks that much higher than other jurisdictions so that ARIN needs to take a different approach than other RIRs ? If they are, perhaps a confederation design instead of centralized one would help scatter those risks ?

Rubens -

   It is true that US has an abundance of litigation, and while this doesn't require
   a different approach than other regions, it does often mean that we're far more
   conservative in both technical and legal approaches initially. ARIN's RPA is
   a typical example, in that it has allowed us to rollout the service in a timely
   manner that would not have otherwise been possible. Now that there is
   some operational experience, it's possible to review the experience and
   see if a more relaxed risk posture can be accommodated.

FYI
/John

John Curran
President and CEO
ARIN

8

We signed our ROAs but we wont be validating anything from the ARIN region.
I believe you will find this to be the norm. The tool provided by RIPE also
ignores ARIN by default.

Someone will probably tell me that I am being arrogant again, but basically
you are asking me to help protect your routes. And you want me to sign
something first. I am not going to even read that agreement. I do not
believe I am alone in this.

Well the tool is designed to prevent you being fooled by people
injecting bogus routing information. If you wish to continue to
be fooled so be it.

If I was running a ISP I wouldn't want to be in the position of
explaining why I was accepting bogus routes when I have the way to
reject them.

The agreement is that if you run the tool and there is a mistake
in the data or the servers are not available that you won't sue
ARIN for the mistake.

Mark

9

I care mostly about routes to destinations close to me. If someone
steals a route from someone on other side of the world everyone will
rightly assume it is the other guys having trouble. Plus we simply do not
have much traffic there. On the other hand it adds up for the target if
many ISPs around the world is fooled.

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.

Regards

Baldur

> We signed our ROAs but we wont be validating anything from the ARIN

region.

> I believe you will find this to be the norm. The tool provided by RIPE

also

> ignores ARIN by default.
>
> Someone will probably tell me that I am being arrogant again, but

basically

10

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. :slight_smile:

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

11

Alex -

  Thanks for sharing your observations from RPKI deployment
  in the RIPE region - it's very helpful for those trying to
  understand how RPKI might affect their operations. :slight_smile:

Thanks again!
/John