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
beck...@angryox.com https://www.angryox.com/
---------------------------------------------------------------------------
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
