One of the most medieval-looking aspects of VoIP today is speech encoding. As a matter of fact, a vast majority of phone calls are being made using the G.711 codec, which is a standard published in the early seventies. That’s even earlier than the very first scientific publications on the subject – voice over packet networks – began to appear.

Over past decade innovation began to make headway. Internet Low Bit Rate Codec (ILBC) is a great codec that delivers voice in good quality even over fairly poor links. It was standardized as RFC3951 in 2004. Other popular codecs ready for the Internet age is Speex (http://www.speex.org/), with an impressive compression rate. New codecs introduce various improvements: quality improvements over ‘lossy’ networks, high compression, low-latency or superb-quality audio. A frequently mentioned humorous application of the latter is ‘voice for dogs’ that can capture broader audio spectrum than humans.

One may observe though that despite how good the recent codecs are, their adoption is still lagging. I believe this has begun to change for good. In the IETF several standards are being standardized. This week the IETF meets in California, and its busy agenda included several codecs among others: BroadCom’s Broadvoice (16 or 32 kbps, royalty-free and open-source), CELT (http://www.celt-codec.org/, low-latency), and Skype’s SILK (royalty-free, open-source).

I believe the key aspect of the work on new codecs is the tendency to release them under patent-free and/or royalty-free conditions. That’s really creating space for innovation, and massive adoption by both small and big players. I can’t await man listening to his dog’s voice.

It may be of interest to readers of this blog that recently a thought-provoking Internet Draft was published by Henry Sinnreich et al: SIP APIs for Communications on the Web – draft-sinnreich-sip-web-apis-00. In a nutshell, the Internet Draft exhibits critique of SIP and suggests a consequent usage of HTTP technology for VoIP used along with other Internet applications.

The question begs, whether the critique is justified and whether the shortcomings mentioned introduce sufficient pain to make one-self busy with abandoning SIP. I think the critique is largely fair; I’m less sure that there is a time window in which the level of pain can cause such a change.

The critique cites several reasons: standards’ complexity, insufficient consideration of NAT traversal and difficulties to link to web apps – to name the most significant ones. The complexity statement can be easily confirmed by looking at the VoIP RFC Watch site maintained by Nils Ohlmeier or by checking the SIP WG RFC dependency graph. And, NAT traversal has proven itself to be a large problem resulting in the formation of new network element type – the session border controller (SBC). Non-voice apps are indeed still letting us wait for them.

The real question to me is whether these difficulties will create enough motivation to change from SIP to Web technology. The window of opportunity seems closed: complexity can be somewhat lowered; like it or not, we have SBCs for NAT traversal; and web-apps can be built with or without SIP.

Still, isn’t the number of these workarounds a good enough reason to give the HTTP legacy a try? I have recently found out that remote sharing of “smart boards” (i.e. whiteboards with direct output to PCs) works over web port 80 via a third party to facilitate NAT and firewall traversal. Most video apps are using HTTP (even though typically one-way), and the number of emails exchanged via HTTP certainty creates a fair traffic share. To me it looks like we’re already giving HTTP a try…

Recently BICC became the protocol of choice for several wireless operators deploying VoIP trunking backbones. For many it is perceived as a temporary workaround solution.

What I’m asking myself is whether such a temporary solution might possibly stay for longer?

In the IP world we have quite a few examples of “temporary solutions” that have featured momentary advantage, real or perceived, and which have stayed with us. I consider NATs (Network Address Translators) the most important example. NATs translate IP addresses in packets from/to the public Internet to a private address range. This allows for the sharing of a scarce public IP address among multiple devices (real problem) and hiding these devices better. The latter is considered a perceived security feature as the same functionality can be implemented in firewalls without the side effect of changing IP packets. The changes to IP packets can cause dysfunctional applications, errors in security protocols and limitations to redundancy schemes. (See RFC3027 for more).

In the IETF standardization body NATs have therefore been considered as architecturally unsound, or even evil architecture. It shall be added that guarding an “architectural spirit” has allowed Internet technology to develop, stay manageable and prevail. In this spirit the “right answer” to the problem of scarce IP addresses has been proposed: IPv6. NATs have been labeled as a “temporary solution”. However, many years later it is as hard to find a user without NATs as it is a user with IPv6. NATs are to stay and the fate of IPv6 is all but clear.

I think a similar scenario is occurring with Session Border Controllers (SBCs). They solve real problems such as NAT difficulties that have bubbled up to the application layer. They solve temporary problems such as interoperability of immature implementations. They also solve perceived problems — we know yet too little about what security problems are out there but SBCs offer an answer already. However, the coincidence of solving real problems and claims they are of a temporary nature seems to me remarkably similar to NATs. I think this may lead to a similar ending, with SBCs staying and solving the problems that are compelling and permanent. Certainly, re-connecting disjoint IP addressing spaces would be one of those.

What is the next controversial architecture to stay? NATs are definitely staying, SBCs keep “temporarily” reconnecting disjoint address spaces. The capability to solve compelling problems has prevailed over desires for a consistent and presumably easier-to-maintain architecture. Recently, several BICC deployments have emerged — is BICC going to be the next protocol that is “architecturally unsound”, yet here to stay?

The BICC architecture is very special-purposed and therefore of limited applicability. Basically, it inherits encoding from ISUP, and transports it over IP or even ATM. Development beyond the purpose of trunking began stalling at “CS3″ (Capability Set 3). By any measure it is a real hybrid vehicle.

Still, as unappealing as it sounds, deployments are reported and continue to solve the MSC trunking scenario. We can soon witness again an architecture solving a real problem and prevailing over “grand architectures” in specific use cases.

It appears that the notion of hybrid vehicles is not exclusively owned by the automotive industry.

Happy New Years!

I have recently asked a few of the very first providers to deploy VoIP, what the biggest technology pain was for them in their VoIP deployment. What do you think it was? Conceptual concerns, such as security, migration path to Telco 2.0 or Telco 3.0, connectivity to Facebook, IPv6, computing clouds and power grids?  Was it perhaps QoS which has been socialized as a key obstacle since the age of 2.4 kbps modems?  Or maybe operational concerns: troubleshooting, or customer-care? What else could it have been?

In fact, the answer is less exciting than that: the winner in being the most long-lived and unnerving technology gap in VoIP deployments is dual-tone multi-frequency (DTMF). Tones over the telephone network are still used massively to communicate with IVRs, and this does not work well yet with VoIP. One can certainly imagine that IVRs will begin to fade out in favor of well-organized web-pages. It really appears very unlikely that any new applications now in the Internet age would choose DTMF as its “user interface”.  Still DTMF is utilized every day. Many call centers are implementing initial dialogs with callers using DTMF. Other applications like payment-terminals and elevator-control systems use in-band signaling, sometimes to the surprise of those who have attempted to migrate to VoIP seamlessly.

It is not that SIP/VoIP do not include protocols for conveying DTMF. In fact, a big problem is that they may include too many of them. Obviously, DTMF tones traversing a VoIP network as digitized audio degrades and becomes harder-to-detect if they traverse multiple points of encoding/decoding.

Two digital alternatives have therefore emerged in the marketplace. Advocates of the “DTMF tones are real-time” approach have standardized transmission of digitized tones in the RTP packets. Yet there is another camp that has seen DTMF as an application control mechanism. From this perspective DTMF steers applications, belongs by its purpose in signaling, and is related to media only by historical evolution.

Based on historical evolution we can see audio, RTP and SIP DTMF encoding in networks – or a combination of these – frequently causing DTMF-based applications not to operate well without extensive tuning.

One of the most frequently asked questions I get over time as co-founder of a startup that leaned heavily on open-source is what I think of its role in telecommunications. It is a question that can easily cause a flame war — pro-open-source advocates frequently position themselves as commerce haters, while some in the anti-open-source camp believes that open-source annihilates intellectual property and introduces unaccounted-for support costs. A lack of understanding of the subject makes these debates usually religious and inconclusive. Concerns exist regarding many aspects from all involved parties: IPR disclosure (still frequently coming from investors), IPR infringement claims, financial backing of open-source companies (customers), process compliance (ISO 9000 backers?), hidden support cost (closed-source competitors), and most importantly the business models (open source companies themselves).

Still, there is amazing interest in the topic of whether one can make money with open source. Today’s widespread use of open source software and its use in all sorts of software products is inviting entrepreneurial minds to find ways to commercialize open source  ideas. There are numerous websites listing 10, 50, and 100 ways of making money with open source. Some of them are known to have produced success, such as the support business model of Red Hat. Yet what we have been looking for is the rather “traditional” software model – producing revenues by licensing and/or positioning a company as an acquisition target. Acquisitions in the past five years show this is becoming possible: Mysql, jboss, and our own company, iptelorg, to name just a few. The questions for me are – is this a trend that creates a pattern and do the aforementioned concerns dilute with increasing understanding of the matter? And perhaps does open source make sense at all?

Our own experience shows a positive picture of the role of open-source in the life-cycle of a startup. It is important though to realize there are two sides: using and producing. Using open source is, as I believe, extremely beneficial. In fact, open-source today creates a “pedestal” for any thinkable software activity. If you have a new project, you really want to focus on your added value. Still, most applications rely on tons of software underneath them: operating system, web servers, and databases… to name the most important ones. Developing them from scratch is simply unthinkable — you really want to put your project’s resources into value added differentiators. Licensing these components is not easy at all — it can substantially drain your project’s budget and create undesirable interdependences. You are likely to get into a position where you have to beg for a software update. Clearly, such dependencies are poison in a software developer’s veins. Open source solves this perfectly for you — it enables you to work on your added value and you are still in control of the software underneath it.

The really hard part with open-source is actually the producing side. How does an open source company convince you and other users to pay for its freely available software? A possible argument is along the value path. In fact, customers are getting (under assumption of comparable quality) more from open-source producers than from closed-source. They stay in full control of publicly reviewed software. That is undoubtedly a great advantage , which could be appropriately rewarded.

Still the prevailing opinion is “why should I pay for something I can download from the Internet”. Support costs is frequently underestimated as many potential customers believe that they can handle maintaining the software and in the worst case pay for ‘work for hire’ to fix bugs. Integrator companies frequently offer themselves for this role. Their incentive system however weakens the open-source producers. The more the integrators change, the more they get paid. This actually redirects money from growing a more general and perfect software to customized hard-to-maintain branches.

As a result, it is non-trivial for open-source producers to find a way to make money by licensing. Customers either directly or indirectly through integrators associate open source with “no money to be paid for”. The  question then remains — how to reconcile “free software” with making money by licensing. Which I consider a very attractive way for making profits: once the software is ready and finds its customers, revenues come back at marginal cost.

Two possible ways to monetize open source intellectual property that we have experienced is dual-licensing and company acquisition. The former way allows open source companies holding copyrights to collect money for sub-licensing their software under commercial terms. That’s particularly appealing to licensees if they are not willing to disclose their software as open source due to terms of GNU license.

Open source company acquisition allows acquiring companies to get unlimited access to both software and the experts developing it, as well as a company’s business opportunities. Both parties benefit of this scenario: open source producers obtain very affordable publicity, and their acquirers obtain excellent visibility into the underlying technology; software, its history and user reactions are all publicly available. Try to compare this to the cost and risk of marketing and sales campaigns for sellers of due diligence for acquirers!

I think these incentives make open-source, contrary to some beliefs, an equal or better vehicle for OEM licensing and acquisitions. As advice to open-source startups and investors, I recommend using and producing open-source as long as the IPR integrity is retained. A necessity to explain and justify open-source is diminishing. In 2000 Cisco bought Vovida. We have gone the OEM and later acquisition path with iptelog in 2005,  Asterisk continues to rely on dual licensing; and in the related field of databases, mysql has been offering dual licensing, and ended up being acquired by Sun in 2008.

Briefly — open-source is a great vehicle for entrepreneurs and investors. It allows them to concentrate on their added value and put it on display. Patterns exist today for making money by the way of dual licensing or acquisitions, which dramatically increases acceptance of open source intellectual properties.

In the last IETF meeting in Stockholm the Codec Bof (a gathering set up to gauge interest to form a working group to launch an effort) has collected so far the greatest interest. It was not purely the topic itself, wideband codecs that deliver superb audio quality. The greatest excitement in the meeting and on the mailing list, on which this topic is being discussed, has been related to the legal aspects of “Intellectual Property Rights,” or IPR.

In fact these concerns have followed continuously polarized viewpoints of the digital Internet age. The “liberal” camp argues that excessive protection of intellectual rights is actually prohibiting progress. Particularly they are worried that exclusive IPR ownership and high royalties make it hard for researches to build upon them. Furthermore, it occurred in history that innovators with a weaker financial position have been compelled to withdraw due to the cost of legal IPR battles. Briefly, the camp argues that IPR protection instruments must not be used against the advance of science.

The “conservative” camp is worried about recovering their cost of research. Clearly it is a similarly valid concern. Research is expensive by both direct cost and risk of failure. Many research projects are launched with expectation of profitability. They have to cover not only their own cost but frequently the cost of projects that haven’t been lucky enough to become profitable as well.

It seems that neither of the camps is wrong, and even that both seem to be right as they have a proven history of success stories (success being defined as a massive adoption of a new technology). Therefore, the IETF has been adopting the policy of setting the IPR policy on a case-by-case basis. While the IETF generally prefers technology free of the IPRs, Working Groups (WGs) can choose to standardize IPR protected technology if it is “worth” it. This case-by-case approach has been quite workable over years.

While the IETF discussion has been focused on all sorts of arguments (do we have expertise? can we achieve milestones in reasonable timeframe? is this piece of work needed at all?) it became clearly apparent that IPR is the key concern and reason why it has been so hard to become conclusive.

What is then going to happen with the standardization effort for new codecs within the IETF? Based on extrapolation of codec history, I’m betting on the “liberals” to prevail.

In fact the most widely deployed codec for Internet telephony is G.711, and there are some royalty-free codecs that are emerging: iLBC, G.722, and speex. These codecs are well understood, deployed, and produce enjoyable audio quality. Let me conclude with a question: what more can a codec offer in exchange for royalties?

As SIP networks mature (established public deployments are way beyond the one million subscriber mark), they begin to attract malicious attention as well. Reports on Edwin Pena [1], German “midnight attack” [2], and “Egyptian story” [3] make apparent that security, unlike in the early pioneering days of VoIP, is of paramount importance.

Of particular importance is confidentiality — the ability to make sure that no one other than the intended recipient can listen to your phone call over the Internet. Obviously, this is not trivial as the path between two parties is long, and there are many parties along the way — your network administrator, your ISP, your ISP’s upstream provider, backbone provider, anyone on the air (should you be using a wireless link), and possibly more. For many, concerns about unlawful use of legal interception facilities and industrial and political spying are also important. All of these potential interception points sit along the path of your voice packets. Confidentiality seems a battle of one against crowds.

Still, even when outnumbered, the privacy battle can be won using mathematics, if wrapped in carefully designed communication protocols.  Encryption techniques and protocols have been with us on the Internet for decades and make it very hard for privacy intruders to understand intercepted IP packets.

While the existence of an encrypted phone call remains apparent, the content is perfectly hidden.

In the rest of this post, I try to forecast which technology will prevail for securing the confidentiality of VoIP calls. I’m leaving the debate about appropriateness and downsides of hard-to-break to some other post. One of the reasons is simply that I believe that good privacy mechanisms are too disruptive to be stopped, whether they are used for just purposes or not.

IETF, the Internet standardization organization, has put enormous effort over the last decade into hard-to-break protocols for conveying encrypted traffic. Particularly, SRTP (RFC 3711) came out as a suitable protocol for transporting encrypted VoIP. While the capability to convey encrypted packets is necessary, it is not sufficient. Over time it became apparent that the yet-to-be-understood piece is actually “keying,” also known as key exchange or key agreement protocols. This is the mechanism in which two or more parties can agree on a “key” for encryption/decryption even in the presence of malicious parties. A variety of protocols have been debated over the years and abandoned mostly on the grounds of complexity, which is generally considered security’s and adoption’s enemy. Eventually two dueling protocols, ZRTP [4] and SRTP-DTLS [5], remained in the play.

The zRTP protocol was invented and advocated by Phil Zimmermann, famous for his brilliant PGP privacy software for email. SRTP-DTLS has been promoted by Eric Rescorla, known for his work on TLS. While both protocols have the potential for achieving confidentiality, zRTP seems a far simpler design and, therefore, a more likely winner.

zRTP uses Diffie-Hellman (DH) key exchange to create a key when a call is being set up. The DH-keying is multiplexed in the RTP stream. That in a nutshell is all it does; its beauty and power lies in its simplicity. As a result, it does not require any enhancements to the signaling infrastructure and bypasses problems that have been troubling SIP deployments since inception — NAT traversal, in particular. As it is rather straightforward, several implementations exist today that are publicly available for use, testing and expert audits.

The competing protocol, SRTP-DTLS, has chosen a more sophisticated approach for key exchange, which uses Public Key Infrastructure (PKI). It leans on SIP negotiation features and needs further security protocols such as SIP extensions for IDentity (RFC4474) and updated Identity (RFC 4916). These extensions have so far experienced very limited, if any, adoption, presumably because of their use of PKI and excessive message integrity protection [6]. The gain is these protocols (if used and deployed together) buy us a notion of identity. We not only know that we speak in privacy but also that a trusted provider vouches for the identity of the other party. Isn’t it comforting to know you are actually having a private conversation with a family member of yours?

While the notion of identity appears appealing, it is not clear yet if it provides any value. It requires additional security vehicles, which are not in place, and can therefore hinder deployment of the system as a whole. It still has its limits. For example it cannot reliably ensure that an office-mate won’t answer a phone call for your family member and impersonate her. In fact, the notion of identity on the Internet is still rather vague after all these years, and it will take a long time until we have a viable sort of “DNA match” for a VoIP call. In many real-world cases, use of common sense to identify a phone call peer seems “good enough”.

What remains though is the argument of complexity, which strongly speaks in favor of zRTP. We have learned in the past that simplicity is the winning ingredient. Simplicity keeps the number of boxes, configuration files, and other pieces to learn, buy and manage, at a minimum. At the same time, the low number of dependencies on other functions keeps the system simple and virtually resilient against failures, interop problems and security attacks.

Perhaps even more important from the adoption point of view is the number of parties that are needed to support the functionality. Keeping it as low as one is the key to success. You don’t have to run from one vendor to another, request commitments and roadmaps and pray they will be mutually in sync.

I personally believe that simplicity has been THE ingredient that allowed the Ethernet to win its race against Token-Ring, SMTP against X.400, and IP against ISO. Simplicity goes hand-in-hand with rapid adoption, public and proprietary implementations, field experience, public audits and subsequent improvements targeting real problems. My observation is that when simple technologies reach V2.0, their more complex (and possibly more “perfect”) counterparts still remain at stage 1.0, fighting for adoption.

In conclusion, I think that zRTP’s amazingly simple design (and simple by no way means simplistic!) will very quickly make it the confidentiality protocol of choice. Simplicity is just too appealing and disruptive to be ignored during new protocol adoption.

References:

[1] http://www.infoworld.com/d/networking/man-charged-selling-hacked-voip-services-800

[2] http://www.ipcom.at/fileadmin/public/2008-10-22_Analysis_of_a_VoIP_Attack.pdf

[3] http://www.sipsecurity.org/?page_id=151

[4] http://tools.ietf.org/html/draft-zimmermann-avt-zrtp

[5] http://tools.ietf.org/html/draft-ietf-sip-dtls-srtp-framework-07

This is the third (of three) blog posting on the topic of “identity management” in SIP-based networks. The first posting was on March 10th, 2009 and the second posting was on March 24th, 2009.

This time I would like to pay attention to phenomena I have observed for years in the industry: technology adopters seeking to solve compelling problems by purchasing a “magic bullet box.” However, does this really work for security problems with Internet telephony?

Is there a Magic Bullet Box for SIP Security?

It would certainly be nice if there were. Clearly operators would like to spend time on increasing service portfolio and subscriber base, as opposed to solving technical problems. Technical problems are a liability and ideally such a liability can be removed by a “liability remover”. Nicely packaged, plug-and-play, served in a gift wrap — a problem-solving box is a compelling value proposition.

• Can we have such a box that addresses VoIP security threats?

• Can we have a box that detects security attacks and stops them without impacting legitimate traffic? Can the so well publicized “deep packet inspection (DPI)” provide us with effective help?

• Can “hardware solutions” be a cure for denial of service (DoS) attacks? Particularly, can a Session Border Controller (SBC) make your network secure?

The Bad News

The bad news is that all these fascinating tools are more placebo than an effective cure. Unlike with medicine however, a false feeling of security can have a devastating impact on the actual system which remains exposed to threats from the public Internet. Securing networks is a constant battle between attackers and defenders. This is in fact an ultra-dynamic war, rather than a static one in which fortresses used to play a role.  Attackers generally do not tick in quarterly cycles, many box manufacturers do however. As attacks become more sophisticated, so do the protection boxes — yet with an inherent delay and increasing complexity, which is in turn an inherent enemy of security.

In particular, do you think that a “deep packet inspection” vehicle (i.e. software) put in front of applications (software too) can improve reliability of the whole system? Do you see a parallel with improving reliability of a light bulb by putting another bulb with it in series? In general in software engineering, the number of lines of code is quite unlikely to increase a system’s reliability.

Establishing a Secure System

I think that for building a secure system, you really have to work hard on simplicity. Simplicity is easy to audit and hard to crack. Security by simplicity is not about building grand architectures consisting of fascinating baroque boxes. It is about systematic elimination of all unnecessary stuff.

A well established service system has three parts: transport, application, and policy.

Transport security is a well understood phenomena addressed by conventional firewalls. They have a set of static rules that allow them to discriminate trusted traffic from untrusted traffic.

Frequently they also can provide effective means of preventing well known attacks such as SYN attacks. So far, so good. If they come with “Application Level Gateways”, just turn them off.

The most likely though undesirable outcome of leaving them on is that they will drop legitimate traffic their builders have not anticipated.

Application security is, measured by number of incidents, most importantly about robustness of server software in use. Too frequently we witness software that is not mature enough to deal with rough traffic coming from the public Internet. I’m personally rather conservative in this matter and believe that you cannot beat open-source software that has benefited from public scrutiny, rather than proprietary software. (On this note I feel compelled to mention that Tekelec’s SIP routing products have in their heart the open-source SIP Express Router (SER) foundation.) Of course, regular maintenance and updates are a necessary part of the story.

Last but not least the application policy comes in play: who can talk with whom, who may get a “VIP service”, which calls are forbidden, a.s.o., a.s.f… This is a part of the definition of a provider’s service and cannot be addressed by anyone else other than the provider. Occasionally it involves some low-level protocol decisions such as disallowing call redirection.

In Conclusion…

What is the conclusion? First of all, security does not come for free. A box cannot replace a hard-thinking analytical process. It takes an accurate definition of the transport-level and application-level policies, and choice of software that has been built for use in the public Internet. (A group of us recently published a book about SIP Security, which hopefully will help to create a more thorough understanding of all the delicate aspects.)

If you are really worried about security of a SIP service, learn a lot about it first. Then choose software that has been known to operate in harsh Internet conditions. Keep it well maintained. Surround it with conventional firewalls that don’t do deep packet inspection and cannot damage applications. Spend time on defining your application policies – no one else can do it for you.

Where is the SBC here? It is funny, but it seems that you just built a secure and SBC-free network, like in fact many other public SIP service providers did. Congratulations!

This is the second in a series of blog postings on the topic of “identity management” in SIP-based networks. The first posting was on Tuesday, March 10th, 2009. Click HERE to access PART 1.

We need identity for VoIP

I believe that a reasonable notion of identity can largely mitigate such horror scenarios. It would be very hard to eliminate anonymous undesirable communication. How could you blacklist “joedoe195″ if the user behind the name would choose to be “joedoe591″ in the next second. How could you deny incoming calls from “anonymous” if the majority of your callers would suppress caller ID, like in the stone age of traditional telephony? Asking for a legal action against “anonymous” would be as ridiculous as when Polyphemus blinded by cunning Odysseus was shouting ‘”nobody harmed me.”

What is Identity Actually?

The question is how can we reasonably answer to the compelling need for creating identity? Maybe even the first question to ask ourselves is “what is identity?”. Certainly DNA is a widely accepted notion of identity and if we were able to link IP packets with the originator’s DNA, the problem would have been solved. DNA is hard to change and unambiguous. Unfortunately, linking DNA to electronic communication does not sound very easy. Learning one’s DNA, encoding it, disclosing it in a way that guarantees non-repudiation, all of these problems make it terribly impractical.

Other Sorts of “Identity”

Many of the Internet e-shops have thus chosen a much simpler way for their purpose: they don’t really care about their customers’ DNA as long as they know their valid credit card number. Showing one’s credit card number to create trust is certainly not applicable to all Internet applications. However, if we find a way, in which sender’s IP packets are linked to a paid-for identity of his, we are on the right way. Only then will it be hard for an attacker to deny, change frequently or conceal his identity.

The “best current practice”

Actually a paid-for identity does exist in the Internet, we do not need to re-invent such. In fact all address verification emails “confirm this email if you wanted to do something with us” are paid-for, as they rely on paid-for DNS name. The verification established that the communication party is reachable under a non-free address, which is thus harder to change. IF we use the same scheme for VoIP, it would become quickly ineffective for all sorts of attackers to change identity by buying new domain names serially. Additionally, DNS as “trust currency” is already established for many other applications.

VoIP Verification

So this is I believe the conclusion: let’s use the email current best practices for weak verification of addresses to establish a notion of traceable identity. Not only is this proven and linked to a paid-for DNS service, it has a great migration strategy and incentives for adopters. It does not take the cooperation of multiple parties, industry consortia and other factors predestining a “cute idea” to fail. All it takes is telephones using this verification callback and providing preferential treatment for phone calls with clear identity. Callers’ telephones are likely to develop support for such verification (if needed) not to be blacklisted soon.

In summary, being able to verify with whom you talk will soon be one of the success-determining factors for VoIP. Using Current Best Practices as reverse address verification seems to be quite an appealing proposal. In the next post, I will provide a more technical review of current efforts to provide identity for VoIP services.