Re: A way that ARIN can help encourage RPKI adoption

[Alex Band]

> On 13 Apr 2022, at 13:47, John Curran  wrote:
> 
>> 
>> On 13 Apr 2022, at 5:16 AM, Alex Band  wrote:
>> 
>> In case people would like to compare notes to the way this is arranged in 
>> the RIPE NCC service region, here is the Resource Certification for non-RIPE 
>> NCC Members policy which has been in place since 2013:
>> 
>> https://www.ripe.net/publications/docs/ripe-596
>> 
>> This resulted in the implementation documented here:
>> 
>> https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/resource-certification-rpki-for-provider-independent-end-users
>> 
>> It essentially means that Provider Independent End Users and Legacy End 
>> Users can log into the RIPE NCC equivalent of ARIN Online and *only* manage 
>> RPKI, without having access to any other options.
> 
> Alex - 
> 
> Could you also include the definition of “legacy resource holders” in the 
> RIPE region? In the ARIN region it’s quite clear – organizations (or their 
> legal successors) who were part of the early Internet and obtained their 
> number resources before ARIN’s formation are extended the courtesy of 
> specific benefits for those number resources (i.e. basic registry services 
> without any fee or contract and a favorable cap on total fees for those who 
> bring their resources under registry agreement)
> 
> As I understand it in the RIPE region, legacy number resources have little to 
> do with parties that were issued them, and is instead some sort of magic 
> property that is inherent to the address block itself and transfers along 
> with the address block - is this correct?

I think this page gives the best overview of all the puzzle pieces at play:

https://www.ripe.net/manage-ips-and-asns/legacy-resources/ripe-ncc-services-to-legacy-internet-resource-holders

-Alex

Re: A way that ARIN can help encourage RPKI adoption

[John Curran]

> On 13 Apr 2022, at 5:16 AM, Alex Band  wrote:
> 
> In case people would like to compare notes to the way this is arranged in the 
> RIPE NCC service region, here is the Resource Certification for non-RIPE NCC 
> Members policy which has been in place since 2013:
> 
> https://www.ripe.net/publications/docs/ripe-596
> 
> This resulted in the implementation documented here:
> 
> https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/resource-certification-rpki-for-provider-independent-end-users
> 
> It essentially means that Provider Independent End Users and Legacy End Users 
> can log into the RIPE NCC equivalent of ARIN Online and *only* manage RPKI, 
> without having access to any other options.

Alex - 

Could you also include the definition of “legacy resource holders” in the RIPE 
region?  In the ARIN region it’s quite clear – organizations (or their legal 
successors) who were part of the early Internet and obtained their number 
resources before ARIN’s formation are extended the courtesy of specific 
benefits for those number resources (i.e. basic registry services without any 
fee or contract and a favorable cap on total fees for those who bring their 
resources under registry agreement)

As I understand it in the RIPE region, legacy number resources have little to 
do with parties that were issued them, and is instead some sort of magic 
property that is inherent to the address block itself and transfers along with 
the address block - is this correct?

Thanks,
/John

John Curran
President and CEO
American Registry for Internet Numbers

Re: A way that ARIN can help encourage RPKI adoption

[John Curran]

> On 13 Apr 2022, at 1:33 AM, Doug Barton  wrote:
> 
> On 4/12/22 9:56 PM, John Curran wrote:
>> Doug, we’re not contracting with these parties to provide any other 
>> services…i.e.  there’s nothing to "add a rider to”.
>> (Those who have any registration services agreement with ARIN already have 
>> access to all services incl. RPKI)
> 
> Thank you for considering my suggestion. Perhaps I misunderstand the current 
> state.
> 
> I'm thinking of a scenario where a person holds legacy space, with no [L]RSA, 
> but they do have a registered ASN through ARIN (for example). In that 
> scenario are they eligible for RPKI for their legacy space?

Doug - 

My apologies - I didn't quite understand the scenario that you were 
considering…   Yes, there are organizations that already have registration 
services agreements with ARIN for either ASNs or IPv6, and now that we have 
uniform fee schedule it is trivial to bring their legacy IPv4 number resources 
under such an existing agreement with a simple addendum – and then the legacy 
number resources receive full registry services including RPKI.

Of course this probably doesn’t address the concerns of some legacy resource 
holders, expressed generally as “there’s no way my legal department will ever 
let us sign the ARIN RSA….”  In fact, that’s often not the case with such 
customers: they already have signed the ARIN RSA when they obtained their ASN 
or IPv6 number resources, so that’s really not the issue, rather it is belief 
that there is some elusive property enshrined in their legacy IPv4 number 
resources that can't be described but will dissipate if brought under a 
registration services agreement. 

Thanks,
/John

John Curran
President and CEO
American Registry for Internet Numbers

P.S.  While legacy resource holders do benefit from a basic services without 
any fee or contract, and if brought under agreement get a rather favorable 
total annual cap on their registry maintenance fees [currently $150/yr, 
increasing $25 / year] – those are simply benefits that are provided for the 
folks that were involved in the early days of the Internet and held number 
resources at ARIN’s formation in 1997 (rather than some strange intrinsic 
property of certain IP address blocks…) 

Re: A way that ARIN can help encourage RPKI adoption

[Alex Band]

In case people would like to compare notes to the way this is arranged in the 
RIPE NCC service region, here is the Resource Certification for non-RIPE NCC 
Members policy which has been in place since 2013:

https://www.ripe.net/publications/docs/ripe-596

This resulted in the implementation documented here:

https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/resource-certification-rpki-for-provider-independent-end-users

It essentially means that Provider Independent End Users and Legacy End Users 
can log into the RIPE NCC equivalent of ARIN Online and *only* manage RPKI, 
without having access to any other options.

-Alex


> On 13 Apr 2022, at 06:56, John Curran  wrote:
> 
>> 
>> On 12 Apr 2022, at 11:38 PM, Doug Barton  wrote:
>> 
>> On 4/6/22 10:55 AM, John Curran wrote:
>>> Interesting philosophy - historically ARIN customers have asked for 
>>> simplicity in the relationship; i.e. a single fee that encompasses all of 
>>> the services - in this way, an organization can utilize something without 
>>> having to “get new approval” and there’s no financial or service 
>>> disincentive for deployment of IPv6, IRR, RPKI, etc.
>>> Feel free to propose an alternative structure if you think it makes sense - 
>>> the suggestion process would be a good step (but feel free to run for the 
>>> ARIN Board of Trustees if you want to really advocate for a different 
>>> approach.)
>> 
>> John,
>> 
>> I think you raise an interesting point here. From an outside perspective it 
>> seems to me that ARIN is using RPKI participation as leverage to get legacy 
>> space holders to sign an LRSA. You have mentioned in past messages that this 
>> is at least in part based on the desire to recover costs related to 
>> providing that service. So let's look creatively at the cost issue.
>> 
>> Taking that claim at face value, I wonder if it's possible for ARIN to 
>> compromise slightly here, in the interest of encouraging the adoption of 
>> RPKI to the benefit of the Internet community. My suggestion is to open 
>> participation in RPKI to anyone with legacy space who is paying ARIN a fee 
>> for service, regardless of LRSA status.
>> 
>> Someone else mentioned creating a lightweight agreement for legacy space 
>> holders who want RPKI, which I think is a good idea. I'm not up on the 
>> current contents of the LRSA, but I imagine that there is an indemnification 
>> clause. I would be surprised if your lawyers didn't want that for the 
>> situation I'm proposing as well. Being lawyers, I imagine that they can come 
>> up with other things too. :) But given that you're already contracting with 
>> these parties for other services, a "rider" for RPKI should be easily 
>> accomplished.
> 
> Doug, we’re not contracting with these parties to provide any other 
> services…i.e. there’s nothing to "add a rider to”.
> (Those who have any registration services agreement with ARIN already have 
> access to all services incl. RPKI) 
> 
> Based on feedback received over the years, we’ve revised the terms of RSA and 
> LRSA several times to provide for friendlier terms and conditions - at this 
> point they’re actually the same agreement (See 
> https://www.arin.net/vault/announcements/2015/20151007.html) 
> 
> We remain open to suggestions for improving the registration services 
> agreement for all of ARIN’s customers – if the community comes up with 
> further changes, we can incorporate (but that will need to be per a member 
> vote since we also, per community request, locked down the agreement so it 
> couldn’t be unilaterally changed by the ARIN.) 
> 
> ARIN’s RSA is structured appropriately for a not-for-profit membership 
> organization in which members have open participation and governance 
> mechanisms that help them shape the services, policies and fees that will be 
> provided. If one looks at the RSA expecting it to be a commercial services 
> agreement (e.g., such as one would receive for domain name hosting) then 
> indeed it is quite different, but that’s because the RiRs are structured as 
> five cooperating not-for-profit membership organizations that instantiate the 
> cooperation within the network operator community for a globally unique 
> Internet number registry, with agreements that have everyone joining the 
> registry system for that purpose. This works extremely well and meets the 
> expectations of many of the registry customers globally – but such a model 
> doesn’t align with the expectations voiced by some legacy resource holders. 
> 
> I also would like to see RPKI more widely deployed, and happy to work on 
> making the RSA “more lightweight” for all ARIN customers to the extent 
> possible, but that requires clearly articulated feedback on changes that need 
> to be made, including the reasoning. Those with legacy resources have been 
> receiving free basic services for nearly 25 years, and even now have a very 
> favorable cap on their annual ARIN fees if they do enter into an RSA – 

Re: A way that ARIN can help encourage RPKI adoption

[William Herrin]

On Tue, Apr 12, 2022 at 10:34 PM Doug Barton  wrote:
> On 4/12/22 9:56 PM, John Curran wrote:
> > Doug, we’re not contracting with these parties to provide any other 
> > services…i.e.  there’s nothing to "add a rider to”.
> > (Those who have any registration services agreement with ARIN already have 
> > access to all services incl. RPKI)
>
> Thank you for considering my suggestion. Perhaps I misunderstand the
> current state.
>
> I'm thinking of a scenario where a person holds legacy space, with no
> [L]RSA, but they do have a registered ASN through ARIN (for example). In
> that scenario are they eligible for RPKI for their legacy space?

Hi Doug,

There are multiple challenges here. In many cases, all number
resources held are legacy status so the registrant has no current
contracts with ARIN. In others, the resources are held under different
org handles where the org handle for the legacy resources is not
associated with any contract. In both cases, some of the legacy org
handles fail to meet current ARIN standards for legal existence,
precluding ARNI from directly forming a contract. ARIN would have to
form a contract for RPKI with an entity that is, in the strictest
technical sense, different from the entity which holds the addresses.
Or consent to change the legacy org to something that has the proper
legal existence without creating a contract, which ARIN has to date
been adamant that it won't do. Recall that before ARIN the name of the
organization was a single line on an email form copied uncritically
into the registry. The POC info was far more important.

Nothing here that ARIN couldn't overcome of course. But the web is a
little bit tangled.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: A way that ARIN can help encourage RPKI adoption

[Doug Barton]

On 4/12/22 9:56 PM, John Curran wrote:

Doug, we’re not contracting with these parties to provide any other services…i.e.  
there’s nothing to "add a rider to”.
(Those who have any registration services agreement with ARIN already have 
access to all services incl. RPKI)


Thank you for considering my suggestion. Perhaps I misunderstand the 
current state.


I'm thinking of a scenario where a person holds legacy space, with no 
[L]RSA, but they do have a registered ASN through ARIN (for example). In 
that scenario are they eligible for RPKI for their legacy space?


If so, that's awesome, and I apologize for cluttering everyone's 
mailboxes.  :)


Doug

Re: A way that ARIN can help encourage RPKI adoption

[John Curran]

> On 12 Apr 2022, at 11:38 PM, Doug Barton  wrote:
> 
> On 4/6/22 10:55 AM, John Curran wrote:
>> Interesting philosophy - historically ARIN customers have asked for 
>> simplicity in the relationship; i.e. a single fee that encompasses all of 
>> the services - in this way, an organization can utilize something without 
>> having to “get new approval” and there’s no financial or service 
>> disincentive for deployment of IPv6, IRR, RPKI, etc.
>> Feel free to propose an alternative structure if you think it makes sense - 
>> the suggestion process would be a good step (but feel free to run for the 
>> ARIN Board of Trustees if you want to really advocate for a different 
>> approach.)
> 
> John,
> 
> I think you raise an interesting point here. From an outside perspective it 
> seems to me that ARIN is using RPKI participation as leverage to get legacy 
> space holders to sign an LRSA. You have mentioned in past messages that this 
> is at least in part based on the desire to recover costs related to providing 
> that service. So let's look creatively at the cost issue.
> 
> Taking that claim at face value, I wonder if it's possible for ARIN to 
> compromise slightly here, in the interest of encouraging the adoption of RPKI 
> to the benefit of the Internet community. My suggestion is to open 
> participation in RPKI to anyone with legacy space who is paying ARIN a fee 
> for service, regardless of LRSA status.
> 
> Someone else mentioned creating a lightweight agreement for legacy space 
> holders who want RPKI, which I think is a good idea. I'm not up on the 
> current contents of the LRSA, but I imagine that there is an indemnification 
> clause. I would be surprised if your lawyers didn't want that for the 
> situation I'm proposing as well. Being lawyers, I imagine that they can come 
> up with other things too.  :)  But given that you're already contracting with 
> these parties for other services, a "rider" for RPKI should be easily 
> accomplished.

Doug, we’re not contracting with these parties to provide any other 
services…i.e.  there’s nothing to "add a rider to”.
(Those who have any registration services agreement with ARIN already have 
access to all services incl. RPKI) 

Based on feedback received over the years, we’ve revised the terms of RSA and 
LRSA several times to provide for friendlier terms and conditions - at this 
point they’re actually the same agreement (See 
https://www.arin.net/vault/announcements/2015/20151007.html)  

We remain open to suggestions for improving the registration services agreement 
for all of ARIN’s customers – if the community comes up with further changes, 
we can incorporate (but that will need to be per a member vote since we also, 
per community request, locked down the agreement so it couldn’t be unilaterally 
changed by the ARIN.)   

ARIN’s RSA is structured appropriately for a not-for-profit membership 
organization in which members have open participation and governance mechanisms 
that help them shape the services, policies and fees that will be provided.  If 
one looks at the RSA expecting it to be a commercial services agreement (e.g., 
such as one would receive for domain name hosting) then indeed it is quite 
different, but that’s because the RiRs are structured as five cooperating 
not-for-profit membership organizations that instantiate the cooperation within 
the network operator community for a globally unique Internet number registry, 
with agreements that have everyone joining the registry system for that 
purpose. This works extremely well and meets the expectations of many of the 
registry customers globally – but such a model doesn’t align with the 
expectations voiced by some legacy resource holders.  

I also would like to see RPKI more widely deployed, and happy to work on making 
the RSA “more lightweight” for all ARIN customers to the extent possible, but 
that requires clearly articulated feedback on changes that need to be made, 
including the reasoning.  Those with legacy resources have been receiving free 
basic services for nearly 25 years, and even now have a very favorable cap on 
their annual ARIN fees if they do enter into an RSA – i.e., there are 
incentives in place, and the situation for a legacy resource holder who signed 
an RSA is actually more favorable than the 15000+ other ARIN customers who 
don’t receive the more favorable terms. 

The good news is that this is ultimately in the hands of the ARIN membership, 
so engagement with that community on further desired changes for legacy 
resource holders is the best path forward. 

Thanks,
/John

John Curran
President and CEO
American Registry for Internet Numbers

A way that ARIN can help encourage RPKI adoption

[Doug Barton]

On 4/6/22 10:55 AM, John Curran wrote:

Interesting philosophy - historically ARIN customers have asked for simplicity 
in the relationship; i.e. a single fee that encompasses all of the services - 
in this way, an organization can utilize something without having to “get new 
approval” and there’s no financial or service disincentive for deployment of 
IPv6, IRR, RPKI, etc.

Feel free to propose an alternative structure if you think it makes sense - the 
suggestion process would be a good step (but feel free to run for the ARIN 
Board of Trustees if you want to really advocate for a different approach.)


John,

I think you raise an interesting point here. From an outside perspective 
it seems to me that ARIN is using RPKI participation as leverage to get 
legacy space holders to sign an LRSA. You have mentioned in past 
messages that this is at least in part based on the desire to recover 
costs related to providing that service. So let's look creatively at the 
cost issue.


Taking that claim at face value, I wonder if it's possible for ARIN to 
compromise slightly here, in the interest of encouraging the adoption of 
RPKI to the benefit of the Internet community. My suggestion is to open 
participation in RPKI to anyone with legacy space who is paying ARIN a 
fee for service, regardless of LRSA status.


Someone else mentioned creating a lightweight agreement for legacy space 
holders who want RPKI, which I think is a good idea. I'm not up on the 
current contents of the LRSA, but I imagine that there is an 
indemnification clause. I would be surprised if your lawyers didn't want 
that for the situation I'm proposing as well. Being lawyers, I imagine 
that they can come up with other things too.  :)  But given that you're 
already contracting with these parties for other services, a "rider" for 
RPKI should be easily accomplished.


I think that there is broad agreement (although I note not universal 
agreement) that RPKI is a good thing, and that its use should be 
encouraged. I would like to see ARIN do everything in its power to 
support that goal. I think it's also worth noting that there are options 
with at least one other RIR for legacy space holders to get into RPKI 
with a lighter weight mechanism than what ARIN is offering. While on the 
one hand I think that there is some value in the RIR model in that 
services can be tailored to meet the needs of those in their regions, I 
don't think users in the ARIN region should need to "jump the fence" in 
order to help make the Internet more secure.


What do you think?

Doug

Re: RPKI adoption (was: Re: 2749 routes AT RISK )

[Livingood, Jason via NANOG]

From: NANOG  on 
behalf of John Curran 

> Along these lines, I’d like to remind everyone of a fairly important 
> consultation that Andrew Hadenfeldt posted here last month

> (FCC) seeks comment on vulnerabilities threatening the security and integrity 
> of
the Border Gateway Protocol (BGP)...
> Comments are due on or before April 11, 2022
> If you have particular views on this important consultation, please take the 
> time to file comments as appropriate.

+1 to this suggestion to file comments - IMO there is always value in comments 
from technical experts. If you have not done so before, this may help:

•   Comments are due: April 11, 2022 & Reply Comments are due: May 10, 2022
•   Can file earlier than these dates, but no later.
•   File comments in the FCC’s Electronic Comment Filing System (ECFS) at 
https://www.fcc.gov/ecfs/filings/standard in docket CG Docket No. 22-90 (in the 
“Proceeding(s)” box, type in “22-90” and click on the option that populates: 
“Secure Internet Routing”
•   Fill in all other required information.  For “Type of Filing,” choose 
“Comment” or “Reply to Comments” (as applicable) from the drop-down menu.
•   Disregard the fields labeled File Number, Report Number, and Bureau ID 
Number.
•   Upload document as a PDF.
•   Check the box for “Email Confirmation” and then “Continue to review 
screen” where you will submit the comments into the record.

Jason

RPKI adoption (was: Re: 2749 routes AT RISK )

[John Curran]

On 4 Apr 2022, at 8:16 PM, John Gilmore mailto:g...@toad.com>> 
wrote:
...
Also, centralizing control over route acceptance can be used for
censorship.  If the RIRs succeed in convincing "enough of the net" to
reject any route that doesn't come with an RIR signature, then any
government with jurisdiction over those RIRs can force them to not sign
routes for sites that are politically incorrect.  How convenient -- for
authoritarians.  You can have all the IP addresses you want, you just
can't get 90% of the ISPs in the world to route packets to them.

There is no shortage of Horsemen of the Infopocalypse (child porn,
terrorism, sex slavery, Covid misinformation, manipulative propaganda,
war news, copyright violations, etc, etc, etc) that Absolutely Need To
Be Stamped Out Today whenever politicians decide that Something Must Be
Done.  As an example, we have regularly seen courts force centralized
domain registrars to reject perfectly good applicants for just such
reasons (e.g. SciHub).  The distributed Internet has "routed around"
their ability to censor such information via the routing table.  ISPs
should not hand governments a tool that they have abused so many times
in the past.

There’s a pretty serious misunderstanding here – ARIN certainly offers RPKI 
services and we’ll help someone get ROAs setup for their resources, but that’s 
about as far as we go…

We do point folks to resources on how to perform route origin validation (ROV) 
so they can know the steps involved, but it is truly is up to each network 
operator to decide whether they wish to take that step – which as you note 
comes with some real-world implications (both good & bad) as a result of new 
linkages with additional parties for your network routing…

Would the Internet be a better place if everyone did ROV?  I could easily argue 
some of the upsides such as potential mitigation of routing hijack attempts, 
but the centralization of control and corresponding risks do also need to be 
weighed here.   For example, while ARIN has done exceptionally well 
historically avoiding any government interference in the operation of the 
registry, that is obviously no assurance of future outcomes in this regard.  In 
this end, network operators need to consider the potential benefits and the 
potential risks applicable to their own circumstances, determine _their_ 
desired outcomes, and then shouldn’t hesitate to speak up with regard how they 
want the Internet networking layer to evolve.

Along these lines, I’d like to remind everyone of a fairly important 
consultation that Andrew Hadenfeldt posted here last month 
 –

https://www.federalregister.gov/documents/2022/03/11/2022-05121/secure-internet-routing
https://www.fcc.gov/document/fcc-launches-inquiry-internet-routing-vulnerabilities

(FCC) seeks comment on vulnerabilities threatening the security and integrity of
the Border Gateway Protocol (BGP), which is central to the Internet's global
routing system, its impact on the transmission of data from email,
e-commerce, and bank transactions to interconnected Voice-over Internet
Protocol (VoIP) and 9-1-1 calls, and how best to address them.

Comments are due on or before April 11, 2022

If you have particular views on this important consultation, please take the 
time to file comments as appropriate.

Best wishes,
/John

John Curran
President and CEO
American Registry for Internet Numbers

RE: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[Michel Py]

Hi John,

> John Curran wrote :
> Even so, we at ARIN are in the midst of a Board-directed review of the RPKI 
> legal framework to see if any improvements can be made
> 
>   – I will provide further updates once it is completed.

Thanks, we appreciate the effort.

That being said, something has to be done. I feel that the RPKI validation by 
ARIN is somehow useless. Why : because few download the TAL (at least in part 
because of the indemnisation clause).
Therefore, many networks that do RPKI validation do validate prefixes from the 
other 4 RIRs but not mine.
In simple words : why bother validating, if all of most of the networks that 
could block invalid prefixes don't, because the TAL agreement is not palatable.

I understand that ARIN has to deal with a legal system that makes things 
difficult, but OTOH I would like ARIN's RPKI validation to provide the same 
protection than the other RIRs, which it currently does not.

I created my ROAs, but I am not protected as well as an Org belonging to 
another RIR.

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!...

Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[Ronald F. Guilmette]

In message , 
John Curran  wrote:

>Alas, it’s not those who fail to properly configure RPKI that are likely to be
>litigating, but rather their impacted customers and those customers' business
>partners who all were unable to communicate due to no fault of their own. 
>
>Such a matter will not be thrown out of court, but will be the start of a long
>and very expensive process involving claims, discovery, experts, etc...

Perhaps.  There are certainly some big players (AWS) that if routing were
interrupted for even, say, 12 hours, a lot of folks would get really mad
about.

Correct me if I'm wrong, but one of your presentation slides seemed to
suggest that a separate arms-length legal entity could be established
to do the RPKI stuff, thus offloading most or all of the potential
liability onto and into this separate entity, which could conveniently
have minimal assets of the kind that might inspire members of the
plaintiff's bar who are looking for deep pockets.

Is that an actual possibility, or did you just throw that in there for the
sake of completness?

Personally, I don't much care how the problem gets solved, as long as it
gets solved.  The fundamental BGP problem has been known and discussed
now for 20+ years and it is only getting more dire and ominous, day by day.


Regards,
rfg

Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[Anne P. Mitchell, Esq.]

> There's obviously a disconnect where people aren't worried about indemnifying
> Spamhaus for using their block list, but are worried about indemnifying ARIN 
> for
> using the TAL.

That would be because there is a rather substantial difference between 
publishing an IP address for which you have spam in hand, and are saying (and 
only saying) "I received spam from this IP address" (not to mention something 
which people use to only affect inbound email), and hosting something on which 
others rely for making their acceptance decision of all legitimate Internet 
traffic, as well as for the ability to not move malicious (or even accidentally 
misconfigured) Internet traffic.

Anne

Anne P. Mitchell, Attorney at Law
Dean of Cybersecurity & Cyberlaw, Lincoln Law School of San Jose
CEO/President, Institute for Social Internet Public Policy
SuretyMail Email Reputation Certification
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Legislative Consultant
GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant
Board of Directors, Denver Internet Exchange
Board of Directors, Asilomar Microcomputer Workshop
Legal Counsel: The CyberGreen Institute
Former Counsel: Mail Abuse Prevention System (MAPS)
Member: California Bar Association

Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[Valdis Klētnieks]

On Wed, 14 Aug 2019 16:07:49 -, John Curran said:

> > But I suspect a lot of companies are reading it as: "If a spammer sues you 
> > for using
> > a block list that prevents them from spamming your customers, you can't end 
> > up
> > owing money to the block list maintainers.  But if you rely on the ARIN 
> > TAL, and get
> > sued by an address hijacker, you could end up owing money to ARIN".

> It's is not "you owe money to ARIN", but it could be "you need to defend both
> yourself and ARIN from your customers litigation should you get it wrong."

Is there any workable way to remove or diminish the perception of liability in
the case of using it *correctly*?   I admit that (a) I'm not a lawyer and (b)
when I actually tried to read it I couldn't actually tell if it was "you
promise to defend us if you screw it up and customer traffic gets accidentally
dropped on the floor" or "you promise to defend us if you use it correctly and
miscreant traffic is intentionally dropped on the floor"...

There's obviously a disconnect where people aren't worried about indemnifying
Spamhaus for using their block list, but are worried about indemnifying ARIN for
using the TAL.



pgpPfQJhUFewN.pgp
Description: PGP signature

Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[Rubens Kuhl]

On Wed, Aug 14, 2019 at 1:09 PM John Curran  wrote:

> On 14 Aug 2019, at 11:15 AM, Valdis Klētnieks 
> wrote:
> >
> > On Wed, 14 Aug 2019 02:42:09 -, John Curran said:
> >
> >> You might want want to ask them why they are now a problem when they
> weren’t
> >> before (Also worth noting that many of these ISP's own contracts with
> their
> >> customers have rather similar indemnification clauses.)
> >
> > Actually, it's probably ARIN that should be doing the asking, and seeing
> if
> > they can change the wording and/or rephrase the issue to allay concerns.
> >
> > It sounds to me like ARIN's *intent* was "if you get sued by your
> customers because
> > you screw the pooch on deployment, it's your screw-up to clean up and
> not our
> > problem". Or at least I *hope* that was the intent (see next paragraph)
>
> That is indeed the intent - please deploy routing validation using best
> practices, so that you & your customers don’t suffer any adverse impact
> when ARIN's repository is not available.
>
>
Or, move all your number resources to a subsidiary in the AP region, pay
membership fees to APNIC instead of ARIN, and use their trust anchor
instead of ARIN's.
BTW, since all 5 RIRs have certificates signing the whole IP address space,
it really makes no difference.


Rubens

Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[John Curran]

On 14 Aug 2019, at 11:15 AM, Valdis Klētnieks  wrote:
> 
> On Wed, 14 Aug 2019 02:42:09 -, John Curran said:
> 
>> You might want want to ask them why they are now a problem when they weren’t
>> before (Also worth noting that many of these ISP's own contracts with their
>> customers have rather similar indemnification clauses.)
> 
> Actually, it's probably ARIN that should be doing the asking, and seeing if
> they can change the wording and/or rephrase the issue to allay concerns.
> 
> It sounds to me like ARIN's *intent* was "if you get sued by your customers 
> because
> you screw the pooch on deployment, it's your screw-up to clean up and not our
> problem". Or at least I *hope* that was the intent (see next paragraph)

That is indeed the intent - please deploy routing validation using best 
practices, so that you & your customers don’t suffer any adverse impact when 
ARIN's repository is not available.

> But I suspect a lot of companies are reading it as: "If a spammer sues you 
> for using
> a block list that prevents them from spamming your customers, you can't end up
> owing money to the block list maintainers.  But if you rely on the ARIN TAL, 
> and get
> sued by an address hijacker, you could end up owing money to ARIN”.

It’s is not “you owe money to ARIN’, but it could be “you need to defend both 
yourself and ARIN from your customers’ litigation should you get it wrong."

> (Having said that, John, it takes a special sort of CEO to stand out and be 
> seen
> in situations like this, and the world could probably use more CEO's like 
> that…)

 fairly easy to do if one has a thick skin… ;-)

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers




signature.asc
Description: Message signed with OpenPGP

Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[Valdis Klētnieks]

On Wed, 14 Aug 2019 02:42:09 -, John Curran said:

> You might want want to ask them why they are now a problem when they weren’t
> before (Also worth noting that many of these ISP's own contracts with their
> customers have rather similar indemnification clauses.)

Actually, it's probably ARIN that should be doing the asking, and seeing if
they can change the wording and/or rephrase the issue to allay concerns.

It sounds to me like ARIN's *intent* was "if you get sued by your customers 
because
you screw the pooch on deployment, it's your screw-up to clean up and not our
problem". Or at least I *hope* that was the intent (see next paragraph)

But I suspect a lot of companies are reading it as: "If a spammer sues you for 
using
a block list that prevents them from spamming your customers, you can't end up
owing money to the block list maintainers.  But if you rely on the ARIN TAL, 
and get
sued by an address hijacker, you could end up owing money to ARIN".

(Having said that, John, it takes a special sort of CEO to stand out and be seen
in situations like this, and the world could probably use more CEO's like 
that...)





pgpqCVyRjaf5u.pgp
Description: PGP signature

Re: RPKI adoption

[Job Snijders]

Dear all,

On Wed, Aug 14, 2019 at 10:36:44AM +, John Curran wrote:
> On 14 Aug 2019, at 2:26 AM, Matthew Petach  wrote:
> > ...
> > Now, at the risk of bringing down the ire of the community on my
> > head...ARIN could consider tying the elements together, at least for
> > ARIN members.  Add the RPKI terms into the RSA document.  You need
> > IP number resources, congratulations, once you sign the RSA, you're
> > covered for RPKI purposes as well.
> 
> Matthew - 
> 
>   Yes indeed - this is one of several potential improvements that we’re 
> also investigating. 

I've attempted to produce a humorous world map chart to help clarify
there is a degree of asymmetry our community may need to consider:


http://instituut.net/~job/screenshots/e079d90a-3047-4034-8e7c-9caf6e387f1a.png

The ARIN members (mostly located in the red area) would like all
not-ARIN-members (located in the blue area, the rest of the world) to
use and honor their ROAs published through ARIN's RPKI service.

If not for the purpose of facilitating BGP Origin Validation on as many
as possible of Internet's routers to protect one's IP resources, why
else would anyone publish RPKI ROAs through their RIR?

In other words: ARIN members want something (something very reasonable!)
from "the rest of the world", but in order to accomplish that
'something', unfortunately "the rest" needs to agree to the ARIN RPA.
This has proven to be somewhat of an adoption barrier.

It would be fantastic when "the rest" are not required to do any such
thing and the ARIN RPKI TAL can be distributed without restrictions or
limitations.

I would love to see any solution that removes all potential friction for
"the rest of the world", even if that shifts some additional burden to
ARIN members themselves; because it's ARIN members that want something
from the world, less so the other way around.

On Wed, Aug 14, 2019 at 4:42 AM John Curran  wrote:
> Interestingly enough, those same indemnification clauses are in the
> registration services agreement that they already signed but
> apparently they were not an issue at all when requesting IP address
> space or receiving a transfer.

Your observation (if correct) indeed is very interesting, and perhaps
demonstrates that RPKI business is something between ARIN and ARIN's
members, and less so between ARIN and all other potential relaying
parties on this planet. Or phrased differently: perhaps only ARIN
members should be the ones incurring the cost and burden of reviewing
and accepting ARIN's agreements.

I'd like to express my appreciation to ARIN's staff & ARIN's Board of
Trustees for dedicating their time and resources to research how to
improve in this context.

Kind regards,

Job

ps. Ofcourse this map is an oversimplification of the situation,
apologies for any inaccuracies.

Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[John Curran]

On 14 Aug 2019, at 1:21 AM, Ronald F. Guilmette 
mailto:r...@tristatelogic.com>> wrote:

In message 
<06570278-e1ad-4bb0-a9fc-11a77bed7...@arin.net>,
John Curran mailto:jcur...@arin.net>> wrote:

Even so, we at ARIN are in the midst of a Board-directed review of the RPKI
legal framework to see if any improvements can be made   – I will
provide further updates once it is completed.

This is an excellent presentation John, and I'm real glad to see that you
have done such a nice job on it and touched on all of the important points.

In particular, I'm glad that you clarified that if everyone is just doing
what they ought to be doing, i.e. following best practices, then even if
RPKI central and all of its sister satellites should all be simultaneously
hit by metorites, then in theory at least, nobody should be any worse off
than they already are today.

And yes, I can't argue and won't argue that some folks aren't going to be
bozos and screw up their RPKI deployment, and then some of them -may-
possibly want to blame ARIN for -their- screw ups, but I continue to have
trouble envisioning how this would ever traslate into a lawsuit that
wouldn't simply be laughed out of court in about five seconds if handled
properly.

Alas, it’s not those who fail to properly configure RPKI that are likely to be 
litigating, but rather their impacted customers and those customers' business 
partners who all were unable to communicate due to no fault of their own.

Such a matter will not be thrown out of court, but will be the start of a long 
and very expensive process involving claims, discovery, experts, etc.  (a 
recent legal matter that was promptly resolved in ARIN’s favor pre-litigation 
still resulted in more than 1/3 million USD in costs...)   Absent a specific 
reason for dismissal, it is only in actual trial that the preponderance of 
evidence gets considered – and note that in such a dispute, we’d end up with a 
jury of regular folks hearing fairly technical arguments about certificate 
validation, covering ROA’s, caching, etc.In other words, even if handled 
perfectly, your five second estimate is likely off by a year or more (and hence 
the reason for indemnification - it provides a clear basis for ARIN’s exit from 
the matter, as it makes plain that the liability resulting from use of the RPKI 
repository lies with the ISP.)

Thanks,
/John

John Curran
President and CEO
American Registry for Internet Numbers

Re: RPKI adoption

[John Curran]

On 14 Aug 2019, at 12:51 AM, Hank Nussbacher  wrote:
> …
> Just like to add kudos to John for being open and responsive on this list and 
> other lists to numerous issues and questions in regards to ARIN.  Not many 
> CEOs are willing or able to respond as you do.  

Hank - 

Thanks! – as I work for you (i.e. this collective community), I see it 
as a reasonable obligation to be reachable/answerable regarding how your 
registry is being run.

/John

John Curran
President and CEO
American Registry for Internet Numbers

p.s.  As a reminder, those interested in more prominent/direct role in 
oversight of ARIN should consider running for the Board of Trustees…  

Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[John Curran]

On 14 Aug 2019, at 2:26 AM, Matthew Petach  wrote:
> ...
> Now, at the risk of bringing down the ire 
> of the community on my head...ARIN could
> consider tying the elements together, at 
> least for ARIN members.  Add the RPKI terms 
> into the RSA document.  You need IP number
> resources, congratulations, once you sign the
> RSA, you're covered for RPKI purposes as well.

Matthew - 

Yes indeed - this is one of several potential improvements that we’re 
also investigating. 

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers

Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[John Curran]

On 14 Aug 2019, at 1:01 AM, William Herrin  wrote: 
> ...
> >  I would observe that continued use at that point has been held
> > to indicate agreement on your part [ref: Register.com, Inc. v. Verio, Inc., 
> > 356 F.3d 393 (2d Cir. 2004)]
> 
> In which Verio admitted to the court that they knew they were abusing 
> Register's computers but figured Register's contract with ICANN gave them the 
> right. The court would have reached the same decision regardless of 
> Register's notice: You're abusing computers that aren't yours. Stop it.

BIll - 

The particular finding from Register v. Verio that is relevant was that a user 
made aware of applicable terms with each query (even at the end) is sufficient 
for contractual binding after continued use.  

> Specht v. Netscape Communications Corp, on the other hand, found that, 
> "plaintiffs neither received reasonable notice of the existence of the 
> license terms nor manifested unambiguous assent" to the contract Netscape 
> offered for the use of their software at download-time, including assent to 
> settle disputes through arbitration.

Register v. Verio was after Specht v Netscape, and distinguished the situation 
where the user received terms at the end of each response from those cases 
where a user couldn’t reasonably determine that there were any applicable terms 
and conditions. 

> I'll take any bet you care to offer that the latter precedent applies to 
> casual consumer use of ARIN's whois.

That bet is available to you at any time by violating the terms the ARIN’s 
Whois service, so the question to ask yourself is: "do you feel lucky?”

Thanks,
/John

John Curran
President and CEO
American Registry for Internet Numbers

Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[Matthew Petach]

On Tue, Aug 13, 2019 at 5:44 PM John Curran  wrote:

> On 13 Aug 2019, at 9:28 PM, Ronald F. Guilmette 
> wrote:
>
> ...
> The last time I looked, RPKI adoption was sitting at around a grand total
> of 15% worldwide.  Ah yes, here it is...
>
>   https://rpki-monitor.antd.nist.gov/
>
> I've asked many people and many companies why adoption remains so low, and
> why their own companies aren't doing RPKI.  I've gotten the usual
> assortment
> of utterly lame excuses, but the one that I have had the hardest time
> trying to counter is the one where a network engineer says to me "Well,
> ya know, we were GOING to do that, but then ARIN... unlike the other four
> regional authorities... demanded that we sign some silly thing indemnifying
> them in case of something.
>
>
> Interestingly enough, those same indemnification clauses are in the
> registration services agreement that they already signed but apparently
> they were not an issue at all when requesting IP address space or receiving
> a transfer.
> You might want want to ask them why they are now a problem when they
> weren’t before (Also worth noting that many of these ISP's own contracts
> with their customers have rather similar indemnification clauses.)
>

Hi John,

There are things companies will sign
when their backs are up against the wall
that they will balk at signing when it is
for an optional geek-ish extra.

IP addresses are the lifeblood of the
tech industry.  If you don't have an
IP address, you don't exist on the
Internet.  (Apologies to those of us
who still have modems configured
to call and retrieve mail addressed
with UUCP bang paths).

So, companies will grudgingly and with
much hand-wringing sign the RSA
necessary to get IP space.  Without,
they die.  Rather like oxygen; if we
had to sign a license agreement in
order to receive air to breathe, you'd
find most people would sign pretty
horrific terms of service agreements.

Slip those same terms in front of someone
as a requirement for them to buy beer,
and you'll likely discover a whole lot of
people are just fine drinking something
else instead.

So too with the RSA terms versus the
RPKI terms.

As companies, we can't survive without
IP addresses.  We'll sign just about anything
to stay alive.

RPKI is a geek toy.  It's not at all required
for a business to stay alive on the Internet,
so companies feel much safer in saying
"no way will we sign that!".

Now, at the risk of bringing down the ire
of the community on my head...ARIN could
consider tying the elements together, at
least for ARIN members.  Add the RPKI terms
into the RSA document.  You need IP number
resources, congratulations, once you sign the
RSA, you're covered for RPKI purposes as well.

That doesn't solve the issue for out-of-region
folks who don't have an RSA with ARIN; but
that's no worse than you are today; and by
bundling the RPKI terms in with the rest of the
RSA, you at  least get everyone in the ARIN
region that wants^Wneeds to maintain their
IP number resources in order to stay in business
on the Internet covered in terms of being able to
use the RPKI data.

If you've got them by the short and curlies
already, might as well bundle everything in
while they've got the pen in their hand.  ^_^;

Even so, we at ARIN are in the midst of a Board-directed review of the RPKI
> legal framework to see if any improvements can be made <
> https://www.arin.net/vault/participate/meetings/reports/ARIN_43/PDF/PPM/curran_rpki.pdf>
>  – I will provide further updates once it is completed.
>

Best of luck!  I know we'll all be watching carefully to
see how it goes.:)

Matt


> Thanks!
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
>

Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[Ronald F. Guilmette]

In message <06570278-e1ad-4bb0-a9fc-11a77bed7...@arin.net>, 
John Curran  wrote:

>Even so, we at ARIN are in the midst of a Board-directed review of the RPKI
>legal framework to see if any improvements can be made vault/participate/meetings/reports/ARIN_43/PDF/PPM/curran_rpki.pdf>  – I will
>provide further updates once it is completed. 

This is an excellent presentation John, and I'm real glad to see that you
have done such a nice job on it and touched on all of the important points.

In particular, I'm glad that you clarified that if everyone is just doing
what they ought to be doing, i.e. following best practices, then even if
RPKI central and all of its sister satellites should all be simultaneously
hit by metorites, then in theory at least, nobody should be any worse off
than they already are today.

And yes, I can't argue and won't argue that some folks aren't going to be
bozos and screw up their RPKI deployment, and then some of them -may-
possibly want to blame ARIN for -their- screw ups, but I continue to have
trouble envisioning how this would ever traslate into a lawsuit that
wouldn't simply be laughed out of court in about five seconds if handled
properly.

Some arguably proximate historical analogs might be relevant here.

In the past, there have occasionally been problems when one or more of
the root name servers have been DDoSd or have otherwise had issues.
I don't recall anybody lining up to sue ICANN in those instances.

Spamhaus and other public anti-spam services publish their stuff to all
comers, without demanding indemnification.  Yes, they have been sued
from time to time, but none of that has ever resulted in any meaningful
damages, and if the company itself had just been more consistant in
obtaining sound legal advice, none of those events would even have been
all that bothersome.

So, what makes ARIN so special that it can't do what these others are doing
and just simply publish some information?  ARIN is in the State of Virginia
the last time I checked, and I do believe that the First Amendment still
applies in the State of Virginia, and indeed in all 50 states.  I mean it
isn't as if ARIN is going to go around yelling "Fire!" in a crowded theater
for God's sake!

So, you just slap a label on the whole bloody RPKI thing that says "Use at
your own risk" and that ought to do it, I think.  I understand that Steve
Ryan may not see it that way, but it's his job not to see it that way.
In practice, there is no need for -both- belt -and- suspenders.


Regards,
rfg


P.S.  Proactive failure testing (slide #15) is an excellent idea.  You could
and probably should fail the whole thing deliberately for 24 hours once a
year, just as a way of shaking the trees to see what idiots fall out.  It
would be like DNS Flag Day, on steroids.

Re: RPKI adoption

[William Herrin]

On Tue, Aug 13, 2019 at 9:51 PM Hank Nussbacher 
wrote:

> Just like to add kudos to John for being open and responsive on this list
> and other lists to numerous issues and questions in regards to ARIN.  Not
> many CEOs are willing or able to respond as you do.
>
> Thanks for your time and effort,
>

I'll second that despite my criticism.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[William Herrin]

On Tue, Aug 13, 2019 at 8:25 PM John Curran  wrote:
> On 13 Aug 2019, at 11:03 PM, William Herrin  wrote:
> I signed no legal agreement either to register my legacy addresses or to
do a whois lookup to check someone else's addresses. Just sayin’.
>
> If you instead used a command line interface (e.g. "whois -h
whois.arin.net …”),
> then you received output from ARIN’s Whois server along with notice of
the applicable terms of service…

Hi John,

As I no longer live within or act from within one of the 2 states to have
passed UCITA, you'll find that notice difficult to enforce.


>  I would observe that continued use at that point has been held
> to indicate agreement on your part [ref: Register.com, Inc. v. Verio,
Inc., 356 F.3d 393 (2d Cir. 2004)]

In which Verio admitted to the court that they knew they were abusing
Register's computers but figured Register's contract with ICANN gave them
the right. The court would have reached the same decision regardless of
Register's notice: You're abusing computers that aren't yours. Stop it.

Specht v. Netscape Communications Corp, on the other hand, found that,
"plaintiffs neither received reasonable notice of the existence of the
license terms nor manifested unambiguous assent" to the contract Netscape
offered for the use of their software at download-time, including assent to
settle disputes through arbitration.

I'll take any bet you care to offer that the latter precedent applies to
casual consumer use of ARIN's whois. I won't take any such bet when it
comes to the legal safety of redistributing ARIN's RPKI Trust Anchor
Locator in my software. And neither, apparently, do many of the folks who
would have to redistribute that TAL for ARIN's RPKI to be useful, as was
discussed here last September:
https://mailman.nanog.org/pipermail/nanog/2018-September/097161.html

Regards,
Bill Herrin


--
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: RPKI adoption

[Hank Nussbacher]

On 14/08/2019 06:24, John Curran wrote:


When you did that Whois look up at the ARIN website, you did agree to 
terms of use for the Whois service which contains indemnification 
provisions and are legally enforceable. 



If you instead used a command line interface (e.g. "whois -h 
whois.arin.net  …”), then you received output 
from ARIN’s Whois server along with notice of the applicable terms of 
service…  I would observe that continued use at that point has been 
held to indicate agreement on your part [ref: Register.com 
, Inc. v. Verio, Inc., 356 F.3d 393 (2d Cir. 2004)]


Thanks,
/John

John Curran
President and CEO
American Registry for Internet Numbers

Just like to add kudos to John for being open and responsive on this 
list and other lists to numerous issues and questions in regards to 
ARIN.  Not many CEOs are willing or able to respond as you do.


Thanks for your time and effort,

-Hank

Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[John Curran]

On 13 Aug 2019, at 11:03 PM, William Herrin 
mailto:b...@herrin.us>> wrote:

On Tue, Aug 13, 2019 at 7:42 PM John Curran 
mailto:jcur...@arin.net>> wrote:
On 13 Aug 2019, at 9:28 PM, Ronald F. Guilmette 
mailto:r...@tristatelogic.com>> wrote:
The last time I looked, RPKI adoption was sitting at around a grand total
of 15% worldwide.  Ah yes, here it is...

  https://rpki-monitor.antd.nist.gov/

I've asked many people and many companies why adoption remains so low, and
why their own companies aren't doing RPKI.  I've gotten the usual assortment
of utterly lame excuses, but the one that I have had the hardest time
trying to counter is the one where a network engineer says to me "Well,
ya know, we were GOING to do that, but then ARIN... unlike the other four
regional authorities... demanded that we sign some silly thing indemnifying
them in case of something.

Interestingly enough, those same indemnification clauses are in the 
registration services agreement that they already signed but apparently they 
were not an issue at all when requesting IP address space or receiving a 
transfer.

I signed no legal agreement either to register my legacy addresses or to do a 
whois lookup to check someone else's addresses. Just sayin’.

Bill -

When you did that Whois look up at the ARIN website, you did agree to terms of 
use for the Whois service which contains indemnification provisions and are 
legally enforceable. <https://www.arin.net/resources/registry/whois/tou/>

If you instead used a command line interface (e.g. "whois -h 
whois.arin.net<http://whois.arin.net> …”), then you received output from ARIN’s 
Whois server along with notice of the applicable terms of service…  I would 
observe that continued use at that point has been held to indicate agreement on 
your part [ref: Register.com<http://Register.com>, Inc. v. Verio, Inc., 356 
F.3d 393 (2d Cir. 2004)]

Thanks,
/John

John Curran
President and CEO
American Registry for Internet Numbers

Re: RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[William Herrin]

On Tue, Aug 13, 2019 at 7:42 PM John Curran  wrote:

> On 13 Aug 2019, at 9:28 PM, Ronald F. Guilmette 
> wrote:
>
> The last time I looked, RPKI adoption was sitting at around a grand total
> of 15% worldwide.  Ah yes, here it is...
>
>   https://rpki-monitor.antd.nist.gov/
>
> I've asked many people and many companies why adoption remains so low, and
> why their own companies aren't doing RPKI.  I've gotten the usual
> assortment
> of utterly lame excuses, but the one that I have had the hardest time
> trying to counter is the one where a network engineer says to me "Well,
> ya know, we were GOING to do that, but then ARIN... unlike the other four
> regional authorities... demanded that we sign some silly thing indemnifying
> them in case of something.
>
>
> Interestingly enough, those same indemnification clauses are in the
> registration services agreement that they already signed but apparently
> they were not an issue at all when requesting IP address space or receiving
> a transfer.
>

I signed no legal agreement either to register my legacy addresses or to do
a whois lookup to check someone else's addresses. Just sayin'.

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

RPKI adoption (was: Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17)

[John Curran]

On 13 Aug 2019, at 9:28 PM, Ronald F. Guilmette 
mailto:r...@tristatelogic.com>> wrote:
...
The last time I looked, RPKI adoption was sitting at around a grand total
of 15% worldwide.  Ah yes, here it is...

  https://rpki-monitor.antd.nist.gov/

I've asked many people and many companies why adoption remains so low, and
why their own companies aren't doing RPKI.  I've gotten the usual assortment
of utterly lame excuses, but the one that I have had the hardest time
trying to counter is the one where a network engineer says to me "Well,
ya know, we were GOING to do that, but then ARIN... unlike the other four
regional authorities... demanded that we sign some silly thing indemnifying
them in case of something.

Interestingly enough, those same indemnification clauses are in the 
registration services agreement that they already signed but apparently they 
were not an issue at all when requesting IP address space or receiving a 
transfer.
You might want want to ask them why they are now a problem when they weren’t 
before (Also worth noting that many of these ISP's own contracts with their 
customers have rather similar indemnification clauses.)

Even so, we at ARIN are in the midst of a Board-directed review of the RPKI 
legal framework to see if any improvements can be made 
<https://www.arin.net/vault/participate/meetings/reports/ARIN_43/PDF/PPM/curran_rpki.pdf>
  – I will provide further updates once it is completed.

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers

Re: Report on Legal Barriers to RPKI Adoption

[Ben Maddison via NANOG]

Hi all,

Thanks Christopher and co-authors for this document. The issues that you have 
highlighted are critical to ensuring that SOV and other future applications of 
the RPKI can be deployed in production without becoming serious latent risk to 
the Internet community and RIR system.

As a case in point with respect to your recommendations regarding the RPA, we, 
AS37271, have announced that we will implement strict SOV (i.e. dropping 
Invalids) as of 1 April 2019.

As things stand today, we will not be making use of the ARIN TAL.

We have arrived at this decision primarily because we are not willing to be 
bound by the indemnification clause (paragraph 7) of the RPA. In our 
assessment, the potential (and unbounded) liability that we could be exposed to 
under that clause presents a substantial business risk, and that it is 
inappropriate given the nature of the service and the role of an RIR in 
providing authoritative data on the allocation of number resources.

I believe problems also exist in other sections of the RPA, and my strong 
preference would be for ARIN to dispense with it altogether. However, if 
paragraph 7 were to be removed, we would likely be inclined towards accepting 
it.

Since the RPA imposes substantial obligations and risks on the relying party, I 
also believe that putting convenience methods (such as click-through acceptance 
during install of RP software packages) in place will simply encourage users to 
agree to accept those risks without fully understanding them, thus storing up 
unintended legal risks for Internet operators in the future.
I therefore welcome Job and Nathalie's assertions that there is little interest 
in the community of RP software developers to implement these "features".

This mail is already plenty long enough, but I am happy to discuss in more 
detail, either on- or off-list, if others are interested.

Cheers,

Ben Maddison

Director
Workonline Communications (Pty) Ltd


From: NANOG  on behalf of Nathalie Trenaman 

Sent: 08 January 2019 12:40:33
To: Job Snijders
Cc: David Wishnick; Christopher S. Yoo; nanog@nanog.org
Subject: Re: Report on Legal Barriers to RPKI Adoption

Dear all,

After reading the report, I agree with Job it was well written and a must-read 
for everyone with an interest in RPKI, even outside the ARIN region. Well done!
As RIPE NCC is maintaining validator software, I would like to comment on point 
2:

2.   Developers of RPKI validation software should consider integrating 
acceptance of ARIN's RPA into their software workflows. ARIN recently enabled 
this possibility, and developers should deliberate on whether to capitalize on 
the opportunity.


To put it bluntly: item 2 is not going to happen.

We've discussed this extensively in the OpenBSD community (who are working on a 
new RPKI Validation implementation [source: rpki-client]), and concluded that 
collecting explicit consent to the RPA on behalf of ARIN is undesirable and 
without precedent. This doesn't exist for DNSSEC, TLS certificates, or IRR data 
- and we're not going to make an exception for ARIN and encumber each and every 
OpenBSD or rpki-client(1) installation.

I checked the temperature in the room of the other relevant RPKI Validation 
implementations, and it appears that *nobody* is planning to integrate 
acceptance of ARIN's RPA into their installation process.


I concur that for the RIPE NCC Validator this is something we don't want to 
implement.
Having said that, we do hear from our users that the current setup, where we 
point users to the ARIN TAL, is not optimal to say the least. Users simply 
don't understand why the other TALs automatically are installed and the ARIN 
TAL isn't, so we follow the discussions in the ARIN region closely.

Best regards,

Nathalie Trenaman
RIPE NCC





Op 6 jan. 2019, om 17:02 heeft Job Snijders mailto:j...@ntt.net>> 
het volgende geschreven:

Dear Christopher, David, NANOG community,

Thank you for your research and report. I found the report quite readable (not 
having a legal background) and well structured. Definitely edifying and worth 
the read! In this mail I'll reply specifically to a few points from the 
executive summary (and snip the rest).

For those of you who don't want to create a SSRN account here is a copy of the 
report:
http://instituut.net/~job/SSRN-id3309813.pdf


On Thu, 3 Jan 2019 at 23:53, Christopher S. Yoo 
mailto:cs...@law.upenn.edu>> wrote:
Here is a summary of our recommendations:
On the ROV side of the equation, the principal legal hindrances have to do with 
the terms and conditions governing access to the RPKI repository offered by 
ARIN in its Relying Party Agreement ("RPA"), and in the manner it has employed 
to ensure the agreement is binding. Regarding ROV:
1.   The goal of widespread ROV counsels in favor of ARIN reviewing its 
current approach to repository distribution, embodied in the RPA. W

Re: Report on Legal Barriers to RPKI Adoption

[Nathalie Trenaman]

Dear all,

After reading the report, I agree with Job it was well written and a must-read 
for everyone with an interest in RPKI, even outside the ARIN region. Well done!
As RIPE NCC is maintaining validator software, I would like to comment on point 
2:

> 2.   Developers of RPKI validation software should consider integrating 
> acceptance of ARIN’s RPA into their software workflows. ARIN recently enabled 
> this possibility, and developers should deliberate on whether to capitalize 
> on the opportunity.
> 
> 
> 
> To put it bluntly: item 2 is not going to happen.
> 
> We’ve discussed this extensively in the OpenBSD community (who are working on 
> a new RPKI Validation implementation [source: rpki-client]), and concluded 
> that collecting explicit consent to the RPA on behalf of ARIN is undesirable 
> and without precedent. This doesn’t exist for DNSSEC, TLS certificates, or 
> IRR data - and we’re not going to make an exception for ARIN and encumber 
> each and every OpenBSD or rpki-client(1) installation.
> 
> I checked the temperature in the room of the other relevant RPKI Validation 
> implementations, and it appears that *nobody* is planning to integrate 
> acceptance of ARIN’s RPA into their installation process.


I concur that for the RIPE NCC Validator this is something we don’t want to 
implement. 
Having said that, we do hear from our users that the current setup, where we 
point users to the ARIN TAL, is not optimal to say the least. Users simply 
don’t understand why the other TALs automatically are installed and the ARIN 
TAL isn’t, so we follow the discussions in the ARIN region closely.

Best regards,

Nathalie Trenaman
RIPE NCC





> Op 6 jan. 2019, om 17:02 heeft Job Snijders  het volgende 
> geschreven:
> 
> Dear Christopher, David, NANOG community,
> 
> Thank you for your research and report. I found the report quite readable 
> (not having a legal background) and well structured. Definitely edifying and 
> worth the read! In this mail I’ll reply specifically to a few points from the 
> executive summary (and snip the rest). 
> 
> For those of you who don’t want to create a SSRN account here is a copy of 
> the report: 
> http://instituut.net/~job/SSRN-id3309813.pdf 
> 
> 
> 
> On Thu, 3 Jan 2019 at 23:53, Christopher S. Yoo  > wrote:
> Here is a summary of our recommendations:
> 
> On the ROV side of the equation, the principal legal hindrances have to do 
> with the terms and conditions governing access to the RPKI repository offered 
> by ARIN in its Relying Party Agreement (“RPA”), and in the manner it has 
> employed to  ensure the agreement is binding. Regarding ROV:
> 
> 1.   The goal of widespread ROV counsels in favor of ARIN reviewing its 
> current approach to repository distribution, embodied in the RPA. We conclude 
> that two paths would be reasonable. First, ARIN should consider dropping the 
> RPA altogether. This would remove the most significant legal barriers to 
> widespread utilization of the ARIN RPKI repository.
> 
> 
> 
> I’m happy to see suggestions that dropping the RPA is a viable path.
> 
> In December 2018 we’ve measured that around TWENTY percent of the networks 
> deploying RPKI based Origin Validation are missing the ARIN TAL [source: 
> benjojo]. This is an extremely worrying number, as it means that ARIN ROAs 
> are worth far less than RIPE, APNIC, AFRINIC, or LACNIC ROAs. I believe the 
> root cause for ARIN being an outliner is absence of the ARIN TAL in the 
> common RPKI Validation softwares. The absence of the ARIN TAL in software 
> distributions can be directly attributed to the existence of the RPA and 
> applicable contract doctrines.
> 
> If no changes are made to the current situation, I expect the 20% number to 
> remain the same or even grow, effectively making ARIN’s RPKI services 
> unsuitable for the purpose of securing routing.
> 
> 
> 2.   Developers of RPKI validation software should consider integrating 
> acceptance of ARIN’s RPA into their software workflows. ARIN recently enabled 
> this possibility, and developers should deliberate on whether to capitalize 
> on the opportunity.
> 
> 
> 
> To put it bluntly: item 2 is not going to happen.
> 
> We’ve discussed this extensively in the OpenBSD community (who are working on 
> a new RPKI Validation implementation [source: rpki-client]), and concluded 
> that collecting explicit consent to the RPA on behalf of ARIN is undesirable 
> and without precedent. This doesn’t exist for DNSSEC, TLS certificates, or 
> IRR data - and we’re not going to make an exception for ARIN and encumber 
> each and every OpenBSD or rpki-client(1) installation.
> 
> I checked the temperature in the room of the other relevant RPKI Validation 
> implementations, and it appears that *nobody* is planning to integrate 
> acceptance of ARIN’s RPA into their installation process.
> 
> 
> 4.   In addition to the 

Re: Report on Legal Barriers to RPKI Adoption

[Job Snijders]

Dear Christopher, David, NANOG community,

Thank you for your research and report. I found the report quite readable
(not having a legal background) and well structured. Definitely edifying
and worth the read! In this mail I’ll reply specifically to a few points
from the executive summary (and snip the rest).

For those of you who don’t want to create a SSRN account here is a copy of
the report:
http://instituut.net/~job/SSRN-id3309813.pdf


On Thu, 3 Jan 2019 at 23:53, Christopher S. Yoo  wrote:

> Here is a summary of our recommendations:
>
On the ROV side of the equation, the principal legal hindrances have to do
> with the terms and conditions governing access to the RPKI repository
> offered by ARIN in its Relying Party Agreement (“RPA”), and in the manner
> it has employed to ensure the agreement is binding. Regarding ROV:
>
> 1.   The goal of widespread ROV counsels in favor of ARIN reviewing
> its current approach to repository distribution, embodied in the RPA. We
> conclude that two paths would be reasonable. First, ARIN should consider
> dropping the RPA altogether. This would remove the most significant legal
> barriers to widespread utilization of the ARIN RPKI repository.
>


I’m happy to see suggestions that dropping the RPA is a viable path.

In December 2018 we’ve measured that around TWENTY percent of the networks
deploying RPKI based Origin Validation are missing the ARIN TAL [source:
benjojo]. This is an extremely worrying number, as it means that ARIN ROAs
are worth far less than RIPE, APNIC, AFRINIC, or LACNIC ROAs. I believe the
root cause for ARIN being an outliner is absence of the ARIN TAL in the
common RPKI Validation softwares. The absence of the ARIN TAL in software
distributions can be directly attributed to the existence of the RPA and
applicable contract doctrines.

If no changes are made to the current situation, I expect the 20% number to
remain the same or even grow, effectively making ARIN’s RPKI services
unsuitable for the purpose of securing routing.


2.   Developers of RPKI validation software should consider integrating
> acceptance of ARIN’s RPA into their software workflows. ARIN recently
> enabled this possibility, and developers should deliberate on whether to
> capitalize on the opportunity.
>


To put it bluntly: item 2 is not going to happen.

We’ve discussed this extensively in the OpenBSD community (who are working
on a new RPKI Validation implementation [source: rpki-client]), and
concluded that collecting explicit consent to the RPA on behalf of ARIN is
undesirable and without precedent. This doesn’t exist for DNSSEC, TLS
certificates, or IRR data - and we’re not going to make an exception for
ARIN and encumber each and every OpenBSD or rpki-client(1) installation.

I checked the temperature in the room of the other relevant RPKI Validation
implementations, and it appears that *nobody* is planning to integrate
acceptance of ARIN’s RPA into their installation process.


4.   In addition to the important step ARIN has already taken to enable
> third-party software developers to integrate RPA acceptance into their
> software workflows, ARIN should consider reducing the barriers to
> third-party service development imposed by the RPA’s prohibited conduct
> clause. Specifically, ARIN should consider methods for allowing approved
> developers to make use of RPKI information as an input into more
> sophisticated services.
>
5.   Separately, ARIN should consider revising the prohibited conduct
> clause to allow broader distribution of information created with RPKI as an
> input for research and analysis purposes.
>


To provide context for the above two paragraphs, at this point in time it’s
unclear whether BGPMon’s WHOIS, NLNOG’s IRRExplorer, and the various “RPKI
to IRR” services are violating the RPA. I believe it to be highly
undesirable for this uncertainty to persist, nor would it be acceptable to
require each and every (potential) innovator or researcher to sign
contracts with ARIN. ARIN members would be significantly worse off if these
services stop using the ARIN TAL.

Finally, ARIN members should realize that the majority of ASNs on the
Internet are *outside* North America and are not ARIN members. We want
*all* networks to be able to honor ARIN RPKI ROAs. BGP hijacks and
misconfigurations don’t know borders. It’s not reasonable to require Dutch,
Indian, Russian and Chinese networks to enter into a contractual agreement
with ARIN in order to protect the ARIN members. This is why we need things
to work properly out of the box, just like was done with DNSSEC. Reform is
needed.

Kind regards,

Job

[benjojo]: https://blog.benjojo.co.uk/post/state-of-rpki-in-2018
[rpki-client]:
https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-validator-openbsd-rpki-client-1-15b74e7a3f65

Report on Legal Barriers to RPKI Adoption

[Christopher S. Yoo]

As many of you know, the prospects for widespread RPKI adoption grew more 
promising in 2018. Cloudflare issued route origin authorizations ("ROAs") to 
cover 25% of its prefixes, including its 1.1.1.1 resolver and DNS servers. NTT 
began treating RPKI ROAs as if they were IRR route(6)-objects. Google announced 
its intention to begin filtering routes in early 2019. The Mutually Agreed 
Norms for Routing Security now has over 100 network operators signed on.

Still, as 2019 begins, many worry that legal issues are hindering RPKI 
adoption. This is especially true for North American networks, which have a 
comparatively low percentage of IPv4 space covered by ROAs, and whose ROAs are 
comparatively underutilized by parties using RPKI-based route origin validation 
("ROV") to inform their routing decisions.

My coauthor (David Wishnick) and I have spent the past year delving into the 
legal issues surrounding RPKI. Today, we are publicizing our report on how the 
network operator community should address these issues. It is available 
here<https://ssrn.com/abstract=3308619>. If you are interested in the future of 
routing security, we encourage you to read it (or its Executive Summary). We've 
tried to keep the legalese to a minimum.

RPKI was a major topic of discussion at NANOG 74 and ARIN 42 in Vancouver. 
Going forward, we expect to continue a fruitful dialogue about how the network 
operator community can reduce the legal barriers to RPKI adoption.

Here is a summary of our recommendations:

On the ROV side of the equation, the principal legal hindrances have to do with 
the terms and conditions governing access to the RPKI repository offered by 
ARIN in its Relying Party Agreement ("RPA"), and in the manner it has employed 
to ensure the agreement is binding. Regarding ROV:

1.   The goal of widespread ROV counsels in favor of ARIN reviewing its 
current approach to repository distribution, embodied in the RPA. We conclude 
that two paths would be reasonable. First, ARIN should consider dropping the 
RPA altogether. This would remove the most significant legal barriers to 
widespread utilization of the ARIN RPKI repository. Second, because the legal 
risks faced by ARIN in an RPA-free world are ultimately uncertain, it would 
also be reasonable for ARIN to maintain the RPA for the purposes of 
contractually allocating risks to the parties best positioned to reduce and 
mitigate them. If ARIN keeps the RPA, ARIN should consider removing the RPA's 
indemnification clause, instead relying solely on the RPA's disclaimers of 
warranties and limitations of liability, or at least reducing the 
indemnification clause's scope to eliminate the problem of moral hazard.

2.   Developers of RPKI validation software should consider integrating 
acceptance of ARIN's RPA into their software workflows. ARIN recently enabled 
this possibility, and developers should deliberate on whether to capitalize on 
the opportunity.

3.   The network operator community and ARIN should broadly publicize 
ARIN's policy of revising various RPA clauses for government entities that are 
prohibited from agreeing to them.

4.   In addition to the important step ARIN has already taken to enable 
third-party software developers to integrate RPA acceptance into their software 
workflows, ARIN should consider reducing the barriers to third-party service 
development imposed by the RPA's prohibited conduct clause. Specifically, ARIN 
should consider methods for allowing approved developers to make use of RPKI 
information as an input into more sophisticated services.

5.   Separately, ARIN should consider revising the prohibited conduct 
clause to allow broader distribution of information created with RPKI as an 
input for research and analysis purposes.

6.   As a general alternative, the Internet community should consider 
whether to develop a separate corporate entity that would be responsible for 
operational aspects of RPKI repository provision. That corporation could 
conduct such activities for the North American region, or on a worldwide basis.

Regarding the ROA-issuance side of the equation, the principal legal obstacles 
stem from the terms and conditions found in ARIN's Registration Services 
Agreement ("RSA"), Legacy Registration Services Agreement ("LRSA"), and RPKI 
Terms of Service. Regarding these, the report recommends the following:

1.   ARIN should consider adopting a pathway to provide RPKI services that 
would explicitly refrain from altering the existing balance of property and 
transferability rights associated with IP address allocations.

2.   The network operator community and ARIN should broadly publicize 
ARIN's policy of revising certain RSA/LRSA and RPKI Terms of Service clauses 
for government entities that are prohibited from agreeing to them. ARIN should 
also begin presenting the RPKI Terms of Service to newly-onboarded