Re: ARIN Fraud Reporting Form ... Don't waste your time

[David Miller <dmiller () tiggee com>]

 On 10/1/2010 9:07 AM, bmanning () vacation karoshi com  wrote:
> On Fri, Oct 01, 2010 at 08:47:29AM -0400, David Miller wrote:
> > As to what ARIN can 'do' about addresses that are unused/abandoned and
> > later hijacked...
> >
> > ARIN delegates Reverse DNS for every allocation that they make.  Address
> > blocks that are reported, investigated, and determined to be
> > unused/abandoned could be delegated to special ARIN name servers that
> > merely returned the following for any reverse DNS query:
> >
> > z.y.x.w.in-addr.arpa.  172800  IN   PTR
> > do.not.accept.anything.from.this.abandoned.address.space
> >
> > This is something that ARIN *could* easily do technically.  Admittedly,
> > this would require reporting and investigation that I am uncertain
> > whether or not ARIN is empowered/funded to do.  This would also require
> > a process be put in place for removing allocations from the delegation
> > to the unused/abandoned reverse DNS servers...
> >
> > -DM
>         Goodness me - I've seen that trick before.  Worked for
>         about 15 minutes before I had legal camped out in the office.
>         Pulled it shortly there after.
>
>         I -think- what you are really after is the (fairly) new rPKI
>         pilot - where there are crypto-keys tied to each delegated
>         prefix.  If the keys are valid, then ARIN (or other RIR) has
>         "sanctioned" thier use.  No or Bad crypto, then the RIR has
>         some concerns about the resource.
>
>         the downside to this is that the RIR can effectivey cut off
>         someone who would otherwise be in good standing.  Sort of
>         removes a level of independence in network operations.  Think
>         of what happens when (due to backhoe-fade, for instance) you
>         -can't- get to the RIR CA to validate your prefix crypto?  Do
>         you drop the routes?  Or would you prefer a more resilient
>         and robust solution?  YMMV here, depending on whom you are
>         willing to trust as both a reputation broker -AND- as the prefix
>         police.
>
>         The idea is that the crypto is harder to forge.  DNS forging
>         is almost as easy as prefix "borrowing".
>
>
> --bill

I am not referring to DNS forging or crypto DNS validation or route 
announcement validation - which are certainly good topics that are 
worthy of further discussion.

I am merely refuting the statement, which I have heard many times in 
many different forums, that ARIN (or any RIR) makes address allocations 
and then walks away with no further active involvement in the use of 
these allocations.  This statement is simply not true.

These sorts of statements about an RIR having no ability to affect prior 
allocations are normally formed like:
1) RIRs have no control over the routing table or anything operationally 
in the path of evil people using IPs.
2) An RIR just makes allocations and then has nothing to do with IPs on 
a daily basis.
3) An RIR is powerless to affect anything operationally (other than 
reclaiming allocations) for allocations that have been made in the past.

These are all untrue statements.  The RIR's reverse DNS servers are 
queried all day every day for the reverse DNS delegations for every 
netblock that they allocate.  This means that RIRs are, in at least this 
way, actively operationally involved in the use of the allocations that 
they make.  This also means that an RIR has the technical vector to 
affect the active present use of the allocations that they have made in 
the past.

From ARIN's Number Resource Policy Manual [ 
https://www.arin.net/policy/nrpm.html ]:
...
3.6 Annual Whois POC Validation
  3.6.1 Method of Annual Verification
    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 POC record shall be 
marked invalid. ARIN will maintain, and make readily available to the 
community, a current list of number resources with no valid POC; this 
data will be subject to the current bulk Whois policy.
...
7. Reverse Mapping
  7.1 Maintaining IN-ADDRs
    All ISPs receiving one or more distinct /16 CIDR blocks of IP 
addresses from ARIN will be responsible for maintaining all IN-ADDR.ARPA 
domain records for their respective customers. For blocks smaller than 
/16, and for the segment of larger blocks  smaller than /16, ARIN can 
maintain IN-ADDRs.

  7.2 Lame Delegations in IN-ADDR.ARPA
    ARIN will actively identify lame DNS name server(s) for reverse 
address delegations associated with address blocks allocated, assigned 
or administered by ARIN. Upon identification of a lame delegation, ARIN 
shall attempt to contact the POC for that resource and resolve the 
issue. If, following due diligence, ARIN is unable to resolve the lame 
delegation, ARIN will update the Whois database records resulting in the 
removal of lame servers.

So... ARIN has some 'investigation' power and responsibility for 
actively removing lame POC contacts and Reverse DNS delegations.  What 
isn't clear to me from ARIN's policies is what happens when all POC 
contacts or all Reverse DNS delegations for an allocation have been 
removed because they are lame...

This is not to single ARIN out particularly.  All of the above is true 
for every RIR (ARIN, RIPE, APNIC, AFRINIC, LACNIC), though I haven't dug 
into any policies except ARIN's.

-DM