[arin-ppml] Draft Policy 2008-7: Identify Invalid WHOIS POC's

[Ted Mittelstaedt]

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Grundemann
> Sent: Monday, March 30, 2009 12:54 PM
> To: Member Services
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml]Draft Policy 2008-7: Identify Invalid 
> WHOIS POC’s
> 
> On Mon, Mar 23, 2009 at 13:05, Member Services <info at arin.net> wrote:
> > SUBJECT: Draft Policy 2008-7: Identify Invalid WHOIS POC’s
> >
> > Draft Policy 2008-7
> > Identify Invalid WHOIS POC’s
> >
> > The following draft policy text is being posted for feedback and 
> > discussion on the Public Policy Mailing List (PPML).
> >
> > After the October 2008 Public Policy Meeting the ARIN 
> Advisory Council
> > (AC) decided that 2008-7 required more work. The text below was 
> > developed by the AC with help from the proposal originators. The AC 
> > was required to submit text to ARIN for staff and legal assessment 
> > prior to selecting it as a draft policy. The assessment, along with 
> > the text that was assessed, is located below the draft policy.
> >
> > On 20 March 2009 the ARIN Advisory Council (AC) selected 
> Draft Policy
> > 2008-7: Identify Invalid WHOIS POC’s (formally known as WHOIS 
> > Integrity Policy Proposal) for adoption discussion on the 
> PPML and at 
> > the upcoming Public Policy Meeting.
> >
> > Draft Policy 2008-7 is below and can be found at:
> > https://www.arin.net/policy/proposals/2008_7.html
> >
> > We encourage you to discuss Draft Policy 2008-7 on PPML 
> prior to the 
> > ARIN XXIII Public Policy Meeting. Both the discussion on 
> the PPML and 
> > at the Public Policy Meeting will be used by the ARIN 
> Advisory Council 
> > to determine the community consensus regarding adopting 
> this as policy.
> >
> > The ARIN Policy Development Process can be found at:
> > https://www.arin.net/policy/pdp.html
> >
> > All of the Draft Policies under discussion can be found at:
> > https://www.arin.net/policy/proposals/index.html
> >
> > Regards,
> >
> > Member Services
> > American Registry for Internet Numbers (ARIN)
> >
> >
> > ## * ##
> >
> >
> > Draft Policy 2008-7
> > Identify Invalid WHOIS POC’s
> >
> > Date: 23 March 2009
> >
> > Policy Statement:
> >
> > During ARINs annual WHOIS POC validation, an e-mail will be sent to 
> > every POC in the WHOIS database. Each POC will have a maximum of 60 
> > days to respond with an affirmative that their WHOIS contact 
> > information is correct and complete. Unresponsive POC email 
> addresses 
> > shall be marked as such in the database. If ARIN staff 
> deems a POC to 
> > be completely and permanently abandoned or otherwise 
> illegitimate, the 
> > record shall be deleted. ARIN will maintain, and make readily 
> > available to the community, a current list of 
> address-blocks with no 
> > valid POC; this data will be subject to the current bulk 
> WHOIS policy.
> >
> > Timetable for implementation: Immediate
> >
> >
> > #####
> >
> > ARIN Staff Assessment
> >
> > 2008-7
> >
> > Title:  Identify Invalid WHOIS POC's (formerly known as WHOIS 
> > Integrity Policy Proposal)
> >
> > Revision Submitted: 07 March 2008
> >
> > 2nd Revision Submitted: 12 Feb 2009
> >
> > Date of Assessment:  24 Feb 2009
> >
> > The assessment of this text includes comments from ARIN 
> staff and the 
> > ARIN General Counsel. It contains analysis of procedural, 
> legal, and 
> > resource concerns regarding the implementation of this text 
> as it is 
> > currently stated. Any changes to the language may 
> necessitate further 
> > analysis by staff and Counsel.
> >
> > I.  Understanding
> >
> > ARIN staff understands that this will institute an annual 
> > re-registration of all POCs registered in WHOIS.  POCs who do not 
> > respond within 60 days will be marked in the database as 
> "un-responsive"
> > and if staff deems them to be invalid for any reason, may 
> remove them 
> > from WHOIS.  In addition, staff will maintain a list of all address 
> > blocks with no valid POCs and will make this data available to any 
> > organization using the bulk whois policy criteria.
> >
> > II.  Issues and Concerns
> >
> >  A.  ARIN Staff Comments:
> >
> >    * Resource records marked as “unresponsive” or those 
> with no POCs 
> > at
> >      all could become the targets of hijackers who, in the past have
> >      tended to look for address blocks that contain 
> obsolete or stale data.
> 
> This is exactly why I (and I believe the other authors of 
> this proposed policy) wanted the discloser to be required.  
> Hijackers, like spammers, phishers and other criminals spend 
> their time finding this kind of data -- the idea of this 
> portion of this policy is to give everyone the data that we 
> can assume hijackers (probably) already have.  This public 
> disclosure of netblocks with out any valid POCs will 
> hopefully encourage the rightful holders of those blocks to 
> update their POC info and if not, it at least allows the rest 
> of the community to be mindful of such blocks.
> 
> >    *  An annual re-registration of all POCs (~223,000 
> currently) will
> >      likely result in a vast increase in workload, particularly with
> >      the follow up work and research involved when a POC does not 
> > reply
> >      within 60 days.  This could result in a slow down in 
> registration
> >      response and processing times.
> 
> This proposal does not require a "re-registration of all POCs"
> annually.  It requires an email validation of all POCs 
> annually and that POCs which do not respond to email have 
> their record marked as such -- this is meant to be an 
> entirely automated process.  The policy then grants ARIN 
> staff the discretion to do follow up work and research on 
> POCs; it does not require that ARIN follow up on every (or 
> even any) unresponsive POC every year -- it is meant to allow 
> staff to follow up where they can/need and give them 
> authority to lock or remove POCs that are found to be 
> completely illegitimate (those that don't respond to repeated 
> and various contact attempts, etc).
> 
> >    * This policy refers to the Bulk Whois policy rather than stating
> >      the actual criteria under which an organization will 
> be allowed 
> > to
> >      request the list of all address blocks with no valid POCs.  It
> >      would be better policy text to state the specific criteria,
> >      including the requirement to sign an AUP, within this 
> policy itself.
> >
> 
> "ARIN will maintain, and make readily available to the 
> community, a current list of address-blocks with no valid 
> POC; this data will be subject to the current bulk WHOIS policy."
> 
> My understanding of this text is that the list of address blocks with
> no valid POCs should be available to anyone interested in it.    We
> chose to reference the Bulk WHOIS policy instead of 
> re-stating it here so as to maintain a central policy 
> regarding WHOIS data. 

Chris and I are two of the authors on this policy.

The statement:

"...this data will be subject to the current bulk WHOIS policy..."

was added so as to direct ARIN staff that the list of address blocks
without valid POC, discovered through this policy, was NOT to be considered
special, privileged information,
and it would not allow our policy proposal to be construed as granting
these "found" blocks any special "blocking" of this data within WHOIS.

It is my suggestion that people worried about hijackers finding stale blocks
create and submit a policy proposal that deals with making, or not making,
available such status in WHOIS.  Maybe you want it available via bulk but
not individual query - whatever.  You have to be aware that "non-virginial"
IPv4 blocks can be added into WHOIS from ARIN staff from OTHER PROCESSES
than our whois grooming policy proposal.

So, if your objection to our proposal is based on this hijacking thing,
then I submit that your barking up the wrong tree because "holes"
already exist right now in WHOIS data submission, and your not objecting
to them.

To see what I mean, issue these queries:

whois -h whois.arin.net 206.50.0.0
whois -h whois.arin.net 206.51.0.0
whois -h whois.arin.net 206.52.0.0

Note that 206.50 and 206.52 are both assigned to NTT but 206.51 is not.
That is because 206.51.0.0 was occupied by some other org that went
defunct - otherwise don't you think that NTT and ARIN would have both
wanted NTT to be assigned a contiguous block?

When the original owner of 206.51 disappeared, ARIN hasn't yet reassigned
that block - so it just removed all POC's from it and left the block
just floating in WHOIS.

This very-hijackable block only took me about 10 minutes to find, with WHOIS
queries issued by hand, by typing each one in.  So please, if the hijacking
thing is really your concern, then address it, and quit knocking our policy.

Ted