|
|
accept for the presentation. xing li Sanjaya wrote: > > Dear Prof. Xing Li, Hakikur Rahman and list participants, > please find the following proposal by APNIC secretariat. > Requesting acceptance to be discussed in APNIC 16 DB-SIG. > My apologies for the long text and late submission. > > Thank you, > Sanjaya > ______________________________________________________________________ > Senior Project Manager <sanjaya@apnic.net> > Asia Pacific Network Information Centre (APNIC) Tel: +61-7-3858-3100 > PO Box 2131 Milton, QLD 4064 Australia Fax: +61-7-3858-3199 > ---------------------------------------------------------------------- > See you at APNIC 16 > Seoul, Korea, 19-22 August 2003 http://www.apnic.net/meetings > ---------------------------------------------------------------------- > > 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.