Mailing List Archive

SHAKEN/STIR Robocall Summit - July 11 2019 at FCC
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.


https://www.fcc.gov/SHAKENSTIRSummit

Date: Thursday, July 11, 2019
Time: Unknown, the public announcement did not include the time. Usually
these summits start around 9am EDT.
Location: Commission Meeting Room at FCC Headquarters, 445 12th Street,
S.W. Washington, D.C. 20554.

It will also be streamed at the FCC?s web page at www.fcc.gov/live.
Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC [ In reply to ]
----- 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
Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC [ In reply to ]
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/
---------------------------------------------------------------------------
Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC [ In reply to ]
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/
> ---------------------------------------------------------------------------
>
RE: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC [ In reply to ]
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.
Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC [ In reply to ]
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
RE: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC [ In reply to ]
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
Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC [ In reply to ]
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....
Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC [ In reply to ]
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.
>
Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC [ In reply to ]
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
RE: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC [ In reply to ]
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.
>>
Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC [ In reply to ]
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
RE: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC [ In reply to ]
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
RE: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC [ In reply to ]
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.
Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC [ In reply to ]
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.
>
>
>
>
Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC [ In reply to ]
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
Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC [ In reply to ]
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
Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC [ In reply to ]
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>
Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC [ In reply to ]
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.
Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC [ In reply to ]
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
RE: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC [ In reply to ]
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/
---------------------------------------------------------------------------
Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC [ In reply to ]
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.
Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC [ In reply to ]
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
RE: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC [ In reply to ]
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
Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC [ In reply to ]
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?)

1 2 3  View All