[sig-db]Re: Proposal: Protecting Resource Records in APNIC Whois Databas

  • To: Sanjaya <sanjaya at apnic dot net>
  • Subject: [sig-db]Re: Proposal: Protecting Resource Records in APNIC Whois Database
  • From: Xing Li <xing at cernet dot edu dot cn>
  • Date: Mon, 28 Jul 2003 19:48:09 +0800
  • Cc: sig-db at apnic dot net, sig-db-chair at apnic dot net, sig at apnic dot net
  • List-archive: <http://www.apnic.net/mailing-lists/sig-db/>
  • List-help: <mailto:sig-db-request@lists.apnic.net?subject=help>
  • List-id: APNIC SIG on whois database issues <sig-db.lists.apnic.net>
  • List-post: <mailto:sig-db@lists.apnic.net>
  • List-subscribe: <http://mailman.apnic.net/mailman/listinfo/sig-db>,<mailto:sig-db-request@lists.apnic.net?subject=subscribe>
  • List-unsubscribe: <http://mailman.apnic.net/mailman/listinfo/sig-db>,<mailto:sig-db-request@lists.apnic.net?subject=unsubscribe>
  • References: <000001c351b5$b92e1000$a71d0cca@assanjaya>
  • Sender: sig-db-admin@lists.apnic.net
    • 
      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 at apnic dot 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.