<div dir="ltr">Well, in any kind of fully-distributed scenario some type of security mechanism that might not look all that dissimilar from STIR/SHAKEN would be implied.<div><br></div><div>What I've heard so far is many different potential implementations at just about every level of the business stack that exists today, so I'd say that question is still unresolved.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 25, 2023 at 5:08 PM Peter Beckman <<a href="mailto:beckman@angryox.com">beckman@angryox.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This whole conversation, and topic, is "Voice Peering" -- ORIGINATING CALLS<br>
directly to the endpoint rather than me passing to Level3 who passes to IQ<br>
who passes to their customer who passes to their customer who has a VoIP<br>
device that I could reach directly if I only had the ability to do so.<br>
<br>
This has nothing to do with rejecting incoming calls signed with<br>
STIR/SHAKEN.<br>
<br>
The call cannot start until I know where to send the call. <-- problem that we are discussing<br>
<br>
Beckman<br>
<br>
On Wed, 25 Oct 2023, Matthew Crocker wrote:<br>
<br>
><br>
> I never said STIR/SHAKEN would be used to ‘look up’ for call routing.<br>
><br>
> Earlier someone mentioned an issue with open peering is spam calls.  STIR/SHAKEN can solve that issue.<br>
><br>
> You can certainly use STIR/SHAKEN to reject calls from $COMPANY once you have determined you don’t like $COMPANY.  That can easily be done off line by CDR analysis.  Sure you let a couple dozen calls in but you can pretty quickly find ‘$BAD_COMPANY’ and start rejecting their calls.   The system would settle our fairly quickly<br>
><br>
> From: Peter Beckman <<a href="mailto:beckman@angryox.com" target="_blank">beckman@angryox.com</a>><br>
> Date: Wednesday, October 25, 2023 at 12:04 PM<br>
> To: Matthew Crocker <<a href="mailto:matthew@corp.crocker.com" target="_blank">matthew@corp.crocker.com</a>><br>
> Cc: Pinchas Neiman <<a href="mailto:neimanpinchas@gmail.com" target="_blank">neimanpinchas@gmail.com</a>>, Jawaid Bazyar <<a href="mailto:jawaid@bazyar.net" target="_blank">jawaid@bazyar.net</a>>, voiceops <<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a>><br>
> Subject: Re: [VoiceOps] Voice Peering<br>
> CAUTION: This email originated from outside of Crocker. Do not click links or open attachments unless you recognize the sender and know the content is safe.<br>
><br>
><br>
> STIR/SHAKEN does not delegate any authority to anyone.<br>
><br>
> It merely allows me to sign a call that I originate, so that someone else<br>
> can say "Oh this came from $COMPANY."<br>
><br>
> Besides, STIR/SHAKEN is done at the time of an origination call, it cannot<br>
> be "looked up" to see where to route a call.<br>
><br>
> The suggestion that STIR/SHAKEN could be used to authoritatively assign a<br>
> DID endpoint to someone demonstrates a lack of understanding in how it<br>
> works and what it does and does not do.<br>
><br>
> Beckman<br>
><br>
> On Wed, 25 Oct 2023, Matthew Crocker via VoiceOps wrote:<br>
><br>
>><br>
>> With STIR/SHAKEN (in theory) all calls will be signed, authenticated so you can trace the originating carrier.  In an open peering environment you can use it to accept/reject calls<br>
>><br>
>> Open SIP proxy handles all of the SIP traffic,  RTP goes directly between carriers.<br>
>> All calls originated must be signed (STIRred)<br>
>><br>
>>  *   Call isn’t signed, gets rejected by the SIP peering proxy<br>
>> Terminating carrier can validate the signed calls (SHAKEN)<br>
>><br>
>>  *   Don’t like the signing CA?  reject the call<br>
>>  *   Don’t like the signing carrier? Reject the call<br>
>>  *   Carrier sending too many spam calls,  adjust treatment based on customer spam settings<br>
>><br>
>><br>
>> Routing is handled between terminating carrier and SIP peering proxy.  Originating carrier sends all calls to peering proxy first, if proxy doesn’t have the route it sends a 4XX error back and originating carrier can continue routing on other paths.<br>
>><br>
>> So terminating carriers would need to export/upload (hacked BGP?) numbers they are willing to receive calls on to the peering proxy.<br>
>><br>
>> Proxies can be spun up in various AWS/Azure/GoogleCloud VPS<br>
>><br>
>><br>
>> From: Pinchas Neiman <<a href="mailto:neimanpinchas@gmail.com" target="_blank">neimanpinchas@gmail.com</a>><br>
>> Date: Wednesday, October 25, 2023 at 11:18 AM<br>
>> To: Jawaid Bazyar <<a href="mailto:jawaid@bazyar.net" target="_blank">jawaid@bazyar.net</a>><br>
>> Cc: Matthew Crocker <<a href="mailto:matthew@corp.crocker.com" target="_blank">matthew@corp.crocker.com</a>>, voiceops <<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a>><br>
>> Subject: Re: [VoiceOps] Voice Peering<br>
>> CAUTION: This email originated from outside of Crocker. Do not click links or open attachments unless you recognize the sender and know the content is safe.<br>
>><br>
>> By reading the RFCs I was able to grasp 75% of it, it's well written and covers your clear constraint, at least on how to verify the SIP header comes from a trustworthy authority (If you agree on the root authority)<br>
>> Practically implementing STIR/SHAKEN has bureaucracy involved.<br>
>><br>
>> On Tue, Oct 24, 2023 at 9:38 PM Jawaid Bazyar via VoiceOps <<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a><mailto:<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a>>> wrote:<br>
>> Is there a good clear document somewhere describing how STIR/SHAKEN is supposed to work?<br>
>><br>
>> On Tue, Oct 24, 2023 at 9:33 PM Matthew Crocker via VoiceOps <<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a><mailto:<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a>>> wrote:<br>
>><br>
>><br>
>>> On Oct 24, 2023, at 9:13 PM, Peter Beckman via VoiceOps <<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a><mailto:<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a>>> wrote:<br>
>>><br>
>>> CAUTION: This email originated from outside of Crocker. Do not click links or open attachments unless you recognize the sender and know the content is safe.<br>
>>><br>
>>><br>
>>> The challenge is how do you authenticate the end "carrier" or service<br>
>>> provider?<br>
>>><br>
>><br>
>> STIR/SHAKEN<br>
>><br>
>><br>
>>> Sure, anyone who leases numbers directly from NANPA can look up the carrier<br>
>>> of record and exchange traffic directly, but any business who also leases<br>
>>> numbers INDIRECTLY gets cut out and still needs to pay their upstream<br>
>>> carrier(s) to place/receive calls, either by channels or per minute, even<br>
>>> if their upstream is directly peered and not transiting the PSTN at all.<br>
>>><br>
>>> If this would be for the end user, then NANPA would have to delegate to the<br>
>>> leasee, the leasee delegate to the reseller, the reseller to the end user,<br>
>>> then the end user could publish their VoIP contact info, and anyone could<br>
>>> call directly via VoIP, cutting out all of the middle peers.<br>
>>><br>
>>> But, as another person said, this is ripe for abuse, and with no motivation<br>
>>> by NANPA or the larger carriers to make calls less expensive for the<br>
>>> reseller or end user, I see this going nowhere. Until there is some value<br>
>>> in NANPA (plus all the other country telephony organizations) and the<br>
>>> direct carriers leasing numbers to do so.<br>
>>><br>
>>> Beckman<br>
>>><br>
>>>> On Tue, 24 Oct 2023, Ross Tajvar via VoiceOps wrote:<br>
>>>><br>
>>>> I can think of a few ways that could be adapted into a platform more like<br>
>>>> an Internet exchange, but as others have said, it just doesn't seem worth<br>
>>>> it.<br>
>>>><br>
>>>> On Tue, Oct 24, 2023, 5:31 PM Jawaid Bazyar via VoiceOps <<br>
>>>> <a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a><mailto:<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a>>> wrote:<br>
>>>><br>
>>>>> I think schemes like DUNDI (and some of the others mentioned here) suffer<br>
>>>>> from a trust issue – what’s to prevent operator X from poisoning the<br>
>>>>> protocol with bogus “stolen” numbers?<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> On Tue, Oct 24, 2023 at 5:25 PM Jared Smith via VoiceOps <<br>
>>>>> <a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a><mailto:<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a>>> wrote:<br>
>>>>><br>
>>>>>> On Tue, Oct 24, 2023 at 8:49 AM Mike Hammett via VoiceOps <<br>
>>>>>> <a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a><mailto:<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a>>> wrote:<br>
>>>>>><br>
>>>>>>> This was in another thread, but I broke it out into it's own<br>
>>>>>>> conversation. Someone had asked:<br>
>>>>>>><br>
>>>>>>> ---<br>
>>>>>>> I am joining this thread late, but, would anyone out there be interested<br>
>>>>>>> in exchanging traffic with other carriers directly over SIP?<br>
>>>>>>><br>
>>>>>><br>
>>>>>> Just another point of VoIP history trivia at this point... but in<br>
>>>>>> addition to things like ENUM and ITAD, Mark Spencer of Asterisk fame also<br>
>>>>>> invented Dundi, which was an encrypted peer-to-peer protocol for route<br>
>>>>>> advertisement and discovery.  As far as I know, very few people besides me<br>
>>>>>> ever put it in production, but it worked really well at the time. (Of<br>
>>>>>> course, it's been about 17 or 18 years now since I used it in production.)<br>
>>>>>><br>
>>>>>> -Jared<br>
>>>>>> _______________________________________________<br>
>>>>>> VoiceOps mailing list<br>
>>>>>> <a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><mailto:<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a>><br>
>>>>>> <a href="https://puck.nether.net/mailman/listinfo/voiceops" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
>>>>>><br>
>>>>> _______________________________________________<br>
>>>>> VoiceOps mailing list<br>
>>>>> <a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><mailto:<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a>><br>
>>>>> <a href="https://puck.nether.net/mailman/listinfo/voiceops" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
>>>>><br>
>>>><br>
>>><br>
>>> ---------------------------------------------------------------------------<br>
>>> Peter Beckman                                                  Internet Guy<br>
>>> <a href="mailto:beckman@angryox.com" target="_blank">beckman@angryox.com</a><mailto:<a href="mailto:beckman@angryox.com" target="_blank">beckman@angryox.com</a>>                                <a href="https://www.angryox.com/" rel="noreferrer" target="_blank">https://www.angryox.com/</a><br>
>>> ---------------------------------------------------------------------------<br>
>>> _______________________________________________<br>
>>> VoiceOps mailing list<br>
>>> <a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><mailto:<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a>><br>
>>> <a href="https://puck.nether.net/mailman/listinfo/voiceops" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
>>> _______________________________________________<br>
>>> VoiceOps mailing list<br>
>>> <a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><mailto:<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a>><br>
>>> <a href="https://puck.nether.net/mailman/listinfo/voiceops" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
>> _______________________________________________<br>
>> VoiceOps mailing list<br>
>> <a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><mailto:<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a>><br>
>> <a href="https://puck.nether.net/mailman/listinfo/voiceops" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
>> _______________________________________________<br>
>> VoiceOps mailing list<br>
>> <a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><mailto:<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a>><br>
>> <a href="https://puck.nether.net/mailman/listinfo/voiceops" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
>><br>
>><br>
>> --<br>
>> Pinchas S. Neiman<br>
>> Software Engineer At ESEQ Technology Corp.<br>
>> 845.213.1229 #2<br>
>> [Image removed by sender.]<br>
>><br>
><br>
> ---------------------------------------------------------------------------<br>
> Peter Beckman                                                  Internet Guy<br>
> <a href="mailto:beckman@angryox.com" target="_blank">beckman@angryox.com</a>                                <a href="https://www.angryox.com/" rel="noreferrer" target="_blank">https://www.angryox.com/</a><br>
> ---------------------------------------------------------------------------<br>
><br>
<br>
---------------------------------------------------------------------------<br>
Peter Beckman                                                  Internet Guy<br>
<a href="mailto:beckman@angryox.com" target="_blank">beckman@angryox.com</a>                                <a href="https://www.angryox.com/" rel="noreferrer" target="_blank">https://www.angryox.com/</a><br>
---------------------------------------------------------------------------</blockquote></div>