Mailing List Archive

> However, your point is taken and ARIN shall endeavor to make terms and
> conditions for use of the TAL and the ARIN repository clearer in this
> regard.
>
> As alluded to above, the attached ARIN announcement from today notes
> that the ARIN RPA has now been updated (again) specifically to improve
> its clarity regarding the ability to distribute the ARIN TAL.

so carefully worded

the following is a binary question. yes or no, please

may i include the arin tal in my software product with neither i nor
the user of the product being encumbered, signing anything, ... as
with the other RIRs?

randy

> On 29 Sep 2022, at 6:12 PM, Randy Bush <randy@psg.com> wrote:
>
>> However, your point is taken and ARIN shall endeavor to make terms and
>> conditions for use of the TAL and the ARIN repository clearer in this
>> regard.
>>
>> As alluded to above, the attached ARIN announcement from today notes
>> that the ARIN RPA has now been updated (again) specifically to improve
>> its clarity regarding the ability to distribute the ARIN TAL.
>
> so carefully worded
>
> the following is a binary question. yes or no, please
>
> may i include the arin tal in my software product with neither i nor
> the user of the product being encumbered, signing anything, ... as
> with the other RIRs?

Randy -

Yes.

From the revised RPA - "Notwithstanding the foregoing, You are specifically allowed to publicly distribute the ARIN TAL, including by embedding the ARIN TAL in relying party software;”

Thanks,
/John

John Curran
President and CEO
American Registry for Internet Numbers

>> may i include the arin tal in my software product with neither i nor
>> the user of the product being encumbered, signing anything, ... as
>> with the other RIRs?
> Yes.

excellent. thank you.

[. and arin might ask itself why and how it took O(decade) to come to
this simple position; just in case there are other mis-matches between
arin's positions and community needs ]

randy

On 29 Sep 2022, at 6:26 PM, John Curran <jcurran@arin.net<mailto:jcurran@arin.net>> wrote:
...
may i include the arin tal in my software product with neither i nor
the user of the product being encumbered, signing anything, ... as
with the other RIRs?

Randy -

Yes.

From the revised RPA - "Notwithstanding the foregoing, You are specifically allowed to publicly distribute the ARIN TAL, including by embedding the ARIN TAL in relying party software;”

Randy -

Note that “as with the other RIRs” may be a key element of your question, since users
of the other RIRs RPKI repositories are also subject to the relevant terms and conditions
(e.g. "RIPE NCC Certification Repository Terms and Conditions" https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/legal/ripe-ncc-certification-repository-terms-and-conditions) To the extent that you rely on ARIN’s RPA to provide the right to publicly
distribute the TAL, you are also subject its terms and conditions. I don’t particularly
consider being subject to the terms and conditions of service that your choose as
making one “encumbered”, but for avoidance of doubt figured I should point that out.

Thanks,
/John

John Curran
President and CEO
American Registry for Internet Numbers

> On 29 Sep 2022, at 6:30 PM, Randy Bush <randy@psg.com> wrote:
>
>>> may i include the arin tal in my software product with neither i nor
>>> the user of the product being encumbered, signing anything, ... as
>>> with the other RIRs?
>> Yes.
>
> excellent. thank you.
>
> [. and arin might ask itself why and how it took O(decade) to come to
> this simple position; just in case there are other mis-matches between
> arin's positions and community needs ]

Randy -

It’s actually not a simple position at all, but a rather complicated set of
tradeoffs that the organization has to consider (and periodically review
based on changing conditions) by the Board of Trustees. Even now
there are significant differences in RPKI approaches among the RIRs,
and that’s to be expected given the different legal environments in which
operates.

Note also there’s a variety of views in the community on nearly any topic,
but ultimately the members have to elect those whose judgment they trust
to the Board if they wish to have outcomes that they trust – as it is the
trustees who have the fiduciary duty to organization and its community.

ARIN has recently been reviewing quite a bit of customer facing legal
agreements based on current conditions, and the result include both an
updated RPA, and also the recently announced update to the RSA/LRSA -
<https://www.arin.net/announcements/20220912/>) If you have further
suggestions for items you’d like reviewed, please drop me an email (or
submit into the ARIN Consultation and Suggestion process if you want
formal tracking - https://www.arin.net/participate/community/acsp/process/)

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers

On Thu, Sep 29, 2022 at 03:30:55PM -0700, Randy Bush wrote:
> >> may i include the arin tal in my software product with neither i nor
> >> the user of the product being encumbered, signing anything, ... as
> >> with the other RIRs?
> > Yes.
>
> excellent. thank you.
>
> [. and arin might ask itself why and how it took O(decade) to come to
> this simple position; just in case there are other mis-matches between
> arin's positions and community needs ]
>

Randy, did you sign the RPA?

I did not sign the RPA.
Am I allowed to use rpki software like this?
And am I in any way restricted in the use of the produced work below
from this RP software?

> rpki-client -t /etc/rpki/arin.tal -d /tmp/a /tmp
rpki-client: https://rpki.sailx.co/rrdp/notification.xml: TLS handshake: certificate verification failed: certificate has expired
rpki-client: https://rpki.sailx.co/rrdp/notification.xml: load from network failed, fallback to rsync
rpki-client: rpki-rps.arin.net/repository/8a848adf8143bf6201823bd454752be6/0/267181B0A5DD38D60BCC22881342C64FFC8CBC1F.mft: no valid mft available
rpki-client: rpki-rps.arin.net/repository/8a848ade7fb71aa9017fdd9c5dd324c7/0/EB1DD8AA3E2B6864E06379C751DBFFFCC6418350.mft: no valid mft available
rpki-client: rpki-rps.arin.net/repository/8a848ade7fb71aa901800003287f4402/0/2BF7605B8927C87448B3B294A8B61D8E983248E0.mft: no valid mft available
rpki-client: rpki-rps.arin.net/repository/8a848adf7fb722e9017ffead9f534ac5/0/BFA2750976CA07F56A68976B0F01EB862F17C3B3.mft: no valid mft available
openrsync: warning: connect timeout: 208.82.103.214, rpki.sailx.co
openrsync: error: cannot connect to host: rpki.sailx.co
rpki-client: rsync rsync://rpki.sailx.co/repo failed
rpki-client: .rsync/rpki.sailx.co/repo: load from network failed, fallback to cache
rpki-client: rpki.sailx.co/repo/Sail-Internet-Inc/0/DFC5509768EA587E638D20680032E0FF122BD25A.mft: no valid mft available
Processing time 202 seconds (54 seconds user, 30 seconds system)
Skiplist entries: 0
Route Origin Authorizations: 56644 (0 failed parse, 0 invalid)
AS Provider Attestations: 0 (0 failed parse, 0 invalid)
BGPsec Router Certificates: 0
Certificates: 2878 (0 invalid)
Trust Anchor Locators: 1 (0 invalid)
Manifests: 2878 (5 failed parse, 0 stale)
Certificate revocation lists: 2873
Ghostbuster records: 0
Repositories: 16
Cleanup: removed 0 files, 2900 directories, 580 superfluous
VRP Entries: 81311 (75592 unique)
VAP Entries: 0 (0 unique)

# Processing time 202 seconds (54s user, 30s system)
# Route Origin Authorizations: 56644 (0 failed parse, 0 invalid)
# BGPsec Router Certificates: 0
# Certificates: 2878 (0 invalid)
# Trust Anchor Locators: 1 (0 invalid) [ /etc/rpki/arin.tal ]
# Manifests: 2878 (5 failed parse, 0 stale)
# Certificate revocation lists: 2873
# Ghostbuster records: 0
# Repositories: 16
# VRP Entries: 81311 (75592 unique)
roa-set {
3.0.0.0/15 source-as 16509 expires 1664683200
3.0.0.0/15 source-as 38895 expires 1664683200
3.0.0.0/10 maxlen 24 source-as 8987 expires 1664683200
3.0.0.0/10 maxlen 24 source-as 14618 expires 1664683200
3.0.0.0/10 maxlen 24 source-as 16509 expires 1664683200
3.2.1.0/24 source-as 16509 expires 1664683200
3.3.5.0/24 source-as 7224 expires 1664683200
3.4.1.0/24 source-as 7224 expires 1664683200
3.4.2.0/24 source-as 7224 expires 1664683200
3.4.4.0/24 source-as 7224 expires 1664683200
3.33.48.0/20 maxlen 24 source-as 7224 expires 1664683200
3.64.0.0/10 maxlen 24 source-as 8987 expires 1664683200
3.64.0.0/10 maxlen 24 source-as 14618 expires 1664683200
3.64.0.0/10 maxlen 24 source-as 16509 expires 1664683200
3.112.0.0/14 source-as 16509 expires 1664683200
3.128.0.0/10 maxlen 24 source-as 8987 expires 1664683200
3.128.0.0/10 maxlen 24 source-as 14618 expires 1664683200
3.128.0.0/10 maxlen 24 source-as 16509 expires 1664683200
3.192.0.0/10 maxlen 24 source-as 8987 expires 1664683200
3.192.0.0/10 maxlen 24 source-as 14618 expires 1664683200
3.192.0.0/10 maxlen 24 source-as 16509 expires 1664683200
4.128.0.0/12 source-as 8075 expires 1664769600
4.144.0.0/12 source-as 8075 expires 1664769600
4.160.0.0/12 source-as 8075 expires 1664769600
4.176.0.0/12 source-as 8075 expires 1664769600
4.192.0.0/12 source-as 8075 expires 1664769600
4.208.0.0/12 source-as 8075 expires 1664769600
4.224.0.0/12 source-as 8075 expires 1664769600
4.240.0.0/12 source-as 8075 expires 1664769600
8.2.120.0/24 source-as 20473 expires 1664683200
8.2.121.0/24 source-as 20473 expires 1664683200
8.2.122.0/24 source-as 20473 expires 1664683200
8.3.29.0/24 source-as 20473 expires 1664683200
8.6.8.0/24 source-as 20473 expires 1664683200
8.6.193.0/24 source-as 20473 expires 1664683200
8.7.233.0/24 source-as 20473 expires 1664683200
8.8.4.0/24 source-as 15169 expires 1664683200
8.8.8.0/24 source-as 15169 expires 1664683200
...

--
:wq Claudio

> Randy, did you sign the RPA?

you're kidding, right?

> I did not sign the RPA.
> Am I allowed to use rpki software like this?
> And am I in any way restricted in the use of the produced work below
> from this RP software?

i am not a lawyer and do not play one on the net

randy

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)
>
>