Skip to Content.
Sympa Menu

netsec-sig - Re: [Security-WG] LESA (was:Re: [External] Re: ARIN, RPKI, and legal barriers....)

Subject: Internet2 Network Security SIG

List archive

Re: [Security-WG] LESA (was:Re: [External] Re: ARIN, RPKI, and legal barriers....)


Chronological Thread 
  • From: "Montgomery, Douglas (Fed)" <>
  • To: "" <>
  • Subject: Re: [Security-WG] LESA (was:Re: [External] Re: ARIN, RPKI, and legal barriers....)
  • Date: Wed, 17 Apr 2019 13:15:10 +0000

I think most of this is FUD.

 

https://www.arin.net/resources/guide/legacy/

 

Note that ARIN will not reclaim unutilized address space from legacy holders who sign this RSA, nor will ARIN attempt to take away legacy resources from organizations that choose not to sign it. However, signing the RSA contractually locks in a set of rights, and thus reduces the risk of future change.”

 

https://www.arin.net/resources/fees/fee_schedule/

 

At $150 per legacy block per year and $150 per ASN per year … we have probably already cost our organizations that much in this email thread.  Or put another way, if BGP hijacks are used to enable a serious breach at your organization, it will seem pretty silly to argue that it would have cost $300/yr to prevent them.

 

Much like the fact that there is no case law evidence of legal suits surrounding the operational failure of other trust infrastructures,  I would be interested to know if ARIN has ever “reclaimed” an address block in use, for non-payment of fees.   ARIN is a community trust and community driven organization.  If they started doing such things I suspect it would greatly damage their position in the community.

 

 

 

All FUD aside, create ROA data for your IPv6 allocations – you already have, and pay for, a RSA for them.  Deploy a validating cache, integrate it with your routers and use it to tag routes with RPKI validation information (no need to write policy to act on those tags yet).  Get some experience in how the system and services work.   Explore how to integrate the system in your existing provisioning, route policy, and monitoring systems.

 

All of the above has zero risk in the FUD domain.

 

 

dougm

-- 

DougM at NIST

 

 

From: <> on behalf of Eldon Koyle <>
Reply-To: " List:" <>
Date: Tuesday, April 16, 2019 at 7:37 PM
To: " List:" <>
Subject: Re: [Security-WG] LESA (was:Re: [External] Re: ARIN, RPKI, and legal barriers....)

 

If I don't pay my registration fees to the DMV, my car still belongs to me...  I'm just no longer allowed to operate it on the road.  If for some reason I didn't pay my ARIN fees (or I break one of their rules), according to the LRSA, I forfeit my resource -- this sounds like it no longer belongs to me, even if ARIN will let me transfer it to someone else.  You cannot deny that there is some risk in signing an LRSA, and it is very much a one-way deal (the one exception: if ARIN remains in breach of contract for 60 days after written notice).

 

I mostly object on principle, I don't think ARIN will go around trying to take allocations away.  There is definitely FUD on both sides of this argument, however until someone can prove to me that I don't actually have the rights I'm signing away with an LRSA, it makes me uncomfortable.

 

--

Eldon


From: <> on behalf of "Montgomery, Douglas (Fed)" <>
Sent: Tuesday, April 16, 2019 4:40 PM
To:
Subject: Re: [Security-WG] LESA (was:Re: [External] Re: ARIN, RPKI, and legal barriers....)

 

I think a better analogy to the automotive world is that signing an RSA is like getting your tags/registration in the state that you live.   You pay a yearly fee and agree to abide by the rules of the road.  In this case the rules of the road are ARIN policies.   Unlike your tags/registration, you are still legally allowed on the Internet road even if you don’t register (i.e., sign an RSA).

 

Signing an RSA is not like signing the title to your car over (which transfers ownership).  You are still able to sell your address space through the ARIN transfer process.  The ARIN transfer process is like DMV’s role in selling a car, they want to record the sale so that there is some accurate record of ownership.  If ARIN did not do that … global uniqueness of address would go out the window pretty fast.

 

Some folks make a pretty cogent argument that if you want to protect the future right of use and right of transfer of your number resources, you should sign an RSA to protect those rights.  That is, your rights to your address space are riskier without 

 

All current ARIN transfer policies (https://www.arin.net/resources/registry/transfers/) are written to deal with IPv4 addresses (after all, why would you need to transfer IPv6?).  Job Snijders’s proposal to open that for IPv6 was a bit of a protest proposal (IMHO) about ARIN’s RPKI policies.  That is to allow ARIN IPv6 holders to transfer their number resources to another RIR who’s RPKI services are more to the holders tastes. 

 

Finally, as far as I know, all ARIN IPv6 assignments already have an RSA.  There is no such thing as legacy IPv6.

 

On the topic of the RPA, one of the recommendations of the UPenn study was to separate the operation of the RPKI technical infrastructure from its administration and/or to replace the indemnification clause with an as-is disclaimer.

 

https://www.arin.net/vault/participate/meetings/reports/ARIN_43/PDF/PPM/yoo_rpki.pdf

 

ARIN still focuses on liability concerns WRT potential failure scenarios in the RPKI system.

 

https://www.arin.net/vault/participate/meetings/reports/ARIN_43/PDF/PPM/curran_rpki.pdf

 

Personally I think these concerns are overstated and somewhat misleading.    Much of the discussion focuses on an assumption that systems require configuration to “fall back” to present routing should there be long term outages in ARIN’s RPKI services (slide 6 above).    There are two reasons that I think this concern is overstated.

 

1.     RPKI origin validation is designed for incremental deployment and the assumption that some announcements may never have ROAs.  For these reasons, no one who understands the system would ever consider configuring a “DROP NOT FOUND” policy.   I guess we could write a BCP that states why that would be a very bad idea (similar to writing a global drop if no ROUTE object in IRR policy).  But assuming you do not have such a crazy policy, RPKI “fails open”.  That is the lack of RPKI data only removes the added protection it provides, leaving you with exactly what you have today.  That does not require the configuration of some “fall back policy” … it is how it works out of the box.

 

2.     One of the things the UPenn team sometimes fails to stress enough (slide 9 above) is that there is no legal precedents (i.e., case law history) of law suits around failures of similar systems web PKI CAs, DNSSec, IRR’s.   Certainly there are many examples of technical failures and process errors in each of these types of systems that have led to significant failures in Internet infrastructure or worse outcomes.   To date there is not legal record of anyone being sued over such failures.

 

Finally, as others have pointed out, there are similar indemnification and defense clauses on other ARIN services that everyone already uses (see section 5 of https://www.arin.net/resources/registry/whois/tou/).   So while I think the risks are overstated in the RPKI discussion, the legal requirement to indemnify and defend “ARIN and its directors, officers, employees and agents from and against all losses, liabilities, actual or pending claims, actions, damages, expenses, costs of defense and reasonable attorneys’ fees brought against ARIN by any third party arising from your use of Whois Service or any violation of these Terms, the rights of a third party or applicable law.”

 

 

TL;DR:  There is a lot of FUD in this space.  IMHO the risks of failures are over blown and the legal terms that no one can accept, apparently already apply to services we all have used for years.

 

dougm

-- 

DougM at NIST

 

 

From: <> on behalf of Eldon Koyle <>
Reply-To: " List:" <>
Date: Tuesday, April 16, 2019 at 2:19 AM
To: " List:" <>
Subject: Re: [Security-WG] LESA (was:Re: [External] Re: ARIN, RPKI, and legal barriers....)

 

I know that this is a highly polarizing topic, and maybe I should not have brought it up.

 

 

According to NSF and the courts, these allocations are a "thing of value".

 

My main objection is this: if legacy IP address allocations are "a thing of value", then signing an LRSA is somewhat like signing over the title to my car to be afforded the privilege of registering it with the DMV. 

 

Alternatively, we could try to transfer our allocation to RIPE (if we have a presence in their jurisdiction), and get more favorable terms.  Currently, I just don't see the value of signing away any rights we may or may not have for what we would get in return.

 

If courts do decide at some point in the future that IP allocations are not property (which they have not), it is still dubious whether ARIN would have any claim over our allocation.

 

--

Eldon

 


From: <> on behalf of David Farmer <>
Sent: Monday, April 15, 2019 4:27 PM
To:
Subject: [Security-WG] LESA (was:Re: [External] Re: ARIN, RPKI, and legal barriers....)

 

 

 

On Mon, Apr 15, 2019 at 4:36 PM Eldon Koyle <> wrote:

Just one problem with Internet2 requiring RPKI:  We are unable/unwilling to sign an LRSA for our legacy resources with ARIN because of the "No property rights" clause.  I don't have any problems paying the fees or abiding by the rules... signing away our rights without getting much of anything in return is not going to fly with management (or myself, for that matter).  I suspect we are not the only university in this situation.  No (L)RSA means no RPKI.

 

--

Eldon

 

What rights do you think you are signing away? I would like to understand your reasoning. 

 

The following is something I prepared for someone who asked me if they should sign an LRSA. However, I note I'm not a lawyer and you should talk to one before signing any contract;

 

My recommendation is; if the only documentation for the allocation or assignment for legacy IPv4 or ASN resources you have exists the ARIN database (Whois), then you probably want to contractually bind ARIN to keep those resources in their database and allocated or assigned to you. Meaning if you don't have, or can't find, the original documentation (letters or emails) making the assignments to you.

 

Effectively this is what the LRSA does, it is a contract with ARIN that recognizes that you are the legitimate resources holder for those resources, with commitments from ARIN regarding those resources.

 

This is what some people don't like about the contract;

 

7. NO PROPERTY RIGHTS

 

Holder acknowledges and agrees that: (a) the Included Number Resources are not property (real, personal, or

intellectual) of Holder; (b) Holder does not and will not have or acquire any property rights in or to Included Number

Resources by virtue of this Agreement; (c) Holder will not attempt, directly or indirectly, to obtain or assert any

patent, trademark, service mark or copyright in any number resources in the United States or any other country; and

(d) Holder will transfer or receive Included Number Resources in accordance with the Policies.

 

But in the contract ARIN grants the following rights;

 

2. CONDITIONS OF SERVICE

...

(b) Provision of Services and Rights. Subject to Holder’s on-going compliance with its obligations under the

Service Terms, including, without limitation, the payment of the fees (as set forth in Section 4), ARIN shall (i)

provide the Services to Holder in accordance with the Service Terms and (ii) grant to Holder the following

specified rights:

 

(1) The exclusive right to be the registrant of the Included Number Resources within the ARIN database;

(2) The right to use the Included Number Resources within the ARIN database; and

(3) The right to transfer the registration of the Included Number Resources pursuant to the Policies.

 

Holder acknowledges that other registrants with ARIN have rights that intersect or otherwise impact Holder’s

rights and/or use of the Included Number Resources, including, but not limited to, other registrants benefiting

from visibility into the public portions of registrations of the Included Number Resources as further described in

the Policies.

 

By the contract, you are granted certain exclusive rights to use your numbers. However, others have certain non-exclusive rights to use your numbers too; others have the right to use your numbers to address traffic to you, they have the right to expect your numbers to be registered in the database accurately, and they have the right to expect you to follow the policies for our region.

 

This is different than property (real, personal, or intellectual); property is a thing that you have or can have exclusive control over, meaning you can exclude others use of it. However, for Internet number resources, if the others don't have rights to use your resources in certain ways, and further, if you don't have rights to use their resources in certain ways, and if we all aren't bound to follow the same policies, the Internet just doesn't work. So basically, Internet number resources aren't property, at least, real, personal, or intellectual property.

 

In my opinion, the people that are objecting to #7 above, don't want to be bound by the same policies as everyone else, they think they have some property right that means they don't have to follow the policies established by the Internet community in our region. This kind of thinking risks breaking the Internet.

 

So, I can't come up with good reasons not to sign the LRSA and there are several compelling reasons to sign it, especially if you can't find the original documentation for your assignments or allocations.  

 

Thanks

 

--

===============================================
David Farmer              
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota  
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================




Archive powered by MHonArc 2.6.19.

Top of Page