I see it as stopping fraud the same way SPF and DKIM stopped spam.

On 12/17/19 3:38 PM, Dovid Bender wrote:
Mike beat me to it. It's going to stop fraud. The bigger issue you are going to have is the larger packets. So many devices out there can't seem to fragment packets correctly.


On Tue, Dec 17, 2019 at 3:28 PM <m...@astrocompanies.com <mailto:m...@astrocompanies.com>> wrote:

    Hi Peter,

    Good question.  First, if you're using Hooli, you'll have to
    migrate to
    Pipernet sooner or later.  Their middle-out compression provides
    much better
    call quality so it's worth the effort to migrate.

    But to the issue you raised, the purpose of STIR/SHAKEN is not to
    block
    robocalls per se, it is to provide an authentication chain so that
    you can
    determine and contact the originating carrier regardless of the
    route the
    call took to reach the terminating side.  This has been a big
    issue; many
    VoIP companies hand off calls to large indifferent CLEC or IXCs
    who send
    them everywhere but won't respond to the terminating carrier's
    fraud and
    nuisance requests.

    So, now we can see that the call was attested by Hooli, and if
    Hooli does
    not cooperate with our fraud/nuisance investigations we are now
    authorized
    to block traffic signed by Hooli.  That does fix the problem to a
    large
    degree.

    However, it's also worthy of note that this is not the main
    problem that
    needs to be solved.  The main problem that needs to be solved is
    the case
    where you are sending the call to Hooli originating from a number
    that is
    assigned to our CLEC, which you don't have permission to use. This
    does
    solve that problem, because Hooli is only going to issue partial
    attestation
    for that call since it's not their number.  So we can still
    contact Hooli
    about it because they attested it and from that I can find them,
    but we or
    our subscriber can also block calls with partial attestations if
    we/they
    choose to.

    Regards,

    Mike

    Mike Ray, MBA, CNE, CTE
    Astro Companies, LLC
    11523 Palm Brush Trail #401
    Lakewood Ranch, FL  34202
    DIRECT: call or text 941 600-0207
    http://www.astrocompanies.com

    -----Original Message-----
    From: VoiceOps <voiceops-boun...@voiceops.org
    <mailto:voiceops-boun...@voiceops.org>> On Behalf Of Peter Beckman
    Sent: Tuesday, December 17, 2019 2:58 PM
    To: VoiceOps <voiceops@voiceops.org <mailto:voiceops@voiceops.org>>
    Subject: [VoiceOps] STIR/SHAKEN Discussion: Will it help?

    A few months ago I attended an FCC STIR/SHAKEN discussion in
    Washington DC.
    They didn't get deep into the technical details but there were a
    bunch of
    big carrier representatives there.

    If you haven't followed STIR/SHAKEN, it's really just an
    additional SIP
    header that contains cryptographically-signed information about
    the origin
    point of the call.

    You can verify the signature with publically published public keys
    so you
    know whomever signed it is really them.

    Here's a few resources if you want to learn more:

    https://www.bandwidth.com/glossary/stir-shaken/
    https://www.fcc.gov/call-authentication
    https://en.wikipedia.org/wiki/STIR/SHAKEN
    https://www.home.neustar/stir-shaken-resource-hub

    There are three levels to tell you how much you should trust the
    origin of
    the call:

         1. Full -- The call came from the originating carrier's
    customer and is
             authorized to use the number

         2. Partial -- The call came from the originating carrier's
    customer but
             may or may not be authorized to use the number

         3. Gateway -- The carrier has authenticated from where it
    received the
             call, but cannot authenticate the call source (e.g.,
    International
             Gateway call).

    As an example, as will be many legit cases, a Verizon Wireless mobile
    customer will place a call, which will route to Verizon, who will
    sign the
    call using STIR/SHAKEN with Full Attestation and we can all
    "trust" the
    call.

    But now we throw in VoIP.

    I'm a small customer, Initech, of a larger carrier, Hooli. I don't
    sign my
    calls, so I hand my calls to my larger carrier, Hooli. Hooli sees
    the call
    from me (their customer) with a valid CallerID I'm authorized to
    use and so
    Hooli signs the call with STIR/SHAKEN with Full Attestation.

    Turns out the call was a robocall.

    What changes? The only thing that changes is that the receiving
    party, say
    Soylent Corp, knows that Hooli originated the call. Soylent is not
    Hooli's
    customer, so how does Soylent complain to Hooli about the content
    of the
    call?

    And as carriers, we are not legally responsible for the content of our
    customer's calls.

    How will Soylent accept 90% of Hooli's Fully Attested valid
    traffic but
    avoid the 10% that is spam/robocalls that are ALSO Fully Attested?

    How exactly does STIR/SHAKEN help fix the robocall and spam call
    problem?

    Yes, I could block all of Hooli's calls where the attestation is
    Partial or
    Gateway, but you run the risk of false positives, especially in the
    International category, or just when Hooli isn't sure, like when I
    rent a
    DID from Acme but do termination through Hooli -- Hooli doesn't
    know that I
    am authorized to use that DID from Acme, even though I am, so
    Hooli has to
    mark my call as Partial or Gateway.

    I'm all for reducing annoying spam and robocalls, but I'm still
    not yet
    convinced that STIR/SHAKEN is going to materially reduce them.

    Let's discuss!

    Beckman
    ---------------------------------------------------------------------------
    Peter Beckman Internet Guy
    beck...@angryox.com <mailto:beck...@angryox.com>
    http://www.angryox.com/
    ---------------------------------------------------------------------------
    _______________________________________________
    VoiceOps mailing list
    VoiceOps@voiceops.org <mailto:VoiceOps@voiceops.org>
    https://puck.nether.net/mailman/listinfo/voiceops

    _______________________________________________
    VoiceOps mailing list
    VoiceOps@voiceops.org <mailto:VoiceOps@voiceops.org>
    https://puck.nether.net/mailman/listinfo/voiceops


_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops


_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Reply via email to