A few months ago I attended an FCC STIR/SHAKEN discussion in Washington DC. They didn't get deep into the technical details but there were a bunch of big carrier representatives there. If you haven't followed STIR/SHAKEN, it's really just an additional SIP header that contains cryptographically-signed information about the origin point of the call. You can verify the signature with publically published public keys so you know whomever signed it is really them. Here's a few resources if you want to learn more: https://www.bandwidth.com/glossary/stir-shaken/ https://www.fcc.gov/call-authentication https://en.wikipedia.org/wiki/STIR/SHAKEN https://www.home.neustar/stir-shaken-resource-hub There are three levels to tell you how much you should trust the origin of the call: 1. Full -- The call came from the originating carrier's customer and is authorized to use the number 2. Partial -- The call came from the originating carrier's customer but may or may not be authorized to use the number 3. Gateway -- The carrier has authenticated from where it received the call, but cannot authenticate the call source (e.g., International Gateway call). As an example, as will be many legit cases, a Verizon Wireless mobile customer will place a call, which will route to Verizon, who will sign the call using STIR/SHAKEN with Full Attestation and we can all "trust" the call. But now we throw in VoIP. I'm a small customer, Initech, of a larger carrier, Hooli. I don't sign my calls, so I hand my calls to my larger carrier, Hooli. Hooli sees the call from me (their customer) with a valid CallerID I'm authorized to use and so Hooli signs the call with STIR/SHAKEN with Full Attestation. Turns out the call was a robocall. What changes? The only thing that changes is that the receiving party, say Soylent Corp, knows that Hooli originated the call. Soylent is not Hooli's customer, so how does Soylent complain to Hooli about the content of the call? And as carriers, we are not legally responsible for the content of our customer's calls. How will Soylent accept 90% of Hooli's Fully Attested valid traffic but avoid the 10% that is spam/robocalls that are ALSO Fully Attested? How exactly does STIR/SHAKEN help fix the robocall and spam call problem? Yes, I could block all of Hooli's calls where the attestation is Partial or Gateway, but you run the risk of false positives, especially in the International category, or just when Hooli isn't sure, like when I rent a DID from Acme but do termination through Hooli -- Hooli doesn't know that I am authorized to use that DID from Acme, even though I am, so Hooli has to mark my call as Partial or Gateway. I'm all for reducing annoying spam and robocalls, but I'm still not yet convinced that STIR/SHAKEN is going to materially reduce them. Let's discuss! Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
Hi Peter, Good question. First, if you're using Hooli, you'll have to migrate to Pipernet sooner or later. Their middle-out compression provides much better call quality so it's worth the effort to migrate. But to the issue you raised, the purpose of STIR/SHAKEN is not to block robocalls per se, it is to provide an authentication chain so that you can determine and contact the originating carrier regardless of the route the call took to reach the terminating side. This has been a big issue; many VoIP companies hand off calls to large indifferent CLEC or IXCs who send them everywhere but won't respond to the terminating carrier's fraud and nuisance requests. So, now we can see that the call was attested by Hooli, and if Hooli does not cooperate with our fraud/nuisance investigations we are now authorized to block traffic signed by Hooli. That does fix the problem to a large degree. However, it's also worthy of note that this is not the main problem that needs to be solved. The main problem that needs to be solved is the case where you are sending the call to Hooli originating from a number that is assigned to our CLEC, which you don't have permission to use. This does solve that problem, because Hooli is only going to issue partial attestation for that call since it's not their number. So we can still contact Hooli about it because they attested it and from that I can find them, but we or our subscriber can also block calls with partial attestations if we/they choose to. Regards, Mike Mike Ray, MBA, CNE, CTE Astro Companies, LLC 11523 Palm Brush Trail #401 Lakewood Ranch, FL? 34202 DIRECT: call or text 941 600-0207 http://www.astrocompanies.com -----Original Message----- From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Peter Beckman Sent: Tuesday, December 17, 2019 2:58 PM To: VoiceOps <voiceops at voiceops.org> Subject: [VoiceOps] STIR/SHAKEN Discussion: Will it help? A few months ago I attended an FCC STIR/SHAKEN discussion in Washington DC. They didn't get deep into the technical details but there were a bunch of big carrier representatives there. If you haven't followed STIR/SHAKEN, it's really just an additional SIP header that contains cryptographically-signed information about the origin point of the call. You can verify the signature with publically published public keys so you know whomever signed it is really them. Here's a few resources if you want to learn more: https://www.bandwidth.com/glossary/stir-shaken/ https://www.fcc.gov/call-authentication https://en.wikipedia.org/wiki/STIR/SHAKEN https://www.home.neustar/stir-shaken-resource-hub There are three levels to tell you how much you should trust the origin of the call: 1. Full -- The call came from the originating carrier's customer and is authorized to use the number 2. Partial -- The call came from the originating carrier's customer but may or may not be authorized to use the number 3. Gateway -- The carrier has authenticated from where it received the call, but cannot authenticate the call source (e.g., International Gateway call). As an example, as will be many legit cases, a Verizon Wireless mobile customer will place a call, which will route to Verizon, who will sign the call using STIR/SHAKEN with Full Attestation and we can all "trust" the call. But now we throw in VoIP. I'm a small customer, Initech, of a larger carrier, Hooli. I don't sign my calls, so I hand my calls to my larger carrier, Hooli. Hooli sees the call from me (their customer) with a valid CallerID I'm authorized to use and so Hooli signs the call with STIR/SHAKEN with Full Attestation. Turns out the call was a robocall. What changes? The only thing that changes is that the receiving party, say Soylent Corp, knows that Hooli originated the call. Soylent is not Hooli's customer, so how does Soylent complain to Hooli about the content of the call? And as carriers, we are not legally responsible for the content of our customer's calls. How will Soylent accept 90% of Hooli's Fully Attested valid traffic but avoid the 10% that is spam/robocalls that are ALSO Fully Attested? How exactly does STIR/SHAKEN help fix the robocall and spam call problem? Yes, I could block all of Hooli's calls where the attestation is Partial or Gateway, but you run the risk of false positives, especially in the International category, or just when Hooli isn't sure, like when I rent a DID from Acme but do termination through Hooli -- Hooli doesn't know that I am authorized to use that DID from Acme, even though I am, so Hooli has to mark my call as Partial or Gateway. I'm all for reducing annoying spam and robocalls, but I'm still not yet convinced that STIR/SHAKEN is going to materially reduce them. Let's discuss! Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Mike beat me to it. It's going to stop fraud. The bigger issue you are going to have is the larger packets. So many devices out there can't seem to fragment packets correctly. On Tue, Dec 17, 2019 at 3:28 PM <mike at astrocompanies.com> wrote:
Hi Peter,
Good question. First, if you're using Hooli, you'll have to migrate to Pipernet sooner or later. Their middle-out compression provides much better call quality so it's worth the effort to migrate.
But to the issue you raised, the purpose of STIR/SHAKEN is not to block robocalls per se, it is to provide an authentication chain so that you can determine and contact the originating carrier regardless of the route the call took to reach the terminating side. This has been a big issue; many VoIP companies hand off calls to large indifferent CLEC or IXCs who send them everywhere but won't respond to the terminating carrier's fraud and nuisance requests.
So, now we can see that the call was attested by Hooli, and if Hooli does not cooperate with our fraud/nuisance investigations we are now authorized to block traffic signed by Hooli. That does fix the problem to a large degree.
However, it's also worthy of note that this is not the main problem that needs to be solved. The main problem that needs to be solved is the case where you are sending the call to Hooli originating from a number that is assigned to our CLEC, which you don't have permission to use. This does solve that problem, because Hooli is only going to issue partial attestation for that call since it's not their number. So we can still contact Hooli about it because they attested it and from that I can find them, but we or our subscriber can also block calls with partial attestations if we/they choose to.
Regards,
Mike
Mike Ray, MBA, CNE, CTE Astro Companies, LLC 11523 Palm Brush Trail #401 Lakewood Ranch, FL 34202 DIRECT: call or text 941 600-0207 http://www.astrocompanies.com
-----Original Message----- From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Peter Beckman Sent: Tuesday, December 17, 2019 2:58 PM To: VoiceOps <voiceops at voiceops.org> Subject: [VoiceOps] STIR/SHAKEN Discussion: Will it help?
A few months ago I attended an FCC STIR/SHAKEN discussion in Washington DC. They didn't get deep into the technical details but there were a bunch of big carrier representatives there.
If you haven't followed STIR/SHAKEN, it's really just an additional SIP header that contains cryptographically-signed information about the origin point of the call.
You can verify the signature with publically published public keys so you know whomever signed it is really them.
Here's a few resources if you want to learn more:
https://www.bandwidth.com/glossary/stir-shaken/ https://www.fcc.gov/call-authentication https://en.wikipedia.org/wiki/STIR/SHAKEN https://www.home.neustar/stir-shaken-resource-hub
There are three levels to tell you how much you should trust the origin of the call:
1. Full -- The call came from the originating carrier's customer and is authorized to use the number
2. Partial -- The call came from the originating carrier's customer but may or may not be authorized to use the number
3. Gateway -- The carrier has authenticated from where it received the call, but cannot authenticate the call source (e.g., International Gateway call).
As an example, as will be many legit cases, a Verizon Wireless mobile customer will place a call, which will route to Verizon, who will sign the call using STIR/SHAKEN with Full Attestation and we can all "trust" the call.
But now we throw in VoIP.
I'm a small customer, Initech, of a larger carrier, Hooli. I don't sign my calls, so I hand my calls to my larger carrier, Hooli. Hooli sees the call from me (their customer) with a valid CallerID I'm authorized to use and so Hooli signs the call with STIR/SHAKEN with Full Attestation.
Turns out the call was a robocall.
What changes? The only thing that changes is that the receiving party, say Soylent Corp, knows that Hooli originated the call. Soylent is not Hooli's customer, so how does Soylent complain to Hooli about the content of the call?
And as carriers, we are not legally responsible for the content of our customer's calls.
How will Soylent accept 90% of Hooli's Fully Attested valid traffic but avoid the 10% that is spam/robocalls that are ALSO Fully Attested?
How exactly does STIR/SHAKEN help fix the robocall and spam call problem?
Yes, I could block all of Hooli's calls where the attestation is Partial or Gateway, but you run the risk of false positives, especially in the International category, or just when Hooli isn't sure, like when I rent a DID from Acme but do termination through Hooli -- Hooli doesn't know that I am authorized to use that DID from Acme, even though I am, so Hooli has to mark my call as Partial or Gateway.
I'm all for reducing annoying spam and robocalls, but I'm still not yet convinced that STIR/SHAKEN is going to materially reduce them.
Let's discuss!
Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
I see it as stopping fraud the same way SPF and DKIM stopped spam. On 12/17/19 3:38 PM, Dovid Bender wrote:
Mike beat me to it. It's going to stop fraud. The bigger issue you are going to have is the larger packets. So many devices out there can't seem to fragment packets correctly.
On Tue, Dec 17, 2019 at 3:28 PM <mike at astrocompanies.com <mailto:mike at astrocompanies.com>> wrote:
Hi Peter,
Good question.? First, if you're using Hooli, you'll have to migrate to Pipernet sooner or later.? Their middle-out compression provides much better call quality so it's worth the effort to migrate.
But to the issue you raised, the purpose of STIR/SHAKEN is not to block robocalls per se, it is to provide an authentication chain so that you can determine and contact the originating carrier regardless of the route the call took to reach the terminating side.? This has been a big issue; many VoIP companies hand off calls to large indifferent CLEC or IXCs who send them everywhere but won't respond to the terminating carrier's fraud and nuisance requests.
So, now we can see that the call was attested by Hooli, and if Hooli does not cooperate with our fraud/nuisance investigations we are now authorized to block traffic signed by Hooli.? That does fix the problem to a large degree.
However, it's also worthy of note that this is not the main problem that needs to be solved.? The main problem that needs to be solved is the case where you are sending the call to Hooli originating from a number that is assigned to our CLEC, which you don't have permission to use. This does solve that problem, because Hooli is only going to issue partial attestation for that call since it's not their number.? So we can still contact Hooli about it because they attested it and from that I can find them, but we or our subscriber can also block calls with partial attestations if we/they choose to.
Regards,
Mike
Mike Ray, MBA, CNE, CTE Astro Companies, LLC 11523 Palm Brush Trail #401 Lakewood Ranch, FL? 34202 DIRECT: call or text 941 600-0207 http://www.astrocompanies.com
-----Original Message----- From: VoiceOps <voiceops-bounces at voiceops.org <mailto:voiceops-bounces at voiceops.org>> On Behalf Of Peter Beckman Sent: Tuesday, December 17, 2019 2:58 PM To: VoiceOps <voiceops at voiceops.org <mailto:voiceops at voiceops.org>> Subject: [VoiceOps] STIR/SHAKEN Discussion: Will it help?
A few months ago I attended an FCC STIR/SHAKEN discussion in Washington DC. They didn't get deep into the technical details but there were a bunch of big carrier representatives there.
If you haven't followed STIR/SHAKEN, it's really just an additional SIP header that contains cryptographically-signed information about the origin point of the call.
You can verify the signature with publically published public keys so you know whomever signed it is really them.
Here's a few resources if you want to learn more:
https://www.bandwidth.com/glossary/stir-shaken/ https://www.fcc.gov/call-authentication https://en.wikipedia.org/wiki/STIR/SHAKEN https://www.home.neustar/stir-shaken-resource-hub
There are three levels to tell you how much you should trust the origin of the call:
? ? ?1. Full -- The call came from the originating carrier's customer and is ? ? ? ? ?authorized to use the number
? ? ?2. Partial -- The call came from the originating carrier's customer but ? ? ? ? ?may or may not be authorized to use the number
? ? ?3. Gateway -- The carrier has authenticated from where it received the ? ? ? ? ?call, but cannot authenticate the call source (e.g., International ? ? ? ? ?Gateway call).
As an example, as will be many legit cases, a Verizon Wireless mobile customer will place a call, which will route to Verizon, who will sign the call using STIR/SHAKEN with Full Attestation and we can all "trust" the call.
But now we throw in VoIP.
I'm a small customer, Initech, of a larger carrier, Hooli. I don't sign my calls, so I hand my calls to my larger carrier, Hooli. Hooli sees the call from me (their customer) with a valid CallerID I'm authorized to use and so Hooli signs the call with STIR/SHAKEN with Full Attestation.
Turns out the call was a robocall.
What changes? The only thing that changes is that the receiving party, say Soylent Corp, knows that Hooli originated the call. Soylent is not Hooli's customer, so how does Soylent complain to Hooli about the content of the call?
And as carriers, we are not legally responsible for the content of our customer's calls.
How will Soylent accept 90% of Hooli's Fully Attested valid traffic but avoid the 10% that is spam/robocalls that are ALSO Fully Attested?
How exactly does STIR/SHAKEN help fix the robocall and spam call problem?
Yes, I could block all of Hooli's calls where the attestation is Partial or Gateway, but you run the risk of false positives, especially in the International category, or just when Hooli isn't sure, like when I rent a DID from Acme but do termination through Hooli -- Hooli doesn't know that I am authorized to use that DID from Acme, even though I am, so Hooli has to mark my call as Partial or Gateway.
I'm all for reducing annoying spam and robocalls, but I'm still not yet convinced that STIR/SHAKEN is going to materially reduce them.
Let's discuss!
Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com <mailto:beckman at angryox.com> http://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
I knew Gavin Belson was behind this. ? Sent from mobile, with due apologies for brevity and errors.
On Dec 17, 2019, at 4:07 PM, Paul Timmins <paul at timmins.net> wrote:
? I see it as stopping fraud the same way SPF and DKIM stopped spam.
On 12/17/19 3:38 PM, Dovid Bender wrote:
Mike beat me to it. It's going to stop fraud. The bigger issue you are going to have is the larger packets. So many devices out there can't seem to fragment packets correctly.
On Tue, Dec 17, 2019 at 3:28 PM <mike at astrocompanies.com> wrote:
Hi Peter,
Good question. First, if you're using Hooli, you'll have to migrate to Pipernet sooner or later. Their middle-out compression provides much better call quality so it's worth the effort to migrate.
But to the issue you raised, the purpose of STIR/SHAKEN is not to block robocalls per se, it is to provide an authentication chain so that you can determine and contact the originating carrier regardless of the route the call took to reach the terminating side. This has been a big issue; many VoIP companies hand off calls to large indifferent CLEC or IXCs who send them everywhere but won't respond to the terminating carrier's fraud and nuisance requests.
So, now we can see that the call was attested by Hooli, and if Hooli does not cooperate with our fraud/nuisance investigations we are now authorized to block traffic signed by Hooli. That does fix the problem to a large degree.
However, it's also worthy of note that this is not the main problem that needs to be solved. The main problem that needs to be solved is the case where you are sending the call to Hooli originating from a number that is assigned to our CLEC, which you don't have permission to use. This does solve that problem, because Hooli is only going to issue partial attestation for that call since it's not their number. So we can still contact Hooli about it because they attested it and from that I can find them, but we or our subscriber can also block calls with partial attestations if we/they choose to.
Regards,
Mike
Mike Ray, MBA, CNE, CTE Astro Companies, LLC 11523 Palm Brush Trail #401 Lakewood Ranch, FL 34202 DIRECT: call or text 941 600-0207 http://www.astrocompanies.com
-----Original Message----- From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Peter Beckman Sent: Tuesday, December 17, 2019 2:58 PM To: VoiceOps <voiceops at voiceops.org> Subject: [VoiceOps] STIR/SHAKEN Discussion: Will it help?
A few months ago I attended an FCC STIR/SHAKEN discussion in Washington DC. They didn't get deep into the technical details but there were a bunch of big carrier representatives there.
If you haven't followed STIR/SHAKEN, it's really just an additional SIP header that contains cryptographically-signed information about the origin point of the call.
You can verify the signature with publically published public keys so you know whomever signed it is really them.
Here's a few resources if you want to learn more:
https://www.bandwidth.com/glossary/stir-shaken/ https://www.fcc.gov/call-authentication https://en.wikipedia.org/wiki/STIR/SHAKEN https://www.home.neustar/stir-shaken-resource-hub
There are three levels to tell you how much you should trust the origin of the call:
1. Full -- The call came from the originating carrier's customer and is authorized to use the number
2. Partial -- The call came from the originating carrier's customer but may or may not be authorized to use the number
3. Gateway -- The carrier has authenticated from where it received the call, but cannot authenticate the call source (e.g., International Gateway call).
As an example, as will be many legit cases, a Verizon Wireless mobile customer will place a call, which will route to Verizon, who will sign the call using STIR/SHAKEN with Full Attestation and we can all "trust" the call.
But now we throw in VoIP.
I'm a small customer, Initech, of a larger carrier, Hooli. I don't sign my calls, so I hand my calls to my larger carrier, Hooli. Hooli sees the call from me (their customer) with a valid CallerID I'm authorized to use and so Hooli signs the call with STIR/SHAKEN with Full Attestation.
Turns out the call was a robocall.
What changes? The only thing that changes is that the receiving party, say Soylent Corp, knows that Hooli originated the call. Soylent is not Hooli's customer, so how does Soylent complain to Hooli about the content of the call?
And as carriers, we are not legally responsible for the content of our customer's calls.
How will Soylent accept 90% of Hooli's Fully Attested valid traffic but avoid the 10% that is spam/robocalls that are ALSO Fully Attested?
How exactly does STIR/SHAKEN help fix the robocall and spam call problem?
Yes, I could block all of Hooli's calls where the attestation is Partial or Gateway, but you run the risk of false positives, especially in the International category, or just when Hooli isn't sure, like when I rent a DID from Acme but do termination through Hooli -- Hooli doesn't know that I am authorized to use that DID from Acme, even though I am, so Hooli has to mark my call as Partial or Gateway.
I'm all for reducing annoying spam and robocalls, but I'm still not yet convinced that STIR/SHAKEN is going to materially reduce them.
Let's discuss!
Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On Tue, 17 Dec 2019, Paul Timmins wrote:
I see it as stopping fraud the same way SPF and DKIM stopped spam.
Yes! Agreed. It makes legit traffic easier to identify, but does nothing to stop spam.
On 12/17/19 3:38 PM, Dovid Bender wrote:
Mike beat me to it. It's going to stop fraud. The bigger issue you are going to have is the larger packets. So many devices out there can't seem to fragment packets correctly.
On Tue, Dec 17, 2019 at 3:28 PM <mike at astrocompanies.com <mailto:mike at astrocompanies.com>> wrote:
Hi Peter,
Good question.? First, if you're using Hooli, you'll have to migrate to Pipernet sooner or later.? Their middle-out compression provides much better call quality so it's worth the effort to migrate.
But to the issue you raised, the purpose of STIR/SHAKEN is not to block robocalls per se, it is to provide an authentication chain so that you can determine and contact the originating carrier regardless of the route the call took to reach the terminating side.? This has been a big issue; many VoIP companies hand off calls to large indifferent CLEC or IXCs who send them everywhere but won't respond to the terminating carrier's fraud and nuisance requests.
So, now we can see that the call was attested by Hooli, and if Hooli does not cooperate with our fraud/nuisance investigations we are now authorized to block traffic signed by Hooli.? That does fix the problem to a large degree.
However, it's also worthy of note that this is not the main problem that needs to be solved.? The main problem that needs to be solved is the case where you are sending the call to Hooli originating from a number that is assigned to our CLEC, which you don't have permission to use. This does solve that problem, because Hooli is only going to issue partial attestation for that call since it's not their number.? So we can still contact Hooli about it because they attested it and from that I can find them, but we or our subscriber can also block calls with partial attestations if we/they choose to.
Regards,
Mike
Mike Ray, MBA, CNE, CTE Astro Companies, LLC 11523 Palm Brush Trail #401 Lakewood Ranch, FL? 34202 DIRECT: call or text 941 600-0207 http://www.astrocompanies.com
-----Original Message----- From: VoiceOps <voiceops-bounces at voiceops.org <mailto:voiceops-bounces at voiceops.org>> On Behalf Of Peter Beckman Sent: Tuesday, December 17, 2019 2:58 PM To: VoiceOps <voiceops at voiceops.org <mailto:voiceops at voiceops.org>> Subject: [VoiceOps] STIR/SHAKEN Discussion: Will it help?
A few months ago I attended an FCC STIR/SHAKEN discussion in Washington DC. They didn't get deep into the technical details but there were a bunch of big carrier representatives there.
If you haven't followed STIR/SHAKEN, it's really just an additional SIP header that contains cryptographically-signed information about the origin point of the call.
You can verify the signature with publically published public keys so you know whomever signed it is really them.
Here's a few resources if you want to learn more:
https://www.bandwidth.com/glossary/stir-shaken/ https://www.fcc.gov/call-authentication https://en.wikipedia.org/wiki/STIR/SHAKEN https://www.home.neustar/stir-shaken-resource-hub
There are three levels to tell you how much you should trust the origin of the call:
? ? ?1. Full -- The call came from the originating carrier's customer and is ? ? ? ? ?authorized to use the number
? ? ?2. Partial -- The call came from the originating carrier's customer but ? ? ? ? ?may or may not be authorized to use the number
? ? ?3. Gateway -- The carrier has authenticated from where it received the ? ? ? ? ?call, but cannot authenticate the call source (e.g., International ? ? ? ? ?Gateway call).
As an example, as will be many legit cases, a Verizon Wireless mobile customer will place a call, which will route to Verizon, who will sign the call using STIR/SHAKEN with Full Attestation and we can all "trust" the call.
But now we throw in VoIP.
I'm a small customer, Initech, of a larger carrier, Hooli. I don't sign my calls, so I hand my calls to my larger carrier, Hooli. Hooli sees the call from me (their customer) with a valid CallerID I'm authorized to use and so Hooli signs the call with STIR/SHAKEN with Full Attestation.
Turns out the call was a robocall.
What changes? The only thing that changes is that the receiving party, say Soylent Corp, knows that Hooli originated the call. Soylent is not Hooli's customer, so how does Soylent complain to Hooli about the content of the call?
And as carriers, we are not legally responsible for the content of our customer's calls.
How will Soylent accept 90% of Hooli's Fully Attested valid traffic but avoid the 10% that is spam/robocalls that are ALSO Fully Attested?
How exactly does STIR/SHAKEN help fix the robocall and spam call problem?
Yes, I could block all of Hooli's calls where the attestation is Partial or Gateway, but you run the risk of false positives, especially in the International category, or just when Hooli isn't sure, like when I rent a DID from Acme but do termination through Hooli -- Hooli doesn't know that I am authorized to use that DID from Acme, even though I am, so Hooli has to mark my call as Partial or Gateway.
I'm all for reducing annoying spam and robocalls, but I'm still not yet convinced that STIR/SHAKEN is going to materially reduce them.
Let's discuss!
Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com <mailto:beckman at angryox.com> http://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
On Tue, 17 Dec 2019, Dovid Bender wrote:
Mike beat me to it. It's going to stop fraud. The bigger issue you are going to have is the larger packets. So many devices out there can't seem to fragment packets correctly.
How is it going to stop fraud?
On Tue, Dec 17, 2019 at 3:28 PM <mike at astrocompanies.com> wrote:
Hi Peter,
Good question. First, if you're using Hooli, you'll have to migrate to Pipernet sooner or later. Their middle-out compression provides much better call quality so it's worth the effort to migrate.
But to the issue you raised, the purpose of STIR/SHAKEN is not to block robocalls per se, it is to provide an authentication chain so that you can determine and contact the originating carrier regardless of the route the call took to reach the terminating side. This has been a big issue; many VoIP companies hand off calls to large indifferent CLEC or IXCs who send them everywhere but won't respond to the terminating carrier's fraud and nuisance requests.
So, now we can see that the call was attested by Hooli, and if Hooli does not cooperate with our fraud/nuisance investigations we are now authorized to block traffic signed by Hooli. That does fix the problem to a large degree.
However, it's also worthy of note that this is not the main problem that needs to be solved. The main problem that needs to be solved is the case where you are sending the call to Hooli originating from a number that is assigned to our CLEC, which you don't have permission to use. This does solve that problem, because Hooli is only going to issue partial attestation for that call since it's not their number. So we can still contact Hooli about it because they attested it and from that I can find them, but we or our subscriber can also block calls with partial attestations if we/they choose to.
Regards,
Mike
Mike Ray, MBA, CNE, CTE Astro Companies, LLC 11523 Palm Brush Trail #401 Lakewood Ranch, FL 34202 DIRECT: call or text 941 600-0207 http://www.astrocompanies.com
-----Original Message----- From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Peter Beckman Sent: Tuesday, December 17, 2019 2:58 PM To: VoiceOps <voiceops at voiceops.org> Subject: [VoiceOps] STIR/SHAKEN Discussion: Will it help?
A few months ago I attended an FCC STIR/SHAKEN discussion in Washington DC. They didn't get deep into the technical details but there were a bunch of big carrier representatives there.
If you haven't followed STIR/SHAKEN, it's really just an additional SIP header that contains cryptographically-signed information about the origin point of the call.
You can verify the signature with publically published public keys so you know whomever signed it is really them.
Here's a few resources if you want to learn more:
https://www.bandwidth.com/glossary/stir-shaken/ https://www.fcc.gov/call-authentication https://en.wikipedia.org/wiki/STIR/SHAKEN https://www.home.neustar/stir-shaken-resource-hub
There are three levels to tell you how much you should trust the origin of the call:
1. Full -- The call came from the originating carrier's customer and is authorized to use the number
2. Partial -- The call came from the originating carrier's customer but may or may not be authorized to use the number
3. Gateway -- The carrier has authenticated from where it received the call, but cannot authenticate the call source (e.g., International Gateway call).
As an example, as will be many legit cases, a Verizon Wireless mobile customer will place a call, which will route to Verizon, who will sign the call using STIR/SHAKEN with Full Attestation and we can all "trust" the call.
But now we throw in VoIP.
I'm a small customer, Initech, of a larger carrier, Hooli. I don't sign my calls, so I hand my calls to my larger carrier, Hooli. Hooli sees the call from me (their customer) with a valid CallerID I'm authorized to use and so Hooli signs the call with STIR/SHAKEN with Full Attestation.
Turns out the call was a robocall.
What changes? The only thing that changes is that the receiving party, say Soylent Corp, knows that Hooli originated the call. Soylent is not Hooli's customer, so how does Soylent complain to Hooli about the content of the call?
And as carriers, we are not legally responsible for the content of our customer's calls.
How will Soylent accept 90% of Hooli's Fully Attested valid traffic but avoid the 10% that is spam/robocalls that are ALSO Fully Attested?
How exactly does STIR/SHAKEN help fix the robocall and spam call problem?
Yes, I could block all of Hooli's calls where the attestation is Partial or Gateway, but you run the risk of false positives, especially in the International category, or just when Hooli isn't sure, like when I rent a DID from Acme but do termination through Hooli -- Hooli doesn't know that I am authorized to use that DID from Acme, even though I am, so Hooli has to mark my call as Partial or Gateway.
I'm all for reducing annoying spam and robocalls, but I'm still not yet convinced that STIR/SHAKEN is going to materially reduce them.
Let's discuss!
Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
On Tue, Dec 17, 2019 at 03:38:39PM -0500, Dovid Bender wrote:
The bigger issue you are going to have is the larger packets. So many devices out there can't seem to fragment packets correctly.
There are many other reasons why SIP messages are getting bigger and bigger, of which STIR/SHAKEN is not the first, second or fifth: other standards, WebRTC interop, more/wideband codecs in SDP bodies, SRTP(-SDES/DTLS), support for other features and standards, etc. So, this problem needs to be dealt with one way or another and is pervasive irrespectively of STIR/SHAKEN. The solution, of course, is to use SIP over TCP. -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
On 12/17/19 6:24 PM, Alex Balashov wrote:
There are many other reasons why SIP messages are getting bigger and bigger, of which STIR/SHAKEN is not the first, second or fifth: other standards, WebRTC interop, more/wideband codecs in SDP bodies, SRTP(-SDES/DTLS), support for other features and standards, etc. So, this problem needs to be dealt with one way or another and is pervasive irrespectively of STIR/SHAKEN.
The solution, of course, is to use SIP over TCP.
-- Alex
Hell, it's worth it for the avoidance of cheap, stupid SIP ALGs* all by itself. * Is there any other type? For that matter, is there actually someone who went HOT DAMN THANK GOD THIS ROUTER HAS SIP ALG let alone "THANK GOD ITS ON BY DEFAULT WITH THE SWITCH SNAPPED OFF"
"The ALG fixed everything!" -- said nobody, ever. But ALGs are increasingly meddling in TCP streams too. Some of them even do insidious fingerprinting to where switching ports won't throw them. For those pathological cases, TLS is the only solution. On Tue, Dec 17, 2019 at 06:34:43PM -0500, Paul Timmins wrote:
On 12/17/19 6:24 PM, Alex Balashov wrote:
There are many other reasons why SIP messages are getting bigger and bigger, of which STIR/SHAKEN is not the first, second or fifth: other standards, WebRTC interop, more/wideband codecs in SDP bodies, SRTP(-SDES/DTLS), support for other features and standards, etc. So, this problem needs to be dealt with one way or another and is pervasive irrespectively of STIR/SHAKEN.
The solution, of course, is to use SIP over TCP.
-- Alex
Hell, it's worth it for the avoidance of cheap, stupid SIP ALGs* all by itself.
* Is there any other type? For that matter, is there actually someone who went HOT DAMN THANK GOD THIS ROUTER HAS SIP ALG let alone "THANK GOD ITS ON BY DEFAULT WITH THE SWITCH SNAPPED OFF"
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
-- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
The solution, of course, is to use SIP over TCP.
Agreed, but that too has implications. Maybe your carriers support TCP, maybe they don't. Also, the memory footprint on gear just got bigger to manage the TCP overhead. We've also seen odd incidents around TCP (not releasing sessions and exhausting sockets, etc), but that's all been patched by now.* (Or has it been?)* Is anyone out there doing SIP/TCP on a large-scale basis? Thoughts on implementation/technologies? Where in the network would you do your assertion (softswitch, SBC, other?), and where would you authenticate incoming (my inclination is to do it at the SBC edge)?
On Dec 31, 2019, at 11:06 AM, Pete Eisengrein <peeip989 at gmail.com> wrote:
Thoughts on implementation/technologies? Where in the network would you do your assertion (softswitch, SBC, other?),
Many of the implementations allow SHAKEN over SIP, using a 302 to add the Identity header. This is much more convenient than having to use the original HTTPS interface, because you really do have the options to do it in many places. The signing gadgets (STI-AS) are fairly blind... they'll sign anything that comes in to them with proper authentication. I'm guessing one of the big risks will be sending calls through the STI-AS that shouldn't go through it. So for A-level attestation (the "highest levels of trust" in the word of the TRACED Act), we really want authentication to be done by a device that knows the call originated from a known user, and the known user was calling from a phone number they had rights to call from. The STI-AS doesn't know whether call screening (which ensures the user only calls from a number directly assigned to that user) is active. What we really want is the BroadWorks AS or the Metaswitch CFS to send the call to the STI-AS only if the user is calling from their own number.
and where would you authenticate incoming (my inclination is to do it at the SBC edge)?
Two points to be made here: 1. The idea of "authenticating the incoming calls" only applies if you're really going to block incoming calls. The mood of the industry is that -- (A) We want to Display information about the authenticity of the call. "Call Verified" or "Spam likely", etc. (B) We need an Analytics that make the best guess about the caller's authenticity. (Think: AT&T Call Protect, powered by Hiya.) (C) SHAKEN/STIR is one of those inputs to the Analytics systems. That is to say: callers are concerned about blocking, but carriers who are testing SHAKEN/STIR right now aren't really thinking of doing blocking. 2. Because the big goal of the verification is display, not blocking, we can expect verification (STI-VS) before the analytics platform, which is before the call is sent to the final recipient. Slides from my SIPNOC presentation on hacking SHAKEN/STIR: Lindsey_SHAKEN_STIR_White-Hat_Security_Analysis_-_SIPNOC_2019-2019-11-02-1820.pdf <https://www.ecg.co/files/resources/files/2/Lindsey_SHAKEN_STIR_White-Hat_Sec...> https://www.ecg.co/files/resources/files/2/Lindsey_SHAKEN_STIR_White-Hat_Sec... My presentation focused Bad Actors who don't register with anybody. But after my presentation, Jon Peterson (who wrote much of the SHAKEN RFCs) added another security gap in the American implementation: anybody can get an OCN and CLLI code, access to numbers, get a Service Provider Token and a signing Certificate from the PA/CA, and then sign every call they want to from any number they want to. Mark R Lindsey, SMTS | +1-229-316-0013 | mark at ecg.co | https://ecg.co/lindsey/ <https://ecg.co/lindsey/>
The idea of "authenticating the incoming calls" only applies if you're really going to block incoming calls.
Sort of. Even if the goal is to update the CLID (e.g. Spam likely) one needs to authenticate it. That is, to do the verify the Identity.
anybody can get an OCN and CLLI code
Agreed. This doesn't protect anyone anymore than an SSL cert on a web page prevents a site from being malicious (e.g. an "authentic" phishing page) So, while the SHAKEN idea is well-intentioned, we may be spinning our wheels, just as it was well-intentioned to prepare for Y2K a short 20 years ago; we all knew nothing would happen but we prepared anyway :-)
On Tue, Dec 31, 2019 at 8:54 AM Mark Lindsey <lindsey at e-c-group.com> wrote:
My presentation focused Bad Actors who don't register with anybody. But after my presentation, Jon Peterson (who wrote much of the SHAKEN RFCs) added another security gap in the American implementation: anybody can get an OCN and CLLI code, access to numbers, get a Service Provider Token and a signing Certificate from the PA/CA, and then sign every call they want to from any number they want to.
*Mark R Lindsey, SMTS* | +1-229-316-0013 | mark at ecg.co |* https://ecg.co/lindsey/ <https://ecg.co/lindsey/>*
I think the entire point of S/S (can we abbreviate this yet?) *is* the bad actors. Yes, an entity can go through all the hoops to sign calls, and their traffic will become immediately identifiable. It shouldn't take long for their certificate to get revoked while the FCC and others work on fining them out of existence with possible criminal charges with jail time.
I wouldn't say it's all that easy because you have to be certified as a CLEC, Interconnected VOIP, or Wireless provider in order to get access to numbering resources. A lot of people missed that part in the guidelines because it was not worded clearly and they didn't know that you can't get NXXs assigned without providing the certification to the PA. I contacted Brent Struthers (STI-GA Director) a few months back and asked him about that because it didn't make sense that you could get access to NANPA resources without the proper certification to get NXXs. He verified that you DO have to have a CLEC, Interconnected VOIP, or Wireless provider cerfification in order to get access to NANPA resources! MARY LOU CAREY BackUP Telecom Consulting Office: 615-791-9969 Cell: 615-796-1111 On 2019-12-31 01:35 PM, Calvin Ellison wrote:
On Tue, Dec 31, 2019 at 8:54 AM Mark Lindsey <lindsey at e-c-group.com> wrote:
My presentation focused Bad Actors who don't register with anybody. But after my presentation, Jon Peterson (who wrote much of the SHAKEN RFCs) added another security gap in the American implementation: anybody can get an OCN and CLLI code, access to numbers, get a Service Provider Token and a signing Certificate from the PA/CA, and then sign every call they want to from any number they want to.
MARK R LINDSEY, SMTS | +1-229-316-0013 | mark at ecg.co | HTTPS://ECG.CO/LINDSEY/
I think the entire point of S/S (can we abbreviate this yet?) _is_ the bad actors. Yes, an entity can go through all the hoops to sign calls, and their traffic will become immediately identifiable. It shouldn't take long for their certificate to get revoked while the FCC and others work on fining them out of existence with possible criminal charges with jail time. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
It turns out this (STIR/SHAKEN) was signed into law last week and the clock started ticking on 12/30/19 for us to implement within 18 months. "S.151 - Pallone-Thune Telephone Robocall Abuse Criminal Enforcement and Deterrence Act" https://www.congress.gov/bill/116th-congress/senate-bill/151/text Interestingly it also covers the one-ring (call back) scam. I guess we're left to our own devices on this one to analyze our customer's calling patterns to find who is doing it....
On Tue, 17 Dec 2019, mike at astrocompanies.com wrote:
Good question. First, if you're using Hooli, you'll have to migrate to Pipernet sooner or later. Their middle-out compression provides much better call quality so it's worth the effort to migrate.
Doh! What's their Weissman score?
But to the issue you raised, the purpose of STIR/SHAKEN is not to block robocalls per se, it is to provide an authentication chain so that you can determine and contact the originating carrier regardless of the route the call took to reach the terminating side.
AFAIK, it is only the first originating carrier that gets a SIP Invite that contains no STIR/SHAKEN header. Each carrier does not also add their own header. I may be incorrect.
So, now we can see that the call was attested by Hooli, and if Hooli does not cooperate with our fraud/nuisance investigations we are now authorized to block traffic signed by Hooli. That does fix the problem to a large degree.
Sure, but have you ever tried to contact a carrier for which you do not have a business relationship and get them to do something, and you are smaller and less consequential than they are? We can block Hooli, but now OUR customers are livid, and Hooli doesn't really care.
However, it's also worthy of note that this is not the main problem that needs to be solved. The main problem that needs to be solved is the case where you are sending the call to Hooli originating from a number that is assigned to our CLEC, which you don't have permission to use. This does solve that problem, because Hooli is only going to issue partial attestation for that call since it's not their number. So we can still contact Hooli about it because they attested it and from that I can find them, but we or our subscriber can also block calls with partial attestations if we/they choose to.
But if I DO have a number assigned to me BY as CLEC that is not the terminating carrier (e.g. Acme gives me a DID, which I am authorized to use, then try to terminate using that DID as CallerID through Hooli, Hooli does not know (and cannot know for certain) that I, the Hooli customer, is authorized to use that DID as CallerID, even though I am. This results in a Hooli Partial Attestation, even though the call is fully compliant with all the rules. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
In article <alpine.BSF.2.20.1912171724140.8519 at nog2.angryox.com> you write:
Sure, but have you ever tried to contact a carrier for which you do not have a business relationship and get them to do something, and you are smaller and less consequential than they are?
We can block Hooli, but now OUR customers are livid, and Hooli doesn't really care.
It's more subtle than that. The signature from Hooli is a signal you can stir into your spam filters. If the call comes from them and the calling number isn't one you'd expect them to host, that's a pretty strong signal your customer won't be happy to get the call. R's, John
On Tue, 17 Dec 2019, John Levine wrote:
In article <alpine.BSF.2.20.1912171724140.8519 at nog2.angryox.com> you write:
Sure, but have you ever tried to contact a carrier for which you do not have a business relationship and get them to do something, and you are smaller and less consequential than they are?
We can block Hooli, but now OUR customers are livid, and Hooli doesn't really care.
It's more subtle than that. The signature from Hooli is a signal you can stir into your spam filters. If the call comes from them and the calling number isn't one you'd expect them to host, that's a pretty strong signal your customer won't be happy to get the call.
In my case, we use different termination carriers than our origination carriers in many situations. If we are authorized to use a DID for CallerID, but it is not from the termination carrier, how does the termination carrier know to set the attestation to full? Will I be forced to use my origination carrier as my termination carrier to ensure that my calls are not dropped or sent straight to Voicemail? This would break the competitive termination market. How do _I_ or my origination carrier publish that _I_ am authorized to use a DID for termination so that the termination carrier can set attestion to Full? There is nothing in STIR/SHAKEN to help me identify my calls as Full Attestion if the Calling DID is not with the Terminating Carrier. Anything less than Full Attestation will likely start to break call completion. Now I have a new problem -- what carriers are blocking or dropping my calls and why?!? There's no header for that. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
If you want to keep up to date on this, join the ATIS IP NNI and SIP Forum mailing lists. You'll see frequent notifications as the policy and protocol documents get updated. On Tue, Dec 17, 2019 at 3:49 PM Peter Beckman <beckman at angryox.com> wrote:
In my case, we use different termination carriers than our origination carriers in many situations. If we are authorized to use a DID for CallerID, but it is not from the termination carrier, how does the termination carrier know to set the attestation to full?
This one of the things being worked out. There are frameworks for certificate delegation and TN authorization, but I can't speak to the details.
On Tue, 17 Dec 2019, Calvin Ellison wrote:
If you want to keep up to date on this, join the ATIS IP NNI and SIP Forum mailing lists. You'll see frequent notifications as the policy and protocol documents get updated.
On Tue, Dec 17, 2019 at 3:49 PM Peter Beckman <beckman at angryox.com> wrote:
In my case, we use different termination carriers than our origination carriers in many situations. If we are authorized to use a DID for CallerID, but it is not from the termination carrier, how does the termination carrier know to set the attestation to full?
This one of the things being worked out. There are frameworks for certificate delegation and TN authorization, but I can't speak to the details.
Awesome to hear Calvin. I was under the impression that the STIR/SHAKEN standard had been ratified by the participating carriers and they were moving forward. I have not seen anything about cert delecation and TN authorization in the technical specs. Is STIR/SHAKEN not really completed and ready for deployment yet? The FCC and larger carriers seem to be moving forward with test implementations without of TN authorization and delegation. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
On Dec 19, 2019, at 12:09 AM, Peter Beckman <beckman at angryox.com> wrote:
Is STIR/SHAKEN not really completed and ready for deployment yet? The FCC and larger carriers seem to be moving forward with test implementations without of TN authorization and delegation.
Oh, thank goodness. I was worried for a second that we were being given a legal mandate to use a finished protocol specification. It's good to see that we're so worried about acting that the lack of completed standards is no obstacle. /s
An HTML attachment was scrubbed... URL: <https://puck.nether.net/pipermail/voiceops/attachments/20191219/868be1c0/att...>
My impression is that it will eventually allow for very efficient traceback, since the info will be carried in the call. It will effectively have a complete trace embedded. What happens with that info is another matter entirely. We can presume that it will be used to good effect, but that may be optimistic. Traceback info is being generated now. Rarely does it result in anything tangible. Michael Graves mgraves at mstvp.com<mailto:mgraves at mstvp.com> o: (713) 861-4005 c: (713) 201-1262 sip:mgraves at mjg.onsip.com From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Glen Gerhard Sent: Thursday, December 19, 2019 11:59 AM To: voiceops at voiceops.org Subject: Re: [VoiceOps] STIR/SHAKEN Discussion: Will it help? Peter, the initial rollout of S/S does not include delegated certificates. It's being rushed so at least basic call blocking/tracing can be done by tier one carriers. It is usable in the limited design but doesn't cover all use cases. Using the public CA is still the work in progress from my understanding. Delegated certs is a much more complex call flow and has potential holes in the vetting process of the call flow chain. It has to allow for a customer to pass the call through several App/CPAAS providers before hitting the telco operators so the number of companies that need to be properly vetted for ownership and right to use information is MUCH larger. I think eventually it will be effective in cutting down the number of rogue callers and catching the ones that are egregious offenders. ~Glen On 12/18/2019 21:09, Peter Beckman wrote: On Tue, 17 Dec 2019, Calvin Ellison wrote: If you want to keep up to date on this, join the ATIS IP NNI and SIP Forum mailing lists. You'll see frequent notifications as the policy and protocol documents get updated. On Tue, Dec 17, 2019 at 3:49 PM Peter Beckman <beckman at angryox.com><mailto:beckman at angryox.com> wrote: In my case, we use different termination carriers than our origination carriers in many situations. If we are authorized to use a DID for CallerID, but it is not from the termination carrier, how does the termination carrier know to set the attestation to full? This one of the things being worked out. There are frameworks for certificate delegation and TN authorization, but I can't speak to the details. Awesome to hear Calvin. I was under the impression that the STIR/SHAKEN standard had been ratified by the participating carriers and they were moving forward. I have not seen anything about cert delecation and TN authorization in the technical specs. Is STIR/SHAKEN not really completed and ready for deployment yet? The FCC and larger carriers seem to be moving forward with test implementations without of TN authorization and delegation. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com<mailto:beckman at angryox.com> http://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops -- Glen Gerhard glen at cognexus.net<mailto:glen at cognexus.net> 858.324.4536 Cognexus, LLC 7891 Avenida Kirjah San Diego, CA 92037
AT&T is now using STIR/SHAKEN (incorrectly James Bonded as SHAKEN/STIR in the article) to identify calls with Full Attestation as "Verified" on select Android phones. https://www.engadget.com/2019/12/18/att-call-validation-displays/ Thankfully they note, as this discussion was intended to highlight, "This doesn't guaranteed that someone calling from a real number is above-board, either. It could still be a robocaller, a scammer or a telemarketer." I'm concerned that smaller carriers are going to be hurt by STIR/SHAKEN being implemented by large carriers who own both their numbers and the end users, whereas smaller carriers need to get numbers and termination from different carriers to achieve competitive rates. Beckman On Thu, 19 Dec 2019, mgraves mstvp.com wrote:
My impression is that it will eventually allow for very efficient traceback, since the info will be carried in the call. It will effectively have a complete trace embedded.
What happens with that info is another matter entirely. We can presume that it will be used to good effect, but that may be optimistic. Traceback info is being generated now. Rarely does it result in anything tangible.
Michael Graves mgraves at mstvp.com<mailto:mgraves at mstvp.com> o: (713) 861-4005 c: (713) 201-1262 sip:mgraves at mjg.onsip.com
From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Glen Gerhard Sent: Thursday, December 19, 2019 11:59 AM To: voiceops at voiceops.org Subject: Re: [VoiceOps] STIR/SHAKEN Discussion: Will it help?
Peter,
the initial rollout of S/S does not include delegated certificates. It's being rushed so at least basic call blocking/tracing can be done by tier one carriers. It is usable in the limited design but doesn't cover all use cases. Using the public CA is still the work in progress from my understanding.
Delegated certs is a much more complex call flow and has potential holes in the vetting process of the call flow chain. It has to allow for a customer to pass the call through several App/CPAAS providers before hitting the telco operators so the number of companies that need to be properly vetted for ownership and right to use information is MUCH larger.
I think eventually it will be effective in cutting down the number of rogue callers and catching the ones that are egregious offenders.
~Glen
On 12/18/2019 21:09, Peter Beckman wrote: On Tue, 17 Dec 2019, Calvin Ellison wrote:
If you want to keep up to date on this, join the ATIS IP NNI and SIP Forum mailing lists. You'll see frequent notifications as the policy and protocol documents get updated.
On Tue, Dec 17, 2019 at 3:49 PM Peter Beckman <beckman at angryox.com><mailto:beckman at angryox.com> wrote:
In my case, we use different termination carriers than our origination carriers in many situations. If we are authorized to use a DID for CallerID, but it is not from the termination carrier, how does the termination carrier know to set the attestation to full?
This one of the things being worked out. There are frameworks for certificate delegation and TN authorization, but I can't speak to the details.
Awesome to hear Calvin. I was under the impression that the STIR/SHAKEN standard had been ratified by the participating carriers and they were moving forward. I have not seen anything about cert delecation and TN authorization in the technical specs.
Is STIR/SHAKEN not really completed and ready for deployment yet? The FCC and larger carriers seem to be moving forward with test implementations without of TN authorization and delegation.
Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com<mailto:beckman at angryox.com> http://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
--
Glen Gerhard
glen at cognexus.net<mailto:glen at cognexus.net>
858.324.4536
Cognexus, LLC
7891 Avenida Kirjah
San Diego, CA 92037
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
I do not think the fact that S/S poses the problem you raise is an accident. Nor do I think that the lopsided consequences of most other solutions enthusiastically supported by incumbents and large industry actors are an accident. Think CALEA. ? Sent from mobile, with due apologies for brevity and errors.
On Dec 19, 2019, at 2:13 PM, Peter Beckman <beckman at angryox.com> wrote:
?AT&T is now using STIR/SHAKEN (incorrectly James Bonded as SHAKEN/STIR in the article) to identify calls with Full Attestation as "Verified" on select Android phones.
https://www.engadget.com/2019/12/18/att-call-validation-displays/
Thankfully they note, as this discussion was intended to highlight, "This doesn't guaranteed that someone calling from a real number is above-board, either. It could still be a robocaller, a scammer or a telemarketer."
I'm concerned that smaller carriers are going to be hurt by STIR/SHAKEN being implemented by large carriers who own both their numbers and the end users, whereas smaller carriers need to get numbers and termination from different carriers to achieve competitive rates.
Beckman
On Thu, 19 Dec 2019, mgraves mstvp.com wrote:
My impression is that it will eventually allow for very efficient traceback, since the info will be carried in the call. It will effectively have a complete trace embedded.
What happens with that info is another matter entirely. We can presume that it will be used to good effect, but that may be optimistic. Traceback info is being generated now. Rarely does it result in anything tangible.
Michael Graves mgraves at mstvp.com<mailto:mgraves at mstvp.com> o: (713) 861-4005 c: (713) 201-1262 sip:mgraves at mjg.onsip.com
From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Glen Gerhard Sent: Thursday, December 19, 2019 11:59 AM To: voiceops at voiceops.org Subject: Re: [VoiceOps] STIR/SHAKEN Discussion: Will it help?
Peter,
the initial rollout of S/S does not include delegated certificates. It's being rushed so at least basic call blocking/tracing can be done by tier one carriers. It is usable in the limited design but doesn't cover all use cases. Using the public CA is still the work in progress from my understanding.
Delegated certs is a much more complex call flow and has potential holes in the vetting process of the call flow chain. It has to allow for a customer to pass the call through several App/CPAAS providers before hitting the telco operators so the number of companies that need to be properly vetted for ownership and right to use information is MUCH larger.
I think eventually it will be effective in cutting down the number of rogue callers and catching the ones that are egregious offenders.
~Glen
On 12/18/2019 21:09, Peter Beckman wrote: On Tue, 17 Dec 2019, Calvin Ellison wrote:
If you want to keep up to date on this, join the ATIS IP NNI and SIP Forum mailing lists. You'll see frequent notifications as the policy and protocol documents get updated.
On Tue, Dec 17, 2019 at 3:49 PM Peter Beckman <beckman at angryox.com><mailto:beckman at angryox.com> wrote:
In my case, we use different termination carriers than our origination carriers in many situations. If we are authorized to use a DID for CallerID, but it is not from the termination carrier, how does the termination carrier know to set the attestation to full?
This one of the things being worked out. There are frameworks for certificate delegation and TN authorization, but I can't speak to the details.
Awesome to hear Calvin. I was under the impression that the STIR/SHAKEN standard had been ratified by the participating carriers and they were moving forward. I have not seen anything about cert delecation and TN authorization in the technical specs.
Is STIR/SHAKEN not really completed and ready for deployment yet? The FCC and larger carriers seem to be moving forward with test implementations without of TN authorization and delegation.
Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com<mailto:beckman at angryox.com> http://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
--
Glen Gerhard
glen at cognexus.net<mailto:glen at cognexus.net>
858.324.4536
Cognexus, LLC
7891 Avenida Kirjah
San Diego, CA 92037
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
An HTML attachment was scrubbed... URL: <https://puck.nether.net/pipermail/voiceops/attachments/20191219/0b32af3e/att...>
participants (12)
-
abalashov＠evaristesys.com -
beckman＠angryox.com -
calvin.ellison＠voxox.com -
dovid＠telecurve.com -
glen＠cognexus.net -
johnl＠taugh.com -
lindsey＠e-c-group.com -
marylou＠backuptelecom.com -
mgraves＠mstvp.com -
mike＠astrocompanies.com -
paul＠timmins.net -
peeip989＠gmail.com