Re: BCP Question: Handling trouble reports from non-customers

[Steve Gibbard <scg () gibbard org>]

On Fri, 1 Sep 2006, Owen DeLong wrote:

> I think my previous post may have touched on a more global issue.
>
> Given the number of such posts I have seen over time, and, my 
> experiences trying to report problems to other ISPs in the past, it 
> seems to me that a high percentage of ISPs, especially the larger ones, 
> simply don't allow for the possibility of a non-customer needing to 
> report a problem with the ability to reach one of their customers.

Anybody trying to put together such a BCP should first give some 
consideration to what sorts of calls from non-customers a service provider 
should be expected to accept.  Based solely on Owen's earlier post, this 
looks to me like a good example of why service providers are sometimes 
reluctant to accept trouble reports from non-customers.

> From DNS and whois, it looks like the IP address Owen sited earlier is an 
individual DSL customer.  The equipment Owen says is dropping packets 
looks like DSL concentration equipment in a local POP.  Owen says he's 
having trouble reaching the address from multiple locations.  If we look 
at this from the service provider's perspective, we see some random person 
calling up to complain that somebody else, whose phone number the caller 
doesn't know, is having trouble with their DSL service.  That's probably 
not a call they get a lot of, and it probably seems pretty strange.  If 
that DSL customer were really having problems getting anywhere, wouldn't 
they call it in themselves?  If there were a problem with the whole POP, 
the random outside person calling in would be more believable, but the 
people in the call center would probably have their hands full dealing 
with actual customers.

There are DSL customers who use their DSL circuits to host actual services 
that others might want to access, or IP phones that somebody might want to 
call.  There are big hosting companies who specialize in making content 
available to lots and lots of end users, who still don't like taking calls 
from non-customers.  In those cases, it's at least obvious why a 
non-customer might call and complain, but there are scaling issues because 
of which somebody might not want to accept such a call.  The cost of 
passing bits through to somebody with thousands or millions of customers 
may be significantly less than the cost of taking phone calls from the 
customers' customers.  Transit providers therefore tend to expect such 
organizations to handle their own customer support, and to call the 
transit provider themselves if there's a problem.  That way the transit 
provider knows who they're dealing with, and only has to explain things 
once.

This isn't to say there aren't valid reasons for network operators to 
contact other network operators they don't have relationships with. 
Packet loss affecting only the providers' customers may not count, but a 
call saying "hi, your customer, who isn't answering their phone, is 
sourcing unauthorized routes to my address space" probably should be taken 
seriously.  Of course, the challenge there is determining that the person 
calling *is* authorized to tell you not to announce the space.  Same for 
customers sourcing attacks, and the like.

Some questions you might want to consider would be:

What sorts of problems should a non-customer legitimately be reporting?

Which non-customers should be reporting such things?  Affected 
individuals?  Other network operators (as defined by who?)?  CERTs?  Law 
enforcement?

What channels should be used for such contacts?  Phone?  E-mail? 
INOC-DBA?  Where should the contact information be published and who 
should have access to it?

How should identity of callers be determined?

Also, note that lots of solutions to many of these problems have already 
been tried at various times with varying degrees of success, and that some 
of them are working fairly well.  You'd probably do better to build on 
existing systems and practices than to start from scratch.

-Steve