[arin-ppml] Draft Policy ARIN-2019-2: Waiting List Block Size Restriction

Wed Feb 27 15:21:36 EST 2019

“The waiting list does work pretty well.  Let's cut down on the abuse with a minimal change in policy as in option 1 above.”

I see three reasons why Option#1 is the best proposal so far:

1-      Fraud reduction, not necessarily elimination. There is nothing wrong with a review after implementation to determine the effect on /22 blocks.

2-      A limit of /22 would conserve the existing pool and provide service to more applicants on the waiting list.

3-      At the very least, it would force innovators to reconsider deployment on IPv6 instead.

Whether there is statistical evidence to support fraud or abuse, it is inevitable.

Orin Roberts

From: ARIN-PPML <arin-ppml-bounces at arin.net> On Behalf Of Tom Fantacone
Sent: February-27-19 2:53 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2019-2: Waiting List Block Size Restriction

Hi Robert,

The statistical evidence indicates that the fraud is mostly associated with larger block sizes, which may make up a decent percentage of the address space on the waiting list, but only a small percentage of the businesses on the waiting list.

From John Curran's synopsis of the data:
"Of those blocks issued, 25 have been subsequently transferred (19 of which were /18 and above, 6 of which /16 or /17 in size); i.e. only 3% of the smaller blocks issued have been transferred, whereas 42% of the largest block sizes issued (/16 and /17) were subsequently transferred."

So while it's possible a bad actor will commit fraud to receive a /22 off the waiting list and resell it a year later, it doesn't appear there's evidence this is happening now on any significant scale.

This data also suggests the optimum solution to curb the problem.  The ideas being discussed here seem to fall into one of these camps:

1. Limit the size of blocks being distributed from the waiting list (i.e. to a /22 as in the current proposal):  Based on the data above, this would eliminate the bulk of the abuse.  The waiting list would
largely facilitate smaller entrants into the market and more of these requests could be fulfilled since the large ones won't be there to deplete the inventory.

2. Restrict the subsequent transfer of blocks being received on the waiting list (such as extending the wait time from 1 year to 3 years before those blocks could be re-transferred):  This would reduce the incentive for fraud, but would not eliminate it and would have some unintended consequences.  A fraudster grabbing a /16 would still likely profit even if they had to wait 3 years.  If you eliminate the ability to transfer these waiting list blocks entirely, fraudsters could still "game the system" by pulling the blocks into a shell entity and selling the entity.  You would have to change the waiting list rules for both 8.3/8.4 and 8.2 transfers since both types of transfers can be used for fraud.  Furthermore, you end up creating a new "class" of IPv4 addresses - those which cannot be re-transferred or can only be re-transferred after a longer wait.  That makes it tougher on buyers, sellers and brokers to identify blocks available for transfer since their eligibility depends on their history on the wait list which even the block registrant may not be aware of.  In RIPE and APNIC, they've instituted longer wait periods for blocks issues from their final /8, but these blocks are easily identifiable based on their first octet.  Plus, RIPE encountered issues with fraud on the /22s issued from their final /8 which we aren't seeing in ARIN.

3. Turn ARIN into an ecommerce business selling IP space:  This is such a massive change in direction for the community-driven non-profit steward of North American number resources that I can't even fathom it.  Think of the liability issues - is ARIN going to bless certain address blocks as free of blacklists or block lists?  Will there not be massive conflicts of interest between ARIN, with its vast insider knowledge of address space history, and other ARIN members looking to sell/transfer their unused space, not to mention the brokers/facilitators they are suddenly competing with (while charging an annual fee to be listed on their facilitators' page)?  How would it be fair to organizations that need IPv4 space that suddenly the waiting list blocks are only accessible on some kind of auction site?  There are auction sites now, and they serve a certain type of buyer well, but many organizations cannot procure resources through a public auction as it conflicts with their internal procedures, the need to cut purchase orders for specific amounts, etc.

The waiting list does work pretty well.  Let's cut down on the abuse with a minimal change in policy as in option 1 above.

Regards,

Tom

---- On Wed, 27 Feb 2019 13:25:47 -0500 Robert Clarke <robert at cubemotion.com<mailto:robert at cubemotion.com>> wrote ----

Hello David,

How are you quantifying the success of the policy here? What’s to say that 20-30% of the businesses that make up those 700 allocations didn’t provide fraudulent information?

If ARIN were to sell off the blocks this would entirely fix the clear incentive problem around spinning up new shells to profit off these policies at the detriment of good actors. Not to mention the cost of implementing a bid system would be minimal.

Best Regards,

Robert Clarke
CubeMotion LLC
robert at cubemotion.com<mailto:robert at cubemotion.com>
M: +1 (844) 244-8140 ex. 512
300 Lenora Street #454, Seattle, WA, 98121

On Feb 27, 2019, at 9:47 AM, David Farmer <farmer at umn.edu<mailto:farmer at umn.edu>> wrote:

I concur with what Tom says below. Further would like to add that when I look at the statistics I see a policy that for the most part has been very successful in accomplishing its primary goal, ensuring that IPv4 resources are not stuck in an ARIN pool.  More than 1.5M IPv4 addresses have been allocated, in 700 allocations, to organizations meeting their continuing need for IPv4 addresses, including a few larger allocations to presumably larger organizations, and many smaller allocations to presumably smaller organizations.

Unfortunately, it seems a small minority have decided to use this policy to profiteer.  This was recognized as a possible outcome of the original policy, but the community didn't want to limit the possibility of larger allocations from this policy only on the potential for abuse. Now that we have at least statistical evidence of abuse, it is therefore probably prudent to not allow further large allocations through this policy. The proposed /22 limit seems reasonable and should be effective in limiting the financial incentives to profiteer.  That is not to say it will completely eliminate the possibility of profiteering, however, good policy doesn't have to be perfect in this regard.  I think we just need to eliminate the possibility of a gigantic windfall from these larger blocks. The benefits to the community of continuing to allocate smaller blocks seem to outweigh the relatively small risk of profiteering on these smaller block.

I support the general idea of this policy, however, I think we need to fully consider all the possibilities on how to adjust this policy. But, lets not forget overall this has been a very effective policy.

Thanks.

On Wed, Feb 27, 2019 at 10:31 AM Tom Fantacone <tom at iptrading.com<mailto:tom at iptrading.com>> wrote:
Kevin,

I agree that statistical data should be used in this case to validate that the problem exists.  Not only do non-disclosures prevent ARIN from presenting most evidence of specific cases, but ARIN acknowledges that there may be specific instances where transferring out a block received from the waiting list is not fraudulent at all, but due to unusual but legitimate business circumstances.  It would not be fair to publicly point out all actors in potential fraud when a few of them might not be culpable.  But the statistical evidence is strong enough to indicate that fraud exists.

In that regard, in addition to the data John Curran provided showing the high percentage of larger blocks that have been re-transferred, it's worth reviewing the presentation by John Sweeting at the ARIN 42 meeting last October where he discussed the evidence and solicited possible solutions from the community.

Transcript;
https://www.arin.net/vault/participate/meetings/reports/ARIN_42/ppm1_transcript.html#anchor_5

Youtube;
https://www.youtube.com/watch?v=MJHgs4wWO58

Presentation;
https://www.arin.net/vault/participate/meetings/reports/ARIN_42/PDF/PPM/sweeting-policy.pdf

Specifically, John discusses the re-transfer statistics, the fact that several waiting list orgs already have at least a /16 of space, and the cases of 8.2 mergers performed by orgs on the waiting list to consolidate their holdings, avoid the one year wait, and then perform an 8.3 transfer.

Regards,

Tom

At 03:06 AM 2/27/2019, Kevin Blumberg wrote:

Ronald,

To be clear. For the purposes of the Policy Proposal I'm perfectly content with the aggregate data that has been provided.

The problem statement from the author, in my view, matches up with the data provided by John Curran.

Kevin

_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto:ARIN-PPML at arin.net>).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.

--
===============================================
David Farmer               Email:farmer at umn.edu<mailto:Email%3Afarmer at umn.edu>
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
===============================================
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto:ARIN-PPML at arin.net>).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20190227/a64669f2/attachment.htm>