ARIN RPA updated (again) to address TAL distribution (Re: ARIN RPKI services terms/conditions - Change to Management of the Trust Anchor Locator for ARIN’s RPKI Service)
As the coauthors of the 2019 NSF-supported report that contributed to the current momentum toward overcoming the barriers RPKI adoption, a prior posting asked for our assessment of the changes. Our apologies that we won't be able to join you at this NANOG. We hope to put together some type of program in Atlanta in February. We would say that intent of ARIN's Sept. 26 and 29 updates ((link<https://www.arin.net/announcements/2022/documents/rpa_092622_redline.pdf> and link<https://www.arin.net/announcements/2022/documents/rpa_092922_redline.pdf>) to the RPA-to permit distribution of the TAL without signing the RPA-represent positive steps to address the most significant concern that we raised. In particular, the language in Section 5 added by the Sept. 29 update explicitly stating, "Notwithstanding the foregoing, You are specifically allowed to publicly distribute the ARIN TAL, including by embedding the ARIN TAL in relying party software," appears to authorize including ARIN's TAL in all distributions of validator software, and RPKI adopters would no longer need to download ARIN's TAL from its website. If effective, this is would remove the single most important legal obstacle to broader use of RPKI. The continuing wrinkle is that Section 5 authorizes distribution of ORCP services (including the ARIN TAL) only as permitted by the ORCP service terms. Section 9 requires third parties receiving this information either to have agreed to the RPA or to have entered into an agreement with the distributing party that includes the key terms of the RPA. That would suggest that anyone distributing validator software with ARIN's TAL must ensure that the recipient has agreed to the RPA in order to avoid violating the ORCP service terms. Although open source typically relies on licenses that are good against all users regardless of knowledge or assent (because they sound in property instead of contract), assent to the terms of the RPA could be incorporated into the distribution process, perhaps in the same manner used for other certificate authorities, which typically have terms of use. Another comment on this thread asked if ARIN has now addressed the other issues raised by our report. It is our assessment that ARIN has adequately addressed three of our other concerns, has announced its intention to address two others, and partially addressed one. The three issues that ARIN has adequately addressed include: * Dropping provision of the RSA requiring legacy address holders to acknowledge ARIN's property rights in IP addresses: dropped in update to LRSA dated Sept. 12, 2022 (link<https://www.arin.net/about/corporate/agreements/rsav13_changes.pdf>). * Drop provision of RPA prohibiting sharing of RPKI-derived data in a machine-readable format: authorized for informational purposes by update to RPA dated Oct. 21, 2019 (link<https://www.arin.net/vault/announcements/2019/20191021.html>); authorized for routing purposes by update to RPA dated Sept. 26, 2022 (link<https://www.arin.net/announcements/2022/documents/rpa_092622_redline.pdf>). * Better dissemination of best practices to the community: addressed by expansion of RPKI training at FISPA, WISPA, CaribNOG, and NANOG. ARIN has its intention to address two of our other concerns in the near future: * Better disclosure to government agencies of ARIN's willingness to waive insemination and choice of law clauses when barred by law: likely to be addressed by ARIN's announced plans to create webpage specifically for governments. * Better disclosure of operational practices, such as uptime, update frequency, and response expectations: likely to be addressed further by planned update to certificate practices statement. It partially addressed one concern that we raised. * Dropping blanket indemnification clause in favor of disclaimer of warranties and liability: revised RPA to exclude indemnification for ARIN's gross negligence by update to RPA dated Oct. 21, 2019 (link<https://www.arin.net/vault/announcements/2019/20191021.html>). We hope these comments are helpful and look forward to continuing to work with the community on removing the remaining legal barriers to RPKI adoption. Christopher Yoo (on behalf of myself and David Wishnick)
Thanks a lot for your overview Christopher. We’re very happy that ARIN is working to address the concerns expressed by the community about the Relying Party Agreement and TAL distribution. Based on earlier conversations on this list [1], NLnet Labs intended to ship a new release of the free, open-source Routinator Relying Party software on short notice. Other Relying Party vendors are planning similar steps [2]. However, the remaining concern you voiced in the third paragraph of your e-mail has paused our effort. The planned Routinator release would leverage the possibility to include the ARIN TAL and no longer require explicit consent to the RPA. As no additional steps are needed after installation this greatly simplifies TAL management, which will be especially advantageous for deployment in unattended environments: https://github.com/NLnetLabs/routinator/pull/796 (code) https://routinator--796.org.readthedocs.build/en/796/configuration.html (documentation) We hope ARIN will be able to clarify the current RPA text to address your third paragraph, so that we are in a position to release Routinator with one fewer hurdle to adoption. Kind regards, Alex [1] https://seclists.org/nanog/2022/Sep/212 [2] https://github.com/cloudflare/cfrpki/issues/112
On 16 Oct 2022, at 23:52, Christopher S. Yoo <csyoo@law.upenn.edu> wrote:
As the coauthors of the 2019 NSF-supported report that contributed to the current momentum toward overcoming the barriers RPKI adoption, a prior posting asked for our assessment of the changes. Our apologies that we won’t be able to join you at this NANOG. We hope to put together some type of program in Atlanta in February. We would say that intent of ARIN’s Sept. 26 and 29 updates ((link and link) to the RPA—to permit distribution of the TAL without signing the RPA—represent positive steps to address the most significant concern that we raised. In particular, the language in Section 5 added by the Sept. 29 update explicitly stating, “Notwithstanding the foregoing, You are specifically allowed to publicly distribute the ARIN TAL, including by embedding the ARIN TAL in relying party software,” appears to authorize including ARIN’s TAL in all distributions of validator software, and RPKI adopters would no longer need to download ARIN’s TAL from its website. If effective, this is would remove the single most important legal obstacle to broader use of RPKI. The continuing wrinkle is that Section 5 authorizes distribution of ORCP services (including the ARIN TAL) only as permitted by the ORCP service terms. Section 9 requires third parties receiving this information either to have agreed to the RPA or to have entered into an agreement with the distributing party that includes the key terms of the RPA. That would suggest that anyone distributing validator software with ARIN’s TAL must ensure that the recipient has agreed to the RPA in order to avoid violating the ORCP service terms. Although open source typically relies on licenses that are good against all users regardless of knowledge or assent (because they sound in property instead of contract), assent to the terms of the RPA could be incorporated into the distribution process, perhaps in the same manner used for other certificate authorities, which typically have terms of use. Another comment on this thread asked if ARIN has now addressed the other issues raised by our report. It is our assessment that ARIN has adequately addressed three of our other concerns, has announced its intention to address two others, and partially addressed one. The three issues that ARIN has adequately addressed include:
• Dropping provision of the RSA requiring legacy address holders to acknowledge ARIN’s property rights in IP addresses: dropped in update to LRSA dated Sept. 12, 2022 (link). • Drop provision of RPA prohibiting sharing of RPKI-derived data in a machine-readable format: authorized for informational purposes by update to RPA dated Oct. 21, 2019 (link); authorized for routing purposes by update to RPA dated Sept. 26, 2022 (link). • Better dissemination of best practices to the community: addressed by expansion of RPKI training at FISPA, WISPA, CaribNOG, and NANOG. ARIN has its intention to address two of our other concerns in the near future:
• Better disclosure to government agencies of ARIN’s willingness to waive insemination and choice of law clauses when barred by law: likely to be addressed by ARIN’s announced plans to create webpage specifically for governments. • Better disclosure of operational practices, such as uptime, update frequency, and response expectations: likely to be addressed further by planned update to certificate practices statement. It partially addressed one concern that we raised.
• Dropping blanket indemnification clause in favor of disclaimer of warranties and liability: revised RPA to exclude indemnification for ARIN’s gross negligence by update to RPA dated Oct. 21, 2019 (link). We hope these comments are helpful and look forward to continuing to work with the community on removing the remaining legal barriers to RPKI adoption. Christopher Yoo (on behalf of myself and David Wishnick)
After discussing this topic directly with ARIN, our concerns have been taken away. We have been assured our updated implementation in Routinator precisely reflects the intent of the updated Relying Party Agreement. As a result, we have just released version 0.12.0-RC1. With ARIN's updated their RPA, we are now able to embed all five RIR TALs and completely remove the manual initialisation step from Routinator. After installation, Routinator will immediately start fetching data from all five RIR production TALs. This should make use in unattended environments much easier. While it makes setting up and using Routinator much simpler, this presents a major change in behaviour. We’ve been very careful to update and test the package installation scripts and Docker image to not break existing installations, but please let us know if you find a corner case in this Release Candidate. Details on this change, along with many other improvements and fixes, are available here: https://github.com/NLnetLabs/routinator/releases/tag/v0.12.0-rc1 Updated documentation, which also explains how to install RCs, is available here: https://routinator.docs.nlnetlabs.nl/en/v0.12.0-rc1/ Kind regards, Alex
On 17 Oct 2022, at 10:26, Alex Band <alex@nlnetlabs.nl> wrote:
Thanks a lot for your overview Christopher. We’re very happy that ARIN is working to address the concerns expressed by the community about the Relying Party Agreement and TAL distribution.
Based on earlier conversations on this list [1], NLnet Labs intended to ship a new release of the free, open-source Routinator Relying Party software on short notice. Other Relying Party vendors are planning similar steps [2]. However, the remaining concern you voiced in the third paragraph of your e-mail has paused our effort.
The planned Routinator release would leverage the possibility to include the ARIN TAL and no longer require explicit consent to the RPA. As no additional steps are needed after installation this greatly simplifies TAL management, which will be especially advantageous for deployment in unattended environments:
https://github.com/NLnetLabs/routinator/pull/796 (code) https://routinator--796.org.readthedocs.build/en/796/configuration.html (documentation)
We hope ARIN will be able to clarify the current RPA text to address your third paragraph, so that we are in a position to release Routinator with one fewer hurdle to adoption.
Kind regards,
Alex
[1] https://seclists.org/nanog/2022/Sep/212 [2] https://github.com/cloudflare/cfrpki/issues/112
On 16 Oct 2022, at 23:52, Christopher S. Yoo <csyoo@law.upenn.edu> wrote:
As the coauthors of the 2019 NSF-supported report that contributed to the current momentum toward overcoming the barriers RPKI adoption, a prior posting asked for our assessment of the changes. Our apologies that we won’t be able to join you at this NANOG. We hope to put together some type of program in Atlanta in February. We would say that intent of ARIN’s Sept. 26 and 29 updates ((link and link) to the RPA—to permit distribution of the TAL without signing the RPA—represent positive steps to address the most significant concern that we raised. In particular, the language in Section 5 added by the Sept. 29 update explicitly stating, “Notwithstanding the foregoing, You are specifically allowed to publicly distribute the ARIN TAL, including by embedding the ARIN TAL in relying party software,” appears to authorize including ARIN’s TAL in all distributions of validator software, and RPKI adopters would no longer need to download ARIN’s TAL from its website. If effective, this is would remove the single most important legal obstacle to broader use of RPKI. The continuing wrinkle is that Section 5 authorizes distribution of ORCP services (including the ARIN TAL) only as permitted by the ORCP service terms. Section 9 requires third parties receiving this information either to have agreed to the RPA or to have entered into an agreement with the distributing party that includes the key terms of the RPA. That would suggest that anyone distributing validator software with ARIN’s TAL must ensure that the recipient has agreed to the RPA in order to avoid violating the ORCP service terms. Although open source typically relies on licenses that are good against all users regardless of knowledge or assent (because they sound in property instead of contract), assent to the terms of the RPA could be incorporated into the distribution process, perhaps in the same manner used for other certificate authorities, which typically have terms of use. Another comment on this thread asked if ARIN has now addressed the other issues raised by our report. It is our assessment that ARIN has adequately addressed three of our other concerns, has announced its intention to address two others, and partially addressed one. The three issues that ARIN has adequately addressed include:
• Dropping provision of the RSA requiring legacy address holders to acknowledge ARIN’s property rights in IP addresses: dropped in update to LRSA dated Sept. 12, 2022 (link). • Drop provision of RPA prohibiting sharing of RPKI-derived data in a machine-readable format: authorized for informational purposes by update to RPA dated Oct. 21, 2019 (link); authorized for routing purposes by update to RPA dated Sept. 26, 2022 (link). • Better dissemination of best practices to the community: addressed by expansion of RPKI training at FISPA, WISPA, CaribNOG, and NANOG. ARIN has its intention to address two of our other concerns in the near future:
• Better disclosure to government agencies of ARIN’s willingness to waive insemination and choice of law clauses when barred by law: likely to be addressed by ARIN’s announced plans to create webpage specifically for governments. • Better disclosure of operational practices, such as uptime, update frequency, and response expectations: likely to be addressed further by planned update to certificate practices statement. It partially addressed one concern that we raised.
• Dropping blanket indemnification clause in favor of disclaimer of warranties and liability: revised RPA to exclude indemnification for ARIN’s gross negligence by update to RPA dated Oct. 21, 2019 (link). We hope these comments are helpful and look forward to continuing to work with the community on removing the remaining legal barriers to RPKI adoption. Christopher Yoo (on behalf of myself and David Wishnick)
participants (2)
-
Alex Band -
Christopher S. Yoo