[arin-ppml] Revealing /32 customers?

John Curran jcurran at arin.net
Thu Apr 26 18:45:18 EDT 2012

On Apr 26, 2012, at 3:12 PM, Jack Bates wrote:

> A person could lie about customer data about as easily as they could lie about arp tables with a perl script.

And they do indeed attempt that on occasion (which can be caught as well...) 

There's quite a bit of surprise when we ask ISPs for detailed contact
information for some of their 'organizational customers' chosen at 
random that have received reassignments...  but we do ask for that 
as well when it appears that the organizations in the reassignment 
list are predominantly fabricated.

> If you want a true audit, why not do a meeting session and a quick verify within a router/switch/etc?

I don't know if we've done an actual meeting session, but I know that we've 
done output dumps of various commands at the command line, verification from 
public looking glass locations, requested copies of equipment configuration,
and even occasional read-only remote access.

> Why cause a large amount of work on the part of honest requests (who probably don't have an IP -> Customer Name format readily available since it isn't mentioned in NRPM), especially when the requested information is for customers who don't even have to exist to receive an allocation?

Actually, it's not a large amount of work since we rarely ask for it.
Send us an 'interesting' request, and you will receive back a query
for verification of some information and might be asked to confirm 
again in another matter.

It is trivial to pregenerate a known format and known request, but much 
harder to handle (and forge) a request for something that you did not 
expect, particularly when it has to not only be complete but match your
early generations.   Trivial to dump and supply if you're authentic, but
challenging otherwise.  We decline those resource requests when the 
routine supporting followup information seems to be readily unavailable 
(i.e. w/o days to generate it)

> My big concern is that ARIN is being more aggressive than PA allocation criteria. There is no indication that at some point ISPs need to collect this /32 information from our subtending ISPs. Granted, this makes it more attractive for someone to stay with PA space, but creating hardships for that reason doesn't seem appropriate (dual standard?).

Either remove the utilization requirement, or state specifically what ARIN 
is to perform for verification (with the understanding that doing that will 
quickly result in toolkits to generate fraudulent materials in short order.)

I believe the current system is not ideal and am certain it will be 
interesting during regional IPv4 runout, but I believe it does work.
Changing the manner in which we verify need is something that can be
done if the community feels that it is a policy priority at this time
and there is consensus on how to change it.


John Curran
President and CEO

More information about the ARIN-PPML mailing list