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.
----- 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.
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 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
On 7/8/19 5:54 PM, Keith Medcalf wrote: 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
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.
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 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 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>
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 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....
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
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 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
sending you a message? It's more subtle than that - you always know the "identity" of the
On 7/8/19 6:11 PM, Valdis Klētnieks wrote: the MTA 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 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/ ---------------------------------------------------------------------------
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-roboca... 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 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.
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.
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
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
Caller. If it is not the ID of the Caller then Fraud is being committed and the bastards should be castrated (or worse), and
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
<kmedcalf@dessus.com> the the 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/ ---------------------------------------------------------------------------
-- 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.
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/ ---------------------------------------------------------------------------
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.
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?)
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?)
On 7/11/19 12:03 PM, Christopher Morrow 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.
On Thu, Jul 11, 2019 at 2:35 PM Michael Thomas <mike@mtcc.com> wrote: 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
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?
"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: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
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
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/ ---------------------------------------------------------------------------
----- 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, 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
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.”
participants (14)
-
Brian J. Murrell -
Christopher Morrow -
Dan Hollis -
Izzy Goldstein - TeleGo -
Jay R. Ashworth -
John Curran -
Keith Medcalf -
Michael Thomas -
Paul Timmins -
Peter Beckman -
Rich Kulawiec -
Ross Tajvar -
Sean Donelan -
Valdis Klētnieks