[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[sig-policy] prop-037-v001: Deprecation of email updates forAPNIC Registry and whois
Dear SIG members
The proposal "Deprecation of email updates for APNIC Registry and whois
data" has been sent to the Policy SIG for review. It will be presented at
the Policy SIG at APNIC 22 in Kaohsiung, Taiwan, 4-8 September 2006.
You are invited to review and comment on the proposal on the mailing list
before the meeting.
The proposal's history can be found at:
http://www.apnic.net/docs/policy/proposals/prop-037-v001.html
Regards
Kenny Huang
Policy SIG
huangk@alum.sinica.edu
________________________________________________________________________
prop-037-v001: Deprecation of email updates for APNIC Registry and whois
data
________________________________________________________________________
Author: Terry Manderson, APNIC
<terry@apnic.net>
Version: 1
Date: 7 August 2006
Introduction
------------
There are two ways to update data in the APNIC registry (which includes
whois data). The first is to use interfaces on the certificate-secured
MyAPNIC web site. The second is to send plain text updates by email to
<autodbm@apnic.net> (for whois objects only).
This is a proposal to phase out email updates.
Problem summary
---------------
Security:
The mechanisms for securing the contents of an email and validating
the identity of the author of the update are weak by modern
standards. Although there are ways of improving the use of email for
secure transactions, these are not considered sufficiently
scaleable.
Unsolicited mails (spam):
The destination for email updates, <autodbm@apnic.net>, suffers from
the same set of problems as any other email address on the Internet.
Despite the APNIC Secretariat's best efforts to reduce the impact of
spam and email-borne viruses, the <autodbm@apnic.net> system
constantly receives irrelevant emails, which can affect the system's
ability to efficiently process legitimate updates.
It has also been observed that members' mail servers often reject
automated replies from <autodbm@apnic.net> as spam. This frequently
interferes with the update process, causing confusion for users and
avoidable work for the APNIC Helpdesk.
Service development:
APNIC registry services are becoming more complex and their
requirements are growing beyond the capabilities of the email update
system.
For instance, the provisions for protecting the privacy of customer
data (Policy prop-007-v001) require an interactive feedback cycle
that would be difficult and complex in an automated email
transaction. At present these privacy provisions are supported only
in MyAPNIC.
It is also doubtful that an email-based process will be able to
support the likely future implementation of routing security using
RFC3779 and related mechanisms.
Proposal summary
----------------
The APNIC Secretariat will phase out email-based updates to registry data 12
months after adoption of the policy.
Implementation stages:
To ensure that enough time is given to APNIC members to familiarise
themselves with alternative ways of updating registry records, we
propose the following schedule:
- 4 months after adoption: Stop accepting email updates for
domain objects
- 8 months after adoption: Stop accepting email updates for
inetnum, inet6num, and aut-num
objects
- 12 months after adoption: Stop accepting email update for the
remaining object types
At every stage, the Secretariat will actively inform those who are
still using email updates to change to the alternative method.
Situation in other RIRs
-----------------------
LACNIC currently does not accept any updates to registry via email. All
updates are via a web-based interface.
ARIN only accepts modifications to registry data via email.
RIPE-NCC primarily accepts modifications to registry data via email;
however, a web portal 'LIR Portal' has been developed to augment the
management of registry data.
AfriNIC currently accepts modifications to registry data via email. A web
based 'MyAfriNIC' portal is being developed.
Details of this proposal
------------------------
Before deprecating email updates, the APNIC Secretariat will provide an
alternative mechanism that is suitable for automated and secured registry
transactions. It is expected that this mechanism will be based on web
services (XML/REST), delivering atomic transactions via a
certificate-secured HTTPS layer, as presented in the APNIC 21 DNS
operaterions SIG.
During the process of email update deprecation, MyAPNIC functionality will
remain unaffected.
The following steps are proposed to ensure a smooth migration for members
using email updates.
- Deploy evaluation web services technology to allow registry record
update using automated tools
- Target: 2 months after adoption
- Provide a test system with its own URL for users to safely test
their scripts
- Provide example command line Unix tools to aid in members'
automation efforts
- Deprecate domain object email updates
- Target: 4 months after adoption
- Public and members announcement 1 month prior to cut-off date
- Monitor and actively inform users who are still sending updates
via email
- Deprecate inetnum, inet6num, aut-num objects email updates
- Target: 8 months after adoption
- Public and members announcement 1 month prior to cut-off date
- Monitor and actively inform users who are still sending updates
viae-mail
- Deprecate all remaining objects email updates
- Target: 12 months after adoption
- Public and members announcement 1 month prior to cut-off date
- Monitor and actively inform users who are still sending updates
via email
- The APNIC Secretariat will present progress reports at APNIC 23 and
APNIC 24.
Advantages and disadvantages of adopting the proposed policy
------------------------------------------------------------
The web services system will provide immediate feedback on the success or
failure of an update to registry data (within the TCP session).
All updates to APNIC registry will be encrypted in transit, and the identity
of the author verified and authorised by APNIC certificates.
All future data submitted to the APNIC Secretariat will be in an XML
structured syntax. The XML schema will be publicly available for members'
own development use.
The APNIC Secretariat will only support strong encryption and authentication
mechanisms for managing registry data.
Effect on APNIC members
-----------------------
- Members currently using automated email procedures for managing APNIC
data should prepare in advance for the deprecation.
- Members using simple email methods for managing their registry data
should evaluate their process and be prepared to implement new
methods.
Effect on NIRs
--------------
NIRs should consider their data management procedures with APNIC and modify
their manual and automated systems as appropriate.
References
----------
RFC3779: X.509 Extensions for IP Addresses and AS Identifiers
http://www.ietf.org/rfc/rfc3779.txt
DRAFT: A Profile for X.509 PKIX Resource Certificates
draft-ietf-sidr-res-certs-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-sidr-res-certs-01.txt
DRAFT: Profile for Resource Certificate Repository Structure
draft-huston-sidr-repos-struct-00.txt
http://www.ietf.org/internet-drafts/draft-huston-sidr-repos-struct
-00.txt
APNIC Policy: Privacy of customer assignment records
http://www.apnic.net/docs/policy/proposals/prop-007-v001.html
APNIC Presentation: APNIC reverse DNS management roadmap
http://www.apnic.net/meetings/21/docs/sigs/dns/
dns-pres-terry-revdns-roadmap.pdf
