Re: [Modern] Nationwide Number Portability MODERN Use Case Draft

["Gorman, Pierce A [CTO]" <[e-mail]>]

I’m guilty of writing something I myself don’t like to receive- a very long e-mail.  For those with little patience for such things, TLDR won’t hurt my feelings.



“The key feature of phone numbers is that there is a broadly interoperable infrastructure for communicating between things identified by those numbers.” – P. Kyzivat



First, I’ll simply agree, but emphasize the key word is “communicating” and that there is a fairly limited set of applications establishing communication using only a telephone number as an address.



For the most part communication established using a telephone number is voice calls and text messages (occasinally accompanied by small pictures).



3GPP and GSMA specifications envision the possibility of more, but do not encompass (yet) communications such as tweets, social networking IM, commercial website chat, and e-mail to name a few.



In the past I’ve advocated that telephone numbers and (private) ENUM could dramatically help improve communications application reachability.  And really it isn’t ENUM per se that offers such an opportunity so much as NAPTR, SRV, and A/AAAA DNS resource records.  And in that regard, a good old-fashioned domain name will work even better than a telephone number.  And in fact could be used to discover telephone numbers in TEL/SIP URIs.  What I like about NAPTR in particular is the ability to use a domain name to discover multiple addresses and applications of interest for a given domain or host with whom I would like to communicate in one or more ways.



The main MODERN problems we’re going to keep coming back to are security and scarcity.



With regard to security, very few of my children’s generation have their telephone number listed in a phone book and if you suggested they needed to list their number they would most likely be annoyed or appalled (or ask, “what is a phone book?”).  THEY want to control who is able to communicate with them, and one of the prime ways they do that, whether they know it or not, is through obscurity.  Robo-dialers and worse are invading their privacy and destroying their ability to remain anonymous and obscure yet available.



When I read about user agent assignments in MODERN, I immediately think of Public ENUM (which failed and which Richard Shockey reminds us from time time is “dead”).  I think the main problem was fear of SPIT (SPAM over Internet Telephony).



So to me the key problems remaining to be solved in user agent assignments of reachability information are:



1)      auditing and recovery   [the scarcity problem]

2)      securely controlling access to the reachability information   [the security problem]



I will paraphrase the suggestion made by Henning on the call today as, “MODERN should acknowledge aportionment from a limited address space can act as a form of containment for damage from abuse of that space.”

It’s a pretty crude form of containment, but it does somewhat address the problems at #1, but we can do better I think.



As acknowledged by 3GPP IMS technical specifications, single user assignments should include the concept of public addresses (best for applications with SPAM filters), and private addresses for those entities or applications permitted more secure access.



I suggest that public addresses should be nearly infinite with little restriction on their syntax such as are invidual domain names of the .name top-level domain.



Private addresses should be discoverable from the public addresses insofar as the discoverer has one or more key(s) permitting them access to that information.  (This is similar to the idea that bad actors whom wish to use confidence to commit fraud and theft use a telephone number to place a call to someone and then using social engineering and pschological manipulation as a password, retrieve more valuable information such as credit card numbers.)



Discovery could be conducted using something like a NAPTR + OPT RR DNS query using (MODERN?) application-specific logic and where the key(s) in the query were supplied in the OPT RR ala something like “draft-kaplan-dnsext-enum-sip-source-ref-opt-code-00” but without the ENUM reverse decimal dot notation and instead using the public individual domain name.  (Clearly, this isn’t something you could do using your father’s DNS.)



A key to one or more of the private addresses could be something as simple as a 10-digit telephone number but really should be simply a password (and of course potentially very long ugly passwords incorporating prime numbers could be used too depending upon who is asking and what application they’re asking for/from).  One or more subsets of private addresses could be reachable via one or more passwords.



Some of the discoverable private “address” information could be a personal telephone number and a STIR public key certificate and the address of the certificate authority, for example.



Other kinds of discoverable private address information could include URIs for Twitter, Facebook, e-mail, et cetera.



I believe what I’ve described could be part of a MODERN solution framework, but would not necessarily include primary assignment of an individual’s private telephone number (although it wouldn’t prevent it either).  The logic offered today for porting could even be expanded to broker commercial service registration transactions with providers such as CSPs and social networks.



There would necessarily be the usual domain name and password security issues, but domain names are not going away and they don’t suffer from being a finite address space heavily integrated into legacy PSTN databases (yet).





________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.