[arin-ppml] Revealing /32 customers?

[Jack Bates]

On 4/26/2012 5:45 PM, John Curran wrote:
> 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. 

I never care about organizational customers. Given they generally have 
/29 or larger netblocks, they are forewarned concerning ARIN and get to 
enjoy long conference calls while we discuss how exactly they'll be 
using IP Address space.

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

This sort of thing makes better sense than asking for residential 
customer details; although I'd probably argue against uncensored views 
of configs. I don't believe in security through obscurity, but I also 
don't believe in letting people view snmp community names and encrypted 
passwords if it can be helped.

> 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) 

66 customer details for /32 assignments is probably not readily 
available. I suspect it takes hours of hand typing or copy and pasting 
to generate that information. Depending on the size of the request, you 
may be asking for a database report instead of monkeys hand typing. That 
can take days to get requested by some companies.

You rarely ask for it so it may be little work to ARIN, but it is a 
burden to the requester.

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

I think there are many things ARIN can do or request that doesn't 
include residential customer information or unfiltered access to a 
config. Some of them, such as meeting sessions would provide greater 
assurances of accurate details and should take less time to verify than 
reviewing a report of names (supposing ARIN actually reviews the report 
and doesn't just say, "They sent it, it looks okay, so accept it."). It 
also falls into the standard ISP/Corporate structure that is allowed for 
standard vendor interaction (Some places may let vendors run free, but 
some of us watch every little thing they do and restrict what they can see).


Jack