[VoiceOps] Voice Peering

Wed Oct 25 19:10:45 EDT 2023

On Wed, 25 Oct 2023, Mike Johnston via VoiceOps wrote:
> Anyways, say your system is getting a call from 555-555-1234.  So you do a 
> DNS query against...I do not know.
>
>  dig TXT 4.3.2.1.5.5.5.5.5.5.i-do-not-know.....

  How do you take an incoming call, from an IP you do not know, turn that IP
  and/or phone number into a Domain Name, and then query it?

  If you get a domain name, you now automatically trust that the incoming call is
  worthy of your trust, because I can set up "allyourbase.com" and send a
  call to you and you check my SPF record and I say "totally ip4:0.0.0.0/24"
  (the entire internet) and you go "Cool! I'll take the call!"

  Yet what entity is actually sending you the call?

  SPF works because what you are sending (email) is also part of the domain
  name. And even if you added a SIP header with a domain, all you are doing
  is looking up a SPF/TXT record for the domain the call says they are
  coming from, but now you have to implement DKIM-signing so someone cannot
  pretend to be calling from a different domain. Then YOU the call receiver
  have to decide if you trust the entity that is sending the call!!! And you
  still haven't solved the problem of how the caller found out your Endpoint
  in the first place to make the SIP call.

There are DNS SRV records, which tell you HOW to access a certain service
given a domain name.

e.g.

 	--> dig srv _sip._udp.srv.lcr.thinq.com

 	; <<>> DiG 9.10.6 <<>> srv _sip._udp.srv.lcr.thinq.com
 	;; global options: +cmd
 	;; Got answer:
 	;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27421
 	;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

 	;; OPT PSEUDOSECTION:
 	; EDNS: version: 0, flags:; udp: 512
 	;; QUESTION SECTION:
 	;_sip._udp.srv.lcr.thinq.com.    IN    SRV

 	;; ANSWER SECTION:
 	_sip._udp.srv.lcr.thinq.com. 20384 IN    SRV    100 50 5060 lcr-lb02.rdu.thinq.com.
 	_sip._udp.srv.lcr.thinq.com. 20384 IN    SRV    200 50 5060 lcr-lb02.dfw.thinq.com.
 	_sip._udp.srv.lcr.thinq.com. 20384 IN    SRV    200 50 5060 lcr-lb01.dfw.thinq.com.
 	_sip._udp.srv.lcr.thinq.com. 20384 IN    SRV    100 50 5060 lcr-lb01.rdu.thinq.com.

 	;; Query time: 5 msec
 	;; SERVER: 192.168.0.1#53(192.168.0.1)
 	;; WHEN: Wed Oct 25 18:47:53 EDT 2023
 	;; MSG SIZE  rcvd: 224

That's great, so I know where to send a call, if I know that Thinq is the
endpoint of record for a phone numbe . But how do I take +1 202 456 1111
and authoritatively know what endpoint/domain/entity to reach out to? And
how does that endpoint know to trust me?

Due to Number Porting and a lack of any way for any leasee of a number to
publish such information with the blessing of NANPA ($govt-entity) and the
assigned Tier 0 carrier, or have any fallback if your endpoint is offline or
unavailable, there's no hierarchy to implement.

I suppose something like this could work:

 	NANPA (root) gets request for 12024561111, tells you to check with IQ at a
 		certain hostname

     IQ (delegate) gets request for 12024561111, tells you to check with
         FrogTele at a certain hostname

     FrogTele gives you a response that confirms that one can call them and
         reach the endpoint

     A SRV query is made to determine what host(s) within FrogTele can
         handle a UDP SIP call

     You place the call

If it fails, maybe you can go to IQ as a backup and call through them.

If FrogTele says "no I do not service that number," then what do you do, go
back to IQ?

For ANY of this to work, NANPA and Tier 0 carriers who get numbers directly
from NANPA (NANPA only knows about its direct customers, not resellers, or
Tier 1+ carriers) would have to build it and participate.

Even if they did, currently all this is implemented either through security
through obscurity (which this model breaks) or IP firewalls & whitelists.
Most of the authentication stuff is weak or static, which is another
security risk.

Now that all the Internet knows what carrier is handling a specific phone
number, which potentially discloses PII, which an attacker could then use
to target the website and web account of the target with a re-used password
from another hack, and your customer loses their account (granted because
of their bad security practices) because you wanted to save a few tenths of
a cent per minute.

TRUST is the problem. MONEY is the problem.

NANPA has no financial nor governmental incentive to do this.

Tier 0 carriers have a negative financial incentive to do this.

Without NANPA and Tier 0 carriers involvement, anyone can self-publish a
record somewhere saying "Call me here!" and nobody will know if that can be
trusted, because the trust chain is non-existent without NANPA and Tier 0
carriers involvement.

Like Alex said, Technically this is achievable.

Politically and Financially this is Dead on Arrival, at least until the
incentives change.

On Wed, 25 Oct 2023, Mike Johnston via VoiceOps wrote:

> Who can source email from a domain is more-or-less a solved problem by using 
> DNS SPF records.
>
> An SPF record is a list of IP addresses[1] that is allowed to send email for 
> a domain.  When an email server receives an email, best practice is to do a 
> DNS lookup for the SPF of the alleged sender domain.  If the server 
> attempting to send the email is not mentioned in the SPF, then you can reject 
> the incoming email.
>
> Does anybody know if something like SPF has been adapted to voice?
>
> For example, say anything from 54.239.16.0/24 is allowed as that is where 
> your phone switches are.  And 20.112.88.88/29 can also make calls, as that is 
> one of those School Auto-Dialer services[2].  (Or whatever, make up your own 
> scenarios.)
>
> When you receive calls, you would need to do a DNS lookup to get the list of 
> allowed senders.  If it's not in the list, reject the call.
>
> The exact query, and who we are querying, is a good question, though. Who 
> owns the phone number?
>
> Anyways, say your system is getting a call from 555-555-1234.  So you do a 
> DNS query against...I do not know.
>
>  dig TXT 4.3.2.1.5.5.5.5.5.5.i-do-not-know.....

  How do you take an incoming call, from an IP you do not know, turn that IP
  and/or phone number into a Domain Name, and then query it?

  If you get that, you now automatically trust that the incoming call is
  worthy of your trust, because I can set up "allyourbase.com" and send a
  call to you and you check my SPF record and I say "totally ip4:0.0.0.0/24"
  (the entire internet) and you go "Cool! I'll take the call!"

  Yet what entity is actually sending you the call?

> And say you got this back from the DNS query:
>
>  "v=spf1 ip4:54.239.16.0/24 ip4:20.112.88.88/29 -all"
>
> If the server sending you the call is not in 54.239.16.0/24 or 
> 20.112.88.88/29, then reject the call.
>
> [1] An SPF record can have more than just IP addresses, but can also 
> "include" other domain names.
> [2] You might do your DNS in such a way, that 20.112.88.88/29 is only 
> returned for the specific number(s) that you expect them to be sending from, 
> not ALL of your numbers.
>
> Further reading:
> https://en.wikipedia.org/wiki/Sender_Policy_Framework
> https://www.cloudflare.com/learning/dns/dns-records/dns-spf-record/
> https://support.google.com/a/answer/10685031?hl=en

---------------------------------------------------------------------------
Peter Beckman                                                  Internet Guy
beckman at angryox.com                                https://www.angryox.com/
---------------------------------------------------------------------------