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

[Steve Bertrand]

On 2010.04.06 20:11, Jay Hennigan wrote:
> On 4/6/10 4:17 PM, Steve Bertrand wrote:
> 
>> 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?".
> 
> The receptionist is likely to respond with a LAN vendor that may or may
> not be in a position to fix the issue.  It may be trivial to look up the
> POC for the encompassing block but it is another step, another phone
> call or conversation, more delay, etc.

Understood. However, I would rather have to take one extra one-minute
step to validate via a phone call that the person I'm calling is who
they are reported to be before I need to do a one second lookup to find
out who you are and how to contact you.

At least I'll know they are who you say they are, and will know for the
future that they have clueless monkeys on call for 'network
maintenance'. In the long run, I believe a potential extra step is worth it.

> The ISP of a non-technical customer is likely to be more knowledgeable
> regarding his customer's network than the receptionist and probably in a
> better position to work directly with any other local vendors and
> consultants.  Also the ISP is in a position to down an interface or add
> an ACL *right now* in serious cases.
> 
> The end customer isn't going to want to spend money on a consultant to
> fix something that isn't a problem (to them), and hasn't heard of some
> remote network operator calling with a complaint.  

Even if I'm more knowledgeable in an emergency and I have to shut a
client interface, then it is clear that the client is in need of
spending money to fix a problem anyways.

This potentially results in wasted time for you up front, or extra time
for me later when we're questioned about why they are down without any
prior engagement. Someone will always lose something in a situation like
this... I'm just trying to look at it from the perspective of what can
be gained.

> And if the customer's
> phone number is published in WHOIS, they'll likely dismiss any such
> calls as just another  telemarketer.  (Telemarketers are the only ones
> that ever call that number we were forced to publish, that's why we
> never check that voice mail...)

Fair enough. However, that is attempting to evade anyways, so it doesn't
matter. Every company has a published number for business. You, having
them as a client surely know it somehow.

> I think you mean UNscrupulous LIR.

Thanks ;)

> The customer name is not "protected" from what I read in the proposal.
> The phone number and street address are.  If the customer is a
> deliberate abuser, the phone number and contact information of said
> abuser are going to be worthless. 

I don't believe that. Even though I'm afraid of retribution for saying
this, I feel that re-assignment information of a client is the
responsibility of the re-assigning party.

If people want ARIN to validate the POCs of it's re-alloc/assignments,
then we, as peers, should have the ability to randomly call each other
up and say "hey, does this client still `own' this block?".

I'm likely way off-base here, and perhaps I'm completely missing
something, but:

"If the customer is a
deliberate abuser, the phone number and contact information of said
abuser are going to be worthless. "

...then the re-assigning party should be flamed and noted for not doing
its due diligence in the first place.

>  Usually it's a virus/bot/smurf
> amplifier type of issue where the customer is either unaware of the
> problem or just notices that things are slow.

Usually, yes. However, ignorance is in no way allowed as an excuse.

> If the LIR is unscrupulous and deliberately supporting abusers, they
> wouldn't have a problem with entering completely bogus SWIPs anyway.
> This change isn't going to change the behavior of dishonest and
> unscrupulous LIRs.  It is going to result in valid POCs of those in a
> position to fix problems without having to deal with non-technical people.

A rogue LIR is always going to try to circumvent the legal/policy anyways.

For those LIRs who aren't unscrupulous, it allows for finer grain
monitoring, better statistical gathering, easier documentation, better
peer-to-peer communication. iow, I believe that having the client info
in the db (even if your phone number is beside the clients) will serve
the entire community better in the long run.

> Dishonest and abusive people will continue to be dishonest and abusive
> regardless of the rules.

Yup, but they'd be easier to filter out.

>> 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.
> 
> Agreed, but in the majority of cases when they call your client they are
> going to get little in the way of fixing.  They will wind up calling you
> eventually anyway.  Why not have that be the first call they make?

Well, one reason, I'd like my client know that the situation is being
initiated externally. A serious person is calling to investigate a
potentially serious problem.

To further, it allows the caller to identify that they are speaking
directly to the people who are listed in WHOIS. It provides confidence
to them to know that they are headed in the proper direction.

$receptionist at the counter could say via phone at 1400 that "yes, this
is X company". Even if (s)he couldn't identify her ISP or her tech, the
caller would (imho) merrily take that extra step to see who the next
contact in the hierarchy is given the confidence (s)he has gained.

>> 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?
> 
> See above.  And does it matter?  If you're an unscrupulous ISP that
> deliberately harbors abusers, does the rest of the Internet care which
> particular IP maps to which particular abuser today or next week or are
> they likely to just refuse all of your packets?

I'm not the rest of the Internet, but if I know that you have an abuser
that you admit to having intermittent problems with, I'd rather throw a
/28 into my infrastructure than have my users calling because I've had
to blackhole your /16.

...and yes. I do believe that there are some who still care which block
maps to which user. I personally believe that this research is important
for historical purposes.

>>> 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.
> 
> I don't think this proposal will make a difference one way or another to
> criminals and deliberate abusers.  It will result in faster resolution
> of those cases where the actual user of the IP space is non-technical or
> not staffed 24/7 by providing an immediate lookup of a contact more
> likely to have the ability to resolve problems quickly and competently.

Again, I understand why you feel this way, but I'm torn from it.

I think, and I *feel*, that by ensuring proper block-holder information
in each re-assignment, it will be easier to weed out the 'unscrupulous'.

Perhaps client churn is a concerning factor here, but I see more
importance on being able to know who has what, than someone trying to
steal clients.

Also, I don't imagine there are many here who don't utilize the security
community for some services. Providing policy allowances such as this
may hinder them in what they can potentially provide... and at the same
time load more responsibility upon ARIN to collect information when
necessary, slowing the investigative process down exponentially (due to
following any new policy that would have to be created for them to
acquire the info).

Respectfully, and very inquisitive,

Steve