[arin-ppml] Policy Proposal: whois POC e-mail cleanup - Revised

[Member Services]

The author submitted a revised version of their proposal.

The ARIN Advisory Council (AC) will review this proposal at their next
regularly scheduled meeting. The AC may decide to:

      1. Accept the proposal as written. If the AC accepts the proposal,
it will be posted as a formal policy proposal to PPML and it will be
presented at a Public Policy Meeting.

      2. Postpone their decision regarding the proposal until the next
regularly scheduled AC meeting in order to work with the author. The AC
will work with the author to clarify, combine or divide the proposal. At
their following meeting the AC will accept or not accept the proposal.

      3. Not accept the proposal. If the AC does not accept the proposal,
the AC will explain their decision via the PPML. If a proposal is not
accepted, then the author may elect to use the petition process to
advance their proposal. If the author elects not to petition or the
petition fails, then the proposal will be closed.

In the meantime, the AC invites everyone to comment on this proposal on
the PPML, particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html

Mailing list subscription information can be found at:
http://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal Name: whois POC e-mail cleanup

Author: Ted Mittelstaedt

Proposal Version: 2

Submission Date: 9/19/2008

Proposal type: new

Policy term: permanent

Policy statement:

Under Directory Services in the NRPM

add section 3.6 titled "Reliability of Whois information"

3.6.1  ARIN will use an automated system that once a year will attempt
to e-mail all separate e-mail  addresses in the directory. (including
abuse addresses)  At it's discretion, ARIN will attempt to  contact by
regular mail or phone any POC entries that have invalid e-mail addresses
(i.e. e-mail  addresses that bounce mail sent to them) and give them a 3
month deadline for correction of their mail  address.  The automated
system will not use a mail cluster or other mail transmission software
that is incompatible with commonly available anti-spam technologies,
such as greylisting.

ALL POC's that fail to respond to paper mails or telephone calls after
the deadline will have their e-mail address replaced with "FAILED TO
RESPOND, PRIOR ADDRESS: <previous e-mail address>" in the directory.

The automated e-mails will have a text string titled "ARIN Automated POC
e-mail test" identifying them  so that automated trouble ticket systems
can be programmed to automatically delete the mail messages  instead of
replying to them.

3.6.2  ARIN will supply a report to the community, updated monthly, that
lists the percentage of  "FAILED TO RESPOND" POCs, the percentage of
POCs that accept e-mails, and the percentage of POC  addresses that have
a response pending.

Rationale:

As the entire Internet community gets closer to the date that IPv4 will
be exhausted, more attention is being focused on the possibility that
there is significant amounts of allocated IPv4 that is abandoned.  There
are also concerns that as the amount of usable IPv4 space gets more and
more crowded, that Internet criminals are turning to abandoned IPv4
space that is still listed as allocated  in the whois directories to use
to make attacks on hosts on the Internet.  Because of these reasons,  it
is becoming more important that users of ARIN's whois data have a
reasonable expectation that it is  accurate. The current NRPM has a
mechanism for adding, modifying, and deleting POCs. However it also
carries an assumption that POCs belonging to defunct companies will be
removed when the bills for allocated IP addressing cease being paid, and
the address resources are then returned to the ARIN pool  as a result.
The problem is that this assumption does not hold true for so-called
"Legacy" IP address holders since they do not pay a yearly fee.
Furthermore, billing for the IP addressing allocations is done through
paper mail, thus it is possible for a POC to have a valid street
address, but an invalid E-mail address, and not be caught because they
are current on their account.  This is becoming a serious issue because
contacting a POC via a street address is too slow for victims of an
attack from a hijacked IP block to be able to complain to the block
owners and the block owners to be able to catch the perpetrators.

This proposal is a "first step" proposal to attack the problem of
invalid e-mail addresses in the WHOIS database.  It is specifically
intended to be an automated mechanism.  It is understood that IP address
hijackers could hijack a legacy block and setup a mailserver to respond
to a POC address on the block and thus dodge this system. (assuming the
domain name used in the defunct POC e-mail address was available, which
is not likely)  Detecting such a setup is going to require more advanced
mechanisms than are appropriate to be spelled out in a policy manual,
and this proposal in no way precludes such mechanisms from being
employed.  Fundamentally, ARIN cannot guarantee the validity of WHOIS
entries in the directory that belong to legacy holders who have not
signed an LRSA, there's some legal challenges to proving that a legacy
holder who is masquerading as a defunct organization is in fact a hijacker.

This proposal SPECIFICALLY DOES NOT require a POC to make a response.
All that is needed is for the POC e-mail address to be accepting mail.
The difficulties in dealing with the large number of responses back,
plus the fact that it's likely that many responses back will be sent
from e-mail addresses other than what is listed in the POC, would make
requiring ARIN to get a response back to determine legitimacy to greatly
increase the complexity of this proposal and make it likely to be
unworkable.

The report of FAILED TO RESPOND POCS needs to be monthly because there
is NO REQUIREMENT that ARIN contact ALL POCS in the database ON THE SAME
DATE.  It is assumed that ARIN would e-mail only 1/12'th of all POC's in
the database at the beginning of every month to spread out the workload.

There is a mechanism already defined in the NRPM to get a bulk dump of
the whois database, which would of course contain the FAILED TO RESPOND
entries.

Timetable for implementation: Immediate