[sig-db]Proposal: Protecting Resource Records in APNIC Whois Database
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.
