[Services-wg] ARIN Services WG - CKN23 materials for your consideration

[John Curran]

On Jun 14, 2016, at 4:18 AM, David R Huberman <daveid at panix.com> wrote:
> 
> Hello,
> 
> From the document, the problem statement appears to be that CKN23-ARIN is worrisome to staff because:
> 
> 1) The resources are targets for hijacking;
> 2) Erodes community confidence in Whois accuracy; and
> 3) Unhappy POCs from pre-1998 who haven't updated records.
> 
> I'll be blunt and say 2) and 3) prompt no sympathy from me, and are not valid problems, in my opinion.

David - 
 
  Actually, this issue has originated not with staff, but from a significant
  number of folks who have found themselves no longer able to update
  the DNS servers (or origin AS) for a legacy network block, either though
  they were the original technical contact. 

  If the Services WG believes that the database should remain as-is, we
  are quite happy to proceed accordingly.

> In response to 1), I would think an analysis of all historical and known hijack targets, mapped to routed vs. unrouted at the time of hijacking, would be a good next step.
 
   Could you be more specific regarding “hijack targets”?  Would that be 
   IP address blocks that staff has believed have been hijacked or had
   hijacking attempted?  

> This work ensures the problem statement is valid, and that CKN23-ARIN is the impetus for picking the block, and not just simply a lack of a route announcement in a typical DFZ.

   At present, it is unlikely that CKN23-ARIN is being used to target IP
   address blocks for hijacking - i.e. in the present state, it is fairly hard
   to hijack these because of the changes to the database that have 
   been made and the institution of CKN-23. 

   The problem that we are experiencing is that many folks complain
   that they are no longer listed as the resource POC on an address
   block, even though they were the original technical contact, the anti-
   hijack changes have resulted in them being an informational “abuse” 
   contact on the record.   We can revert this (and risk increased number
   of hijackings) or we can revert this (and lock the records so that there
   still needs to be review at ARIN before changing the resource records)

I hope this helps explain the issue,
/John