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

From: Steve Gibbard (no email)
Date: Fri Sep 01 2006 - 18:48:29 EDT

  • Next message: Brandon Galbraith: "Re: comast email issues, who else has them?"

    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


  • Next message: Brandon Galbraith: "Re: comast email issues, who else has them?"





    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs



    Powered By FreeBSD   Powered By FreeBSD