[arin-ppml] Comments on Draft Policy 2010-3: Customer Confidentiality

Steve Bertrand steve at ibctech.ca
Tue Apr 6 19:17:10 EDT 2010

On 2010.04.06 17:27, Jay Hennigan wrote:
> On 4/6/10 12:51 PM, Wes Young wrote:
>> "ISPs may choose to enter the customer's name along with the ISP's
>> address and phone number in reassignments and reallocations in lieu of
>> the customer's address and phone number. The customer's actual
>> information must be provided to ARIN on request and will be held in the
>> strictest confidence."
>> Those "two lines" (at-least to me), represent sort of the "domains by
>> proxy feature".
>> When dealing with security incidents, if the contact information is
>> virtually proxy'd, then thats more time/money spent trying to get a-hold
>> of someone close enough to the problem to do away with it. A single
>> domain can't wipe out half of the internet, a single address (or set of
>> addresses, or /29--) could. When we can't keep track of those closest to
>> the situation (who care about the situation), the threat potential
>> increases.
> I have to respectfully disagree. The vast majority of our customers are
> small to medium sized businesses who have very little operational clue.
>  Law firms, insurance agents, warehouse firms, etc.  The contacts at the
> phone number or physical address of these operations can barely spell
> BGP, let alone describe it.

The vast majority of my customers are exactly the same.

> As their ISP, we are much more likely to able to do away with any
> problems that they may create than their on-premise staff.


> Listing their phone number and address instead of ours results in total
> confusion as their receptionist is likely to want to have someone call
> you back.  

Even if an operator is half-baked, they still should know that it's
trivial to look up the POCs for the encompassing block in the event that
a receptionist responds with "no" when one asks "do you have a computer
technician that looks after your stuff?".

Better yet, I throw it right into the SWIP 'Comments' section, just to
be safe:

Comment:    For other issues, or if the above contacts
Comment:    are non-responsive, contact the ARIN POC registered
Comment:    to the encompassing IP block.

Any person who values WHOIS for operational purposes will be able to
glean the info they need, and will be able to identify whether the
person on the other end of the phone is 'unresponsive' (such as a

What happens if a scrupulous LIR was getting paid for a client that was
abusing my network, but had their personal information hidden? I
couldn't create a baseline or filtering strategy based on IP, because
they could just move them to another block. I can't monitor based on
customer name, because it's 'protected'. Hence, I may be dealing with a
moving target, with absolutely no classification ability to provide my
upstreams with for aid.

Personally, I don't care about the privacy of my clients. They are on
the global Internet, and with that goes your privacy (as far as IP
addressing is concerned). I can't cross the Canada/US border anymore
without identifying exactly who I am and what my address is, and I see
no difference in this. I just like to know that if someone calls my
client or myself, they'd be able to inform me immediately who is
originating an issue so I can fix it.

> Calling a clueful ISP and being able to reach a NOC person with the
> ability to deal with the problem when a customer gets pwn3d at 02:00
> local time on a Sunday morning is going to be much more useful than
> leaving a voice mail for the receptionist at the wholesale carpet
> distributor whose server got hacked.

Fixed in the 'comments' section, or by gleaning the POCs of the parent

>> I understand what you say about the change in allocations, maybe that
>> shouldn't have been listed as a primary reason (more so than the
>> obfuscation of "last mile" contact information). However, the very thing
>> you're trying to protect against (eg: customer lists), is one of the
>> very things security ops handlers are trying to build up and keep
>> current. The public information in an unstructured and federated
>> environment helps us do that. It is only two sentences, and that's
>> dangerous when you're setting a standard for the backbone of the
>> federated environment that is the internet.
> The change is the *ability* to list the ISP's contact number and
> address, not a *requirement* to do so.  For cases where the end user
> customer has a security and technical staff that is willing able to deal
> with these issues when they come up, said staff will probably want to
> have their own contact number listed in WHOIS.  Indeed it should be.
> If anything, I view this proposal as facilitating, not hindering, rapid
> response to security incidents by those with the knowledge and ability
> to deal with them.

How do we know that you are not going to 'fix' the problem by rendering
the client a new block? When they attack next week, and we call you
again, how can we identify whether it is another one of your clients, or
the same one?

> Note that this proposal in my opinion is better for *technical* reasons,
> without regard to any business and privacy concerns driving it.

I completely understand what your stance is on this and why you feel
this way, as seemingly we have a similar type of client base. However,
you, like I, are the ones who *will* properly fix a problem when
required. I'm concerned about the ones who will use this as a loophole
to avoid that.



More information about the ARIN-PPML mailing list