Protecting Resource Records in APNIC Whois Database --------------------------------------------------- Proposed by: Sanjaya, APNIC Secretariat Version: 1.1 Date: 24 July 2003 Summary: This is a proposal to: 1. Protect all internet resource objects (inetnum, inet6num and aut-num) with proper maintainers. An unprotected object mnt-by attribute (currently has 'MAINT-NULL' value) will be filled with its parent's mnt-by value. 2. Deprecate NONE value in maintainer object's auth: attribute A test on 202/8 range has been performed with minimum impact to APNIC members. A case study will also be presented to highlight the problems associated with unprotected resource records. Background: Historically, before Whois v3, unprotected resource objects were allowed in APNIC Whois Database. As Whois v3 no longer allow unprotected resource object, during Whois v3 migration in December 2002 all unprotected resources have been converted to be protected by 'MAINT-NULL'. This is a temporary solution as MAINT-NULL does not really protect the object. APNIC Secretariat made a proposal in APNIC 14 to replace all MAINT-NULLs with the maintainer of the parent object. Consensus was not reached at that time, but an action item is created: Action db-14-002: Secretariat to create sample hierarchical inetnum objects with associated maintainer objects in the APNIC Whois Database. After APNIC 14, APNIC secretariat suggested in the sig-db mailing list to do the trial test on 202/8 range. This suggestion was accepted in the APNIC 15 meeting. Protecting object with a proper maintainer, however, would not be effective if the maintainer itself is unprotected (having auth: NONE). We propose that the value 'NONE' is no longer allowed in auth: attribute. Preliminary Test Result: APNIC secretariat developed an automated script to sweep 202/8 address space for any inetnum object protected by MAINT-NULL, and replace it with the parent's object. We ran the script on 15 July 2003 with the following result: Total objects found (mnt-by: MAINT-NULL) = 2,889 Total objects successfully converted = 2,419 Total not converted = 470 Failure to convert reasons: - Parent object is also protected by MAINT-NULL : 324 - Object contains other error (e.g. invalid nic-handle) Objects found by geography: CN 813 NZ 684 AU 318 TW 313 HK 200 IN 117 TH 112 Others 332 As of the time this report is written, there has been no complaints received from members. On 24 July 2003 APNIC did a count of maintainers that are unprotected (auth: NONE). There are 101 out of 7,093 maintainer objects found to be unprotected (that is less than 1.5% population). Case Study: On 27 June 2003 APNIC Secretariat received a complaint about unauthorised use of IPv4, pointing to these urls of unauthorised use of addresses within APNIC range: http://www.spamhaus.org/sbl/listings.lasso?isp=APNIC http://www.completewhois.com/hijacked/hijackers.htm#laurencefagan This case highlights historical address delegation to companies that has since ceased operation (due to liquidation, merger or acquisition), and the delegated resources are then transferred to other entities with or without the knowledge of the previous custodians. We are seeking input from members on how to deal with this kind of reports. While APNIC is not in a position to regulate the usage of internet resource, proper address delegation and maintaining correct information about the delegation is one of APNIC's responsibilities. Proposal: To improve the protection of internet resource records in APNIC Whois Database, APNIC secretariat propose that ALL inetnums, inet6nums and aut-nums be protected with proper maintainer (other than MAINT-NULL). This will be done to all historical, current, and erx resource range. Based on the 202/8 testing, impact to APNIC members would be minimum, and any request to change the maintainer (if it turns out to be an error) will be dealt with within 2 business days as long as there is enough evidence and authority to support the request. To ensure that all maintainers are protected, APNIC secretariat will announce deprecation of auth: NONE. Maintainers that are currently protected by auth: NONE will be given 60 days to change to another authentication method. After that period, APNIC secretariat will automatically replace auth: NONE with auth: CRYPT-PW. The password will be given to the appropriate contact persons by contacting APNIC helpdesk. Implementation: The software script to perform MAINT-NULL replacement is ready and APNIC proposes that the implementation be started within 30 days after approved by the members. The following resources will be executed in sequence: - APNIC IPv4 address range delegated from IANA - APNIC ASN range delegated from IANA - APNIC IPv6 address range delegated from IANA - ASN range received by APNIC from ERX project - IPv4 address range received by APNIC from ERX project Estimated completion time for all of the above except the last bullet (the IPv4 ERX transfer has not been completed yet) is 30 days. The software script to perform auth: NONE replacement is also ready and APNIC proposes that the implementation be started within 30 days after approved by the members. The proposed auth: NONE replacement schedule is: - Send email notifications to the contact persons of maintainer objects currently protected by auth: NONE, requesting them to change the authentication method. - 60 days after notification is sent, if auth: NONE has not been changed, APNIC secretariat will replace it with auth: CRYPT-PW. APNIC secretariat will present the implementation project report in APNIC 17.