Followup: Survey results for the ARIN RPA
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.
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
On Dec 7, 2014, at 9:40 PM, Randy Bush <randy@psg.com> wrote:
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.
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
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
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
In message <CAPkb-7DmELgaD0F=paXdJZuPgi5vqP0Pp8ysYSL+GkXLDMJU2Q@mail.gmail.com> , Baldur Norddahl writes:
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
Regards
Baldur -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
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 Den 08/12/2014 23.46 skrev "Mark Andrews" <marka@isc.org>:
In message <CAPkb-7DmELgaD0F=
paXdJZuPgi5vqP0Pp8ysYSL+GkXLDMJU2Q@mail.gmail.com>
, Baldur Norddahl writes:
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
Regards
Baldur -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
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
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. :-) Thanks again! /John
On Dec 9, 2014, at 10:23 AM, Alex Band <alexb@ripe.net> wrote:
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
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
On Dec 8, 2014, at 1:13 PM, Rubens Kuhl <rubensk@gmail.com<mailto:rubensk@gmail.com>> wrote: 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
participants (7)
-
Alex Band
-
Andrew Gallo
-
Baldur Norddahl
-
John Curran
-
Mark Andrews
-
Randy Bush
-
Rubens Kuhl