Home / Blogs

Moving Beyond Telephone Numbers - The Need for a Secure, Ubiquitous Application-Layer Identifier

Do “smart” parking meters really need phone numbers? Does every “smart meter” installed by electric utilities need a telephone number? Does every new car with a built-in navigation system need a phone number? Does every Amazon Kindle (and similar e-readers) really need its own phone number?

In the absence of an alternative identifier, the answer seems to be a resounding “yes” to all of the above.

Henning Schulzrinne, U.S. Federal Communications Commission CTOAt the recent SIPNOC 2013 event, U.S. Federal Communications Commission CTO Henning Schulzrinne gave a presentation (slides available) about “Transitioning the PSTN to IP” where he made a point about the changes around telephone numbers and their uses (starting on slide 14) and specifically spoke about this use of phone numbers for devices (slide 20). While his perspective is obviously oriented to North America and country code +1, the trends he identifies point to a common problem:

What do we use as an application-layer identifier for Internet-connected devices?

In a subsequent conversation, Henning indicated that one of the area codes seeing the largest amount of requests for new phone numbers is one in Detroit—because of the automakers need to provision new cars with navigation systems such as OnStar that need an identifier.

Why Not IPv6 Addresses?

Naturally, doing the work I do promoting IPv6 deployment, my first reaction was of course:

“Can’t we just give all those devices IPv6 addresses and be done with it?”

The answer turns out to be a bit more complex. Yes, we can give all those devices IPv6 addresses (and almost certainly will as we are simply running out of IPv4 addresses), but:

1. Vendors Don’t Want To Be Locked In To Infrastructure – Say you are a utility and you deploy 1,000 smart meters in homes in a city that all connect back to a central server to provide their information. They can connect over the Internet using mobile 3G/4G networks and in this case they could use an IPv6 address or any other identifier. They don’t need to use a telephone number when they squirt their data back to the server. However, the use of IP addresses as identifiers then ties the devices to a specific Internet Service Provider. Should the utility wish to change to a different provider of mobile Internet connectivity, they would now have to reconfigure all their systems with the new IPv6 addresses of the devices. Yes, they could obtain their own block of “Provider Independent (PI)” IPv6 addresses, but now they add the issue of having to have their ISP route their PI address block across that provider’s network.

2. Some Areas Don’t Have Internet Connectivity – In some places where smart meters are being deployed, or where cars travel, there simply isn’t any 3G/4G Internet connectivity and so the devices have to connect back to their servers using traditional “2G” telephone connections. They need a phone number because they literally have to “phone home”.

While we might argue that #2 is a transitory condition while Internet access continues to expand, the first issue of separating the device/application identifier from the underlying infrastructure is admittedly a solid concern.

Telephone Numbers Work Well

The challenge for any new identifier is that telephone numbers work rather well. They are:

  • easily understood – people in general are very comfortable with and used to phone numbers (assuming they have access to phone networks)
  • ubiquitous – phone numbers are everywhere and are available globally
  • well defined – they have a fixed format that is well known and standardized
  • easy to provision – they can be entered and configured very easily, including via keypads, speech recognition and more

For all these reasons, it is understandable that device vendors have chosen phone numbers as identifiers.

The Billing / Provisioning Conundrum

The last bullet above points to a larger issue that will be a challenge for any new identifier. Utilities, telcos and other industries have billing and provisioning systems that in some cases are decades old. They may have been initially written 20 or 30 (or more) years ago and then simply added on to in the subsequent years. These systems work with telephone numbers because that’s what they know.

Changing them to use new identifiers may be difficult or in some cases near impossible.

So Why Change?

So if telephone numbers work so well and legacy systems are so tied to those numbers, why consider changing?

Several reasons come to mind:

1. Security – There really is none with telephone numbers. As Henning noted in his presentation and I’ve written about on the VOIPSA blog in the past, “Caller ID” is easily spoofable. In fact, there are many services you can find through a simple search that will let you easily do this for a small fee. If you operate your own IP-PBX you can easily configure your “Caller ID” to be whatever you want and some VoIP service providers may let you send that Caller ID on through to the recipient.

2. OTT mobile apps moving to desktop (and vice versa) – Many of the “over the top (OTT)” apps that have sprung up in the iOS and Android devices for voice, video or chat communication started out using the mobile devices phone number as an identifier. It’s a simple and easy solution as the device has the number already. We’re seeing some of those apps, though, such as Viber, now move from the mobile space to the desktop. Does the phone number really make sense there? Similarly, Skype made the jump from desktop to mobile several years ago and used its own “Skype ID” identifier—no need for a phone number there.

3. WebRTCAs I’ve written before, I see WebRTC as a fundamental disruption to telecommunications on so many different levels. It is incredibly powerful to have browser-based communication via voice, video or chat… in any web browser… on any platform including ultimately mobile devices. But for WebRTC to work, you do need to have some way to identify the person you are calling. “Identity” is a key component here—and right now many of the WebRTC systems being developed are all individual silos of communication (which in many cases may in fact be fine for their specific use case). WebRTC doesn’t need phone numbers—but some kind of widely-accepted application-layer identifier could be helpful.

4. Global applications – Similarly, this rise of WebRTC and OTT apps has no connection to geography. I can use any of these apps in any country where I can get Internet connectivity (and yes, am not being blocked by the local government). I can also physically move from country to country either temporarily or permanently. Yet if I do so I can’t necessarily take my phone number with me. If I move to the US from the UK, I’ll probably want to get a new mobile device—or at least a new SIM card—and will wind up with a new phone number. Now I have to go back into the apps to change the identifier used by the app to be that of my new phone number.

5. Internet of Things / M2M – As noted in the intro to this post, we’re connecting more and more devices to the Internet. We’ve got “connected homes” where every light switch and electrical circuit is getting a sensor and all appliances are wired into centralized systems. Devices are communicating with other devices and applications. We talk about this as the “Internet of Things (IoT)” or “machine-to-machine (M2M)” communication. And yes, these devices all need IP addresses—and realistically will need to have IPv6 addresses. In some cases that may be all that is needed for provisioning and operation. In other cases a higher-level identifier may be needed.

6. Challenges in obtaining phone numbers – We can’t, yet, just go obtain telephone numbers from a service like we can for domain names. Obtaining phone numbers is a more involved process that, for instance, may be beyond many WebRTC startups (although they can use services that will get them phone numbers). One of the points Henning made in this SIPNOC presentation was the FCC is actually asking for feedback on this topic. Should they open up phone numbers within the US to be more easily obtainable? But even if this were done within the US, how would it work globally?

7. Changes in user behavior – Add to all of this the fact that most of us have stopped remembering phone numbers and instead simply pull them up from contact / address books. We don’t need a phone number any more… we just want to call someone, the underlying identifier is no longer critical.
All of these are reasons why a change to a new application-layer identifier would be helpful.

So What Do We Do?

What about SIP addresses that look like email addresses? What about other OpenID or other URL-based schemes? What about service-specific identifiers? What about using domain names and DNS?

Henning had a chart in his slides that compared these different options (“URL owned” is where you own the domain):

The truth is there is no easy solution.

Telephone numbers are ubiquitous, understood and easy-to-use.

A replacement identifier needs to be all of that… plus secure and portable and able to adapt to new innovations and uses.

Oh… and it has to actually be deployable within our lifetime.

Will there be only one identifier as we have with telephone numbers?

Probably not… but in the absence of one common identifier we’ll see what we are already seeing—many different islands of identity for initiating real-time communications calls:

  • Skype has its own proprietary identity system for calls
  • Apple has its own proprietary identity system for FaceTime calls
  • Google has its own proprietary identity system for Hangouts
  • Facebook has its own proprietary identity system used by some RTC apps
  • Every WebRTC startup seems to be using its own proprietary identity system.
  • A smaller community of people who care about open identifiers are actually using SIP addresses and/or Jabber IDs (for XMPP/Jingle).

And in the meantime, Amazon is still assigning phone numbers to each of its Kindles, the utilities are assigning phone numbers to smart meters and automakers are embedding phone numbers in cars.

How can we move beyond telephone numbers as identifiers? Or are we already doing so but into proprietary walled gardens? Or are we stuck with telephone numbers until they just gradually fade away?

Related Notes:
Some additional pointers are worth mentioning:

• The Internet Society (my employer) has a team focused on the broader subject of online privacy and identity (beyond simply the telephone numbers I mention here) and the links and documents there may be of interest.

• There’s a new Internet Draft out, draft-peterson-secure-origin-ps, that does an excellent job on the problem statement around “secure origin identification” as it relates to VoIP based on the SIP protocol and why there are security issues with what we think of as “Caller ID”.

• Chris Kranky recently argued that telcos are missing the opportunity of leveraging telephone numbers as identifiers in the data world.

By Dan York, Author and Speaker on Internet technologies - and on staff of Internet Society

Dan is the Director, Online Content, for the Internet Society but opinions posted on CircleID are his own. View more of Dan’s writing and audio here.

Visit Page

Filed Under

Comments

ISO//OSI people had thoughts on this Karl Auerbach  –  Jun 4, 2013 6:19 PM

In the old ISO/OSI stuff there was the concept of an “application entity title” (AET).  This was a name that is bound to an instance of an application.  Applications might be any of the things you mentioned in your article - anything from an automobile’s entertainment system to a washing machine to an app on a tablet.

These AET’s would have no topological siginficance - which is a huge difference from IPv6 addresses which are related to the position of the device on an IP network - which makes IPv6 addresses very poor names for things that move about.

A typic AET could look much like a GUID (Globally Unique IDentifier) - http://en.wikipedia.org/wiki/Globally_unique_identifier .

Another form could be domain names where the name is just a name, not an identifier expected to produce an address.

What’s nice about GUID’s is that anybody can create these and with proper rules the chance of collision can be reduced to zero.  But domain name structures are collision free, easy to delegate sub-trees, and people understand them.  But they are a lot larger in protocol streams than GUIDs.  That size might make a difference for applications that are datagram based.

There are issues, of course.  Hard issues are things that occur when naming cloud-entities.  Those things can split or merge and the question then becomes how that affects their names.

But if we stay with physical things then the main issue is mapping these names into other things, such as IPv4/IPv6 addresses or SIP URI’s etc.  In order to facilite things that move this binding might have to be very dynamic - which means that the domain name system (with GUIDs encoded as some way into names) could be a poor choice because DNS is really not designed to change fast enough to support things that move much or quickly.

Again the ISO/OSI people had interesting thoughts on this.  They used a protocol layer above their transport.  They called this layer the “session” layer.  As with everything ISO/OSI it was horribly over-designed.  However the basic concept is something we should consider - which is that of a persistent relationship between the communicating entitites with that relationship being able to span the lifetimes of multiple sucessive underlying transport connections.  It is this session notion that allows underlying transport protocol addresses (IPv4/IPv6) to change as a device moves (thus forcing the breaking of TCP connections and the reforming of new ones as the devie moves.)  This is much, much more effective than the trianglar juggling that is used for IP mobility.

There are things to be avoided - our wars over domain names strongly suggest that any application layer names have no human semantic content - in other words just things that look like a hodgepodge of numbers to the human eye.  And thus no need for UTF-8/Unicode - just bits represented as a structured group of hexadecimal characters (with structuring punctuation.)

Work has been done about adding a new dimension to naming/addressing - which is identifying things by attributes rather than a hard name or address.  This concept is useful when one wants to utilize a member of a class without concern about which one.  This is an important notion that is only starting to come into play in cloud computing.  This attribut-based lookup is only for connection making - Once an appropriate peer is chosen one can then use its actual name.

Over the years the triple of names, addresses, and routes has been a source of constant discussion.  The introduction of attributes will add another aspect.  And we want to avoid the politics that has hit domain names.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

VINTON CERF
Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Related

Topics

IPv4 Markets

Sponsored byIPv4.Global

New TLDs

Sponsored byRadix

Threat Intelligence

Sponsored byWhoisXML API

DNS

Sponsored byDNIB.com

Brand Protection

Sponsored byCSC

Cybersecurity

Sponsored byVerisign

Domain Names

Sponsored byVerisign