[arin-ppml] Policy Proposal: Customer Confidentiality

[Kevin Stange]

Kevin Kargel wrote:
>> -----Original Message-----
>> From: Kevin Stange [mailto:kevin at steadfast.net]
>> Sent: Tuesday, June 09, 2009 1:31 PM
>> To: Kevin Kargel
>> Cc: arin ppml
>> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
>>
>> Kevin Kargel wrote:
>>> I am in general opposed to this proposal.  There are good and valid
>> reasons
>>> for making direct contacts for a network discoverable.  If a host runs
>> amok
>>> and is causing grave problems then I need to be able to contact the
>> person
>>> responsible for that host.  I do not need to find a contact for someone
>>> three tiers up who will contact someone else who will contact someone
>> who
>>> will contact the host owner.
>>>
>> Many of our customers would be slow to respond or unsure how to handle
>> direct contact, which is one of the reasons I like this proposal.  Even
>> when we direct such queries downstream from time to time, we get back a
>> "what do I do with this?" response and basically end up having to deal
>> with the issue ourselves.  If there's a suitably insane issue going on
>> with a customer's machine, contacting us directly can result in
>> immediate resolution where it might take hours to days contacting the
>> customer directly.  We have the power to shut down VLANs, issue null
>> routes, and sometimes just directly access machines to resolve issues.
>> Chances are that we know a better way to get in touch with the customer
>> faster that may not be something rwhois would generally contain such as
>> an IM screen name or alternate phone number or email account, or that
>> the customer is noted in our system to be away on vacation for 6 weeks
>> and wants us to shut down a box in the event of anything seriously wrong.
>>
>> Having centralized contacts gives us a filter, so we can block out
>> useless contact to our customers and keep track of what kind of strange
>> things our customers are doing with their IPs, intentionally, or
>> inadvertently, so that we can handle abuses and keep in touch with
>> customers to provide guidance.
>>
>> That said, as it stands now, most abuse reporters just contact us
>> directly anyway, even if rwhois specifies to contact someone else, so I
>> don't expect much to change in this regard anyway.
> 
> I would agree that in the best possible world the abuse contact would be
> someone who could do something about the issue.  In the real world this is
> seldom the end user.
> 
> In the case of an ISP they are often the best PoC because they are in a
> position to stop routing of a problem host.  In an enterprise network that
> would be the NOC center for the aggregate router.  In this case it gets more
> confusing because a single network may be distributed amongst several NOC's,
> each of which has their own administration and routing policies.

I think in most cases that is why people ignore the bottom level contact
and continue to contact the assignee of the netblock directly, figuring
that the customer-end contact is going to be useless.  It's not always
true, but I think the risk gets higher, the smaller the re-allocated
netblock goes or the more levels down it goes.

> In any case though, this contact "should" be a monitored live person
> reachable contact who can directly manage the network in question.  At the
> very least the PoC should be one phone call removed from that administrator.

I could accept a proposal that suggests that privacy should be limited
such that if the furthest downstream party wishes to have privacy, the
ISP must replace the contact information with that of an immediate POC
that can handle issues on their behalf promptly.  In that case, you have
to address how you can validate that information, or establish a
complaint and resolution (or penalty) process if it turns out that
information published does not meet that criteria.

> Leaving the PoC as the top level ISP could put contact with an effective
> administrator a number of tiers away, and could engender a situation where
> resolution of an immediate issue is days away.

I suppose this does tend to happen a lot.  When we first started, our
IPs were allocated to us from Savvis to our reseller, to us.  We had our
IPs SWIPed to ensure we were contacted, but there were abuse reports
sent directly to Savvis that could take days to reach us.  That just
seems irresponsible, since forwarding email is relatively trivial.

> Filtering customers from abuse contacts is not a good thing.  If customer
> networks are exposed directly to the internet then the customer needs to
> have capable administrators on staff or under contract and those
> administrators must be reachable.  
> 
> Expecting reasonable responsibility is not unreasonable.  Vehicle drivers on
> public roads are or should be required to have the knowledge, resources and
> skills to operate a vehicle. Network operators on public networks should
> likewise be expected to have the knowledge, resources and skills to operate
> a network.

I trust you do not work with dedicated server hosting much. ;)

Expecting this level of knowledge or an appropriate system administrator
is impossible in our business, even when we explicitly tell customers
about the need for this.  Sometimes, a customer believes he has a
competent administrator on staff which turns out to be only slightly
more literate in server and network management than the customer
himself.  Other times the competent administrator leaves the company or
is laid off, with the customer getting the ensuing mess to deal with,
clueless.  It's routine, and letting us field the abuse reports in this
case is the best way we can make sure such issues actually get explained
to the customer and handled promptly.

-- 
Kevin Stange
Chief Technology Officer
Steadfast Networks
http://steadfast.net
Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090609/a6bd52d9/attachment.sig>