Mailing List Archive

----- Original Message -----
> From: "Sean Donelan" <sean@donelan.com>

> I don't think SHAKEN/STIR really addresses the root problems with
> spoofing phone numbers, anymore than any of the BGP proposals for spoofing
> IP addresses.
>
> Nevertheless, the FCC wants to be seen as doing something. So Chairman
> Pai is having a summit to show all the progress.
>
> On Thursday, July 11, 2019, FCC Chairman Ajit Pai will convene a summit
> focused on the industry’s implementation of SHAKEN/STIR, a caller ID
> authentication framework to combat illegal robocalls and caller ID
> spoofing. Chairman Pai expects major voice service providers to deploy
> the SHAKEN/STIR framework this year. The summit will showcase the
> progress that major providers have made toward reaching that goal and
> provide an opportunity to identify any challenges to implementation and
> how best to overcome them.

Well, y'know, it's been 10 years since I originated calls to LD carriers.

But when I did, 3 of my carriers (VZN and 2 LDs) trapped outgoing calls
that weren't for 10D calling numbers *they had assigned us* (and hence I
had to work that out with them to prove that *someone* had)...

nd the other 2 didn't give a crap. I could send them anything -- even calls
with CNID that wasn't a valid NANP address (4th digit 1, frex).

Since nearly all of this is being originated over PRIs to LD carriers, right;
maybe if the FCC just threatened the LD carriers who do not do the calling
number legitimacy enforcement the regs (I think) already require them to do...?

Cheers,
-- jra
--
Jay R. Ashworth Baylink jra@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII
St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

Summary:

SHAKEN/STIR does nothing but sign a call by a carrier that can be verified
by another carrier that they signed it. It does nothing to stem Robocalls.

Discussion:

All SHAKEN/STIR does is have the originating carrier of a call to
cryptographically attest, to some degree, that the call originated from
their network.

One example given was that SHAKEN/STIR can verify that it is really the IRS
calling.

But that would require knowledge of which carrier currently serves the IRS,
and that the IRS use that same carrier for both inbound AND outbound
calling, and that the carrier publishes some record that it is the carrier
of record for the given phone number. THIS DOES NOT EXIST in SHAKEN/STIR.

If Carrier A is taking calls from a spammer and implements SHAKEN/STIR, and
their termination Carrier B have also implemented SHAKEN/STIR verification
and trusted Carrier A's certificate, all that occurs is that Carrier A says
"this call is trustworthy" and Carrier B verifies that Carrier A said so
and completes the call.

Carrier A can lie all they want, as they do now, providing a false "Full
Attestation" that the "service provider has authenticated the calling party
and they are authorized to use the calling number." But there's no proof
that they are telling the truth, and no way for any other intermediate
carrier to verify anything other than the originating carrier.

Now if Carrier B decides not to trust Carrier A anymore, they can stop
trusting their cert and drop calls. Which Carrier B can do today by
terminating the relationship with Carrier A.

I still don't see how this will stop CallerID spoofing or Robocalls.
Carrier B can block Carrier A at anytime. Carrier A can attest that any
call originating from it is authorized to use that number. Plus then
there's a ton of intermediates that aren't even addressed here. Do all the
Intermediates also need to implement SHAKEN/STIR such that the SIP Identity
header is passed onto the next leg? If the intermediate drops the header,
does the call fail?

And spammers already use real, leased phone numbers for Robocalls. We
had a client come to us who wanted 5,000 new/different and not recycled
phone numbers across the US each month. When prompted about how they'd be
used, they just needed inbound calls and SMS messages routed to their
switch hosted at a cloud provider, outbound calls would be made through
another carrier.

With SHAKEN/STIR, these calls would show up as "Authenticated" as the
client could tell their Carrier C that these 5,000 phone numbers were
theirs, and Carrier C could do a "Full Attestation" SIP Identity header and
the spam calls would show up as "Verified." But still Robocalls, just
Verified Robocalls.

We declined to do business with this client.

In summary, SHAKEN/STIR seems to do nothing but be some extra technical
work.

Please correct me if I'm missing a key piece of this.

I'm in DC, I'm going to try to attend this summit.

https://transnexus.com/whitepapers/understanding-stir-shaken/

Beckman

On Mon, 8 Jul 2019, Jay R. Ashworth wrote:

> ----- Original Message -----
>> From: "Sean Donelan" <sean@donelan.com>
>
>> I don't think SHAKEN/STIR really addresses the root problems with
>> spoofing phone numbers, anymore than any of the BGP proposals for spoofing
>> IP addresses.
>>
>> Nevertheless, the FCC wants to be seen as doing something. So Chairman
>> Pai is having a summit to show all the progress.
>>
>> On Thursday, July 11, 2019, FCC Chairman Ajit Pai will convene a summit
>> focused on the industry’s implementation of SHAKEN/STIR, a caller ID
>> authentication framework to combat illegal robocalls and caller ID
>> spoofing. Chairman Pai expects major voice service providers to deploy
>> the SHAKEN/STIR framework this year. The summit will showcase the
>> progress that major providers have made toward reaching that goal and
>> provide an opportunity to identify any challenges to implementation and
>> how best to overcome them.
>
> Well, y'know, it's been 10 years since I originated calls to LD carriers.
>
> But when I did, 3 of my carriers (VZN and 2 LDs) trapped outgoing calls
> that weren't for 10D calling numbers *they had assigned us* (and hence I
> had to work that out with them to prove that *someone* had)...
>
> nd the other 2 didn't give a crap. I could send them anything -- even calls
> with CNID that wasn't a valid NANP address (4th digit 1, frex).
>
> Since nearly all of this is being originated over PRIs to LD carriers, right;
> maybe if the FCC just threatened the LD carriers who do not do the calling
> number legitimacy enforcement the regs (I think) already require them to do...?
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth Baylink jra@baylink.com
> Designer The Things I Think RFC 2100
> Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII
> St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
>

---------------------------------------------------------------------------
Peter Beckman Internet Guy
beckman@angryox.com http://www.angryox.com/
---------------------------------------------------------------------------

when we did DKIM back in the day, almost nobody was requiring SMTP auth
which meant the providers could say "blame me" via the DKIM signature,
but couldn't really take much action since they didn't know who has
doing it. we sort of took a leap of faith that that would happen. 
nowadays, almost everybody requires SMTP auth (and tls, ...) afaik. i
have no idea whether DKIM was in any way a motivating factor, but it did
happen in the meantime.

i know the parallels here are not exact (is it really PRI's that are the
source of most of the spam?) , but it's maybe a little premature to
completely write off the providers for doing the Right Thing. putting
the "blame me" badge on might give them some incentive to clean up their
act. as with email spam, there is no silver bullet of course.

fwiw, the stir/shaken problem statement is a good read.

https://datatracker.ietf.org/doc/rfc7340/

Mike

On 7/8/19 2:53 PM, Peter Beckman wrote:
> Summary:
>
> SHAKEN/STIR does nothing but sign a call by a carrier that can be
> verified
> by another carrier that they signed it. It does nothing to stem
> Robocalls.
>
> Discussion:
>
> All SHAKEN/STIR does is have the originating carrier of a call to
> cryptographically attest, to some degree, that the call originated from
> their network.
>
> One example given was that SHAKEN/STIR can verify that it is really
> the IRS
> calling.
>
> But that would require knowledge of which carrier currently serves the
> IRS,
> and that the IRS use that same carrier for both inbound AND outbound
> calling, and that the carrier publishes some record that it is the
> carrier
> of record for the given phone number. THIS DOES NOT EXIST in SHAKEN/STIR.
>
> If Carrier A is taking calls from a spammer and implements
> SHAKEN/STIR, and
> their termination Carrier B have also implemented SHAKEN/STIR
> verification
> and trusted Carrier A's certificate, all that occurs is that Carrier A
> says
> "this call is trustworthy" and Carrier B verifies that Carrier A said so
> and completes the call.
>
> Carrier A can lie all they want, as they do now, providing a false "Full
> Attestation" that the "service provider has authenticated the calling
> party
> and they are authorized to use the calling number." But there's no proof
> that they are telling the truth, and no way for any other intermediate
> carrier to verify anything other than the originating carrier.
>
> Now if Carrier B decides not to trust Carrier A anymore, they can stop
> trusting their cert and drop calls. Which Carrier B can do today by
> terminating the relationship with Carrier A.
>
> I still don't see how this will stop CallerID spoofing or Robocalls.
> Carrier B can block Carrier A at anytime. Carrier A can attest that any
> call originating from it is authorized to use that number. Plus then
> there's a ton of intermediates that aren't even addressed here. Do all
> the
> Intermediates also need to implement SHAKEN/STIR such that the SIP
> Identity
> header is passed onto the next leg? If the intermediate drops the header,
> does the call fail?
>
> And spammers already use real, leased phone numbers for Robocalls. We
> had a client come to us who wanted 5,000 new/different and not recycled
> phone numbers across the US each month. When prompted about how they'd be
> used, they just needed inbound calls and SMS messages routed to their
> switch hosted at a cloud provider, outbound calls would be made through
> another carrier.
>
> With SHAKEN/STIR, these calls would show up as "Authenticated" as the
> client could tell their Carrier C that these 5,000 phone numbers were
> theirs, and Carrier C could do a "Full Attestation" SIP Identity
> header and
> the spam calls would show up as "Verified." But still Robocalls, just
> Verified Robocalls.
>
> We declined to do business with this client.
>
> In summary, SHAKEN/STIR seems to do nothing but be some extra technical
> work.
>
> Please correct me if I'm missing a key piece of this.
>
> I'm in DC, I'm going to try to attend this summit.
>
> https://transnexus.com/whitepapers/understanding-stir-shaken/
>
> Beckman
>
> On Mon, 8 Jul 2019, Jay R. Ashworth wrote:
>
>> ----- Original Message -----
>>> From: "Sean Donelan" <sean@donelan.com>
>>
>>> I don't think SHAKEN/STIR really addresses the root problems with
>>> spoofing phone numbers, anymore than any of the BGP proposals for
>>> spoofing
>>> IP addresses.
>>>
>>> Nevertheless, the FCC wants to be seen as doing something.  So Chairman
>>> Pai is having a summit to show all the progress.
>>>
>>> On Thursday, July 11, 2019, FCC Chairman Ajit Pai will convene a summit
>>> focused on the industry’s implementation of SHAKEN/STIR, a caller ID
>>> authentication framework to combat illegal robocalls and caller ID
>>> spoofing.  Chairman Pai expects major voice service providers to deploy
>>> the SHAKEN/STIR framework this year.   The summit will showcase the
>>> progress that major providers have made toward reaching that goal and
>>> provide an opportunity to identify any challenges to implementation and
>>> how best to overcome them.
>>
>> Well, y'know, it's been 10 years since I originated calls to LD
>> carriers.
>>
>> But when I did, 3 of my carriers (VZN and 2 LDs) trapped outgoing calls
>> that weren't for 10D calling numbers *they had assigned us* (and hence I
>> had to work that out with them to prove that *someone* had)...
>>
>> nd the other 2 didn't give a crap.  I could send them anything --
>> even calls
>> with CNID that wasn't a valid NANP address (4th digit 1, frex).
>>
>> Since nearly all of this is being originated over PRIs to LD
>> carriers, right;
>> maybe if the FCC just threatened the LD carriers who do not do the
>> calling
>> number legitimacy enforcement the regs (I think) already require them
>> to do...?
>>
>> Cheers,
>> -- jra
>> --
>> Jay R. Ashworth                  Baylink jra@baylink.com
>> Designer                     The Things I Think                      
>> RFC 2100
>> Ashworth & Associates       http://www.bcp38.info 2000 Land Rover DII
>> St Petersburg FL USA      BCP38: Ask For It By Name! +1 727 647 1274
>>
>
> ---------------------------------------------------------------------------
>
> Peter Beckman Internet Guy
> beckman@angryox.com http://www.angryox.com/
> ---------------------------------------------------------------------------
>

On Monday, 8 July, 2019 18:08, Michael Thomas <mike@mtcc.com> wrote:

>when we did DKIM back in the day, almost nobody was requiring SMTP
>auth which meant the providers could say "blame me" via the DKIM
>signature, >but couldn't really take much action since they didn't
>know who has doing it.

This is because DKIM was a solution to a problem that did not exist. You always know the identity of the MTA sending you a message, there never was a need for DKIM. It was a solution to a problem that does not and did not nor will ever exist.

>we sort of took a leap of faith that that would happen.
>nowadays, almost everybody requires SMTP auth (and tls, ...) afaik. i
>have no idea whether DKIM was in any way a motivating factor, but it
>did happen in the meantime.

This happened long long long before DKIM was even a wet spot on the sheets.

>i know the parallels here are not exact (is it really PRI's that are
>the source of most of the spam?) , but it's maybe a little premature to
>completely write off the providers for doing the Right Thing. putting
>the "blame me" badge on might give them some incentive to clean up
>their act. as with email spam, there is no silver bullet of course.

The solution is to disallow spoofing. If the "pretty overlay information" does not equal the "billing information" then do not permit the call to be made. Easy Peasy. However, this will interfere with the carriers ability to make money since the ability to make money depends on being in cahoots with the fraudsters. Making it such that the Directors and Officers those carriers in cahoots suffer the death penalty (or life imprisonment) will solve the problem in an afternoon, but it will not happen because the cahooteers' (those Directors and Officers) own the slimy politicians needed to implement the cure.

>fwiw, the stir/shaken problem statement is a good read.

>https://datatracker.ietf.org/doc/rfc7340/

Not a bad work of complete fiction!

Of course, the "root cause" can be found at the very beginning of the thing where it is pointed out that there are reasons for providing false data, and that since "the other guy" allows the presentation of false data, we should too otherwise we will go out of business. Once this "root cause" is accepted, then the inevitable ensues ...

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.

On 7/8/19 5:54 PM, Keith Medcalf wrote:
> On Monday, 8 July, 2019 18:08, Michael Thomas <mike@mtcc.com> wrote:
>
>> when we did DKIM back in the day, almost nobody was requiring SMTP
>> auth which meant the providers could say "blame me" via the DKIM
>> signature, >but couldn't really take much action since they didn't
>> know who has doing it.
> This is because DKIM was a solution to a problem that did not exist. You always know the identity of the MTA sending you a message, there never was a need for DKIM. It was a solution to a problem that does not and did not nor will ever exist.
>
>
::eyeroll:: pray tell, how do you "always" know the identity of the MTA
sending you a message?


Mike

Wow!

You must not know much about networking or programming if you do not know how to ask the OS to tell you the address/port associated with the "other end" of a TCP connection. Obviously you know who is sending the message since they are in bidirectional communication with you at the time you are receiving the message, and you need to know where to send the "carry on James" prompts to get them to send more data...

Therefore you always know who submitted a message.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.


>-----Original Message-----
>From: Michael Thomas [mailto:mike@fresheez.com] On Behalf Of Michael
>Thomas
>Sent: Monday, 8 July, 2019 18:58
>To: Keith Medcalf; nanog@nanog.org
>Subject: Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC
>
>
>On 7/8/19 5:54 PM, Keith Medcalf wrote:
>> On Monday, 8 July, 2019 18:08, Michael Thomas <mike@mtcc.com>
>wrote:
>>
>>> when we did DKIM back in the day, almost nobody was requiring SMTP
>>> auth which meant the providers could say "blame me" via the DKIM
>>> signature, >but couldn't really take much action since they didn't
>>> know who has doing it.
>> This is because DKIM was a solution to a problem that did not
>exist. You always know the identity of the MTA sending you a
>message, there never was a need for DKIM. It was a solution to a
>problem that does not and did not nor will ever exist.
>>
>>
>::eyeroll:: pray tell, how do you "always" know the identity of the
>MTA
>sending you a message?
>
>
>Mike

On Mon, 08 Jul 2019 17:58:17 -0700, Michael Thomas said:
> On 7/8/19 5:54 PM, Keith Medcalf wrote:

> > This is because DKIM was a solution to a problem that did not exist.
> >
> >
> ::eyeroll:: pray tell, how do you "always" know the identity of the MTA
> sending you a message?

It's more subtle than that - you always know the "identity" of the purported
MTA, because you know their IP address. Whether "purported" is the same as
"legitimate" or "authorized" is a whole different kettle of fish....

Remember - port 25 is widely blocked precisely because there were always a
plenty supply of MTAs whose identity you knew, sending you spam from consumer
living rooms....

Jon Callas, Eric Allman, the IETF security geek contingent and even me
disagree with you. rfc 4871 disagrees with you. STD 76 disagrees with
you. Trillions of signed messages disagree with you. Steve Bellovin
probably disagrees with you too since you seem to be under the illusion
that a reverse DNS lookup tells you anything useful.

::eyeroll::

Mike

On 7/8/19 6:06 PM, Keith Medcalf wrote:
> Wow!
>
> You must not know much about networking or programming if you do not know how to ask the OS to tell you the address/port associated with the "other end" of a TCP connection. Obviously you know who is sending the message since they are in bidirectional communication with you at the time you are receiving the message, and you need to know where to send the "carry on James" prompts to get them to send more data...
>
> Therefore you always know who submitted a message.
>

On 7/8/19 6:11 PM, Valdis Kl?tnieks wrote:
> On Mon, 08 Jul 2019 17:58:17 -0700, Michael Thomas said:
>> On 7/8/19 5:54 PM, Keith Medcalf wrote:
>>> This is because DKIM was a solution to a problem that did not exist.
>>>
>>>
>> ::eyeroll:: pray tell, how do you "always" know the identity of the MTA
>> sending you a message?
> It's more subtle than that - you always know the "identity" of the purported
> MTA, because you know their IP address. Whether "purported" is the same as
> "legitimate" or "authorized" is a whole different kettle of fish....
>
> Remember - port 25 is widely blocked precisely because there were always a
> plenty supply of MTAs whose identity you knew, sending you spam from consumer
> living rooms....
>

Like I said, what DKIM brought is the ability to "blame me". knowing the
IP address doesn't give you that in any useful way. Recall that trust is
mainly a social construct, not a technical one. Bruce Schneier has
written about that endlessly.

Mike

You are the only person who has mentioned reverse DNS lookups.

However, it is true that you do in fact need to already know the identity of the sending MTA/MSA before you can do a "reverse DNS lookup". What does this have to do with the price of tea in China?

And what value do you think a reverse DNS lookup adds to the identity information you already (obviously) have?

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.


>-----Original Message-----
>From: Michael Thomas [mailto:mike@fresheez.com] On Behalf Of Michael
>Thomas
>Sent: Monday, 8 July, 2019 19:12
>To: Keith Medcalf; nanog@nanog.org
>Subject: Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC
>
>Jon Callas, Eric Allman, the IETF security geek contingent and even
>me
>disagree with you. rfc 4871 disagrees with you. STD 76 disagrees with
>you. Trillions of signed messages disagree with you. Steve Bellovin
>probably disagrees with you too since you seem to be under the
>illusion
>that a reverse DNS lookup tells you anything useful.
>
>::eyeroll::
>
>Mike
>
>On 7/8/19 6:06 PM, Keith Medcalf wrote:
>> Wow!
>>
>> You must not know much about networking or programming if you do
>not know how to ask the OS to tell you the address/port associated
>with the "other end" of a TCP connection. Obviously you know who is
>sending the message since they are in bidirectional communication
>with you at the time you are receiving the message, and you need to
>know where to send the "carry on James" prompts to get them to send
>more data...
>>
>> Therefore you always know who submitted a message.
>>

On 7/8/19 6:24 PM, Keith Medcalf wrote:
> You are the only person who has mentioned reverse DNS lookups.
>
I'm only trying to guess what enlightens your misinformed world.

Mike

DKIM brought nothing of any value since it cannot be used to refuse messages or abort before entering the DATA phase of the SMTP conversation. You are, no matter what, committing resources to receiving the message and accepting responsibility for its delivery. All you can do is fart about AFTER THE FACT, after it is already too late to reject the message.

Presently 99.999999% of the SPAM that gets through to me is DKIM signed, yet it is still spam. In fact, that DKIM signature provides absolutely nothing of value whatsoever, except to validate that the SPAM was unmolested between the sending MTA and me (which is unlikely anyway, and even more unlikely since the transport is almost always over a TLS channel which prevents tampering between the sending MTA and my MTA anyway).

Like I said, DKIM does nothing of value and is directed to solve a problem that does not, never has, and never will, exist in the real world.

Contrast this with SPF which does do something of value. It enables the dropping of the session BEFORE the DATA phase if the envelope-from domain is not on the list of authorized MTA to be sending messages for that domain. The only real problem with it is the allowance of prevarication in the data.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.


>-----Original Message-----
>From: Michael Thomas [mailto:mike@fresheez.com] On Behalf Of Michael
>Thomas
>Sent: Monday, 8 July, 2019 19:24
>To: Valdis Kl?tnieks
>Cc: Keith Medcalf; nanog@nanog.org
>Subject: Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC
>
>
>On 7/8/19 6:11 PM, Valdis Kl?tnieks wrote:
>> On Mon, 08 Jul 2019 17:58:17 -0700, Michael Thomas said:
>>> On 7/8/19 5:54 PM, Keith Medcalf wrote:
>>>> This is because DKIM was a solution to a problem that did not
>exist.
>>>>
>>>>
>>> ::eyeroll:: pray tell, how do you "always" know the identity of
>the MTA
>>> sending you a message?
>> It's more subtle than that - you always know the "identity" of the
>purported
>> MTA, because you know their IP address. Whether "purported" is the
>same as
>> "legitimate" or "authorized" is a whole different kettle of
>fish....
>>
>> Remember - port 25 is widely blocked precisely because there were
>always a
>> plenty supply of MTAs whose identity you knew, sending you spam
>from consumer
>> living rooms....
>>
>
>Like I said, what DKIM brought is the ability to "blame me". knowing
>the
>IP address doesn't give you that in any useful way. Recall that trust
>is
>mainly a social construct, not a technical one. Bruce Schneier has
>written about that endlessly.
>
>Mike

On Monday, 8 July, 2019 19:28, Michael Thomas <mike@mtcc.com> wrote:

>On 7/8/19 6:24 PM, Keith Medcalf wrote:

>> You are the only person who has mentioned reverse DNS lookups.

>I'm only trying to guess what enlightens your misinformed world.

You claimed that the "root problem" was not knowing who the originator was.

I claimed that you ALWAYS must know who the originator is -- they are at the other end of the connection.

You want to do a "reverse DNS lookup" for some reason.

I still do not understand how doing a "reverse DNS lookup" will help with the identity at the other end of the connection, since you already have to know that identity in order to perform a reverse DNS lookup...

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.

when do we get back to stir/shaken?

On Mon, Jul 8, 2019 at 9:47 PM Keith Medcalf <kmedcalf@dessus.com> wrote:
>
>
> On Monday, 8 July, 2019 19:28, Michael Thomas <mike@mtcc.com> wrote:
>
> >On 7/8/19 6:24 PM, Keith Medcalf wrote:
>
> >> You are the only person who has mentioned reverse DNS lookups.
>
> >I'm only trying to guess what enlightens your misinformed world.
>
> You claimed that the "root problem" was not knowing who the originator was.
>
> I claimed that you ALWAYS must know who the originator is -- they are at the other end of the connection.
>
> You want to do a "reverse DNS lookup" for some reason.
>
> I still do not understand how doing a "reverse DNS lookup" will help with the identity at the other end of the connection, since you already have to know that identity in order to perform a reverse DNS lookup...
>
> --
> The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
>
>
>
>

On 7/8/19 6:46 PM, Keith Medcalf wrote:
> On Monday, 8 July, 2019 19:28, Michael Thomas <mike@mtcc.com> wrote:
>
>> On 7/8/19 6:24 PM, Keith Medcalf wrote:
>>> You are the only person who has mentioned reverse DNS lookups.
>> I'm only trying to guess what enlightens your misinformed world.
> You claimed that the "root problem" was not knowing who the originator was.
>

I have claimed no such thing.

Mike

On 7/8/19 7:11 PM, Christopher Morrow wrote:
> when do we get back to stir/shaken?

that would be nice. i have a lot of questions about stir/shaken.
attacking a problem statement rfc seems rather bizarre and unhinged to
me. it outlines a lot of the objections i had to p-asserted-identity i
had way back when.

Mike

back on track to stir/shaken

would a service provider also need to implement this? or its for the big
carriers to do ?

On Mon, Jul 8, 2019 at 11:17 PM Michael Thomas <mike@mtcc.com> wrote:

>
> On 7/8/19 7:11 PM, Christopher Morrow wrote:
> > when do we get back to stir/shaken?
>
> that would be nice. i have a lot of questions about stir/shaken.
> attacking a problem statement rfc seems rather bizarre and unhinged to
> me. it outlines a lot of the objections i had to p-asserted-identity i
> had way back when.
>
> Mike
>
>

--

Izzy Goldstein

Chief Technology Officer

Main: (212) 477-1000 x 2085 <(212)%20477-1000>

Direct: (929) 477-2085

Website: www.telego.com <http://www.telego.net/>


<http://www.telego.com/>


Confidentiality Notice: This e-mail may contain confidential and/or
privileged information. If you are not the intended recipient or have
received this e-mail in error please notify us immediately by email reply
and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden. Any
views or opinions presented in this email are solely those of the author
and do not necessarily represent those of TeleGo (T). Employees of TeleGo
are expressly required not to make defamatory statements and not to
infringe or authorize any infringement of copyright or any other legal
right by email communications. Any such communication is contrary to TeleGo
policy and outside the scope of the employment of the individual concerned.
TeleGo will not accept any liability in respect of such communication, and
the employee responsible will be personally liable for any damages or other
liability arising.


TeleGo Hosted PBX <https://youtu.be/DaT8YAZ4V0w>

The agenda for the SHAKEN/STIR robocall summit was published today.

Date: Thursday, July 11, 2019
Time: 9:30 a.m. to 3:30 p.m.
Location: Commission Meeting Room at FCC Headquarters

It will also be live-streamed on the FCC web site.

https://www.fcc.gov/document/chairman-pai-announces-agenda-shakenstir-robocall-summit



The agenda looks like lots of happy, happy talk from industry
representatives.

Unfortunately, like other third-party problems, its not about the
technology. Its really about changing the incentives for all the actors
involved. But the first and second-party players don't want the incentives
to be changed for them.

On Mon, Jul 08, 2019 at 06:54:51PM -0600, Keith Medcalf wrote:
> This is because DKIM was a solution to a problem that did not exist.

This is correct. We have always known the IP address of the connecting
MTA, therefore we have always known the network it resides in, therefore
we have always known who is responsible for what transits that connection.

Worse, this (poorly) attempts to wallpaper over the problems of
compromised systems/accounts. Do recall that not long ago we learned that
EVERY Yahoo account was compromised. Anyone who thinks that Microsoft
or Google or Comcast or anyone else are doing any better is naive:
it's not a question of whether they've also suffered mass compromises,
only a question of how many and when they'll publicly admit it.

This isn't surprising. The real underlying problems here are tough and
expensive, thus it's far easire to do (nearly) meaningless feel-good work,
declare the problems solved, and engage in a round of self-congratulation.
It *appears*, and that's a preliminary assessment on my part, that
SHAKEN/STIR is following this same track.

---rsk

On Mon, 8 Jul 2019, Keith Medcalf wrote:

> The solution is to disallow spoofing. If the "pretty overlay
> information" does not equal the "billing information" then do not permit
> the call to be made. Easy Peasy.

This assumes that all calls from a phone number originate from the carrier
of record for that phone number.

This assumption is false.

For calls made by Verizon Wireless customers that originate FROM Verizon
Wireless's network, STIR/SHAKEN will enable Verizon to tag the call with a
crypto sig that we can all verify came from Verizon, thus increasing the
trust that the call originated from Verizon Wireless.

However, Verizon not-Wireless also does other telephony business, such as
termination. Verizon not-Wireless customers can and likely do terminate
calls to them with CallerID of phone numbers that may or may not be
registered with Level3, Onvoy, Bandwidth or another carrier. However
Verizon not-Wireless has NO IDEA if their customer truly owns/leases the
value in the CallerID field from another carrier. Thus Verizon not-Wireless
may sign the terminating call using STIR/SHAKEN but have *NO IDEA* if their
termination customer actually owns/leases/controls the CallerID value.

And the absence of a STIR/SHAKEN header also means nothing. While we do LRN
lookups for calls, we do not currently use that information to ensure that
the originating party owns/leases that number legitimately.

As a Tier 2 or 3 carrier, our carrier does not publish anywhere that we
lease numbers from them, and our customers are not required to terminate
calls using their phone numbers as CallerID with other carriers.

The presence of STIR/SHAKEN increases the trust in the CallerID value ONLY
when the phone number owner of record in the LNP database matches the
signor of the call.

The absence of STIR/SHAKEN is where we are already today. And small
carriers can implement STIR/SHAKEN without concern for whether or not the
CallerID value is their phone number or not.

Though if the bad-actor does sign the call, I can distrust or block all of
the bad-actor's calls. At least until they stop signing the calls, or they
start a new contract with a new cert leaving all of us to play whack-a-mole
some more, as we do now.

DKIM-signed and SPF approved for all the good it will do,

Beckman
---------------------------------------------------------------------------
Peter Beckman Internet Guy
beckman@angryox.com http://www.angryox.com/
---------------------------------------------------------------------------

On Tue, 9 Jul 2019, Sean Donelan wrote:
> The agenda looks like lots of happy, happy talk from industry
> representatives.

In advance of the SHAKEN/STIR robocall summit, AT&T has issued a press
release announcing plans to automatically block robocalls for its
customers.

https://about.att.com/story/2019/att_call_protect.html

Automatic Blocking of Fraud Calls Coming to Millions of AT&T Customers
AT&T* will add automatic fraud blocking and suspected spam-call alerts to
millions of AT&T consumer lines at no charge.

On Wed, Jul 10, 2019 at 11:56 PM Sean Donelan <sean@donelan.com> wrote:
>
> On Tue, 9 Jul 2019, Sean Donelan wrote:
> > The agenda looks like lots of happy, happy talk from industry
> > representatives.
>
> In advance of the SHAKEN/STIR robocall summit, AT&T has issued a press
> release announcing plans to automatically block robocalls for its
> customers.
>
> https://about.att.com/story/2019/att_call_protect.html
>
> Automatic Blocking of Fraud Calls Coming to Millions of AT&T Customers
> AT&T* will add automatic fraud blocking and suspected spam-call alerts to
> millions of AT&T consumer lines at no charge.

oh goodie!

So, not being a bell shaped headed person... a question:
The calling path and data available inside the phone network smells
(to me) like:
ingress trunk + ANI + CallerID + outgoing trunk of destination ds0/handset

There seem like a bunch of pretty simple 'correlations' one could
make, that actually look a heck of a lot like 'netflow/log analysis
for ddos detection':
o is this trunk sourcing calls to 'too many' of my subs in period-of-time-X
o is this trunk sourcing calls from a low distribution of ANI but
a different distribution of CallerID
o is this trunk sourcing calls from unmatched (as a percent of
total) ANI/CallerID

I would think you could make similar correlations across the
destinations on your phone-network:
o Is there one ANI or CallerID talking to 'all' (a bunch, more
than X of type Y customer end point) of my endpoints?
o are there implausible callerid being used? (lots of 'NPA-NXX
matches destination, yet from a very different geography?)

I imagine that with the number of calls here, this is just a splunk
correlation away from successful identification and then disabling of
these nuisance calls...
I imagine this doesn't need 'shaken' nor 'stir', but DOES take: "a
whiff of a care" on the part of the carrier(s), right?
Maybe they don't actually care about this problem until they are
'forced' to care about it by their regulating body?
'shaken' and 'stir' may not do anything at all useful for the problem,
but they do make it appear that the carriers care about the problem...
I'm certain that they know there are problems. The 5 items above can't
be 'new and novel' concepts ... since this is basically 'logs
analysis' that any security engineer worth their salt does as a matter
of course daily, right?

-chris

Their lawyers probably explained to them that they can "block" the call "after" accepting it and thus can get the best of both world -- the revenue from terminating the call while still preventing it from bothering their customers ...

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.


>-----Original Message-----
>From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Christopher
>Morrow
>Sent: Wednesday, 10 July, 2019 22:10
>To: Sean Donelan
>Cc: nanog list
>Subject: Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC
>
>On Wed, Jul 10, 2019 at 11:56 PM Sean Donelan <sean@donelan.com>
>wrote:
>>
>> On Tue, 9 Jul 2019, Sean Donelan wrote:
>> > The agenda looks like lots of happy, happy talk from industry
>> > representatives.
>>
>> In advance of the SHAKEN/STIR robocall summit, AT&T has issued a
>press
>> release announcing plans to automatically block robocalls for its
>> customers.
>>
>> https://about.att.com/story/2019/att_call_protect.html
>>
>> Automatic Blocking of Fraud Calls Coming to Millions of AT&T
>Customers
>> AT&T* will add automatic fraud blocking and suspected spam-call
>alerts to
>> millions of AT&T consumer lines at no charge.
>
>oh goodie!
>
>So, not being a bell shaped headed person... a question:
> The calling path and data available inside the phone network smells
>(to me) like:
> ingress trunk + ANI + CallerID + outgoing trunk of destination
>ds0/handset
>
>There seem like a bunch of pretty simple 'correlations' one could
>make, that actually look a heck of a lot like 'netflow/log analysis
>for ddos detection':
> o is this trunk sourcing calls to 'too many' of my subs in
>period-of-time-X
> o is this trunk sourcing calls from a low distribution of ANI but
>a different distribution of CallerID
> o is this trunk sourcing calls from unmatched (as a percent of
>total) ANI/CallerID
>
>I would think you could make similar correlations across the
>destinations on your phone-network:
> o Is there one ANI or CallerID talking to 'all' (a bunch, more
>than X of type Y customer end point) of my endpoints?
> o are there implausible callerid being used? (lots of 'NPA-NXX
>matches destination, yet from a very different geography?)
>
>I imagine that with the number of calls here, this is just a splunk
>correlation away from successful identification and then disabling of
>these nuisance calls...
>I imagine this doesn't need 'shaken' nor 'stir', but DOES take: "a
>whiff of a care" on the part of the carrier(s), right?
>Maybe they don't actually care about this problem until they are
>'forced' to care about it by their regulating body?
>'shaken' and 'stir' may not do anything at all useful for the
>problem,
>but they do make it appear that the carriers care about the
>problem...
>I'm certain that they know there are problems. The 5 items above
>can't
>be 'new and novel' concepts ... since this is basically 'logs
>analysis' that any security engineer worth their salt does as a
>matter
>of course daily, right?
>
>-chris

Chris it would be trivial for this to be fixed, nearly overnight, by
creating some liability on the part of carriers for illicit use of
caller ID data on behalf of their customers.

But the carriers don't want that, so now we have to create tons of
technical half solutions to solve a problem that would be neatly solved
by carriers.


On 7/11/19 12:09 AM, Christopher Morrow wrote:
> There seem like a bunch of pretty simple 'correlations' one could
> make, that actually look a heck of a lot like 'netflow/log analysis
> for ddos detection':
> o is this trunk sourcing calls to 'too many' of my subs in period-of-time-X
> o is this trunk sourcing calls from a low distribution of ANI but
> a different distribution of CallerID
> o is this trunk sourcing calls from unmatched (as a percent of
> total) ANI/CallerID
>
> I would think you could make similar correlations across the
> destinations on your phone-network:
> o Is there one ANI or CallerID talking to 'all' (a bunch, more
> than X of type Y customer end point) of my endpoints?
> o are there implausible callerid being used? (lots of 'NPA-NXX
> matches destination, yet from a very different geography?)

On Thu, 2019-07-11 at 11:59 -0400, Paul Timmins wrote:
> Chris it would be trivial for this to be fixed, nearly overnight, by
> creating some liability on the part of carriers for illicit use of
> caller ID data on behalf of their customers.

This 1000%. Once legal liability is in place, the carriers themselves
will come up with the most effective and efficient solutions to solve
the problem.

> But the carriers don't want that,

And the legislators are in the pockets of Corporate America so nothing
will happen.

b.

On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins <paul@telcodata.us> wrote:
>
> Chris it would be trivial for this to be fixed, nearly overnight, by
> creating some liability on the part of carriers for illicit use of
> caller ID data on behalf of their customers.

'illicit use of caller id' - how is caller-id being illicitly used though?
I don't think it's against the law to say a different 'callerid' in the call
session, practically every actual call center does this, right?

> But the carriers don't want that, so now we have to create tons of
> technical half solutions to solve a problem that would be neatly solved
> by carriers.

logs analysis and 'netflow' (CDR trolling, really) would be nearly free for
them, implementing actions based on the data / outcomes of that
analysis at near-real-time would also be nearly free...

but sure, we can do a bunch of this other stuff too... My sort of solution
has actually got proven track record though?

-chris

> On 7/11/19 12:09 AM, Christopher Morrow wrote:
> > There seem like a bunch of pretty simple 'correlations' one could
> > make, that actually look a heck of a lot like 'netflow/log analysis
> > for ddos detection':
> > o is this trunk sourcing calls to 'too many' of my subs in period-of-time-X
> > o is this trunk sourcing calls from a low distribution of ANI but
> > a different distribution of CallerID
> > o is this trunk sourcing calls from unmatched (as a percent of
> > total) ANI/CallerID
> >
> > I would think you could make similar correlations across the
> > destinations on your phone-network:
> > o Is there one ANI or CallerID talking to 'all' (a bunch, more
> > than X of type Y customer end point) of my endpoints?
> > o are there implausible callerid being used? (lots of 'NPA-NXX
> > matches destination, yet from a very different geography?)

On Thursday, 11 July, 2019 11:18, Christopher Morrow <morrowc.lists@gmail.com> wrote:

>On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins <paul@telcodata.us> wrote:

>> Chris it would be trivial for this to be fixed, nearly overnight,
>> by creating some liability on the part of carriers for illicit use of
>> caller ID data on behalf of their customers.

>'illicit use of caller id' - how is caller-id being illicitly used
>though?
>I don't think it's against the law to say a different 'callerid' in
>the call session, practically every actual call center does this, right?

The problem is that CallerID is not really the CallerID. It is some fraudulent shit created by the caller. This is not how "CallerID" was originally sold. It was sold as being the ID of the Caller. If it is not the ID of the Caller then Fraud is being committed and the bastards should be castrated (or worse), and the CEO and Directors of the carrier responsible for fraud getting through to the end-user should face the same penalty.

See then how quickly this gets fixed. You will fall off your chair and it will be a "solved problem" before your arse hits the ground!

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.

So I have a meta-question about all of this. Why in 2019 are we still
using telephone numbers as the primary identifier? It's a pretty sip-py
world these days, even on mobile phones with wifi calling, I assume. It
seems like this problem would be more tractable if callerid was a last
resort rather than a first resort.

Mike


On 7/11/19 10:18 AM, Christopher Morrow wrote:
> On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins <paul@telcodata.us> wrote:
>> Chris it would be trivial for this to be fixed, nearly overnight, by
>> creating some liability on the part of carriers for illicit use of
>> caller ID data on behalf of their customers.
> 'illicit use of caller id' - how is caller-id being illicitly used though?
> I don't think it's against the law to say a different 'callerid' in the call
> session, practically every actual call center does this, right?
>
>> But the carriers don't want that, so now we have to create tons of
>> technical half solutions to solve a problem that would be neatly solved
>> by carriers.
> logs analysis and 'netflow' (CDR trolling, really) would be nearly free for
> them, implementing actions based on the data / outcomes of that
> analysis at near-real-time would also be nearly free...
>
> but sure, we can do a bunch of this other stuff too... My sort of solution
> has actually got proven track record though?
>
> -chris
>
>> On 7/11/19 12:09 AM, Christopher Morrow wrote:
>>> There seem like a bunch of pretty simple 'correlations' one could
>>> make, that actually look a heck of a lot like 'netflow/log analysis
>>> for ddos detection':
>>> o is this trunk sourcing calls to 'too many' of my subs in period-of-time-X
>>> o is this trunk sourcing calls from a low distribution of ANI but
>>> a different distribution of CallerID
>>> o is this trunk sourcing calls from unmatched (as a percent of
>>> total) ANI/CallerID
>>>
>>> I would think you could make similar correlations across the
>>> destinations on your phone-network:
>>> o Is there one ANI or CallerID talking to 'all' (a bunch, more
>>> than X of type Y customer end point) of my endpoints?
>>> o are there implausible callerid being used? (lots of 'NPA-NXX
>>> matches destination, yet from a very different geography?)

What if you use different carriers for termination and origination? How
does your termination carrier validate that your origination carrier has
allocated certain numbers to you and that you're therefore allowed to make
outbound calls with a caller ID set to those numbers? That doesn't sound to
me like something that can be solved as quickly and easily as you imply.

On Thu, Jul 11, 2019, 2:33 PM Keith Medcalf <kmedcalf@dessus.com> wrote:

>
> On Thursday, 11 July, 2019 11:18, Christopher Morrow <
> morrowc.lists@gmail.com> wrote:
>
> >On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins <paul@telcodata.us> wrote:
>
> >> Chris it would be trivial for this to be fixed, nearly overnight,
> >> by creating some liability on the part of carriers for illicit use of
> >> caller ID data on behalf of their customers.
>
> >'illicit use of caller id' - how is caller-id being illicitly used
> >though?
> >I don't think it's against the law to say a different 'callerid' in
> >the call session, practically every actual call center does this, right?
>
> The problem is that CallerID is not really the CallerID. It is some
> fraudulent shit created by the caller. This is not how "CallerID" was
> originally sold. It was sold as being the ID of the Caller. If it is not
> the ID of the Caller then Fraud is being committed and the bastards should
> be castrated (or worse), and the CEO and Directors of the carrier
> responsible for fraud getting through to the end-user should face the same
> penalty.
>
> See then how quickly this gets fixed. You will fall off your chair and it
> will be a "solved problem" before your arse hits the ground!
>
> --
> The fact that there's a Highway to Hell but only a Stairway to Heaven says
> a lot about anticipated traffic volume.
>
>
>
>
>

On Thursday, 11 July, 2019 12:38, Ross Tajvar <ross@tajvar.io> wrote:

>What if you use different carriers for termination and origination?
>How does your termination carrier validate that your origination
>carrier has allocated certain numbers to you and that you're
>therefore allowed to make outbound calls with a caller ID set to
>those numbers? That doesn't sound to me like something that can be
>solved as quickly and easily as you imply.

It does not really matter. What matters is that they bear responsibility for an act in furtherance of a conspiracy to commit fraud.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.


>
>On Thu, Jul 11, 2019, 2:33 PM Keith Medcalf <kmedcalf@dessus.com>
>wrote:
>
>
>
> On Thursday, 11 July, 2019 11:18, Christopher Morrow
><morrowc.lists@gmail.com> wrote:
>
> >On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins
><paul@telcodata.us> wrote:
>
> >> Chris it would be trivial for this to be fixed, nearly
>overnight,
> >> by creating some liability on the part of carriers for
>illicit use of
> >> caller ID data on behalf of their customers.
>
> >'illicit use of caller id' - how is caller-id being illicitly
>used
> >though?
> >I don't think it's against the law to say a different
>'callerid' in
> >the call session, practically every actual call center does
>this, right?
>
> The problem is that CallerID is not really the CallerID. It is
>some fraudulent shit created by the caller. This is not how
>"CallerID" was originally sold. It was sold as being the ID of the
>Caller. If it is not the ID of the Caller then Fraud is being
>committed and the bastards should be castrated (or worse), and the
>CEO and Directors of the carrier responsible for fraud getting
>through to the end-user should face the same penalty.
>
> See then how quickly this gets fixed. You will fall off your
>chair and it will be a "solved problem" before your arse hits the
>ground!
>
> --
> The fact that there's a Highway to Hell but only a Stairway to
>Heaven says a lot about anticipated traffic volume.
>
>
>
>
>

Well yeah, people need to take responsibility, but IMO we as engineers need
to discuss the specific circumstances and methodologies that enable that to
happen. It's easy to say "they should fix it", and you're not wrong that
they should, but how? Do you have a validation framework in mind which
carriers can implement that prevents fraudulent caller ID information from
being sent without preventing legitimate use cases?

On Thu, Jul 11, 2019, 2:46 PM Keith Medcalf <kmedcalf@dessus.com> wrote:

>
> On Thursday, 11 July, 2019 12:38, Ross Tajvar <ross@tajvar.io> wrote:
>
> >What if you use different carriers for termination and origination?
> >How does your termination carrier validate that your origination
> >carrier has allocated certain numbers to you and that you're
> >therefore allowed to make outbound calls with a caller ID set to
> >those numbers? That doesn't sound to me like something that can be
> >solved as quickly and easily as you imply.
>
> It does not really matter. What matters is that they bear responsibility
> for an act in furtherance of a conspiracy to commit fraud.
>
> --
> The fact that there's a Highway to Hell but only a Stairway to Heaven says
> a lot about anticipated traffic volume.
>
>
> >
> >On Thu, Jul 11, 2019, 2:33 PM Keith Medcalf <kmedcalf@dessus.com>
> >wrote:
> >
> >
> >
> > On Thursday, 11 July, 2019 11:18, Christopher Morrow
> ><morrowc.lists@gmail.com> wrote:
> >
> > >On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins
> ><paul@telcodata.us> wrote:
> >
> > >> Chris it would be trivial for this to be fixed, nearly
> >overnight,
> > >> by creating some liability on the part of carriers for
> >illicit use of
> > >> caller ID data on behalf of their customers.
> >
> > >'illicit use of caller id' - how is caller-id being illicitly
> >used
> > >though?
> > >I don't think it's against the law to say a different
> >'callerid' in
> > >the call session, practically every actual call center does
> >this, right?
> >
> > The problem is that CallerID is not really the CallerID. It is
> >some fraudulent shit created by the caller. This is not how
> >"CallerID" was originally sold. It was sold as being the ID of the
> >Caller. If it is not the ID of the Caller then Fraud is being
> >committed and the bastards should be castrated (or worse), and the
> >CEO and Directors of the carrier responsible for fraud getting
> >through to the end-user should face the same penalty.
> >
> > See then how quickly this gets fixed. You will fall off your
> >chair and it will be a "solved problem" before your arse hits the
> >ground!
> >
> > --
> > The fact that there's a Highway to Hell but only a Stairway to
> >Heaven says a lot about anticipated traffic volume.
> >
> >
> >
> >
> >
>
>
>
>
>

On Thu, 11 Jul 2019, Ross Tajvar wrote:

> What if you use different carriers for termination and origination? How
> does your termination carrier validate that your origination carrier has
> allocated certain numbers to you and that you're therefore allowed to make
> outbound calls with a caller ID set to those numbers? That doesn't sound to
> me like something that can be solved as quickly and easily as you imply.

I attended the first panel at the FCC and Scott Mullen, CTO at Bandwidth,
was the only one that brought up issues that are not addressed by
implementing STIR/SHAKEN.

1. There's no delegation -- there is no standardized means of telling
anyone who is the End User of a specific TN.

2. Self-signed certs are being used so far, which means that you need
to establish trust in a full mesh in order for STIR/SHAKEN to be of any
value. Not feasible, definitely fragile. This could be addressed
using a Public Cert Authority.

3. Relies 100% in your trust of the initial carrier to properly set the
Attestation level on the call.

4. Does not cover if the call is received with a STIR/SHAKEN header to
a termination provider with Full Attestation that turns out to be a
lie.

5. Does not actually verify that the CallerID is really the EU
generating the call. For Wireless Carriers it can, since calls are
both received and placed by the same carrier in most cases, but what
about roaming? Is Three UK going to implement STIR/SHAKEN or will it
occur at Verizon's edge? How do any of us know that the Identity:
header was added at the first point of origin?

All STIR/SHAKEN is doing is adding an Identity: header to the SIP payload
that one can use to verify that a carrier signed the call at some point.
Some carriers may be trustworthy, some may blindly add Full Attestation
for a termination customer that has a nice mix legit and spoofed calls.

There is still no connection between the End User of a phone number and
the call itself. And there's no way for me as a carrier to check to see if
a phone number should only originate from specific networks or not. Even
if it is signed, I know nothing more than I do now about the legitimacy of
the call.

Argh.

Beckman
---------------------------------------------------------------------------
Peter Beckman Internet Guy
beckman@angryox.com http://www.angryox.com/
---------------------------------------------------------------------------

Pretty simply - Sending caller ID to commit fraud. It's literally
already illegal. The legislature has already defined it for us, even.

47 USC 227

https://www.law.cornell.edu/uscode/text/47/227

(B)
to initiate any telephone call to any residential telephone line using
an artificial or prerecorded voice to deliver a message without the
prior express consent of the called party, unless the call is initiated
for emergency purposes, is made solely pursuant to the collection of a
debt owed to or guaranteed by the United States
<https://www.law.cornell.edu/uscode/text/47/227>, or is exempted by rule
or order by theCommission
<https://www.law.cornell.edu/uscode/text/47/227>under paragraph (2)(B);

(e)(1)In general

It shall be unlawful for any person
<https://www.law.cornell.edu/uscode/text/47/227> within the United
States <https://www.law.cornell.edu/uscode/text/47/227>, in connection
with any telecommunications service
<https://www.law.cornell.edu/uscode/text/47/227> orIP-enabled voice
service, <https://www.law.cornell.edu/uscode/text/47/227> to cause
anycaller identification service
<https://www.law.cornell.edu/uscode/text/47/227>to knowingly transmit
misleading or inaccuratecaller identification information
<https://www.law.cornell.edu/uscode/text/47/227>with the intent to
defraud, cause harm, or wrongfully obtain anything of value, unless such
transmission is exempted pursuant to paragraph (3)(B).

All I'm asking is to make the carrier liable if it should have been
obvious to a carrier using basic traffic analysis that the service was a
robocaller (low answer rates combined with tons of source numbers,
especially situations where the source and destination number share the
first 6 digits) that the carrier be liable for failing to look into it.

Carriers already look at things like short duration in order to assess
higher charges, and already investigate call center traffic. If they
then look at the caller ID and it looks "suspect", and the customer then
is contacted and barred from sending arbitrary caller ID until they can
verify they own the numbers they're calling from, then they're good to go.

If the carrier continues to just ensure that call center traffic is a
revenue stream they can bill higher without making sure they're
outpulsing valid numbers, then they should absorb the social costs of
what's going on.

Let's not get this confused - this isn't about customer PBXen outpulsing
forwarded calls when they do it, it's about people shooting millions of
calls a month, the carrier hitting them with short duration charges,
making more money, and having zero incentive to question the arrangement.

-Paul

On 7/11/19 1:18 PM, Christopher Morrow wrote:
> 'illicit use of caller id' - how is caller-id being illicitly used though?
> I don't think it's against the law to say a different 'callerid' in the call
> session, practically every actual call center does this, right?

Not my job.

However, if you hire me I am sure that I can come up with a solution.

Since retirement my rates have dropped to $1,000/hour with a 4 hour minimum. Payable in advance since you probably have no established credit with me.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.


>-----Original Message-----
>From: Ross Tajvar [mailto:ross@tajvar.io]
>Sent: Thursday, 11 July, 2019 12:54
>To: Keith Medcalf
>Cc: Christopher Morrow; North American Network Operators' Group
>Subject: Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC
>
>Well yeah, people need to take responsibility, but IMO we as
>engineers need to discuss the specific circumstances and
>methodologies that enable that to happen. It's easy to say "they
>should fix it", and you're not wrong that they should, but how? Do
>you have a validation framework in mind which carriers can implement
>that prevents fraudulent caller ID information from being sent
>without preventing legitimate use cases?
>
>On Thu, Jul 11, 2019, 2:46 PM Keith Medcalf <kmedcalf@dessus.com>
>wrote:
>
>
>
> On Thursday, 11 July, 2019 12:38, Ross Tajvar <ross@tajvar.io>
>wrote:
>
> >What if you use different carriers for termination and
>origination?
> >How does your termination carrier validate that your
>origination
> >carrier has allocated certain numbers to you and that you're
> >therefore allowed to make outbound calls with a caller ID set
>to
> >those numbers? That doesn't sound to me like something that can
>be
> >solved as quickly and easily as you imply.
>
> It does not really matter. What matters is that they bear
>responsibility for an act in furtherance of a conspiracy to commit
>fraud.
>
> --
> The fact that there's a Highway to Hell but only a Stairway to
>Heaven says a lot about anticipated traffic volume.
>
>
> >
> >On Thu, Jul 11, 2019, 2:33 PM Keith Medcalf
><kmedcalf@dessus.com>
> >wrote:
> >
> >
> >
> > On Thursday, 11 July, 2019 11:18, Christopher Morrow
> ><morrowc.lists@gmail.com> wrote:
> >
> > >On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins
> ><paul@telcodata.us> wrote:
> >
> > >> Chris it would be trivial for this to be fixed,
>nearly
> >overnight,
> > >> by creating some liability on the part of carriers
>for
> >illicit use of
> > >> caller ID data on behalf of their customers.
> >
> > >'illicit use of caller id' - how is caller-id being
>illicitly
> >used
> > >though?
> > >I don't think it's against the law to say a different
> >'callerid' in
> > >the call session, practically every actual call center
>does
> >this, right?
> >
> > The problem is that CallerID is not really the CallerID.
>It is
> >some fraudulent shit created by the caller. This is not how
> >"CallerID" was originally sold. It was sold as being the ID of
>the
> >Caller. If it is not the ID of the Caller then Fraud is being
> >committed and the bastards should be castrated (or worse), and
>the
> >CEO and Directors of the carrier responsible for fraud getting
> >through to the end-user should face the same penalty.
> >
> > See then how quickly this gets fixed. You will fall off
>your
> >chair and it will be a "solved problem" before your arse hits
>the
> >ground!
> >
> > --
> > The fact that there's a Highway to Hell but only a
>Stairway to
> >Heaven says a lot about anticipated traffic volume.
> >
> >
> >
> >
> >
>
>
>
>
>

On Thu, Jul 11, 2019 at 2:31 PM Keith Medcalf <kmedcalf@dessus.com> wrote:
>
>
> On Thursday, 11 July, 2019 11:18, Christopher Morrow <morrowc.lists@gmail.com> wrote:
>
> >On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins <paul@telcodata.us> wrote:
>
> >> Chris it would be trivial for this to be fixed, nearly overnight,
> >> by creating some liability on the part of carriers for illicit use of
> >> caller ID data on behalf of their customers.
>
> >'illicit use of caller id' - how is caller-id being illicitly used
> >though?
> >I don't think it's against the law to say a different 'callerid' in
> >the call session, practically every actual call center does this, right?
>
> The problem is that CallerID is not really the CallerID. It is some fraudulent shit created by the caller. This is not how "CallerID" was originally sold. It was sold as being the ID of the Caller. If it is not the ID of the Caller then Fraud is being committed and the bastards should be castrated (or worse), and the CEO and Directors of the carrier responsible for fraud getting through to the end-user should face the same penalty.
>

This is why I said ANI in one of my messages, yes.
you CAN, however, in the network see the callerid, and ANI and tell
what's going on...
(credit where due: a kind caller noted to me:
https://www.law.cornell.edu/uscode/text/18/1028
which may make the use of 'someone elses' callerid by 'me' illegal)

-chris

>
> See then how quickly this gets fixed. You will fall off your chair and it will be a "solved problem" before your arse hits the ground!
>
> --
> The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
>
>
>
>

On Thu, 11 Jul 2019, Keith Medcalf wrote:

> On Thursday, 11 July, 2019 12:38, Ross Tajvar <ross@tajvar.io> wrote:
>
>> What if you use different carriers for termination and origination?
>> How does your termination carrier validate that your origination
>> carrier has allocated certain numbers to you and that you're
>> therefore allowed to make outbound calls with a caller ID set to
>> those numbers? That doesn't sound to me like something that can be
>> solved as quickly and easily as you imply.
>
> It does not really matter. What matters is that they bear responsibility
> for an act in furtherance of a conspiracy to commit fraud.

Fraud means you'll need to know the content of the call to determine if
the spoofing of the CallerID value meets the bar of breaking the law.

Truth in CallerID Act is only violated if there is intent to defraud when
the CallerID is spoofed. If you spoof CallerID and do not know the content
of the call, you cannot know if the Act was violated.

And we don't want to get into the business of monitoring the content of
phone calls. That opens legal floodgates.

If someone complains, at least you have some recourse. But you have that
today. And by the time someone complains and you trace the call back to a
source in the US (if you can, a woman from AT&T said a "traceback" now
takes days instead of months, still too slow to take any real action), you
find out it originated outside the US and you have a dead end.

Traceroute for Calls would be nice... each hop adds its own header, kind
of like the "Received:" header that exists multiple times in an email.

Beckman
---------------------------------------------------------------------------
Peter Beckman Internet Guy
beckman@angryox.com http://www.angryox.com/
---------------------------------------------------------------------------

On Thu, Jul 11, 2019 at 2:35 PM Michael Thomas <mike@mtcc.com> wrote:
>
> So I have a meta-question about all of this. Why in 2019 are we still
> using telephone numbers as the primary identifier? It's a pretty sip-py
> world these days, even on mobile phones with wifi calling, I assume. It
> seems like this problem would be more tractable if callerid was a last
> resort rather than a first resort.

yes! I bet that if you provided some form of 'identity' to the caller
and permitted the callee to verify that data upon call setup... you'd
get further along.
there could even be an ecosystem of services which callees could
subscribe to in order to report reputation and have that be used to
influence call completions over time...

if only there were such systems in existence already... if only some
form of proof of concept existed?

> Mike
>
>
> On 7/11/19 10:18 AM, Christopher Morrow wrote:
> > On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins <paul@telcodata.us> wrote:
> >> Chris it would be trivial for this to be fixed, nearly overnight, by
> >> creating some liability on the part of carriers for illicit use of
> >> caller ID data on behalf of their customers.
> > 'illicit use of caller id' - how is caller-id being illicitly used though?
> > I don't think it's against the law to say a different 'callerid' in the call
> > session, practically every actual call center does this, right?
> >
> >> But the carriers don't want that, so now we have to create tons of
> >> technical half solutions to solve a problem that would be neatly solved
> >> by carriers.
> > logs analysis and 'netflow' (CDR trolling, really) would be nearly free for
> > them, implementing actions based on the data / outcomes of that
> > analysis at near-real-time would also be nearly free...
> >
> > but sure, we can do a bunch of this other stuff too... My sort of solution
> > has actually got proven track record though?
> >
> > -chris
> >
> >> On 7/11/19 12:09 AM, Christopher Morrow wrote:
> >>> There seem like a bunch of pretty simple 'correlations' one could
> >>> make, that actually look a heck of a lot like 'netflow/log analysis
> >>> for ddos detection':
> >>> o is this trunk sourcing calls to 'too many' of my subs in period-of-time-X
> >>> o is this trunk sourcing calls from a low distribution of ANI but
> >>> a different distribution of CallerID
> >>> o is this trunk sourcing calls from unmatched (as a percent of
> >>> total) ANI/CallerID
> >>>
> >>> I would think you could make similar correlations across the
> >>> destinations on your phone-network:
> >>> o Is there one ANI or CallerID talking to 'all' (a bunch, more
> >>> than X of type Y customer end point) of my endpoints?
> >>> o are there implausible callerid being used? (lots of 'NPA-NXX
> >>> matches destination, yet from a very different geography?)

"with the intent to defraud, cause harm, or wrongfully obtain anything of
value"

Kind of a huge hole that, unless you record all calls which opens other
liability, is hard to prove.

Beckman

On Thu, 11 Jul 2019, Paul Timmins wrote:

> Pretty simply - Sending caller ID to commit fraud. It's literally already
> illegal. The legislature has already defined it for us, even.
>
> 47 USC 227
>
> https://www.law.cornell.edu/uscode/text/47/227
>
> (B)
> to initiate any telephone call to any residential telephone line using an
> artificial or prerecorded voice to deliver a message without the prior
> express consent of the called party, unless the call is initiated for
> emergency purposes, is made solely pursuant to the collection of a debt owed
> to or guaranteed by the United States
> <https://www.law.cornell.edu/uscode/text/47/227>, or is exempted by rule or
> order by theCommission <https://www.law.cornell.edu/uscode/text/47/227>under
> paragraph (2)(B);
>
> (e)(1)In general
>
> It shall be unlawful for any person
> <https://www.law.cornell.edu/uscode/text/47/227> within the United States
> <https://www.law.cornell.edu/uscode/text/47/227>, in connection with any
> telecommunications service <https://www.law.cornell.edu/uscode/text/47/227>
> orIP-enabled voice service, <https://www.law.cornell.edu/uscode/text/47/227>
> to cause anycaller identification service
> <https://www.law.cornell.edu/uscode/text/47/227>to knowingly transmit
> misleading or inaccuratecaller identification information
> <https://www.law.cornell.edu/uscode/text/47/227>with the intent to defraud,
> cause harm, or wrongfully obtain anything of value, unless such transmission
> is exempted pursuant to paragraph (3)(B).
>
> All I'm asking is to make the carrier liable if it should have been obvious
> to a carrier using basic traffic analysis that the service was a robocaller
> (low answer rates combined with tons of source numbers, especially situations
> where the source and destination number share the first 6 digits) that the
> carrier be liable for failing to look into it.
>
> Carriers already look at things like short duration in order to assess higher
> charges, and already investigate call center traffic. If they then look at
> the caller ID and it looks "suspect", and the customer then is contacted and
> barred from sending arbitrary caller ID until they can verify they own the
> numbers they're calling from, then they're good to go.
>
> If the carrier continues to just ensure that call center traffic is a revenue
> stream they can bill higher without making sure they're outpulsing valid
> numbers, then they should absorb the social costs of what's going on.
>
> Let's not get this confused - this isn't about customer PBXen outpulsing
> forwarded calls when they do it, it's about people shooting millions of calls
> a month, the carrier hitting them with short duration charges, making more
> money, and having zero incentive to question the arrangement.
>
> -Paul
>
> On 7/11/19 1:18 PM, Christopher Morrow wrote:
>> 'illicit use of caller id' - how is caller-id being illicitly used though?
>> I don't think it's against the law to say a different 'callerid' in the
>> call
>> session, practically every actual call center does this, right?
>

---------------------------------------------------------------------------
Peter Beckman Internet Guy
beckman@angryox.com http://www.angryox.com/
---------------------------------------------------------------------------

On Thu, Jul 11, 2019 at 3:04 PM Peter Beckman <beckman@angryox.com> wrote:
>
> "with the intent to defraud, cause harm, or wrongfully obtain anything of
> value"
>
> Kind of a huge hole that, unless you record all calls which opens other
> liability, is hard to prove.
>

I'm not sure that the cited code works for this case, agreed.
I'm also not a lawyer :)
I'm a chemical engineer.

> Beckman
>
> On Thu, 11 Jul 2019, Paul Timmins wrote:
>
> > Pretty simply - Sending caller ID to commit fraud. It's literally already
> > illegal. The legislature has already defined it for us, even.
> >
> > 47 USC 227
> >
> > https://www.law.cornell.edu/uscode/text/47/227
> >
> > (B)
> > to initiate any telephone call to any residential telephone line using an
> > artificial or prerecorded voice to deliver a message without the prior
> > express consent of the called party, unless the call is initiated for
> > emergency purposes, is made solely pursuant to the collection of a debt owed
> > to or guaranteed by the United States
> > <https://www.law.cornell.edu/uscode/text/47/227>, or is exempted by rule or
> > order by theCommission <https://www.law.cornell.edu/uscode/text/47/227>under
> > paragraph (2)(B);
> >
> > (e)(1)In general
> >
> > It shall be unlawful for any person
> > <https://www.law.cornell.edu/uscode/text/47/227> within the United States
> > <https://www.law.cornell.edu/uscode/text/47/227>, in connection with any
> > telecommunications service <https://www.law.cornell.edu/uscode/text/47/227>
> > orIP-enabled voice service, <https://www.law.cornell.edu/uscode/text/47/227>
> > to cause anycaller identification service
> > <https://www.law.cornell.edu/uscode/text/47/227>to knowingly transmit
> > misleading or inaccuratecaller identification information
> > <https://www.law.cornell.edu/uscode/text/47/227>with the intent to defraud,
> > cause harm, or wrongfully obtain anything of value, unless such transmission
> > is exempted pursuant to paragraph (3)(B).
> >
> > All I'm asking is to make the carrier liable if it should have been obvious
> > to a carrier using basic traffic analysis that the service was a robocaller
> > (low answer rates combined with tons of source numbers, especially situations
> > where the source and destination number share the first 6 digits) that the
> > carrier be liable for failing to look into it.
> >
> > Carriers already look at things like short duration in order to assess higher
> > charges, and already investigate call center traffic. If they then look at
> > the caller ID and it looks "suspect", and the customer then is contacted and
> > barred from sending arbitrary caller ID until they can verify they own the
> > numbers they're calling from, then they're good to go.
> >
> > If the carrier continues to just ensure that call center traffic is a revenue
> > stream they can bill higher without making sure they're outpulsing valid
> > numbers, then they should absorb the social costs of what's going on.
> >
> > Let's not get this confused - this isn't about customer PBXen outpulsing
> > forwarded calls when they do it, it's about people shooting millions of calls
> > a month, the carrier hitting them with short duration charges, making more
> > money, and having zero incentive to question the arrangement.
> >
> > -Paul
> >
> > On 7/11/19 1:18 PM, Christopher Morrow wrote:
> >> 'illicit use of caller id' - how is caller-id being illicitly used though?
> >> I don't think it's against the law to say a different 'callerid' in the
> >> call
> >> session, practically every actual call center does this, right?
> >
>
> ---------------------------------------------------------------------------
> Peter Beckman Internet Guy
> beckman@angryox.com http://www.angryox.com/
> ---------------------------------------------------------------------------

On 7/11/19 12:03 PM, Christopher Morrow wrote:
> On Thu, Jul 11, 2019 at 2:35 PM Michael Thomas <mike@mtcc.com> wrote:
>> So I have a meta-question about all of this. Why in 2019 are we still
>> using telephone numbers as the primary identifier? It's a pretty sip-py
>> world these days, even on mobile phones with wifi calling, I assume. It
>> seems like this problem would be more tractable if callerid was a last
>> resort rather than a first resort.
> yes! I bet that if you provided some form of 'identity' to the caller
> and permitted the callee to verify that data upon call setup... you'd
> get further along.
> there could even be an ecosystem of services which callees could
> subscribe to in order to report reputation and have that be used to
> influence call completions over time...
>
> if only there were such systems in existence already... if only some
> form of proof of concept existed?
>
>>
15 years ago when I was working on DKIM, I added DKIM signatures to SIP
messages for shits and giggles. It really wouldn't be that hard to
extend DKIM for SIP. Same goes for SPF. Same goes, I assume, for DMARC.
We pretty much know how to identify email providers, and the providers
can pretty well identify individual accounts. Same goes for SIP, it
seems to me.

I assume interprovider these days is all IP for the most part. I would
think that the only remaining vestiges of the PSTN is the last mile
where landlines are going extinct, and most mobile minutes are done over
wifi/IP.

Mike

On 7/11/19 12:05 PM, Christopher Morrow wrote:
> On Thu, Jul 11, 2019 at 3:04 PM Peter Beckman <beckman@angryox.com> wrote:
>> "with the intent to defraud, cause harm, or wrongfully obtain anything of
>> value"
>>
>> Kind of a huge hole that, unless you record all calls which opens other
>> liability, is hard to prove.
>>
> I'm not sure that the cited code works for this case, agreed.
> I'm also not a lawyer :)
> I'm a chemical engineer.


I used to think that email spam was a law enforcement problem too, but
it's become very clear that law enforcement has little to no interest in
solving geeks' problems.

Mike

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.


On Thursday, 11 July, 2019 13:03, Peter Beckman <beckman@angryox.com> wrote:


>On Thu, 11 Jul 2019, Keith Medcalf wrote:

>> On Thursday, 11 July, 2019 12:38, Ross Tajvar <ross@tajvar.io>
>wrote:
>>
>>> What if you use different carriers for termination and
>origination?
>>> How does your termination carrier validate that your origination
>>> carrier has allocated certain numbers to you and that you're
>>> therefore allowed to make outbound calls with a caller ID set to
>>> those numbers? That doesn't sound to me like something that can be
>>> solved as quickly and easily as you imply.
>>
>> It does not really matter. What matters is that they bear
>responsibility
>> for an act in furtherance of a conspiracy to commit fraud.
>
> Fraud means you'll need to know the content of the call to
>determine if
> the spoofing of the CallerID value meets the bar of breaking the
>law.
>
> Truth in CallerID Act is only violated if there is intent to
>defraud when
> the CallerID is spoofed. If you spoof CallerID and do not know the
>content
> of the call, you cannot know if the Act was violated.

The "content" of the call is irrelevant.

If one received identification information (the CallerID) and then passes that information on (a deliberate act) with the intent that it be acted upon as if valid (is the CallerID), and that information later turns out to be fraudulent (it does not in fact identify the caller) then the "passer on" has acted in furtherance of the conspiracy to defraud. Neither negligence nor recklessness is a defense against the conspiracy. The only essential elements that need to be proved are that (a) the callerid information was fraudulent (b) the passer-on intended that the information be taken as non-fraudulent. The fact that the passer-on also "made money from" its specific act in furtherance of the conspiracy is further proof of active participation and benefit from participation in the conspiracy.

The second rule in relation to intent also applies:

If one deliberately engages on a course of action in which a given result is possible outcome, and that result ensues, implies the intent to cause the result so obtained, notwithstanding that the course of action was intended to obtain a different result.

If "CallerID" were in fact sold as "whatever information caller chooses to convey" rather than as the Identification of the caller, then there would be no problem in "passing on" that information. However holding out that "CallerID" is in fact the ID of the Caller, and making money by holding out that to be the case, means that the passer-on of the fraudulent information is liable for the falsity of that information notwithstanding that he cannot verify it.

So in fact the whole thing is and was from the get-go a designed with the intent to convey information under fraudulent pretenses and for fraudulent purposes.

Not really. For reasons already cited by Keith Medcalf in an offshoot of
the thread, and because the real world implication of that liability
transfer would be telecom carriers undertaking risk management and
looking at their products and pricing and deciding whether certain
customers should be allowed to send arbitrary caller ID. What would
likely happen is that small customers would be allowed to send whatever,
like today. Call center customers (they are already identifying these
because most big carriers have different rates for callcenter activity
because of the network load it puts on them) would likely be restricted
to a subset of numbers, and the biggest, long term call centers would
probably be allowed to send whatever they want, but with a contract that
compels them to indemnify the carrier against loss (which would only
work if the call center was well capitalized enough to make that
commitment, because the carrier would NOT want to be stuck with the bill
if they couldn't pay up).

It may sound burdensome, but speaking as an employee of a carrier who is
in a position to see how things work on the business AND technical side
(who I do not speak for, in this context) - we're already looking at
what our customer's intended use is, and whether they're asking for a
product they can reasonably afford, we run their business credit and if
they aren't clean enough, we request prepayment for our services, or
similar.

This would just be one more risk we'd take into account.

-Paul

On 7/11/19 3:04 PM, Peter Beckman wrote:
> "with the intent to defraud, cause harm, or wrongfully obtain anything of
> value"
>
> Kind of a huge hole that, unless you record all calls which opens other
> liability, is hard to prove.
>
> Beckman
>
> On Thu, 11 Jul 2019, Paul Timmins wrote:
>
>> Pretty simply - Sending caller ID to commit fraud. It's literally
>> already illegal. The legislature has already defined it for us, even.
>>
>> 47 USC 227
>>
>> https://www.law.cornell.edu/uscode/text/47/227
>>
>> (B)
>> to initiate any telephone call to any residential telephone line
>> using an artificial or prerecorded voice to deliver a message without
>> the prior express consent of the called party, unless the call is
>> initiated for emergency purposes, is made solely pursuant to the
>> collection of a debt owed to or guaranteed by the United States
>> <https://www.law.cornell.edu/uscode/text/47/227>, or is exempted by
>> rule or order by theCommission
>> <https://www.law.cornell.edu/uscode/text/47/227>under paragraph (2)(B);
>>
>> (e)(1)In general
>>
>> It shall be unlawful for any person
>> <https://www.law.cornell.edu/uscode/text/47/227> within the United
>> States <https://www.law.cornell.edu/uscode/text/47/227>, in
>> connection with any telecommunications service
>> <https://www.law.cornell.edu/uscode/text/47/227> orIP-enabled voice
>> service, <https://www.law.cornell.edu/uscode/text/47/227> to cause
>> anycaller identification service
>> <https://www.law.cornell.edu/uscode/text/47/227>to knowingly transmit
>> misleading or inaccuratecaller identification information
>> <https://www.law.cornell.edu/uscode/text/47/227>with the intent to
>> defraud, cause harm, or wrongfully obtain anything of value, unless
>> such transmission is exempted pursuant to paragraph (3)(B).
>>
>> All I'm asking is to make the carrier liable if it should have been
>> obvious to a carrier using basic traffic analysis that the service
>> was a robocaller (low answer rates combined with tons of source
>> numbers, especially situations where the source and destination
>> number share the first 6 digits) that the carrier be liable for
>> failing to look into it.
>>
>> Carriers already look at things like short duration in order to
>> assess higher charges, and already investigate call center traffic.
>> If they then look at the caller ID and it looks "suspect", and the
>> customer then is contacted and barred from sending arbitrary caller
>> ID until they can verify they own the numbers they're calling from,
>> then they're good to go.
>>
>> If the carrier continues to just ensure that call center traffic is a
>> revenue stream they can bill higher without making sure they're
>> outpulsing valid numbers, then they should absorb the social costs of
>> what's going on.
>>
>> Let's not get this confused - this isn't about customer PBXen
>> outpulsing forwarded calls when they do it, it's about people
>> shooting millions of calls a month, the carrier hitting them with
>> short duration charges, making more money, and having zero incentive
>> to question the arrangement.
>>
>> -Paul
>>
>> On 7/11/19 1:18 PM, Christopher Morrow wrote:
>>> 'illicit use of caller id' - how is caller-id being illicitly used
>>> though?
>>> I don't think it's against the law to say a different 'callerid' in
>>> the call
>>>   session, practically every actual call center does this, right?
>>
>
> ---------------------------------------------------------------------------
>
> Peter Beckman Internet Guy
> beckman@angryox.com http://www.angryox.com/
> ---------------------------------------------------------------------------
>

Chairman Pai issues statement at the conclusion of the SHAKEN/STIR
robocall summit.

https://docs.fcc.gov/public/attachments/DOC-358430A1.pdf

WASHINGTON, July 11, 2019—Federal Communications Commission Chairman Ajit
Pai issued the following statement on today’s SHAKEN/STIR Robocall Summit
at the FCC:

“We must move aggressively to help consumers combat scam robocalls that
use and abuse caller ID spoofing, and that’s why we held today’s summit.
The summit was productive, and we received generally encouraging signs
that companies are headed toward full implementation of the SHAKEN/STIR
caller ID authentication framework. I was pleased to hear from voice
service providers, vendors, consumer advocates, and others about the
successes to date and the challenges that remain.

“Given what I heard today, I am optimistic that the major voice service
providers will meet the end-of-2019 deadline for implementation I set for
them. That said, we stand ready to take regulatory action if this deadline
is not met. We have already adopted a Notice of Proposed Rulemaking and
will move quickly to mandate SHAKEN/STIR if needed.

“As I’ve said before and as panelists noted today, there is no silver
bullet to solving the problem of unwanted robocalls. But caller ID
authentication is an important part of the solution. And we will continue
to execute on the rest of our multi-pronged strategy as well. We have been
and will continue to do everything we can to protect American consumers
from this scourge.”

----- Original Message -----
> From: "Christopher Morrow" <morrowc.lists@gmail.com>

> On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins <paul@telcodata.us> wrote:
>>
>> Chris it would be trivial for this to be fixed, nearly overnight, by
>> creating some liability on the part of carriers for illicit use of
>> caller ID data on behalf of their customers.
>
> 'illicit use of caller id' - how is caller-id being illicitly used though?
> I don't think it's against the law to say a different 'callerid' in the call
> session, practically every actual call center does this, right?

I can speak to that, having originated calls from a call center.

Yes, of course we sent out calls with "spoofed" CNID.

But, even though only 2 or 3 or our 5 carriers* held *our* feet to the fire,
we held the clients' feet to the fire, requiring them to prove to our
satisfaction that they had adminstrative control over the numbers in question.

But it's the carrier's responsibility, properly, to do that work.

[. It was, IIRC, Verizon, Qwest and maybe Sprint that forced the issue with us;
at least two carriers did not. No longer recalll which ones. ]

Cheers,
-- jra
--
Jay R. Ashworth Baylink jra@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII
St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

On 7/15/19 12:07 PM, Jay R. Ashworth wrote:
> ----- Original Message -----
>> From: "Christopher Morrow" <morrowc.lists@gmail.com>
>> On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins <paul@telcodata.us> wrote:
>>> Chris it would be trivial for this to be fixed, nearly overnight, by
>>> creating some liability on the part of carriers for illicit use of
>>> caller ID data on behalf of their customers.
>> 'illicit use of caller id' - how is caller-id being illicitly used though?
>> I don't think it's against the law to say a different 'callerid' in the call
>> session, practically every actual call center does this, right?
> I can speak to that, having originated calls from a call center.
>
> Yes, of course we sent out calls with "spoofed" CNID.
>
> But, even though only 2 or 3 or our 5 carriers* held *our* feet to the fire,
> we held the clients' feet to the fire, requiring them to prove to our
> satisfaction that they had adminstrative control over the numbers in question.
>
> But it's the carrier's responsibility, properly, to do that work.
>

How do the clients prove that?

Way back when when we were working on mipv6 we had to work through a
somewhat similar problem for handoffs. The ultimate answer was a return
routability test: that is, if you can answer on the address you're
trying to claim "ownership" for, it's good enough.

Maybe such a thing can be done in for spoofing? Even out of band spot
checking might be adequate to keep clients honest?

But right you are, it's ultimately the carrier who needs to care about
this problem at or nothing gets better.

Mike

On Tue, 16 Jul 2019, Michael Thomas wrote:
> But right you are, it's ultimately the carrier who needs to care about this
> problem at or nothing gets better.

either the carrier starts dealing with it or legislation will come down to
force the issue.

-Dan

On Tue, Jul 16, 2019 at 6:28 PM Dan Hollis <goemon@sasami.anime.net> wrote:
>
> On Tue, 16 Jul 2019, Michael Thomas wrote:
> > But right you are, it's ultimately the carrier who needs to care about this
> > problem at or nothing gets better.
>
> either the carrier starts dealing with it or legislation will come down to
> force the issue.

<checks watch>It's 2019 right? This has been happening since
~1996</checks watch>

----- Original Message -----
> From: "Michael Thomas" <mike@mtcc.com>

> On 7/15/19 12:07 PM, Jay R. Ashworth wrote:
>> Yes, of course we sent out calls with "spoofed" CNID.
>>
>> But, even though only 2 or 3 or our 5 carriers* held *our* feet to the fire,
>> we held the clients' feet to the fire, requiring them to prove to our
>> satisfaction that they had adminstrative control over the numbers in question.
>>
>> But it's the carrier's responsibility, properly, to do that work.
>
> How do the clients prove that?

Do you know, I don't know; it was above my paygrade; the few times I stubbed
a toe on it, I threw it over a wall.

I presume that there was paperwork...

> Way back when when we were working on mipv6 we had to work through a
> somewhat similar problem for handoffs. The ultimate answer was a return
> routability test: that is, if you can answer on the address you're
> trying to claim "ownership" for, it's good enough.

Might have been a handshake like that; I suspect it was mostly just
"here's a picture of the client's phone bill".

> But right you are, it's ultimately the carrier who needs to care about
> this problem at or nothing gets better.

Yup.

Cheers,
-- jra
--
Jay R. Ashworth Baylink jra@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII
St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

On 7/18/19 3:15 PM, Jay R. Ashworth wrote:
> ----- Original Message -----
>> From: "Michael Thomas" <mike@mtcc.com>
>> On 7/15/19 12:07 PM, Jay R. Ashworth wrote:
>>> Yes, of course we sent out calls with "spoofed" CNID.
>>>
>>> But, even though only 2 or 3 or our 5 carriers* held *our* feet to the fire,
>>> we held the clients' feet to the fire, requiring them to prove to our
>>> satisfaction that they had adminstrative control over the numbers in question.
>>>
>>> But it's the carrier's responsibility, properly, to do that work.
>> How do the clients prove that?
> Do you know, I don't know; it was above my paygrade; the few times I stubbed
> a toe on it, I threw it over a wall.
>
> I presume that there was paperwork...
>
>

I still think this would be much easier to solve in the Internet domain
instead of in the PSTN domain. That is, use SIP From: address instead of
telephone numbers. We already have the ability to give with reasonable
certainty that a message has been originated by a given domain. If we
present that address in preference to caller ID, and I can filter based
on that it puts a lot of positive pressure on legit callers to identify
themselves (they already do it for their email), and negative pressure
on the callerid holdouts. They'd have to use their own domain name and
prove their control of it, and that's a good thing. You'd think this
would be easier for the carriers too since they wouldn't have to vet
shady clients... it's their domain they're trashing, not the carriers.

I for one would be perfectly happy with a UA that went straight to a
quarantine if it only had callerid in it.

Mike

On 11 Jul 2019, at 3:23 PM, Michael Thomas <mike@mtcc.com> wrote:
>
> I used to think that email spam was a law enforcement problem too, but it's become very clear that law enforcement has little to no interest in solving geeks' problems.

Law enforcement deals with legal entities (persons, organizations) and jurisdictions (i.e. physical locations) in determining both applicable law and appropriate enforcement authority.

The Internet does not provide reliable attribution of entity or locale, thus precluding any efficient use of our existing law enforcement framework – it is no surprise that our Internet design choices have such consequences.

c'est la vie sur Internet,
/John