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

  • To: <sig-db at apnic dot net>, <sig-db-chair at apnic dot net>, <sig at apnic dot net>
  • Subject: [sig-db]Proposal: Protecting Resource Records in APNIC Whois Database
  • From: "Sanjaya" <sanjaya at apnic dot net>
  • Date: Thu, 24 Jul 2003 17:32:23 +1000
  • Importance: Normal
  • 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>
  • Sender: sig-db-admin@lists.apnic.net
    • 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.