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:
  • To:
  • Subject: Re: [Security-WG] LESA (was:Re: [External] Re: ARIN, RPKI, and legal barriers....)
  • Date: Thu, 18 Apr 2019 13:39:19 -0400

Here’s my understanding WRT to prefixes:

If you specify a range (e.g., 129.79.0.0/16-24), then the more secure approach is to ensure you’re normally announcing all of the /24 specifics. The risk is that someone would prepend your AS and announcement a more specific that a) fits in the range of the ROA and b) you’re not currently announcing. In most cases prepending the target's AS will result in a longer path, so it won’t be used, and the hijack won’t be successful However, if you’re not announcing a more specific that would fit in your ROA, then an evildoer can prepend your AS, and it won’t matter that the resulting AS path is longer…as the more specific will win.

Hope that helps.

Steve


On Apr 18, 2019, at 12:46 PM, Spurling, Shannon <> wrote:

We have had an LRSA with ARIN for some time, and yet we still had to argue with them over the removal of the indemnification and binding arbitration clauses in the TOS for the ROA’s. Be sure to have all legal documentation on hand and ready to present. If they don’t think it is persuasive enough, they will ask you to agree to the TOS as presented, regardless of what your LRSA states.
 
My biggest issue with the ROAs is if they need to be specific or if they can be set for a range of prefixes. There is the ability to do so, but there are a lot of people who feel they need to be specific only. 
 
Shannon Spurling
 
 
From:  <> On Behalf Of 
Sent: Thursday, April 18, 2019 11:37 AM
To: 
Subject: [Security-WG] LESA (was:Re: [External] Re: ARIN, RPKI, and legal barriers....)
 
At the risk repeating myself, I’d like to reenforce DougM’s advice:
 
If you have a current RSA with ARIN, it’s easy to create ROAs for your networks, and it’s in your interest to do so.
 
If you need assistance, while I’m no expert I’ve gone through the process and I’m happy to help, so drop me a note.
 
Steve
 


On Apr 18, 2019, at 11:10 AM, Montgomery, Douglas (Fed) (via security-wg Mailing List) <> wrote:
 
The number of networks and IXP’s filtering BGP announcements (and filtering IRR data) with RPKI is growing.  This is something that is hard to measure … but there is an attempt here: (https://rov.rpki.net/
). Note that the measurement technique does not list ATT, that began route filtering at the beginning of the year (https://pc.nanog.org/static/published/meetings/NANOG75/1956/20190219_Levy_Lightning_Talk_Dropping_v1.pdf
).
 
 
Create ROAs for your BGP announced prefixes listing authorized origin AS’es.  Ask your hosted service providers to do the same in service agreements (see AWS DNS BGP hijack).  
 
Those networks that filter, will in general not accept unauthorized originations (mis-configurations and simple hijacks) of your prefixes from other networks.
 
This provides some protection to routes to your resources in other networks.  Each network that does RPKI OV, protects your routes to them and their downstreams (in general).
 
Employ RPKI origin validation to your BGP feeds.  This provides some protection in the routing you provide your customers.
 
The ROA vs Filtering issue may seem like a chicken and egg problem (why create ROAs until most everyone is filtering?, why filter until most everyone has ROAs?), but it is not.  Incremental deployment gets incremental benefit.  
 
dougm 
-- 
DougM at NIST
 
 
From: <> on behalf of Eldon Koyle <>
Reply-To: " List:" <>
Date: Thursday, April 18, 2019 at 3:01 AM
To: " List:" <>
Subject: Re: [Security-WG] LESA (was:Re: [External] Re: ARIN, RPKI, and legal barriers....)
 

Maybe I'm misunderstanding the situation today...  As I understand it, ARIN provides three major services:

1. whois, which is important to my ISP if I'm changing something or someone claims I'm not the rightful owner of a resource (and, of course, to provide email addresses to spammers)

2. Reverse DNS

3. RPKI that very few people validate as of today

How would any of these protect me from a route hijacking threat on the internet today?  Am I missing some other service, or are we talking about the potential benefits of RPKI if people were to start validating it widely?

--
Eldon Koyle
 

From:  <> on behalf of "Montgomery, Douglas (Fed)" <>
Sent: Wednesday, April 17, 2019 10:04:10 AM
To: 
Subject: Re: [Security-WG] LESA (was:Re: [External] Re: ARIN, RPKI, and legal barriers....)
 
Change is always scary … until you are hit with the reason that makes not changing even more scary.
 
I would have thought the AWS route 53 hijack, or the realization that it is relatively easy for a bad guy to get issued a valid DV CERT for your domain would be motivating enough.  
 
But it will probably take more.
 
dougm
-- 
DougM at NIST
 
 
From: <> on behalf of "Schopis, Paul" <>
Reply-To: " List:" <>
Date: Wednesday, April 17, 2019 at 10:10 AM
To: " List:" <>
Subject: Re: [Security-WG] LESA (was:Re: [External] Re: ARIN, RPKI, and legal barriers....)
 
Doug,
I hope you realize making rationale and logical arguments is a dangerous thing.....
 
Be well,
Paul
 
 
Paul Schopis
Executive Director & Chief Technology Officer
Ohio Academic Resources Network (OARnet)
A member of the Ohio Technology Consortium
1224 Kinnear Road, Columbus, Ohio 43212
Office: (614) 292-1956 • Fax: (614) 728-8110
 

From:  <> on behalf of "Montgomery, Douglas (Fed)" <>
Sent: Wednesday, April 17, 2019 9:15 AM
To: 
Subject: Re: [Security-WG] LESA (was:Re: [External] Re: ARIN, RPKI, and legal barriers....)
 
I think most of this is FUD.
 
 
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.”
 
 
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.
 
 
ARIN still focuses on liability concerns WRT potential failure scenarios in the RPKI system.
 
 
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
===============================================

Attachment: smime.p7s
Description: S/MIME cryptographic signature




Archive powered by MHonArc 2.6.19.

Top of Page