[arin-ppml] Comments on Draft Policy 2010-3
Joe St Sauver
joe at oregon.uoregon.edu
Wed Mar 17 17:44:07 EDT 2010
I have reviewed https://www.arin.net/policy/proposals/2010_3.html
dated 2 Feb 2010, and I have many serious concerns about the
draft policy in its current form.
Let me go over just a dozen of those concerns now.
1) The overarching purpose of IP whois point of contact information
is and should be to insure that operational problems can be addressed
by those who are most knowledgeable and best situated to address them.
While ISPs have a role in limiting or responding to problematic traffic
flowing through their networks, ultimately it is the down stream customer
who is configuring and operating systems which are sourcing or sinking
traffic, and it is those customers who will need to fix many operational
If customer address and telephone information is redacted from IP
whois reassignment and reallocation data, the community's ability to
contact the administrator of a problematic system is profoundly
impaired, and we are reduced to relying on a third party, the upstream
ISP, to proxy our query or complaint to their downstream customer.
Some ISPs may be willing to play this intermediate role, others may not.
There is nothing in this policy that compells them to take on that
additional work (nor is there any indication of how the costs of
meeting that communication "mandate" might be paid).
Even if ISPs *are* required to forward communications they receive
to their downstream confidential customer, it will likely take time
for them to do so -- maybe just a minute or two, but more likely
hours, or perhaps even days if this process is handled manually.
When dealing with problematic systems, time can be of the essence,
yet this policy as currently written enforces no processing time
"SLA" on ISPs who may have elected to shroud customer data.
2) As written, it is unclear that ARIN would be permitted to
respond to legal process seeking disclosure of shrouded customer
contact information. In particular, while the policy states that
"the customer's actual information must be provided to ARIN on
request" the policy also states that the information "will be
held in the strictest confidence."
The customer information will be held in "strictest confidence"
by *whom?* The ISP? ARIN? The ISP *and* ARIN? As written, the
policy is at best ambiguous, and at worst the proposed language
may create a new duty, requiring ARIN to employ all reasonable
efforts to protect customer data it may receive (including
potentially defending against legal actions seeking compulsory
redisclosure of the customer's data).
3) The draft policy allows *ISPs* the option of shrouding their
customer's data, ("*ISPs* may choose to...", emphasis added),
but what of the customer's preferences when it comes to the
release of their point of contact data? The policy is silent
on this matter.
While *some* customers may want to have their contact information
concealed by their ISP, *other* customers may actually prefer full
disclosure and complete transparency. For example, full disclosure
of contact information may be preferred by some as a matter of
bolstering one's online reputation (thereby avoiding what some term
suspicion about "men in ski masks").
Unfortunately, as written, disclosure or non-disclosure of the
customer's point of contact data is solely a matter for the ISP's
discretion. This ignores the role and importance of customer
preferences when it comes to controlling the release of their
4) Does this proposed policy apply to both PA and PI customer
address space? The policy speaks only of "reassignments and
reallocations" -- is that meant to implicitly limit this to
just PA space?
In the case of PI space that may be announced by multiple ISPs for
multihoming, which ISP has controlling authority when it comes
to determining if customer address and phone number information
should be withheld? If there are multiple upstream ISPs, which
ISP's address and phone number would be shown in lieu of the
customer's information? Either? Both? The customer him/her self?
The policy is silent in the face of this potential complexity,
and potentially clouds control over PI netblocks.
5) Eroding the availability of customer point of contact data
hinders the public's ability to formally or informally audit ISP
IP reallocations and reassignments, even though we are now
approaching a critical period when IPv4 address scarcity may motivate
shenanigans or abuse. This lack of transparency is inconsistent with
the Number Resource Organizations first and most critical goal, which
is to "Protect the unallocated Number Resource pool"
6) Will this proposed policy be consistent with the policies of other
regional registries? If ARIN is more permissive in its reassignment
and reallocation process than other registries, ARIN invites an
influx of abusive customers/cybercriminals, potentially damaging
the value of ARIN-assigned/ARIN-allocated space for all who have or
will receive address space from ARIN.
7) Access to IP whois/rwhois data is critical to working cyber abuse
issues in many circumstances (for example, consider a case where
malware or phishing incident involves URIs with raw IP addresses
rather than domain names). Removing customer point of contact
information from whois/rwhois hinders efforts to resolve incidents
of cyber abuse. Since the rationale for this policy makes it clear
that it is motivated solely by competitive concerns, the importance
of those competitive concerns should be weighed against the damage
this proposed policy would potentially cause to the safety and
stability of the Internet.
8) Customer address and phone number information serves an important
purpose with respect to customer differentiation and disambiguation.
Consider an assignment made to a customer with a common name
(hypothetically "John Smith" or "Jane Doe"). If whois/rwhois data
lacks address and phone number information, how am I to distinguish
John Smith of Akron Ohio from John Smith of Wichita Kansas? Answer,
entities (other than the ISP) couldn't, absent assignment of a
unique global customer identifier.
Confouding those two "John Smiths" could have profound consequences.
For example, what if a block list operator incorrectly attributed
both of those blocks to a single malicious "John Smith"?
In a case where one's abusive, and one's wholly innocent, the misdeeds
of the abusive customer may inadvertently result in unjustified
action against the innocent customer who has the misfortune of
having the same "customer name."
9) For that matter, what constitutes an acceptable customer "name"?
If, hypothetically, a celebrity such as Cher held a netblock, would
"Cher" be enough of a name to meet the requirement of this proposed
policy? Are nicknames sufficient? First initial plus a last name?
Just first and last initials? What of a corporation? Is just the
corporation's name to be listed? The corporation's name plus a
human point of contact there? Are role names acceptable? (I wonder
how many netblocks will end up owned by the customer with the
name of "hostmaster", eh?)
10) Arguing in the alternative, if customer privacy *is* a critical
objective, the draft as written fails to adequately shield the
core of customer identity information, namely the customer's name.
Given the customer's name, it may be possible for data brokers and
other "e-penders" to merge the customer's name with other data
sources to the ultimate detriment of the customer's privacy.
Similarly, continuing to argue in the alternative, if privacy *is*
important, the policy as written still allows the public to identify
and potentially tabulate all reassignments or reallocations assigned
to a given customer. Thus, if a single customer with dozens or
(perhaps even hundreds) of small distributed reassignments or
reallocations is perceived differently than a single customer with
a single monolithic netblock, this policy fails to "protect" that
customer's (rather dubious) address usage.
I also have issues with the proposed policy's process, oversight
11) The draft policy has a proposed implementation timeline that
is abrupt: implementation is to be "immediate." No explanation or
justification is provided for this highly expedited deployment
If this policy were to be passed, more time should be provided to
allow ISPs and customers to prepare to accomodate this policy.
12) If a customer is wronged by this policy, does the customer
have the right to appeal their ISP's actions? If so, to whom?
The policy is silent on this point.
If this policy is passed, will there be any analysis of the uptake
of this policy, or any review of the burden it imposes on ARIN
or other members of the community? No.
Given all of these flaws, I urge that this policy not be adopted
unless/until the preceding issues are considered and satisfactorily
Thank you for considering this feedback on Draft Policy 2010-3.
Joe St Sauver, Ph.D.
Disclaimer: the opinions expressed are my own, and do not necessarily
represent the opinion of any other entity or organization.
More information about the ARIN-PPML