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

Fri Aug 22 17:50:15 EDT 2008

I strongly support the general purpose of this proposal but just as
strongly feel that the execution should be different on three points:
1) The verification email should require a response.
2) Non-RSA Legacy, LRSA and RSA space holders should be treated in an
identical manner.
3) Once you start marking POCs as invalid or unresponsive, the list of
netblocks without valid POCs should be pushed fully into the light in
order to mitigate potential hijacking attempts.

Beyond that, I think that a fully automated system will have the least
impact on ARIN staff workload and that it makes sense to close the
loop so to speak within one policy for final actions to be taken for
completely non-responsive POCs.

Based on the primary three differences I listed above, and some strong
encouragement to do so, I went ahead and submitted a POC verification
policy of my own.  I want to thank you for the inspiration and I hope
that you can support the new policy based on my rational for those
changes.
~Chris

On Thu, Aug 21, 2008 at 6:44 PM, Internet Partners Hostmaster
<hostmaster at ipinc.net> wrote:
> Chris,
>
>   I deliberately left it vague as to the exact implementation.  It would
> certainly be
> possible to have the automated system put the REFUSED RESPONSE in
> then ARIN check this later, instead of the automated system producing a list
> that
> would have to be looked at before the address was changed to REFUSED
> RESPONSE.
>
> I am concerned about writing that level of detail into the NRPM itself,
> though.  I
> would rather just leave the vague statement that LIR POCs that fail to
> respond
> will have their address changed to REFUSED RESPONSE, and allow ARIN staff to
> determine the exact method of implementation.
>
> As far as futher action to be taken, I had considered this, but I would
> rather see
> future policy proposals that addressed what kind of action.  As it is now we
> really
> don't know if this is a big problem or not - thus the rationale for section
> 3.6.1 for
> a summary report.  If after a year the summary reports indicate that invalid
> POCs
> are in reality a huge problem, then we can start talking penalties.
>
> I was a bit leery about offering a list of address blocks of uncontactable
> POC's to
> the general public (ie: NOT under the existing rationale for section 3.1 for
> bulk
> copies)  It seems to me that doing so would be making it very simple for the
> crackers to find blocks to attempt hijacking.
>
> In view of these explanations do you still have concerns about this
> proposal?
>
> Ted
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Chris Grundemann
> Sent: Thursday, August 21, 2008 11:49 AM
> To: Member Services
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: whois POC e-mail cleanup
>
> Imo;
> A response to the annual POC email should be required for verification that
> the email address is in fact valid.  If there is no response to the email
> after X amount of time, the automated system should replace the POC address
> with "REFUSED RESPONSE" or some such.  The list of POCs with this marking
> should be reviewed by ARIN staff and manual contact attempts could be made
> at their discretion.  A provision for further action to be taken if manual
> contact methods fail should be considered (locking the POC from making other
> changes, deleting the POC, etc).  A list of address blocks without valid
> POCs should be made easily available to the community.
> ~Chris
>
> On Thu, Aug 21, 2008 at 7:55 AM, Member Services <info at arin.net> wrote:
>>
>> ARIN received the following policy proposal. In accordance with the ARIN
>> Internet Resource Policy Evaluation Process, the proposal is being
>> posted to the ARIN Public Policy Mailing List (PPML) and being placed on
>> ARIN's website.
>>
>> 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.
>>
>> The AC will assign shepherds in the near future. ARIN will provide the
>> names of the shepherds to the community via the PPML.
>>
>> 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: 1
>>
>> Submission Date: 8/20/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 all 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.
>>
>> LIR POC's that fail to respond to paper mails or telephone calls will
>> have Their e-mail address replaced with "REFUSED RESPONSE" in the
>> directory. Non-legacy POCs will be requested to remedy the situation by
>> their next billing date.  At it's discretion and considering the size or
>> number of complaints about an organization, ARIN may require the
>> organization to supply accurate contact information in it's directory
>> entry as a condition of accepting payment from the organization for
>> registration renewals.
>>
>> POCs belonging to blocks reassigned by LIRs who fail to respond will be
>> replaced by the POC of the reassigning LIR.
>>
>> 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.
>>
>> Other standard mailing list practices will be followed by ARIN to insure
>> the absence of e-mail loops, etc.
>>
>> 3.6.1  ARIN will supply a report to the community, updated monthly, that
>> lists the percentage of "REFUSED RESPONSE" POCs, the percentage of POCs
>> that accept e-mails, and the percentage of POC addresses that have not
>> responded but have not yet been notified by paper mail or telephone.
>>
>> 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.
>>
>> Timetable for implementation: Immediate
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>
>
>
> --
> Chris Grundemann
> www.linkedin.com/in/cgrundemann
>

-- 
Chris Grundemann
www.linkedin.com/in/cgrundemann