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

["Sanjaya" <sanjaya@apnic.net>]

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.