ARIN RPKI TAL deployment issues
Dear NANOG, I'd like to draw attention to a very concerning development: it appears that the ARIN TAL is not as widely deployed as other RPKI TALs (such as RIPE or APNIC's TAL). This means that ARIN members are needlessly put at higher risk. Ben Cartwright-Cox performed RPKI research a few weeks ago where he compared the (un)reachability of RPKI Invalid announcements using ARIN, RPKI, APNIC and JPNIC space. The full write-up is available here: https://blog.benjojo.co.uk/post/are-bgps-security-features-working-yet-rpki I quote Ben's assessment: """Using the data, we can also see that the providers that have not downloaded the ARIN TAL. Either because they were not aware that they needed to, or could not agree to the agreement they have with it. This is frustrating to watch. Since it means that ROA signing ARIN prefixes will be less secure than ROA signing others, until these restrictions are abolished. Even after that it will have a long term knock on effect as software updates take a long time to propagate to end networks.""" In other words, when creating RPKI ROAs for your resources, ARIN members are getting *LESS* in return compared to say RIPE members. As ARIN member I'd hope and expect the ARIN organisation to go above and beyond to distribute their RPKI TAL as widely as possible. (Think: proactively submitting the ARIN TAL to relevant open source projects, making the TAL available for download without restrictions or limitations). At the NANOG 74 meeting David Whisnick will talk about legal barriers to RPKI adoption and he'll offer suggestions for reform. I think Ben's observation that the ARIN TAL is less widely deployed is a direct result from the legal barriers that David identified. https://pc.nanog.org/static/published/meetings//NANOG74/daily/day_2.html#tal... I fear that if no action is taken (e.g. when none of the RPKI Cache Validators can include the ARIN TAL in their software distribution [1]), we'll continue to see the gap between ARIN and the other RIRs widen. Software developers have indicated that the RPA is problematic and prevents BGP implementations from shipping "secure by default" software: https://lists.arin.net/pipermail/arin-consult/2018-April/001087.html When ARIN members create ROAs, I assume those members would also like networks *outside* the ARIN region to honor those ROAs and help prevent propagation of incorrect BGP announcements. The ARIN member and the operator of the foreign network may not even have any languages in common! I fear that limited deployment of the ARIN TAL is detrimental to the business interests of resource holders in the ARIN region. Kind regards, Job [1]: https://github.com/NLnetLabs/routinator/commit/b1e70746bb3768554fa439c5ced4e...
On Sep 25, 2018, at 1:30 PM, Job Snijders <job@ntt.net> wrote:
"""Using the data, we can also see that the providers that have not downloaded the ARIN TAL. Either because they were not aware that they needed to, or could not agree to the agreement they have with it.
Job - Is it possible to ascertain how many of those who have not downloaded the ARIN TAL are also publishing ROA’s via RIPE’s CA? /John
On Tue, Sep 25, 2018 at 03:07:54PM -0400, John Curran wrote:
On Sep 25, 2018, at 1:30 PM, Job Snijders <job@ntt.net> wrote:
"""Using the data, we can also see that the providers that have not downloaded the ARIN TAL. Either because they were not aware that they needed to, or could not agree to the agreement they have with it.
Is it possible to ascertain how many of those who have not downloaded the ARIN TAL are also publishing ROA’s via RIPE’s CA?
I'm sure we could extend the data set to figure this out. But given the assymmetric relation between applying Origin Validation based on RPKI data and publishing ROAs, the number will be between 0% and 100% and over time may go up or down. So, out of curiosity, what is your underlaying question? (An example: a route server operator generally doesn't originate any BGP announcements themselves, but route servers are in an ideal position to perform RPKI based BGP Origin Validation.) What I'm hoping for is that there is a way for the ARIN TAL to be included in software distributions, without compromising ARIN's legal position. Perhaps an exception for software distributors would already go a long way? "You can include the ARIN TAL in your software distribution as long as you also include an unmodified copy of the https://www.arin.net/resources/rpki/rpa.pdf file alongside it." Kind regards, Job
Job Snijders wrote : (An example: a route server operator generally doesn't originate any BGP announcements themselves, but route servers are in an ideal position to perform RPKI based BGP Origin Validation.)
Indeed. Also, an IX should have an RPKI validator accessible by its members, and the RPA makes that impossible. IMHO, the RPA is too restrictive. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...
Sounds reasonable to me but IANAL, nor an RIR, nor an IXP. IXPs however do seem to be the sites of some number of recent mis-originations (putting it as charitably as possible). Let's try and make it harder for bad actors to do their mischief. Thanks, Tony On Tue, Sep 25, 2018 at 3:36 PM Job Snijders <job@ntt.net> wrote:
On Tue, Sep 25, 2018 at 03:07:54PM -0400, John Curran wrote:
On Sep 25, 2018, at 1:30 PM, Job Snijders <job@ntt.net> wrote:
"""Using the data, we can also see that the providers that have not downloaded the ARIN TAL. Either because they were not aware that they needed to, or could not agree to the agreement they have with it.
Is it possible to ascertain how many of those who have not downloaded the ARIN TAL are also publishing ROA’s via RIPE’s CA?
I'm sure we could extend the data set to figure this out. But given the assymmetric relation between applying Origin Validation based on RPKI data and publishing ROAs, the number will be between 0% and 100% and over time may go up or down. So, out of curiosity, what is your underlaying question?
(An example: a route server operator generally doesn't originate any BGP announcements themselves, but route servers are in an ideal position to perform RPKI based BGP Origin Validation.)
What I'm hoping for is that there is a way for the ARIN TAL to be included in software distributions, without compromising ARIN's legal position.
Perhaps an exception for software distributors would already go a long way?
"You can include the ARIN TAL in your software distribution as long as you also include an unmodified copy of the https://www.arin.net/resources/rpki/rpa.pdf file alongside it."
Kind regards,
Job
On 25 Sep 2018, at 3:34 PM, Job Snijders <job@ntt.net> wrote:
On Tue, Sep 25, 2018 at 03:07:54PM -0400, John Curran wrote:
On Sep 25, 2018, at 1:30 PM, Job Snijders <job@ntt.net> wrote:
"""Using the data, we can also see that the providers that have not downloaded the ARIN TAL. Either because they were not aware that they needed to, or could not agree to the agreement they have with it.
Is it possible to ascertain how many of those who have not downloaded the ARIN TAL are also publishing ROA’s via RIPE’s CA?
I'm sure we could extend the data set to figure this out.
It would be informative to know how many organizations potentially have concerns about the indemnification clause in the RPA but already agree to indemnification via RIPE NCC Certification Service Terms and Conditions. Thanks! /John John Curran President and CEO ARIN
Dear John, On Tue, Sep 25, 2018 at 08:28:54PM +0000, John Curran wrote:
On 25 Sep 2018, at 3:34 PM, Job Snijders <job@ntt.net> wrote:
On Tue, Sep 25, 2018 at 03:07:54PM -0400, John Curran wrote:
On Sep 25, 2018, at 1:30 PM, Job Snijders <job@ntt.net> wrote:
"""Using the data, we can also see that the providers that have not downloaded the ARIN TAL. Either because they were not aware that they needed to, or could not agree to the agreement they have with it.
Is it possible to ascertain how many of those who have not downloaded the ARIN TAL are also publishing ROA’s via RIPE’s CA?
I'm sure we could extend the data set to figure this out.
It would be informative to know how many organizations potentially have concerns about the indemnification clause in the RPA but already agree to indemnification via RIPE NCC Certification Service Terms and Conditions.
This seems a matter of personal curiosity that perhaps distracts from the problem at hand: the ARIN TAL is less widely deployed than the other TALs. I'm open to solutions or suggestions to get the ARIN TAL more widely distributed, however I do think that inclusion in the RPKI Cache Validators is a *key* element, so the ARIN TAL can be used after a default installation of such software. We really need to bring it back down to "apt install rpki-cache-validator" to best serve the interests of the ARIN members. Imagine the Chrome browser shipping without any of the TLS Root Certificates, or Unbound without the DNSSEC root key! Kind regards, Job
On 25 Sep 2018, at 5:04 PM, Job Snijders <job@ntt.net> wrote:
It would be informative to know how many organizations potentially have concerns about the indemnification clause in the RPA but already agree to indemnification via RIPE NCC Certification Service Terms and Conditions.
This seems a matter of personal curiosity that perhaps distracts from the problem at hand: the ARIN TAL is less widely deployed than the other TALs.
Job - I would have to disagree regarding whether question of indemnification is a simply a distraction… It has been raised by the operator community multiple times, and in fact, you indirectly reference the same issue by quoting a sentence in the write-up within your post -
I quote Ben's assessment:
"""Using the data, we can also see that the providers that have not downloaded the ARIN TAL. Either because they were not aware that they needed to, or could not agree to the agreement they have with it.”"
I believe that you correctly characterize the situation; i.e: 1) Either they were not aware they needed it (note this is trivial to fix with outreach/education and requires skills well within the range of anyone who is going to be doing routing validation based on RPKI data), or 2) They could not agree to ARIN RPA agreement (for which the most cited reason is the indemnification clause, but perplexing given agreement to other indemnification clauses such as RIPE’s Certification services.) Further analysis and characterization of those not using the ARIN TAL would help enormously in understanding which of the scenarios above is dominant, and prioritize efforts for addressing the situation. Thanks! /John John Curran President and CEO ARIN
On Tue, Sep 25, 2018 at 09:17:56PM +0000, John Curran wrote:
On 25 Sep 2018, at 5:04 PM, Job Snijders <job@ntt.net> wrote:
It would be informative to know how many organizations potentially have concerns about the indemnification clause in the RPA but already agree to indemnification via RIPE NCC Certification Service Terms and Conditions.
This seems a matter of personal curiosity that perhaps distracts from the problem at hand: the ARIN TAL is less widely deployed than the other TALs.
I would have to disagree regarding whether question of indemnification is a simply a distraction… It has been raised by the operator community multiple times, and in fact, you indirectly reference the same issue by quoting a sentence in the write-up within your post -
I quote Ben's assessment:
"""Using the data, we can also see that the providers that have not downloaded the ARIN TAL. Either because they were not aware that they needed to, or could not agree to the agreement they have with it.”"
I believe that you correctly characterize the situation; i.e:
1) Either they were not aware they needed it (note this is trivial to fix with outreach/education and requires skills well within the range of anyone who is going to be doing routing validation based on RPKI data), or
My assessment (based on the data Ben collected) is that the current outreach & education are failing to accomplish the goal of widely distributing the ARIN TAL, and I fear this may get worse over time.
2) They could not agree to ARIN RPA agreement (for which the most cited reason is the indemnification clause, but perplexing given agreement to other indemnification clauses such as RIPE’s Certification services.)
It may make sense to associate an implicit agreement (or perhaps a license?) with the ARIN TAL to limit risks to the ARIN organisation. "Use at your own risk"-style clauses are common and acceptable. In section 5 ("prohibited conduct") of the RPA I read: "You shall not, directly or indirectly, disclose, share, divulge, link to, rebroadcast, provide access to or in any other way make available the TAL to any third party, except as permitted by the ORCP Service Terms." I believe this prevents OpenBSD, Cisco, Juniper, etc... from shipping their operating system with a copy of the ARIN TAL, and as far as I understand is the reason that RIPE NCC's RPKI Cache Validator and the NLNetLabs RPKI Validator don't include the ARIN TAL either.
Further analysis and characterization of those not using the ARIN TAL would help enormously in understanding which of the scenarios above is dominant, and prioritize efforts for addressing the situation.
I'd like to frame the discussion in context of what software developers and distributors can do to be able to include the ARIN TAL (by default) rather than focus on getting thousands of organisations to separately download & install a TAL file. The latter approach doesn't scale. We're both at NANOG next week, I'd love to sit down and have a cup of coffee. Kind regards, Job
On 25 Sep 2018, at 5:51 PM, Job Snijders <job@ntt.net<mailto:job@ntt.net>> wrote: ... It may make sense to associate an implicit agreement (or perhaps a license?) with the ARIN TAL to limit risks to the ARIN organisation. "Use at your own risk"-style clauses are common and acceptable. Job - We did look at using a specific set of terms (rather similar to the indeminifcation used by the RIPE in their RPKI Certification Services terms) via a referenced agreement for this purpose, but making that actually legally binding in the US legal environment is a bit challenging. Absent a specific action (such as our present “browserwrap” approach of specifically downloading the TAL), US courts have not generally recognized mere usage of software as an indication of informed consent to enter into an agreement – hence the RPA download, and why so many things in the US require some form of explicit acknowledgement in order to proceed. I'd like to frame the discussion in context of what software developers and distributors can do to be able to include the ARIN TAL (by default) rather than focus on getting thousands of organisations to separately download & install a TAL file. The latter approach doesn't scale. We're both at NANOG next week, I'd love to sit down and have a cup of coffee. Quite understandable - I suspend we’ll hear some more about these issues during David Wishnick’s session, and coffee-fueled discussion afterwards is encouraged. Thanks! /John John Curran President and CEO American Registry for Internet Numbers
John,
John Curran wrote : 2) They could not agree to ARIN RPA agreement (for which the most cited reason is the indemnification clause, but perplexing given agreement to other indemnification clauses such as RIPE’s Certification services.)
I would entertain that "could not agree to ARIN RPA" is why they don't use the TAL. I may not be representative, but I knew I had to download it. And maybe you missed a third possibility : 3) Nobody really cares about the ARIN TAL because almost nobody has validated a prefix within the ARIN region therefore installing the ARIN TAL is almost useless :-( We don't only have a problem withTAL deployment, we also have an adoption issue. And possibly an egg-and-chicken issue : nobody deploys the TAL because nobody validates their prefixes, and vice versa. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...
On Sep 25, 2018, at 7:55 PM, Michel Py <michel.py@tsisemi.com> wrote:
John,
John Curran wrote : 2) They could not agree to ARIN RPA agreement (for which the most cited reason is the indemnification clause, but perplexing given agreement to other indemnification clauses such as RIPE’s Certification services.)
I would entertain that "could not agree to ARIN RPA" is why they don't use the TAL. I may not be representative, but I knew I had to download it. And maybe you missed a third possibility : 3) Nobody really cares about the ARIN TAL because almost nobody has validated a prefix within the ARIN region therefore installing the ARIN TAL is almost useless :-(
We don't only have a problem withTAL deployment, we also have an adoption issue. And possibly an egg-and-chicken issue : nobody deploys the TAL because nobody validates their prefixes, and vice versa.
Actually there are prefixes in the ARIN region with ROAs, and one would presume that issuing the ROA means you want it to be validated as well. (Similar to hosting a website on SSL vs HTTP or even gopher://) The intent is at least there, and similar to DNSSEC, publishing your DS record in the parent is part of that explicit configured intent. Saying “nobody validates their prefixes” is patently false. You may not. I may not, but there are a number of networks that are and have advertised that they are. I’m not saying you need to secure your network, but if you want to secure your routes and have an allocation from ARIN, you really need their TAL to be in the default trust store similar to how you have your PKI trust store in your OS, Browser, etc… I need my local geographic RIR to care that their anchor is included by default and to make it clear that distributing the TAL is different from _using_ the TAL. Just because I have CA roots in my browser trust store does not mean I am using them all, but if I need to it will work. On my Mac when I upgrade Xcode it often asks me to accept the License for what I downloaded. The same is true if you use gnu parallel, it outputs some wonderful legalese. There are many comparisons, which is why I’m asking that ARIN permit developers to make it easier for end-users to use the PKI material that makes the global ecosystem more complete and secure. If to start you have to edit the config file to say “I accept arin license for this”=yes would that work? We need that outreach and clarity because at present it’s not there by default and there is a communication gap between the various developers and ARIN. Those that are issuing ROAs (or are soon to) depend on this. Like I said previously, I’m going to be talking to each ARIN candidate for election this fall about this very topic and what actions they intend to do to support global secure routing. Michel, It would be a shame if you created a ROA and it could not be validated in some non-english speaking corner of the world that put your assets at risk due to this posture. The community needs secure by default for all regions and the barriers for ARIN IP space are a real and measured problem. It’s time to end this disparity as right now not all TALs are equal. They should be. - Jared
Jared,
Jared Mauch wrote : Saying “nobody validates their prefixes” is patently false. You may not. I may not, but there are a number of networks that are and have advertised that they are.
I did validate mine, but in the ARIN region I'm part of the only 2% that did, that's close enough to "nobody" for me, in context compared to RIPE numbers.
Michel, It would be a shame if you created a ROA and it could not be validated in some non-english speaking corner of the world that put your assets at risk due to this posture. The community needs secure by default for all regions and the barriers for ARIN IP space are a real and measured problem. It’s time to end this disparity as right now not all TALs are equal. They should be.
I agree, but it's not that simple. The main issue I currently see with RPKI / ROA is not the ARIN TAL (altough I am directly affected) but the fact that nobody or almost nobody actually enforces RPKI. Most operators who are validating RPKI prefixes keep carrying them even when they are invalid, which makes the entire thing completely useless. And yes I know, it's not that simple ;-) And it may be shameless self-plugin, but I think we need to encourage experiments that actually try to enforce RPKI. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...
On Tue, 25 Sep 2018, Job Snijders wrote:
We really need to bring it back down to "apt install rpki-cache-validator"
You say this as if no packager has a way to display and perhaps require approval of the license nor any way to fetch something remote as part of the installation process, e.g., the Microsoft "freely" supplied TTF files ... # zypper install fetchmsttfonts [...packager stuff...] (1/1) Installing: fetchmsttfonts-11.4-42.28.noarch .........................................[done] Running: fetchmsttfonts-11.4-42.28-fetchmsttfonts.sh.txt (fetchmsttfonts, /var/adm/update-scripts) EULA: END-USER LICENSE AGREEMENT FOR MICROSOFT SOFTWARE IMPORTANT-READ CAREFULLY: This Microsoft End-User License Agreement ("EULA") is a legal agreement between you (either an individual or a single entity) and [...] andale32.exe (https://sourceforge.net/projects/corefonts/files/the%20fonts/final/andale32....): Fetching ... done Extracting ... done [...] I bet apt, dnf, pacman, pkg_add, yum, etc., do as well -- actually I know some of those do. Perhaps fetching as part of installing is less desireable than already present at the outset, but it might appease ARIN and be workable (or superior) for many. /mark
On 26 Sep 2018, at 5:18 PM, Mark Milhollan <mlm@pixelgate.net> wrote:
On Tue, 25 Sep 2018, Job Snijders wrote:
We really need to bring it back down to "apt install rpki-cache-validator"
You say this as if no packager has a way to display and perhaps require approval of the license nor any way to fetch something remote as part of the installation process, e.g., the Microsoft "freely" supplied TTF files … ... I bet apt, dnf, pacman, pkg_add, yum, etc., do as well -- actually I know some of those do. Perhaps fetching as part of installing is less desireable than already present at the outset, but it might appease ARIN and be workable (or superior) for many.
Mark - Agreed: operationally it should be relatively straightforward with most installation tools, but ARIN could help significantly be making it clear this sort of approach is acceptable with its service terms and detailing any specific requirements (as none of that is clear at present.) I’m working on this issue now, and should be able to report back shortly regarding specifics necessary to allow easier access to the ARIN TAL during package installation. Thanks! /John John Curran President and CEO ARIN
On 2018-09-26, Mark Milhollan <mlm@pixelgate.net> wrote:
On Tue, 25 Sep 2018, Job Snijders wrote:
We really need to bring it back down to "apt install rpki-cache-validator"
You say this as if no packager has a way to display and perhaps require approval of the license nor any way to fetch something remote as part of the installation process, e.g., the Microsoft "freely" supplied TTF files ...
# zypper install fetchmsttfonts [...packager stuff...] (1/1) Installing: fetchmsttfonts-11.4-42.28.noarch .........................................[done] Running: fetchmsttfonts-11.4-42.28-fetchmsttfonts.sh.txt (fetchmsttfonts, /var/adm/update-scripts) EULA: END-USER LICENSE AGREEMENT FOR MICROSOFT SOFTWARE
IMPORTANT-READ CAREFULLY: This Microsoft End-User License Agreement ("EULA") is a legal agreement between you (either an individual or a single entity) and [...] andale32.exe (https://sourceforge.net/projects/corefonts/files/the%20fonts/final/andale32....): Fetching ... done Extracting ... done [...]
I bet apt, dnf, pacman, pkg_add, yum, etc., do as well -- actually I know some of those do.
Some do, some don't. As far as OpenBSD is concerned, pkg_add will install signed packages distributed by OpenBSD, they can only do that if free redistribution is possible. For things like the Microsoft fonts, they can be installed, but by a different process which is a lot more work. There's a big difference between this and something like the Microsoft fonts in your example: the fonts are clearly creative work and copyrightable. A generated integer in an RFC-specified format? That seems less likely.
On Wed, Sep 26, 2018 at 02:18:43PM -0700, Mark Milhollan wrote:
On Tue, 25 Sep 2018, Job Snijders wrote:
We really need to bring it back down to "apt install rpki-cache-validator"
You say this as if no packager has a way to display and perhaps require approval of the license nor any way to fetch something remote as part of the installation process, e.g., the Microsoft "freely" supplied TTF files ... [...]
I bet apt, dnf, pacman, pkg_add, yum, etc., do as well -- actually I know some of those do. Perhaps fetching as part of installing is less desireable than already present at the outset, but it might appease ARIN and be workable (or superior) for many.
rpm/yum/dnf do NOT have a way to allow the installation of packages to interact with the user. They specifically block this functionality since it goes against their design of allowing non-interactive installs.
Folks - Perhaps it would be helpful to confirm that we have common goals in the network operator community regarding RPKI, and then work from those goals on the necessary plans to achieve them. It appears that many network operators would like to improve the integrity of their network routing via RPKI deployment. The Regional Internet Registries (RIRs) have all worked to support RPKI services, and while there are different opinions among operators regarding the cost/benefit tradeoffs of RPKI Route Origin Validation (ROV), it is clear that we have to collectively work together now if we are ever to have overall RPKI deployment sufficient to create the network effects that will ensure compelling long-term value for its deployment. Let’s presume that we’ve achieved that very outcome at some point in future; i.e. we’re have an Internet where nearly all network operators are publishing Route Origin Authorizations (ROAs) via RIR RPKI services and are using RPKI data for route validation. It is reasonable to presume that over the next decade the Internet will become even more pervasive in everyday life, including being essential for many connected devices to function, and relied upon for everything from daily personal communication and conducting business to even more innovative uses such as payment & sale systems, delivery of medical care, etc. Recognizing that purpose of RPKI is improve integrity of routing, and not add undo fragility to the network, it is reasonable to expect that many network operators will take due care with the introduction of route validation into their network routing, including best practices such as falling back successfully in the event of unavailability of an RIR RPKI Certificate Authority (CA) and resulting cache timeouts. It is also reasonable expect that RIR RPKI CA services are provisioned with appropriate robustness of systems and controls that befit the highly network-critical nature of these services. Presuming we all share this common goal, the question that arises is whether we have a common vision regarding what should happen when something goes wrong in this wonderful RPKI-rich Internet of the future… More than anyone, network operators realize that even with excellent systems, procedures, and redundancy, outages can (and do) still occur. Hopefully, these are quite rare, and limited to occasions where Murphy’s Law has somehow resulted in nearly unimaginable patterns of coincident failures, but it would irresponsible to not consider the “what if” scenarios for RPKI failure and whether there is shared vision of the resulting consequences. In particular, it would be good to consider the case of an RIR RPKI CA system failure, one sufficient to result in widespread cache expirations for relying parties. Ideally, we will never have to see this scenario when RPKI is widely deployed, but it also not completely inconceivable that an RIR RPKI CA experience such an outage [1]. For network operators following reasonable deployment practices, an RIR RPKI CA outage should result in a fallback to unvalidated network routing data and no significant network impacts. However, it’s likely not a reasonable assumption that all network operators will have properly designed and implemented best practices in this regard, so there will very likely be some networks that experience significant impacts consequential to any RIR RPKI CA outage. Even if this is only 1 or 2 percent of network operators with such configuration issues, it will mean hundreds of ISP outages occurring simultaneously throughout the Internet and millions of customers (individuals and businesses) effected globally. While the Internet is the world’s largest cooperative endeavor, there inevitably will be many folks impacted of a RIR RPKI outage, including some asking (appropriately) the question of “who should bear responsibility” for the harm that they suffered. It is worth understanding what the network community believes is the most appropriate answer to this question, since a common outlook on this question can be used to guide implementation details to match. Additionally, a common understanding on this question will provide real insight into how the network community intends risk of the system to be distributed among the participants. There are several possible options worth considering: A) The most obvious answer for the party that should be held liable for the impacts that result from an RPKI CA failure would be the respective RIR that experienced the outage. This seems rather straightforward until one considers that the RIRs are providing these services specifically noting that they may not be (despite all precautions) available 100% percent of the time, and clearly documented expectations that those relying on RPKI CA information for routing origin validation should be fallback to routing with not validated state [2]. The impacted parties are those customers of ISPs that improperly handled the unavailability of RPKI data; thus escalating situation into a network-affecting outage. Under these circumstances, directing the claims from customers of all the improperly-configured ISP’s to the RIR completely ignores the responsibility of these ISPs to prepare for this precise eventuality, as was done by the fellow network operators. B) One of the more interesting theories on who should be held liable is that those who are publishing ROA’s are the appropriate responsible parties in the event of RPKI CA failure; one can achieve such a position on the logic that they consciously decided to use RPKA CA services and thus asserted globally that they would henceforth have validated routes – an RPKI CA failure is a case of their “vendor" (the RIR) letting them down on the publication. This also has equity issues, since those publishing ROA information don’t have a clear contributory role, and the damages accruing to them are coming from customers from those operators who failed their duty. C) Another potential answer for the party that should be responsible is that each of the ISPs that failed to appropriately configure their route validation and thus experience a network outage should be responsible for their own customers impacted as a result. In addition to keeping the liability proportional to the customers served, this encourages each such ISP to consider appropriate corrective measures. It is possible to architect the various legalities surrounding RPKI to support any of the above outcomes, but it first requires a shared understanding of what the network community believes is the correct outcome. There is likely some on the nanog mailing list who have a view on this matter, so I pose the question of "who should be responsible" for consequences of RPKI RIR CA failure to this list for further discussion. Thanks! /John John Curran President and CEO American Registry for Internet Numbers (ARIN) [1] https://www.ietf.org/mail-archive/web/sidr/current/msg05621.html [2] https://www.rfc-editor.org/rfc/rfc7115.txt
Hello, To avoid any misunderstanding in this discussion going forward, I would like to reiterate that an RPKI ROA is a positive attestation. An unavailable, expired or invalid ROA will result in a BGP announcement with the status NotFound. The announcement will *not* become INVALID, thereby being dropped. Please read Section 5 of RFC 7115 that John linked carefully: Bush Best Current Practice [Page 7] RFC 7115 RPKI-Based Origin Validation Op January 2014 Announcements with NotFound origins should be preferred over those with Invalid origins. Announcements with Invalid origins SHOULD NOT be used, but may be used to meet special operational needs. In such circumstances, the announcement should have a lower preference than that given to Valid or NotFound. Thus, a continued outage of an RPKI CA (or publication server) will result in announcements with status NotFound. This means that the prefixes held by this CA will no longer benefit from protection by the RPKI. However, since only *invalid* announcements should be dropped, this should not lead to large scale outages in routing. It is important to be aware of the impact of such an outage when considering questions of liability. Kind regards, Alex Band NLnet Labs
On 1 Oct 2018, at 01:21, John Curran <jcurran@arin.net> wrote:
Folks -
Perhaps it would be helpful to confirm that we have common goals in the network operator community regarding RPKI, and then work from those goals on the necessary plans to achieve them.
It appears that many network operators would like to improve the integrity of their network routing via RPKI deployment. The Regional Internet Registries (RIRs) have all worked to support RPKI services, and while there are different opinions among operators regarding the cost/benefit tradeoffs of RPKI Route Origin Validation (ROV), it is clear that we have to collectively work together now if we are ever to have overall RPKI deployment sufficient to create the network effects that will ensure compelling long-term value for its deployment.
Let’s presume that we’ve achieved that very outcome at some point in future; i.e. we’re have an Internet where nearly all network operators are publishing Route Origin Authorizations (ROAs) via RIR RPKI services and are using RPKI data for route validation. It is reasonable to presume that over the next decade the Internet will become even more pervasive in everyday life, including being essential for many connected devices to function, and relied upon for everything from daily personal communication and conducting business to even more innovative uses such as payment & sale systems, delivery of medical care, etc.
Recognizing that purpose of RPKI is improve integrity of routing, and not add undo fragility to the network, it is reasonable to expect that many network operators will take due care with the introduction of route validation into their network routing, including best practices such as falling back successfully in the event of unavailability of an RIR RPKI Certificate Authority (CA) and resulting cache timeouts. It is also reasonable expect that RIR RPKI CA services are provisioned with appropriate robustness of systems and controls that befit the highly network-critical nature of these services.
Presuming we all share this common goal, the question that arises is whether we have a common vision regarding what should happen when something goes wrong in this wonderful RPKI-rich Internet of the future… More than anyone, network operators realize that even with excellent systems, procedures, and redundancy, outages can (and do) still occur. Hopefully, these are quite rare, and limited to occasions where Murphy’s Law has somehow resulted in nearly unimaginable patterns of coincident failures, but it would irresponsible to not consider the “what if” scenarios for RPKI failure and whether there is shared vision of the resulting consequences.
In particular, it would be good to consider the case of an RIR RPKI CA system failure, one sufficient to result in widespread cache expirations for relying parties. Ideally, we will never have to see this scenario when RPKI is widely deployed, but it also not completely inconceivable that an RIR RPKI CA experience such an outage [1]. For network operators following reasonable deployment practices, an RIR RPKI CA outage should result in a fallback to unvalidated network routing data and no significant network impacts. However, it’s likely not a reasonable assumption that all network operators will have properly designed and implemented best practices in this regard, so there will very likely be some networks that experience significant impacts consequential to any RIR RPKI CA outage. Even if this is only 1 or 2 percent of network operators with such configuration issues, it will mean hundreds of ISP outages occurring simultaneously throughout the Internet and millions of customers (individuals and businesses) effected globally. While the Internet is the world’s largest cooperative endeavor, there inevitably will be many folks impacted of a RIR RPKI outage, including some asking (appropriately) the question of “who should bear responsibility” for the harm that they suffered.
It is worth understanding what the network community believes is the most appropriate answer to this question, since a common outlook on this question can be used to guide implementation details to match. Additionally, a common understanding on this question will provide real insight into how the network community intends risk of the system to be distributed among the participants.
There are several possible options worth considering:
A) The most obvious answer for the party that should be held liable for the impacts that result from an RPKI CA failure would be the respective RIR that experienced the outage. This seems rather straightforward until one considers that the RIRs are providing these services specifically noting that they may not be (despite all precautions) available 100% percent of the time, and clearly documented expectations that those relying on RPKI CA information for routing origin validation should be fallback to routing with not validated state [2]. The impacted parties are those customers of ISPs that improperly handled the unavailability of RPKI data; thus escalating situation into a network-affecting outage. Under these circumstances, directing the claims from customers of all the improperly-configured ISP’s to the RIR completely ignores the responsibility of these ISPs to prepare for this precise eventuality, as was done by the fellow network operators.
B) One of the more interesting theories on who should be held liable is that those who are publishing ROA’s are the appropriate responsible parties in the event of RPKI CA failure; one can achieve such a position on the logic that they consciously decided to use RPKA CA services and thus asserted globally that they would henceforth have validated routes – an RPKI CA failure is a case of their “vendor" (the RIR) letting them down on the publication. This also has equity issues, since those publishing ROA information don’t have a clear contributory role, and the damages accruing to them are coming from customers from those operators who failed their duty.
C) Another potential answer for the party that should be responsible is that each of the ISPs that failed to appropriately configure their route validation and thus experience a network outage should be responsible for their own customers impacted as a result. In addition to keeping the liability proportional to the customers served, this encourages each such ISP to consider appropriate corrective measures.
It is possible to architect the various legalities surrounding RPKI to support any of the above outcomes, but it first requires a shared understanding of what the network community believes is the correct outcome. There is likely some on the nanog mailing list who have a view on this matter, so I pose the question of "who should be responsible" for consequences of RPKI RIR CA failure to this list for further discussion.
Thanks! /John
John Curran President and CEO American Registry for Internet Numbers (ARIN)
[1] https://www.ietf.org/mail-archive/web/sidr/current/msg05621.html [2] https://www.rfc-editor.org/rfc/rfc7115.txt
On 1/Oct/18 09:47, Alex Band wrote:
Thus, a continued outage of an RPKI CA (or publication server) will result in announcements with status NotFound. This means that the prefixes held by this CA will no longer benefit from protection by the RPKI. However, since only *invalid* announcements should be dropped, this should not lead to large scale outages in routing.
Indeed, and this is on the basis that operators are not overzealous about aggressively acting against a "NotFound" RPKI state. Mark.
On 1 Oct 2018, at 12:47 AM, Alex Band <alex@nlnetlabs.nl> wrote:
Hello,
To avoid any misunderstanding in this discussion going forward, I would like to reiterate that an RPKI ROA is a positive attestation. An unavailable, expired or invalid ROA will result in a BGP announcement with the status NotFound. The announcement will *not* become INVALID, thereby being dropped.
Please read Section 5 of RFC 7115 that John linked carefully: ...
Thus, a continued outage of an RPKI CA (or publication server) will result in announcements with status NotFound. This means that the prefixes held by this CA will no longer benefit from protection by the RPKI. However, since only *invalid* announcements should be dropped, this should not lead to large scale outages in routing.
Alex - Yes – ISPs who have configured RPKI route validation and are using it to preference routes should continue to utilize routes that are have NotFound status due to lack of RPKI repository data. As RFC 7115 notes - " Hence, an operator's policy should not be overly strict and should prefer Valid announcements; it should attach a lower preference to, but still use, NotFound announcements, and drop or give a very low preference to Invalid announcements. " Of course, this presumes correct routing configuration by the ISP when setting up RPKI route validation; while one would hope that the vast majority handle this situation correctly, there is no assurance that will be true without exception. If RPKI routing validation is widely deployed, tens of thousands of ISPs will be setting up such a configuration, with customer impact during an RPKI CA outage occurring for those who somehow failure to fall back to using NotFound routes. If only a small percentage get this wrong, it will still represent dozens of ISPs going dark as a result.
It is important to be aware of the impact of such an outage when considering questions of liability.
Indeed… Hence the question of liability during a RIR CA outage, should the liability for misconfigured ISPs (those handful of ISPs who do not properly fall back to using state NotFound routes) be the responsibility of each ISP, or perhaps those who announce ROAs, or should be with the RIR? Thanks! /John John Curran President and CEO ARIN
On 1/Oct/18 10:26, John Curran wrote:
Of course, this presumes correct routing configuration by the ISP when setting up RPKI route validation; while one would hope that the vast majority handle this situation correctly, there is no assurance that will be true without exception. If RPKI routing validation is widely deployed, tens of thousands of ISPs will be setting up such a configuration, with customer impact during an RPKI CA outage occurring for those who somehow failure to fall back to using NotFound routes. If only a small percentage get this wrong, it will still represent dozens of ISPs going dark as a result.
It is equally important to understand how vendors have interpreted the RFC for default treatment of RPKI data. When we started testing IOS and IOS XE back in 2014/2015, we hit an issue where Cisco were automatically applying policy to RPKI state without configuration from the operator. This was fixed in later code, but goes to show that one should not assume that vendors are always doing the right thing, or at the very least, fully understand what their view on RPKI might be on the wider Internet, in real production. So before deploying network-wide, I encourage operators to test what their equipment will do when RPKI is enabled but without any manual policy applied.
Indeed… Hence the question of liability during a RIR CA outage, should the liability for misconfigured ISPs (those handful of ISPs who do not properly fall back to using state NotFound routes) be the responsibility of each ISP, or perhaps those who announce ROAs, or should be with the RIR?
Any equipment misconfigurations should be the responsibility of the operator. Responsibility for ROA's should lie with the resource holder, in ensuring that not only is the information true, but that also all announced prefixes are covered by a ROA. An RIR CA outage would, in my mind, be the responsibility of the RIR. But this comes back to my question of how this handled with an "all resource" TA. Mark.
On Oct 1, 2018, at 4:36 AM, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 1/Oct/18 10:26, John Curran wrote:
Indeed… Hence the question of liability during a RIR CA outage, should the liability for misconfigured ISPs (those handful of ISPs who do not properly fall back to using state NotFound routes) be the responsibility of each ISP, or perhaps those who announce ROAs, or should be with the RIR?
Any equipment misconfigurations should be the responsibility of the operator.
^^
Responsibility for ROA's should lie with the resource holder, in ensuring that not only is the information true, but that also all announced prefixes are covered by a ROA.
^^ I need to swap out the wheels on my car. I think I know better than to read the manual to, say, understand how much torque I should apply to each bolt, or what pattern I should use when tightening the bolts. Or, I read the manual but decide it’s too hard to understand, and I don’t ask for help in clearing up some of the grey areas. I change the wheels anyway. In the end, it looks right. They roll. Meh. All good. Then the wheels fall off. There is absolutely no one to blame for any of that but me. In my view, I see no difference here.
On 1/Oct/18 14:23, Jason Lixfeld wrote:
I need to swap out the wheels on my car. I think I know better than to read the manual to, say, understand how much torque I should apply to each bolt, or what pattern I should use when tightening the bolts. Or, I read the manual but decide it’s too hard to understand, and I don’t ask for help in clearing up some of the grey areas.
I change the wheels anyway. In the end, it looks right. They roll. Meh. All good.
Then the wheels fall off.
There is absolutely no one to blame for any of that but me.
In my view, I see no difference here.
As with anything else operators need to be responsible for their networks when running them. If I want to participate in the BGP on the Internet, I need to learn how to run BGP. If my part of the BGP breaks my network or those of others because I did not school myself on BGP, it's no one else's fault but mine. I can't blame the IETF for this. There is plenty of text freely available on the Internet about RPKI. In fact, I'd go as far as saying all RIR's have been running RPKI workshops for years. Mark.
On Mon, Oct 01, 2018 at 09:47:43AM +0200, Alex Band wrote:
Hello,
To avoid any misunderstanding in this discussion going forward, I would like to reiterate that an RPKI ROA is a positive attestation. An unavailable, expired or invalid ROA will result in a BGP announcement with the status NotFound. The announcement will *not* become INVALID, thereby being dropped.
Please read Section 5 of RFC 7115 that John linked carefully:
Bush Best Current Practice [Page 7]
RFC 7115 RPKI-Based Origin Validation Op January 2014
Announcements with NotFound origins should be preferred over those with Invalid origins.
Announcements with Invalid origins SHOULD NOT be used, but may be used to meet special operational needs. In such circumstances, the announcement should have a lower preference than that given to Valid or NotFound.
Thus, a continued outage of an RPKI CA (or publication server) will result in announcements with status NotFound. This means that the prefixes held by this CA will no longer benefit from protection by the RPKI. However, since only *invalid* announcements should be dropped, this should not lead to large scale outages in routing.
It is important to be aware of the impact of such an outage when considering questions of liability.
This depends if the prefix in question is covered by another ROA. Because in that case it is well possible that the prefix is marked INVALID. This is especially an issue if a partial failure of a publication server is taking out the more specifics but leaves a large covering ROA (maybe even one with origin AS 0). In the end from a security standpoint it is probably better to fail closed because the alternative is no RPKI and then hijacks become possible and MITM attacks or DNS spoofing can be done leaving every Internet user at risk. Also consider that not using best common practice to protect a service is also putting you at risk for liability charges. So ignoring RPKI because of possible liability concerns may as fire back at you. -- :wq Claudio
On 1/Oct/18 01:21, John Curran wrote:
It is possible to architect the various legalities surrounding RPKI to support any of the above outcomes, but it first requires a shared understanding of what the network community believes is the correct outcome. There is likely some on the nanog mailing list who have a view on this matter, so I pose the question of "who should be responsible" for consequences of RPKI RIR CA failure to this list for further discussion.
John, in the instance where all RIR's transition to a single "All Resource" TA, what would, in your mind, be the (potential) liability considerations? Mark.
On 1 Oct 2018, at 1:20 AM, Mark Tinka <mark.tinka@seacom.mu<mailto:mark.tinka@seacom.mu>> wrote: On 1/Oct/18 01:21, John Curran wrote: It is possible to architect the various legalities surrounding RPKI to support any of the above outcomes, but it first requires a shared understanding of what the network community believes is the correct outcome. There is likely some on the nanog mailing list who have a view on this matter, so I pose the question of "who should be responsible" for consequences of RPKI RIR CA failure to this list for further discussion. John, in the instance where all RIR's transition to a single "All Resource" TA, what would, in your mind, be the (potential) liability considerations? Mark - If there were to be an RIR CA outage, it would not appear that the RIRs use of “All Resources” TAs would materially affect the resulting operational impact to the Internet. (As noted earlier, the impact would be predominantly proportional to the number of ISPs that fail to follow best practices in route processing and fall back properly when their received routes end up with status NotFound, i.e. no longer match against their cache of validate ROAs since the cache has expired) The “All Resources” TA used by each RIR done to avoiding CA invalidation due to overclaiming (as detailed in https://datatracker.ietf.org/doc/rfc8360) – it reduces the probability of a different and hopefully rare RPKI failure scenario (involving the possible accidental invalidation of an RIR CA) until such time as a slightly different RPKI validation algorithm can be deployed that would limit any such invalidation solely to the resources in the overlap. (That’s my high-level understanding of the situation; comments on this question from those closer to the actual network bits would be most welcome…) Thanks! /John John Curran President and CEO ARIN
John Curran wrote on 01/10/2018 00:21:
There is likely some on the nanog mailing list who have a view on this matter, so I pose the question of "who should be responsible" for consequences of RPKI RIR CA failure to this list for further discussion.
other replies in this thread have assumed that RPKI CA failure modes are restricted to loss of availability, but there are others failure modes, for example: - fraud: rogue CA employee / external threat actor signs ROAs illegitimately - negligence: CA accidentally signs illegitimate ROAs due to e.g. software bug - force majeure: e.g. court orders CA to sign prefix with AS0, complicated by NIR RPKI delegation in jurisdictions which may have difficult relations with other parts of the world. These types of situations are well-trodden territory for other types of PKI CA, where users Otherwise, as other people have pointed out, catastrophic systems failure at the CA is designed to be fail-safe. I.e. if the CA goes away, ROAs will be evaluated as "unknown" and life will continue on. If people misconfigure their networks and do silly things with this specific failure mode, that's their problem. You can't stop people from aiming guns at their feet and pulling the trigger. Nick
On 1 Oct 2018, at 9:44 AM, Nick Hilliard <nick@foobar.org> wrote:
John Curran wrote on 01/10/2018 00:21:
There is likely some on the nanog mailing list who have a view on this matter, so I pose the question of "who should be responsible" for consequences of RPKI RIR CA failure to this list for further discussion.
other replies in this thread have assumed that RPKI CA failure modes are restricted to loss of availability, but there are others failure modes, for example:
- fraud: rogue CA employee / external threat actor signs ROAs illegitimately
- negligence: CA accidentally signs illegitimate ROAs due to e.g. software bug
- force majeure: e.g. court orders CA to sign prefix with AS0, complicated by NIR RPKI delegation in jurisdictions which may have difficult relations with other parts of the world.
Nick - Agreed… My question was specific to liability consequential to an operational outage of an RIR CA, since the community’s view of the proper allocation of liability from loss of availability will significantly shape the necessary legalities. (Liability from fraud or gross negligence is unlikely to respect such terms in any case)
Otherwise, as other people have pointed out, catastrophic systems failure at the CA is designed to be fail-safe. I.e. if the CA goes away, ROAs will be evaluated as "unknown" and life will continue on. If people misconfigure their networks and do silly things with this specific failure mode, that's their problem.
One would expect as much (i.e. it’s their problem for networks doing silly things), but we’ve heard some folks suggest it should be the RIR's problem (given the RIR CA's role in triggering events by going unavailable.) Thanks! /John John Curran President and CEO ARIN
Dear all, I'm very happy to see the direction this conversation has taken, seems we've moved on towards focussing on solutions and outcomes - this is encouraging. On Mon, Oct 01, 2018 at 05:44:17PM +0100, Nick Hilliard wrote:
John Curran wrote on 01/10/2018 00:21:
There is likely some on the nanog mailing list who have a view on this matter, so I pose the question of "who should be responsible" for consequences of RPKI RIR CA failure to this list for further discussion.
other replies in this thread have assumed that RPKI CA failure modes are restricted to loss of availability, but there are others failure modes, for example:
- fraud: rogue CA employee / external threat actor signs ROAs illegitimately
- negligence: CA accidentally signs illegitimate ROAs due to e.g. software bug
- force majeure: e.g. court orders CA to sign prefix with AS0, complicated by NIR RPKI delegation in jurisdictions which may have difficult relations with other parts of the world.
These types of situations are well-trodden territory for other types of PKI CA, where users
Otherwise, as other people have pointed out, catastrophic systems failure at the CA is designed to be fail-safe. I.e. if the CA goes away, ROAs will be evaluated as "unknown" and life will continue on. If people misconfigure their networks and do silly things with this specific failure mode, that's their problem. You can't stop people from aiming guns at their feet and pulling the trigger.
There are a number of failure modes and I believe the operational community has yet to fully explore how to mitigate most risks. Over time I expect we'll develop BCPs how to improve the robustness of the system; these BCPs can only come into existence driven by actual operational experierence. A positive development that addresses some aspects of the concerns raised is Certificate Transparency. Cloudflare set up a CT log (https://groups.google.com/forum/#!topic/certificate-transparency/_deL5iGB5sY) and I hope others like Google will also consider doing this. CT is a great tool to help keep the roots perform in line with community expectations. I consider it the operator community's responsibility to figure out how to deal with outages. I don't intend to hold the RIRs liable - we'll need to learn to protect ourselves. Kind regards, Job
On Sep 25, 2018, at 4:28 PM, John Curran <jcurran@arin.net> wrote:
On 25 Sep 2018, at 3:34 PM, Job Snijders <job@ntt.net> wrote:
On Tue, Sep 25, 2018 at 03:07:54PM -0400, John Curran wrote:
On Sep 25, 2018, at 1:30 PM, Job Snijders <job@ntt.net> wrote:
"""Using the data, we can also see that the providers that have not downloaded the ARIN TAL. Either because they were not aware that they needed to, or could not agree to the agreement they have with it.
Is it possible to ascertain how many of those who have not downloaded the ARIN TAL are also publishing ROA’s via RIPE’s CA?
I'm sure we could extend the data set to figure this out.
It would be informative to know how many organizations potentially have concerns about the indemnification clause in the RPA but already agree to indemnification via RIPE NCC Certification Service Terms and Conditions.
It would be interesting to see how much further deployment would have occurred if ARIN made it’s TAL available similar to the other locations. Thankfully we have active measurements that show that ARIN prefixes are less protected due to this. As someone that is (for personal reasons) now a voting member of ARIN, this is one of my primary concerns. My ARIN issued space is _less_ protected than if I were to have used another RIR. This devalues that investment. Instead of asking for an experiment, John I challenge you to make the ARIN TAL available and help play a role in securing the IP space within your region. There is this mantra of Secure by Default that many people have learned since the open-relay, smurf amplification and other attack days. There’s a reason my password isn’t a dictionary word, etc. If you make it easy to secure a website (eg: Lets Encrypt is a great example) there are now fewer self-signed certificates because it’s easier to do. Why is ARIN making it so hard for it’s members to get the benefits of the global ecosystem for their RIR controlled space? What makes ARIN IP space so unique in this sense? As part of a global ecosystem it’s incumbent of many of us to do the right thing here and ARIN is increasing the friction on the part of everyone to do the right thing. If I had to download the ARIN CA in order to interact with www.arin.net vs it being bundled in my browser store, would I be able to securely interact with ARIN? Therefore, I once again challenge you as part of the leadership of this organization to make the ARIN IP space as protected as those issued by the other regions. Let the developers know that if they bundle the ARIN TAL they won’t face legal action. Help bring routing security to the same ease of use as places like LetsEncrypt do for those in the SSL/TLS ecosystem. - Jared Mauch (Representing my own self/WFPL-1)
On 25 Sep 2018, at 7:11 PM, Jared Mauch <jared@puck.nether.net> wrote:
Why is ARIN making it so hard for it’s members to get the benefits of the global ecosystem for their RIR controlled space? What makes ARIN IP space so unique in this sense? As part of a global ecosystem it’s incumbent of many of us to do the right thing here and ARIN is increasing the friction on the part of everyone to do the right thing.
Jared - Indeed - In the process of complying with a different legal environment, ARIN sometimes has to behave differently than RIRs that are located elsewhere... In order to protect the stability of the services we provide to all ARIN customers, we have those relying on ARIN’s certificate services indemnify ARIN from claims of damages in connection with their usage. Such indemnification isn’t unique to ARIN - RIPE has RPKI publishers indemnify RIPE, APNIC has any users of APNIC digital certificates indemnify APNIC, etc. The significant difference for ARIN is that we operate under a different legal regime, and as a matter of US law, it appears that we cannot rely only upon terms and conditions published in our website as evidence of informed agreement; i.e. within the US legal framework, we need a specific act of acceptance in order to have a binding agreement. We originally accomplished this binding via an explicit click-box acknowledgement and emailing the the TAL to agreeing party, then managed to evolve it over time to just the click-box acceptance of terms, and now are able to consider the act of simply downloading of the TAL itself as sufficient to constitute agreement to terms. Different legal regimes result in different implementations, even when the terms (such as indemnification) are similar. Thanks, /John John Curran President and CEO American Registry for Internet Numbers
Hi, John. On Tue, Sep 25, 2018, 22:56 John Curran <jcurran@arin.net> wrote:
Indeed - In the process of complying with a different legal environment, ARIN sometimes has to behave differently than RIRs that are located elsewhere...
[...]
The significant difference for ARIN is that we operate under a different legal regime, and as a matter of US law, it appears that we cannot rely only upon terms and conditions published in our website as evidence of informed agreement; i.e. within the US legal framework, we need a specific act of acceptance in order to have a binding agreement.
Without venturing too far off topic, can you briefly compare this situation versus e.g. licensing of open source software? Often, such software is (apparently) licensed without express agreement - using bundled license files, comments inside source files, etc - and seems to accommodate the IPR and liability needs of developers and their supporting organizations. Is it ARIN's understanding that this approach is not useful for RPKI data in the US, etc? In any case, I also look forward to hearing the Overcoming Legal Barriers to RPKI Adoption talk next week (on Monday afternoon, IIRC), and I hope that the Q&A discussion (and evening follow-up) will be helpful. Thanks, -Benson
On 26 Sep 2018, at 1:14 AM, Benson Schliesser <bensons@queuefull.net> wrote:
Without venturing too far off topic, can you briefly compare this situation versus e.g. licensing of open source software? Often, such software is (apparently) licensed without express agreement - using bundled license files, comments inside source files, etc - and seems to accommodate the IPR and liability needs of developers and their supporting organizations. Is it ARIN's understanding that this approach is not useful for RPKI data in the US, etc?
Benson - Excellent question. First and foremost, an RIR agreement which provide indemnification (such as RIPE’s RPKI publisher terms, APNIC’s Certificate user terms, and ARIN’s RPA) provides an affirmative defense regarding liability claims; i.e. effectively we are able to point out at the very beginning of proceedings that parties using RPKI data per the respective agreement definitively have all of the associated liability from such use, not the RIR. This allows for a timely disposition by a judge of any liability claims against an RIR regarding such use, which is definitely not the case of a software license agreement. In the latter case of a software license agreement, if an RIR should suffer an RPKI outage (e.g. RIPE Feb 2013 – https://www.ietf.org/mail-archive/web/sidr/current/msg05621.html), it will be necessary to show that any parties making claims of damages were harmed as the result an an ISP which had a duty to act with a certain level of care with regard to use of RPKI information and who failed in that duty, as opposed to the being the result of the RIR outage. Such an argument must be made to the satisfaction of a jury based on the preponderance of evidence – i.e. even though each ISPs would have signed an agreement to use the RPKI information “as is”, that would not preclude any case proceeding to trial and would not necessarily be sufficient for an RIR to avoid significant liability in the event of an outage and despite the clear disclaimer of “as is” provision of RPKI data.
In any case, I also look forward to hearing the Overcoming Legal Barriers to RPKI Adoption talk next week (on Monday afternoon, IIRC), and I hope that the Q&A discussion (and evening follow-up) will be helpful.
Indeed – note that your question regarding a comparison to “licensing of open source software” might also be asked during that Monday session in order to gain better insight from an actual attorney (rather than my offhand knowledge of such matters...) Thanks! /John John Curran President and CEO ARIN
(I'm going to regret posting this later, but...) On Tue, Sep 25, 2018 at 10:57 PM John Curran <jcurran@arin.net> wrote:
The significant difference for ARIN is that we operate under a different legal regime, and as a matter of US law, it appears that we cannot rely only upon terms and conditions published in our website as evidence of informed agreement; i.e. within the US legal framework, we need a specific act of acceptance in order to have a binding agreement.
how is arin's problem here different from that which 'lets encrypt' is facing with their Cert things? Don't they have the same sort of problem as ARIN? "somoene trusted a cert signed by LE for "thing" and got scammed/harmed/etc" It seems odd, to me anyway, that this is seemingly so very different... I also would like less friction in the RPKI process...I don't think it serves ARIN, it's community nor the global internet community to make things harder to secure/validate.
On 26 Sep 2018, at 2:09 AM, Christopher Morrow <morrowc.lists@gmail.com<mailto:morrowc.lists@gmail.com>> wrote: (I'm going to regret posting this later, but...) On Tue, Sep 25, 2018 at 10:57 PM John Curran <jcurran@arin.net<mailto:jcurran@arin.net>> wrote: The significant difference for ARIN is that we operate under a different legal regime, and as a matter of US law, it appears that we cannot rely only upon terms and conditions published in our website as evidence of informed agreement; i.e. within the US legal framework, we need a specific act of acceptance in order to have a binding agreement. how is arin's problem here different from that which 'lets encrypt' is facing with their Cert things? Chris - The “Let’s encrypt” subscriber agreement (current version 1.2, 15 Nov 2018) includes "indemnify and hold harmless” clause, and parties affirmatively agree to those terms by requesting that ISRG issue a "Let’s Encrypt” Certificate to you. (I don’t know whether that process is particularly more or less onerous technically than the effort to download the ARIN TAL.) FYI, /John John Curran President and CEO ARIN
On Sep 26, 2018, at 3:13 AM, John Curran <jcurran@arin.net> wrote:
On 26 Sep 2018, at 2:09 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
(I'm going to regret posting this later, but...)
On Tue, Sep 25, 2018 at 10:57 PM John Curran <jcurran@arin.net> wrote:
The significant difference for ARIN is that we operate under a different legal regime, and as a matter of US law, it appears that we cannot rely only upon terms and conditions published in our website as evidence of informed agreement; i.e. within the US legal framework, we need a specific act of acceptance in order to have a binding agreement.
how is arin's problem here different from that which 'lets encrypt' is facing with their Cert things?
Chris -
The “Let’s encrypt” subscriber agreement (current version 1.2, 15 Nov 2018) includes "indemnify and hold harmless” clause, and parties affirmatively agree to those terms by requesting that ISRG issue a "Let’s Encrypt” Certificate to you.
(I don’t know whether that process is particularly more or less onerous technically than the effort to download the ARIN TAL.)
The process for lets encrypt is fairly straightforward, it collects some minimal information (eg: e-mail address, domain name) and then does all the voodoo necessary. If ARIN were to make this request of the developers of RPKI software, it would seem reasonable to have that passed to ARIN via some API saying “bob@example.com” typed “Agree” to the ARIN TAL as part of the initial installation of the software. For me, this is about the friction involved in making it work and while the click-through page may not seem like a barrier, there are active measurements that demonstrate it is. It may take time to communicate to the existing set of operators running RPKI validators they are missing the ARIN TAL, but I would like to ensure that new deployments don’t make this same mistake. I think this thread/communication is part of that. “Don’t forget about the extra step for ARIN”. It’s also “ARIN, please help make it easier to use your service”. With Google Maps, etc.. I may have to create an API key, it comes in multi-lingual systems in non-roman alphabet support, etc. Being part of this global ecosystem and running an RIR comes with some extra effort compared to running a corner mom & pop shop. Our actions and decisions have global consequences to the safety and security of how your and my traffic is routed. Please work with the developers for a suitable method to include the ARIN TAL by default. Come up with the click-accept legalese necessary. Since you asked, here’s what they did with the CertBot that’s commonly used by Lets Encrypt: (The first time you run the command, it will make an account, and ask for an email and agreement to the Let’s Encrypt Subscriber Agreement; you can automate those with --email and --agree-tos) If you want to use a webserver that doesn’t have full plugin support yet, you can still use “standalone” or “webroot” plugins to obtain a certificate: ./certbot-auto certonly --standalone --email admin@example.com -d example.com -d www.example.com -d other.example.net If you/ARIN could work closer with the developers of RPKI software to help make this happen that would be great. If you need introductions, I’m happy to help make them. - Jared
On Wed, Sep 26, 2018 at 03:29:33AM -0400, Jared Mauch wrote:
On Sep 26, 2018, at 3:13 AM, John Curran <jcurran@arin.net> wrote:
On 26 Sep 2018, at 2:09 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
(I'm going to regret posting this later, but...)
On Tue, Sep 25, 2018 at 10:57 PM John Curran <jcurran@arin.net> wrote:
The significant difference for ARIN is that we operate under a different legal regime, and as a matter of US law, it appears that we cannot rely only upon terms and conditions published in our website as evidence of informed agreement; i.e. within the US legal framework, we need a specific act of acceptance in order to have a binding agreement.
how is arin's problem here different from that which 'lets encrypt' is facing with their Cert things?
Chris -
The “Let’s encrypt” subscriber agreement (current version 1.2, 15 Nov 2018) includes "indemnify and hold harmless” clause, and parties affirmatively agree to those terms by requesting that ISRG issue a "Let’s Encrypt” Certificate to you.
(I don’t know whether that process is particularly more or less onerous technically than the effort to download the ARIN TAL.)
The process for lets encrypt is fairly straightforward, it collects some minimal information (eg: e-mail address, domain name) and then does all the voodoo necessary. If ARIN were to make this request of the developers of RPKI software, it would seem reasonable to have that passed to ARIN via some API saying “bob@example.com” typed “Agree” to the ARIN TAL as part of the initial installation of the software.
For me, this is about the friction involved in making it work and while the click-through page may not seem like a barrier, there are active measurements that demonstrate it is. It may take time to communicate to the existing set of operators running RPKI validators they are missing the ARIN TAL, but I would like to ensure that new deployments don’t make this same mistake.
I think this thread/communication is part of that. “Don’t forget about the extra step for ARIN”. It’s also “ARIN, please help make it easier to use your service”.
With Google Maps, etc.. I may have to create an API key, it comes in multi-lingual systems in non-roman alphabet support, etc. Being part of this global ecosystem and running an RIR comes with some extra effort compared to running a corner mom & pop shop. Our actions and decisions have global consequences to the safety and security of how your and my traffic is routed.
Please work with the developers for a suitable method to include the ARIN TAL by default. Come up with the click-accept legalese necessary.
Since you asked, here’s what they did with the CertBot that’s commonly used by Lets Encrypt:
(The first time you run the command, it will make an account, and ask for an email and agreement to the Let’s Encrypt Subscriber Agreement; you can automate those with --email and --agree-tos)
If you want to use a webserver that doesn’t have full plugin support yet, you can still use “standalone” or “webroot” plugins to obtain a certificate:
./certbot-auto certonly --standalone --email admin@example.com -d example.com -d www.example.com -d other.example.net
If you/ARIN could work closer with the developers of RPKI software to help make this happen that would be great. If you need introductions, I’m happy to help make them.
This is the wrong side of the system. If you want to compare the ARIN TAL to anything related to letsencrypt then it is the TLS root certificates which are shipped by all OS and browsers. This discussion is not about the process to get a cerificate (or ROA entry signed) this is about shipping the trust anchor, which makes the system actually work. As an opensource developer what I need is to be able to ship the public key together with my software so that the verification works out of the box. Without the public key (TAL) none of the ARIN ROA entries can be validated. I do not understand why a public key is under a click-accept license. If fear of indemnification is an issue then how is it possible that so many US public keys are shipped with the TLS/SSL root certificates without any issue? ARIN can still use the same license for customers wanting to add entries to the ARIN RPKI database. It is just about the fact that a 3rd party that has nothing todo with ARIN needs to accept their licence to be able to verify that the ARIN signed ROA entry is acctually valid. No other validation system (DNSSEC, TLS/SSL) is doing that. It is actually in the interest of ARIN and all ARIN members that the TAL is as widely distributed as possible since only then adding a ROA actually gives you the intended benefit. -- :wq Claudio
On 26 Sep 2018, at 3:29 AM, Jared Mauch <jared@puck.nether.net> wrote:
The process for lets encrypt is fairly straightforward, it collects some minimal information (eg: e-mail address, domain name) and then does all the voodoo necessary. If ARIN were to make this request of the developers of RPKI software, it would seem reasonable to have that passed to ARIN via some API saying “bob@example.com” typed “Agree” to the ARIN TAL as part of the initial installation of the software.
Jared - Interesting point – thank you for the very clear elaboration of this particular issue. Would it suffice if ARIN made clear in its RPKI information that software installation tools may download the ARIN TAL on behalf of a party so long as the parry agrees to statement displayed which reads “This software utilizes information from the ARIN Certificate Authority, and such usage is subject to the ARIN Relying Party Agreement. Type ‘Agree’ to proceed” ?
Please work with the developers for a suitable method to include the ARIN TAL by default. Come up with the click-accept legalese necessary.
Since you asked, here’s what they did with the CertBot that’s commonly used by Lets Encrypt:
(The first time you run the command, it will make an account, and ask for an email and agreement to the Let’s Encrypt Subscriber Agreement; you can automate those with --email and --agree-tos)
Acknowledged; I believe that allowing something similar to enable software installation tools to download the ARIN TAL for a party should be relatively straightforward – I will research that asap. Thanks! /John John Curran President and CEO ARIN
On Sep 26, 2018, at 7:16 AM, John Curran <jcurran@arin.net> wrote:
On 26 Sep 2018, at 3:29 AM, Jared Mauch <jared@puck.nether.net> wrote:
The process for lets encrypt is fairly straightforward, it collects some minimal information (eg: e-mail address, domain name) and then does all the voodoo necessary. If ARIN were to make this request of the developers of RPKI software, it would seem reasonable to have that passed to ARIN via some API saying “bob@example.com” typed “Agree” to the ARIN TAL as part of the initial installation of the software.
Jared -
Interesting point – thank you for the very clear elaboration of this particular issue.
John, Thank you for listening :-)
Would it suffice if ARIN made clear in its RPKI information that software installation tools may download the ARIN TAL on behalf of a party so long as the parry agrees to statement displayed which reads “This software utilizes information from the ARIN Certificate Authority, and such usage is subject to the ARIN Relying Party Agreement. Type ‘Agree’ to proceed” ?
I think this would help, but ideally you would allow people (software vendors) to package the TAL and if they type ‘Agree’ it would allow use of it.
Please work with the developers for a suitable method to include the ARIN TAL by default. Come up with the click-accept legalese necessary.
Since you asked, here’s what they did with the CertBot that’s commonly used by Lets Encrypt:
(The first time you run the command, it will make an account, and ask for an email and agreement to the Let’s Encrypt Subscriber Agreement; you can automate those with --email and --agree-tos)
Acknowledged; I believe that allowing something similar to enable software installation tools to download the ARIN TAL for a party should be relatively straightforward – I will research that asap.
Thank you! This and/or guidance to software developers about this being a permissible action on their part. This should help improve things. - Jared
On 26 Sep 2018, at 9:26 AM, Jared Mauch <jared@puck.nether.net> wrote:
On Sep 26, 2018, at 7:16 AM, John Curran <jcurran@arin.net> wrote:
On 26 Sep 2018, at 3:29 AM, Jared Mauch <jared@puck.nether.net> wrote:
The process for lets encrypt is fairly straightforward, it collects some minimal information (eg: e-mail address, domain name) and then does all the voodoo necessary. If ARIN were to make this request of the developers of RPKI software, it would seem reasonable to have that passed to ARIN via some API saying “bob@example.com” typed “Agree” to the ARIN TAL as part of the initial installation of the software.
Jared -
Interesting point – thank you for the very clear elaboration of this particular issue.
John,
Thank you for listening :-)
Jared - No problem at all – I work for you (i.e. the collective “you" on this mailing list.)
Would it suffice if ARIN made clear in its RPKI information that software installation tools may download the ARIN TAL on behalf of a party so long as the parry agrees to statement displayed which reads “This software utilizes information from the ARIN Certificate Authority, and such usage is subject to the ARIN Relying Party Agreement. Type ‘Agree’ to proceed” ?
I think this would help, but ideally you would allow people (software vendors) to package the TAL and if they type ‘Agree’ it would allow use of it.
Got it - I’ll look to this approach if at all possible.
Please work with the developers for a suitable method to include the ARIN TAL by default. Come up with the click-accept legalese necessary.
Since you asked, here’s what they did with the CertBot that’s commonly used by Lets Encrypt:
(The first time you run the command, it will make an account, and ask for an email and agreement to the Let’s Encrypt Subscriber Agreement; you can automate those with --email and --agree-tos)
Acknowledged; I believe that allowing something similar to enable software installation tools to download the ARIN TAL for a party should be relatively straightforward – I will research that asap.
Thank you! This and/or guidance to software developers about this being a permissible action on their part. This should help improve things.
Thanks for the thoughtful discussion - very helpful! /John John Curran President and CEO ARIN
John Curran <jcurran@arin.net> wrote:
On 26 Sep 2018, at 2:09 AM, Christopher Morrow <morrowc.lists@gmail.com<mailto:morrowc.lists@gmail.com>> wrote:
how is arin's problem here different from that which 'lets encrypt' is facing with their Cert things?
The “Let’s encrypt” subscriber agreement (current version 1.2, 15 Nov 2018) includes "indemnify and hold harmless” clause, and parties affirmatively agree to those terms by requesting that ISRG issue a "Let’s Encrypt” Certificate to you.
The difference is that the Let's Encrypt agreement is for people obtaining certificates from them. The ARIN equivalent would be the agreement for ARIN members. Let's Encrypt does not require an agreement from relying parties (i.e. browser users), whereas ARIN does. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Rockall, Malin, Hebrides: Southwest veering northwest, 5 to 7, perhaps gale 8 later, but cyclonic 3 or 4 for a time. Rough or very rough. Rain or showers. Good occasionally poor.
On 26 Sep 2018, at 6:42 AM, Tony Finch <dot@dotat.at> wrote:
John Curran <jcurran@arin.net> wrote:
On 26 Sep 2018, at 2:09 AM, Christopher Morrow <morrowc.lists@gmail.com<mailto:morrowc.lists@gmail.com>> wrote:
how is arin's problem here different from that which 'lets encrypt' is facing with their Cert things?
The “Let’s encrypt” subscriber agreement (current version 1.2, 15 Nov 2018) includes "indemnify and hold harmless” clause, and parties affirmatively agree to those terms by requesting that ISRG issue a "Let’s Encrypt” Certificate to you.
The difference is that the Let's Encrypt agreement is for people obtaining certificates from them. The ARIN equivalent would be the agreement for ARIN members.
Let's Encrypt does not require an agreement from relying parties (i.e. browser users), whereas ARIN does.
Tony - That is correct; I did not say that they were parallel situations, only pointing out that the Let’s Encrypt folks also go beyond simply providing services “as is”, and require indemnification from those engaging their CA services, just as ARIN, RIPE, APNIC do… ARIN and APNIC go further by having indemnification by parties using information in the CA; in ARIN’s case, this requires an explicit act of acceptance to be legally valid. Thanks! /John John Curran President and CEO ARIN
On Wed, Sep 26, 2018 at 11:07:49AM +0000, John Curran wrote:
Let's Encrypt does not require an agreement from relying parties (i.e. browser users), whereas ARIN does.
That is correct; I did not say that they were parallel situations, only pointing out that the Let’s Encrypt folks also go beyond simply providing services “as is”, and require indemnification from those engaging their CA services, just as ARIN, RIPE, APNIC do…
Indeed, you can download the Let's Encrypt CA here: https://letsencrypt.org/certificates/ no mention of indemnification, restrictions, liability, limitations or an agreement.
ARIN and APNIC go further by having indemnification by parties using information in the CA; in ARIN’s case, this requires an explicit act of acceptance to be legally valid.
Are you sure about APNIC? The APNIC TAL is available here in a plain and simple format: https://www.apnic.net/community/security/resource-certification/apnic-rpki-t... no mention of indemnification, restrictions, liability, limitations or an agreement If we take a look at other important PKI root certificates: https://www.geotrust.com/resources/root-certificates/ quote: "There is no charge for use under these terms and You are not required to sign the agreement to make use of the Root Certificates." https://www.iana.org/dnssec/files *all* of DNSSEC depends on this one, no mention of indemnification, restrictions, liability, limitations or an agreement https://support.comodo.com/index.php?/Knowledgebase/List/Index/71 no mention of indemnification, restrictions, liability, limitations or an agreement https://support.globalsign.com/customer/en/portal/articles/1426602-globalsig... no mention of indemnification, restrictions, liability, limitations or an agreement The list goes on and on... What makes ARIN's situation unique compared to other PKI systems and certificate authorities? I only see examples where relying parties are accomodated in every possible way for access to the root certificates. Shouldn't the indemnification be just between ARIN and the resource holder? Is there really a necessity to have relying parties agree to anything? Kind regards, Job
On 26 Sep 2018, at 8:21 AM, Job Snijders <job@ntt.net<mailto:job@ntt.net>> wrote: ARIN and APNIC go further by having indemnification by parties using information in the CA; in ARIN’s case, this requires an explicit act of acceptance to be legally valid. Are you sure about APNIC? The APNIC TAL is available here in a plain and simple format: https://www.apnic.net/community/security/resource-certification/apnic-rpki-t... no mention of indemnification, restrictions, liability, limitations or an agreement Job - From <https://www.apnic.net/manage-ip/myapnic/digital-certificates/ca-terms-conditions/> "CA Terms & Conditions APNIC’s Certification Authority (CA) services are provided under the following terms and conditions: ... • The recipient of any Digital Certificates issued by the APNIC CA service will indemnify APNIC against any and all claims by third parties for damages of any kind arising from the use of that certificate.” I imagine that folks are not aware of that (just as they are unaware of the indemnification in most RIR service agreements) due to absence of any requirement to explicitly acknowledge same. What makes ARIN's situation unique compared to other PKI systems and certificate authorities? I only see examples where relying parties are accomodated in every possible way for access to the root certificates. The requirement upon relying parties is not unique among RIRs - see above re APNIC. There is nothing inherent to PKI that requires specific terms (e.g. indemnification for damages arising from use), but it should not be surprising that the PKI use for routing validation poses the opportunity for very significant damage claims if not done by every network operator according to best practices. In the case of ARIN, this does necessitate indemnification in order to reduce risk exposure to the overall RIR mission. Thanks, /John John Curran President and CEO ARIN
John Curran <jcurran@arin.net> wrote:
From <https://www.apnic.net/manage-ip/myapnic/digital-certificates/ca-terms-conditions/>
"CA Terms & Conditions
APNIC’s Certification Authority (CA) services are provided under the following terms and conditions: ...
• The recipient of any Digital Certificates issued by the APNIC CA service will indemnify APNIC against any and all claims by third parties for damages of any kind arising from the use of that certificate.”
That's about certificates, not about trust anchors. It applies to APNIC members and account holders, not to relying parties. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Forth: West or southwest 5 to 7, occasionally gale 8 for a time. Moderate. Rain later. Good, occasionally moderate later.
On 26 Sep 2018, at 11:02 AM, Tony Finch <dot@dotat.at<mailto:dot@dotat.at>> wrote: John Curran <jcurran@arin.net<mailto:jcurran@arin.net>> wrote: From <https://www.apnic.net/manage-ip/myapnic/digital-certificates/ca-terms-conditions/> "CA Terms & Conditions APNIC’s Certification Authority (CA) services are provided under the following terms and conditions: ... • The recipient of any Digital Certificates issued by the APNIC CA service will indemnify APNIC against any and all claims by third parties for damages of any kind arising from the use of that certificate.” That's about certificates, not about trust anchors. It applies to APNIC members and account holders, not to relying parties. Tony - Interesting assertion… while APNIC does issue digital certificates to APNIC customers for identity authentication purposes, it also issues digital certificates for RPKI. It’s possible that the intent that the term “Digital Certificates” (capitalized) in the CA Terms and Conditions refers to only to those within APNIC’s identity CA, but the argument against that would be APNIC’s online information about "Digital Certificates" - === From <https://www.apnic.net/manage-ip/myapnic/digital-certificates/about-cas/>) What is a Digital Certificate? Digital Certificates bind an identity to a pair of electronic keys that can be used to encrypt and sign digital information. APNIC uses electronic certificates to prove its own identity, the identity of its Members, and the right-of-use over Internet resources. APNIC issues regular Public Key Infrastructure (PKI) certificates for access control to APNIC services such as the MyAPNIC Member services website. In the case of Resource Certification, APNIC issues Resource Public Key Infrastructure (RPKI) certificates that have ‘Certificate Extensions’ added. These Certificate Extensions carry the Internet number resources allocated or assigned to the APNIC Member who is the subject of the Resource Certificate. These Resource Certificates are different to the identity certificates used for Web system access, and may only be used in the context of verifying an entity’s “right-of-use” over an IP address or AS. As a result, APNIC now manages two independent certificate authorities, one for Member services, and the second for Resource Certification. … === Given that APNIC explicitly mentions the RPKI electronic certificates in their explanation of what Digital Certificates are (and further noting that ROA’s do indeed contain within them end-entity resource certificates with keys for verification), APNIC”s overall CA Terms and Conditions, including the referenced indemnification clause, would appear to be applicable to their RPKI CA services. If the intent was indeed to limit the scope, then then APNIC could have easily used the term “Identity Certificates” in the indemnification clause to make clear its limited scope; i.e. if you’re particularly concerned about liability from the resulting indemnification, it might be best to get this clarified one way or the other from APNIC. Thanks! /John John Curran President and CEO ARIN
From: NANOG <nanog-bounces@nanog.org> on behalf of John Curran <jcurran@arin.net> Date: Wednesday, 26 September 2018 at 16:51 To: Tony Finch <dot@dotat.at> Cc: David Wishnick <dwishn@law.upenn.edu>, nanog list <nanog@nanog.org>, "Ben@benjojo.co.uk" <Ben@benjojo.co.uk>, Job Snijders <job@ntt.net> Subject: Re: ARIN RPKI TAL deployment issues On 26 Sep 2018, at 11:02 AM, Tony Finch <dot@dotat.at<mailto:dot@dotat.at>> wrote: John Curran <jcurran@arin.net<mailto:jcurran@arin.net>> wrote: From <https://www.apnic.net/manage-ip/myapnic/digital-certificates/ca-terms-conditions/> "CA Terms & Conditions APNIC’s Certification Authority (CA) services are provided under the following terms and conditions: ... • The recipient of any Digital Certificates issued by the APNIC CA service will indemnify APNIC against any and all claims by third parties for damages of any kind arising from the use of that certificate.” That's about certificates, not about trust anchors. It applies to APNIC members and account holders, not to relying parties. Tony - Interesting assertion… while APNIC does issue digital certificates to APNIC customers for identity authentication purposes, it also issues digital certificates for RPKI. It’s possible that the intent that the term “Digital Certificates” (capitalized) in the CA Terms and Conditions refers to only to those within APNIC’s identity CA, but the argument against that would be APNIC’s online information about "Digital Certificates" - === From <https://www.apnic.net/manage-ip/myapnic/digital-certificates/about-cas/>) What is a Digital Certificate? Digital Certificates bind an identity to a pair of electronic keys that can be used to encrypt and sign digital information. APNIC uses electronic certificates to prove its own identity, the identity of its Members, and the right-of-use over Internet resources. APNIC issues regular Public Key Infrastructure (PKI) certificates for access control to APNIC services such as the MyAPNIC Member services website. In the case of Resource Certification, APNIC issues Resource Public Key Infrastructure (RPKI) certificates that have ‘Certificate Extensions’ added. These Certificate Extensions carry the Internet number resources allocated or assigned to the APNIC Member who is the subject of the Resource Certificate. These Resource Certificates are different to the identity certificates used for Web system access, and may only be used in the context of verifying an entity’s “right-of-use” over an IP address or AS. As a result, APNIC now manages two independent certificate authorities, one for Member services, and the second for Resource Certification. … === Given that APNIC explicitly mentions the RPKI electronic certificates in their explanation of what Digital Certificates are (and further noting that ROA’s do indeed contain within them end-entity resource certificates with keys for verification), APNIC”s overall CA Terms and Conditions, including the referenced indemnification clause, would appear to be applicable to their RPKI CA services. If the intent was indeed to limit the scope, then then APNIC could have easily used the term “Identity Certificates” in the indemnification clause to make clear its limited scope; i.e. if you’re particularly concerned about liability from the resulting indemnification, it might be best to get this clarified one way or the other from APNIC. Thanks! /John John Curran President and CEO ARIN I asked APNIC about this and they confirmed that making use of their RPKI TAL does not bind you to their CA terms and conditions, so there’s no indemnity requirement. Edward Dore Freethought Internet
ons. 26. sep. 2018 14.57 skrev John Curran <jcurran@arin.net>:
In the case of ARIN, this does necessitate indemnification in order to reduce risk exposure to the overall RIR mission.
Thanks, /John
John Curran President and CEO ARIN
Did you buy insurance? It is impossible to be immune from legal abuse. I did not agree to anything, yet might still use the service. If I am unhappy I might sue in a danish court of law, were the maner I got access to the service might or might not matter at all. This seems silly. Please find a way to make RPKI useful also in the ARIN region. Where there is will there is a way. Regards Baldur
On Sep 26, 2018, at 3:58 PM, Baldur Norddahl <baldur.norddahl@gmail.com<mailto:baldur.norddahl@gmail.com>> wrote: This seems silly. Please find a way to make RPKI useful also in the ARIN region. Baldur - RPKI in the ARIN region is useable (by definition, as there are indeed people in the region using it.) The question is whether to _improve_ its usability / accessibility, and the tradeoffs involved in doing so. While you may find some of those present tradeoffs “silly”, they have real legal basis and thus cannot be simply discarded but must be carefully considered. (As noted earlier on this thread, there is such an analysis going on presently and we’ll hear about its findings in a session at NANOG this coming Monday.) Thanks, /John John Curran President and CEO ARIN
On 25 Sep 2018, at 3:34 PM, Job Snijders <job@ntt.net> wrote:
... What I'm hoping for is that there is a way for the ARIN TAL to be included in software distributions, without compromising ARIN's legal position.
Perhaps an exception for software distributors would already go a long way?
"You can include the ARIN TAL in your software distribution as long as you also include an unmodified copy of the https://www.arin.net/resources/rpki/rpa.pdf <https://www.arin.net/resources/rpki/rpa.pdf> file alongside it."
Kind regards,
Job - While not exactly what you seek, we can get a bit closer to the goal – i.e. by eliminating the need for the user installing a software package to first go get the ARIN TAL and put it in the right place prior to running the installation software. To that end, the ARIN TAL page <https://www.arin.net/resources/rpki/tal.html <https://www.arin.net/resources/rpki/tal.html>> has been revised with specific guidance – Software Installation Tools Software installation tools may download the ARIN TAL on behalf of a user after the user has confirmed their acceptance of the ARIN Relying Party Agreement (RPA) on the ARIN website. This acceptance must require "agreement to the ARIN Relying Party Agreement (https://www.arin.net/resources/rpki/rpa.pdf)" and obtain a non-ambiguous affirmative action by clicking on, or the entry of, a word of agreement (such as "yes" or "accept") Example: Attention: This package requires the download of the ARIN TAL and agreement to the ARIN Relying Party Agreement (RPA) (https://www.arin.net/resources/rpki/rpa.pdf). Type "yes" to agree, and you can proceed with the ARIN TAL download: yes We will continue to explore mechanisms for making ARIN’s RPKI repository more accessible to the community, but felt that this interim step could be accomplished promptly and was worth noting in a timely manner to those distributing RPKI software. Thanks! /John John Curran President and CEO American Registry for Internet Numbers
Dear John, I'd like to thank you and the ARIN team for these efforts - in doing so I feel that ARIN recognises issues & concerns related to the distribution of the ARIN RPKI TAL. Acknowledging a problem is the first step to solving it! On Sat, Oct 13, 2018 at 09:35:36AM -0400, John Curran wrote:
On 25 Sep 2018, at 3:34 PM, Job Snijders <job@ntt.net> wrote:
... What I'm hoping for is that there is a way for the ARIN TAL to be included in software distributions, without compromising ARIN's legal position.
Perhaps an exception for software distributors would already go a long way?
While not exactly what you seek, we can get a bit closer to the goal – i.e. by eliminating the need for the user installing a software package to first go get the ARIN TAL and put it in the right place prior to running the installation software.
To that end, the ARIN TAL page https://www.arin.net/resources/rpki/tal.html has been revised with specific guidance –
Software Installation Tools
Software installation tools may download the ARIN TAL on behalf of a user after the user has confirmed their acceptance of the ARIN Relying Party Agreement (RPA) on the ARIN website. This acceptance must require "agreement to the ARIN Relying Party Agreement (https://www.arin.net/resources/rpki/rpa.pdf)" and obtain a non-ambiguous affirmative action by clicking on, or the entry of, a word of agreement (such as "yes" or "accept")
Example: Attention: This package requires the download of the ARIN TAL and agreement to the ARIN Relying Party Agreement (RPA) (https://www.arin.net/resources/rpki/rpa.pdf). Type "yes" to agree, and you can proceed with the ARIN TAL download: yes
In this approach I still observe an institutional barrier. If we take DNSSEC as analogous concept, when installing & starting BIND, unbound, NSD, knot, Microsoft DNS, or PowerDNS, no affirmative actions are required. It is also not clear to me how in context of fully automated installation & deployment the paradigm of 'non-ambiguous affirmative action' can exist. If we instruct orchastration software to say 'yes' to whatever questions pop up what does that actually mean? It certainly no longer adheres to the spirit of whatever it is that ARIN seeks. Lastly - having to download a file ('requiring specific network connectivity') in context of installation & deployment is always inferior compared to bundling all required pieces into coherent software packages.
We will continue to explore mechanisms for making ARIN’s RPKI repository more accessible to the community, but felt that this interim step could be accomplished promptly and was worth noting in a timely manner to those distributing RPKI software.
Yes - please do. Providing guidance to software distributors does not change some of the challenging contents of the RPA, nor does it address the fundamental institutional barrier that separates the ARIN TAL from the other RIR TALs. Kind regards, Job
Is the ARIN TAL copyrighted? Is it even copyrightable? It has no creative value, which is a requirement in european law. Why would not RIPE just include it like they do for every other RIR TAL? lør. 13. okt. 2018 15.49 skrev Job Snijders <job@ntt.net>:
Dear John,
I'd like to thank you and the ARIN team for these efforts - in doing so I feel that ARIN recognises issues & concerns related to the distribution of the ARIN RPKI TAL. Acknowledging a problem is the first step to solving it!
On Sat, Oct 13, 2018 at 09:35:36AM -0400, John Curran wrote:
On 25 Sep 2018, at 3:34 PM, Job Snijders <job@ntt.net> wrote:
... What I'm hoping for is that there is a way for the ARIN TAL to be included in software distributions, without compromising ARIN's legal position.
Perhaps an exception for software distributors would already go a long way?
While not exactly what you seek, we can get a bit closer to the goal – i.e. by eliminating the need for the user installing a software package to first go get the ARIN TAL and put it in the right place prior to running the installation software.
To that end, the ARIN TAL page https://www.arin.net/resources/rpki/tal.html has been revised with specific guidance –
Software Installation Tools
Software installation tools may download the ARIN TAL on behalf of a user after the user has confirmed their acceptance of the ARIN Relying Party Agreement (RPA) on the ARIN website. This acceptance must require "agreement to the ARIN Relying Party Agreement (https://www.arin.net/resources/rpki/rpa.pdf)" and obtain a non-ambiguous affirmative action by clicking on, or the entry of, a word of agreement (such as "yes" or "accept")
Example: Attention: This package requires the download of the ARIN TAL and agreement to the ARIN Relying Party Agreement (RPA) (https://www.arin.net/resources/rpki/rpa.pdf). Type "yes" to agree, and you can proceed with the ARIN TAL download: yes
In this approach I still observe an institutional barrier. If we take DNSSEC as analogous concept, when installing & starting BIND, unbound, NSD, knot, Microsoft DNS, or PowerDNS, no affirmative actions are required.
It is also not clear to me how in context of fully automated installation & deployment the paradigm of 'non-ambiguous affirmative action' can exist. If we instruct orchastration software to say 'yes' to whatever questions pop up what does that actually mean? It certainly no longer adheres to the spirit of whatever it is that ARIN seeks.
Lastly - having to download a file ('requiring specific network connectivity') in context of installation & deployment is always inferior compared to bundling all required pieces into coherent software packages.
We will continue to explore mechanisms for making ARIN’s RPKI repository more accessible to the community, but felt that this interim step could be accomplished promptly and was worth noting in a timely manner to those distributing RPKI software.
Yes - please do. Providing guidance to software distributors does not change some of the challenging contents of the RPA, nor does it address the fundamental institutional barrier that separates the ARIN TAL from the other RIR TALs.
Kind regards,
Job
participants (19)
-
Alex Band -
Anderson, Charles R -
Baldur Norddahl -
Benson Schliesser -
Christopher Morrow -
Claudio Jeker -
Edward Dore -
Jared Mauch -
Jason Lixfeld -
Job Snijders -
John Curran -
John Curran -
Mark Milhollan -
Mark Tinka -
Michel Py -
Nick Hilliard -
Stuart Henderson -
Tony Finch -
Tony Tauber