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.
