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