<div dir="ltr">My intention really is the integrity of whois data. As an Internet service provider that is part of the larger internet community, we want to know that the records are accurate. We depend on these records, and the actions we take based on them can affect the community. We'd like to avoid helping someone use something they aren't authorized to, but that is made difficult if we can not trust old records. I truly believe a policy like this, is one step toward making it more
difficult to steal netblocks. One step.. I didn't say it was the
absolute, or the end all way the prevent theft, just that it raises the
bar. <br>
<br>I considered proposing the same policy that was adopted in the APNIC region. The APNIC policy goes a step further and locked all "legacy" resource records at once. I intended the text I proposed as a compromise, to ease into the process by requiring L/RSA when you went to update a record. I am beginning to think that was a mistake, and in order for this to work that the policy should lock all legacy records or remove them altogether. <br>
<br>I concede there are larger issues, ultimately ARIN is providing a service to entities with which it has no formal arangement or agreement. You can argue the merits or demerits of the RSA and LRSA, but they are not relevent to the text or intent of this policy. (If you would like to argue the points of the L/RSA, I encourage you to
do so with ARIN staff and legal counsel, as the policy development process has no
mechanism to change either!) The RSA and LRSA are the only mechanisms I know of for having a formal arrangement with ARIN. If there are other arrangements, or the possibility of others in the future, the text can be modified to take that into account:<br>
<br>"To ensure the integrity of information in the ARIN WHOIS Database a resource must be under an RSA (either legacy or traditional) or other [formal/documented legal/contract/agreement] with ARIN, in order to update the WHOIS record."<br>
<br>I went through all of the emails.. I pulled out a few points/questions to address:<br><br>
<p style="margin-left: 0.25in;">> Which is it, the resource
must be under an RSA, or the holder must be<br>
> able to prove their right to the resource? These are not the same<br>
> thing</p><br>The LRSA contains a procedure for evaluating a legacy applicant's
request to sign the LRSA (See Section 3 of the LRSA). <br><br>.<br>
<p style="margin-left: 0.25in;">> I do not think that this is
an effort to make life difficult for legacy holders (including my employer), but
to <br>> prevent the theft of their address space. Heather, can you clarify?
(Seems that Verizon Business was<br>> involved in one to the cases
I mentioned...not as a hijacker, of course.)</p>
It is not my intention to make anyone's life difficult - in fact quite the opposite. I would like to make everyone more at ease and comfortable with the records in the whois database. I cringe when I see route change requests for old netblocks that have not been updated. I would love to see a technical solution implemented- such a solution would still have this underlying problem. I don't know what incident the poster was referring to wrt VZB - but as I previously mentioned, we are concerned about this, we do not want to be an accessory to a hijacking. Two recent and public incidents, (that did not involve VZB in any way) were covered in this article: <a href="http://voices.washingtonpost.com/securityfix/2008/04/a_case_of_network_identity_the_1.html">http://voices.washingtonpost.com/securityfix/2008/04/a_case_of_network_identity_the_1.html</a> <br>
<br>
<p class="MsoNormal">> If you really want to reduce spam, go after those people
and leave the legacy holders alone who AREN'T<br>> spamming but just happen to have not signed an RSA.</p>
Reduction of spam is not my primary goal, I'm not even sure I see the correlation. Most providers can tell which of their customers is routing a netblock and can work their customer support contacts for spam - besides most spam is sourced from legit but compromised hosts these days. <br>
<br>
<p class="MsoNormal">
</p>--Heather<br><br><div class="gmail_quote"><br>On Mon, Aug 18, 2008 at 10:38 AM, Member Services <span dir="ltr"><<a href="mailto:info@arin.net" target="_blank">info@arin.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
ARIN received the following policy proposal. In accordance with the ARIN<br>
Internet Resource Policy Evaluation Process, the proposal is being<br>
posted to the ARIN Public Policy Mailing List (PPML) and being placed on<br>
ARIN's website.<br>
<br>
The ARIN Advisory Council (AC) will review this proposal at their next<br>
regularly scheduled meeting. The AC may decide to:<br>
<br>
1. Accept the proposal as written. If the AC accepts the proposal,<br>
it will be posted as a formal policy proposal to PPML and it will be<br>
presented at a Public Policy Meeting.<br>
<br>
2. Not accept the proposal. If the AC does not accept the proposal,<br>
the AC will explain their decision via the PPML. If a proposal is not<br>
accepted, then the author may elect to use the petition process to<br>
advance their proposal. If the author elects not to petition or the<br>
petition fails, then the proposal will be closed.<br>
<br>
The AC will assign shepherds in the near future. ARIN will provide the<br>
names of the shepherds to the community via the PPML.<br>
<br>
In the meantime, the AC invites everyone to comment on this proposal on<br>
the PPML, particularly their support or non-support and the reasoning<br>
behind their opinion. Such participation contributes to a thorough<br>
vetting and provides important guidance to the AC in their deliberations.<br>
<br>
The ARIN Internet Resource Policy Evaluation Process can be found at:<br>
<a href="http://www.arin.net/policy/irpep.html" target="_blank">http://www.arin.net/policy/irpep.html</a><br>
<br>
Mailing list subscription information can be found at:<br>
<a href="http://www.arin.net/mailing_lists/" target="_blank">http://www.arin.net/mailing_lists/</a><br>
<br>
Regards,<br>
<br>
Member Services<br>
American Registry for Internet Numbers (ARIN)<br>
<br>
<br>
## * ##<br>
<br>
Policy Proposal Name: Whois Integrity Policy Proposal<br>
<br>
Author: Heather Schiller<br>
<br>
Proposal Version: 1<br>
<br>
Submission Date: August 15, 2008<br>
<br>
Policy statement:<br>
<br>
To ensure the integrity of information in the ARIN WHOIS Database a<br>
resource must be under an RSA (either legacy or traditional) in order to<br>
update the WHOIS record. ARIN will not update historical information in<br>
the ARIN Whois Database until the resource holder can prove the<br>
organization's right to the resource.<br>
<br>
<br>
Rationale:<br>
<br>
ARIN currently maintains WHOIS and in-addr.arpa delegation records in a<br>
best-effort fashion. In many cases ARIN does not have a formal<br>
agreement with the legacy resource holders. Legacy records are<br>
frequently out of date and have become an increasingly popular target<br>
for hijackers. Having up to date contact information and a formal<br>
relationship with legacy record holders would assist ARIN and ISP's in<br>
ensuring these records are maintained accurately. A similar policy was<br>
successfully adopted in the APNIC region.<br>
(<a href="http://www.apnic.net/policy/proposals/prop-018-v001.html" target="_blank">http://www.apnic.net/policy/proposals/prop-018-v001.html</a>)<br>
<br>
Timetable for implementation:<br>
<br>
Within sixty (60) days of approval - with notification to current POC<br>
email addresses listed on historical assignments, or as soon as<br>
reasonable for ARIN staff.<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div><br></div>