Internet-Draft Caller Verification Status February 2019
Albert Expires 1 September 2019 [Page]
Intended Status:
Standards Track
N. Albert

Verifying Caller Identities in Private Peer-to-Peer Voice-over-IP (VoIP) Telephone Networks


This document specifies a mechanism which allows for peer-to-peer Voice over Internet Protocol telephone calls to be formally authenticated and verified, so that recipients can be sure of their authenticity and ensure that calls are not spoofed.

This mechanism is compatible with domains in which calls originate and terminate in private networks where all interoffice trunking is by Internet Protocol (IP) and where a central registry of routing information can be used to provide or facilitate the verification of in-network calls.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 5 August 2019.

Table of Contents

1. Introduction

1.1. The Problem

Caller ID spoofing has been possible for as long as the technology has existed and the advent of IP telephony has promised gains and setbacks alike when dealing with this problem. VoIP technology, combined with high-speed broadband (e.g. T1) has made possible many advances in telephony, including the feasibility of transmitting telephone calls and other telephony media over the Internet. This has allowed for a proliferation of Internet-telephony technologies and cheaper (and, in many cases, free) ways to communicate in ways that mirror traditional telephony experiences.

Many hobbyists, technologists, and enthusiasts in communications realms have taken advantage of VoIP technology to freely provision private facilities between members in geographically distributed locations. Asterisk, the free and open-source telephony toolkit, is frequently used for this application.

As programs like Asterisk generally allow Caller ID and ANI information to be set to any arbitrary value, such environments rely on members' "good faith" intention and ability to set these values properly and correctly. There are three general reasons and cases why this assumption fails to hold in a private VoIP environment. Although Caller ID and ANI refer to different information, we will use them interchangeably here since they are equally accessible and modifiable in VoIP environments. Although strictly peer-to-peer networks may not be true networks in the routing sense of the term, we will take the term to mean an environment which shares routing mechanisms and a common numberspace.

  1. Malicious intent. The most obvious case of foul play would be malicious actors who knowingly and intentionally configure a misleading Caller ID. This could be a number that belongs to somebody else, a number that isn't assigned to anyone, an invalid number that is nonsensical for the numberspace, or no number at all. This could mislead recipients into believing they have received a call from somebody who is not actually calling them.
  2. Technical incompetence. Not all administrators of nodes participating in a VoIP environment, particularly hobbyist networks, may be technically adept at noticing or resolving issues with Caller ID. Instead of sending a full network number, for instance, just an internal private extension may be sent. This is not due to malicious intent on the part of the administrator, but general technical incompetency which is inevitable, especially in larger environments.
  3. Lack of centralized or sanctioned enforcement. Compounding the aforementioned points is that private VoIP environments do not have any external mechanisms of enforcing the correctness and validity of caller number information. On calls that complete to the PSTN, some providers may screen ANI and/or Caller ID and reject calls which purport to be originating from obviously invalid numbers. In a peer-to-peer environment, where calls may route directly from one member to another, such a task is unlikely to be done centrally or in a way that can be enforced.

Ironically, even though Caller ID is easier than ever to spoof with VoIP technologies, in the context of private VoIP environments, ensuring authenticity and integrity of Caller ID can be significantly more feasible. This is because calls delivered over the Internet are associated with information that is, for all practical purposes, impossible to spoof, such as the IP address of the caller. In contrast, no equivalent information is available to recipients of phone calls from the PSTN to ensure that the call is originating from the number it claims to be. This is an ongoing problem for which some solutions have been proposed (see [RFC7340]), but work is ongoing. In contrast to technologies like STIR/SHAKEN which are beginning to see viability in the PSTN, simply utilizing IP addresses for the purposes of authentication can offer robust, yet simple, authentication capabilities that can be easily deployed and extended in VoIP environments which facilitate peer-to-peer calls but rely on a central source of truth for call routing information.

1.2. Basic Verification Using IP Address

This specification addresses the problems discussed in Section 1.1 by reviewing a general mechanism and strategy which may be used for robust validation of the authenticity of Caller ID data on interswitch calls. It is not specific to any particular VoIP enviornment or architecture, though it does take, at its premise, that the environment is designed in a way that facilitates equal access to routing information. Peer-to-peer networks, by definition, satisfy this criterion.

Foundationally, a verification may be performed using a reverse-lookup procedure against the number purported to be calling. The receiver of a call needs some mechanism by which the IP address from which a call purportedly has been received may be verified. The actual mechanism may vary and is not germane here. For instance, an HTTP REST API could be used or an ENUM lookup could be performed. The IP address is then extracted from the routing information, which consists, at minimum, of a URI for some VoIP protocol which could be used by switching software to route the call (e.g. a SIP or IAX2 URI). If a DNS hostname is returned as part of the routing URI, it can thence be resolved to an IP address.

Next, this IP address is compared with the IP address from which the call has actually originated. If they match exactly, the call is assumed to be valid. This rests on the following premises.

  • The routing information is authoritative. This might not be ensured, for instance, if routing lookups are also peer-to-peer instead of centralized (i.e. no single node in the network is capable of obtaining routing information for any particular destination in one hop or fewer). If there is any possibility of routing information being poisoned by an external actor, then there is no reason to believe a match of IP addresses should guarantee that the call has not been spoofed. If routing is maintained by a centralized, trusted authority, this condition may follow more naturally, but that is neither required nor sufficient. For instance, routing information could be collaboratively maintained in a way that ensures integrity or a routing server could be hacked.
  • The call is completed peer-to-peer, that is directly. If a call tandems through another switch along the way, this will not hold. However, this procedure can be extended in a way that accomodates these calls without significantly compromising security.
  • Legitimate calls from any particular number, in the case where a peer-to-peer call is placed, originate from the same IP address to which a call in the other direction would be sent. This assumption is generally reasonable, but may fail in cases where a different IP address is used for completing outbound calls. Additional mechanisms are then necessary to supplement an IP address-based verification procedure.

Consider the case of a legitimate call and a spoofed call. When a legitimate call is placed from Alice to Bob, Bob can verify that the calling number belongs to Alice and that it is actually Alice's IP address from which the call originated. However, if Charlie decided to spoof a call from Alice to Bob, Bob would discover that the number purportedly calling belongs to Alice's IP address, but the calling IP address isn't Alice's. In this case, it's Charlie's, but that is beyond the scope of verification requirements. The call could have originated from anywhere, possibly from a non-network node, in which case there is no way to assess "from whom" a call really did originate. The important thing is that the call has been detected to not be from who it purports to be from, and the call can then be flagged or rejected outright.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Ensuring Robust Verification

3.1. Supplemental Verification Mechanisms

3.1.1. Centralized Tokens

In some cases, the only completely trustworthy entity may be the centralized routing server. It is only indirectly, as a result of performing operations against this server, that any other node in a network may be verified as belonging to that network or not, and furthermore, that such a node is authorized to be using the number it is for a call. However, this model is quite flexible and there is no need to restrict this trust strictly to reverse lookups. This trust can be extended to tokens that are handed out by the same entity which operates the centralized routing server.

It is advisable, at least in the case of obtaining tokens, for some form of authentication to be required between a node and the token server. This ensures that only legitimate network nodes can obtain a token in the first place. The token can then be sent to the called node, e.g. using a custom SIP header or IAX2 variable. The receiver of the call can then verify the token by performing an API request. Since the token server issued the token, it would be able to verify whether a token is valid or not. This usage of tokens overcomes some of the limitations and shortcomings of reverse IP address lookups, namely that it allows for calls originating from IP addresses which cannot be verified as legitimate by the routing service to nonetheless be successfully verified on the other end. This provides flexibility for hosts using DDNS as well as temporary or permanent situations in which a different IP address may be being used for outbound calls.

Additional security precautions include:

  • Auto-expiring tokens after a short period of time. Tokens should be obtained each time they are needed and used for verification procedures. Thus, a timeout of 15 seconds should account for network latency.
  • Capturing the IP address from which the token was requested. Since the token should be requested and verified in an automated process, it would be untoward if the IP address of a call did not match up with that from which the token was requested. On the receiving end, the IP address can be provided to the token server to ensure that they match. This may cause issues if a node uses a proxy server for requesting tokens.

As with performing reverse IP address lookups against routing information, the use of tokens is only as secure as the integrity of the token server. If the token server is compromised, then all bets are off.

3.1.2. Tandem Hopping

So far, the material presented has not necessitated any cooperation between nodes in a network. In some cases, this may be sufficient. However, this can present a problem in cases of what we will call "tandem hopping" here. This could occur if a call leaves Node A for Node C, but passes through Node B on the way for whatever reason. This could be the result of explicit manual intention, such as dialing a DISA number on Node B, but it could be the result of an automatic alternate routing facilitiy as well.

The problem here is that reverse IP address authentication can no longer be successfully performed against the original source of the call. Node C will detect a call that is coming from Node B, and assuming the calling number information is passed through intact (as is generally preferred when possible nowadays), there will be a mismatch between the calling number and the network source as outlined in Section 1.1.

The key realization is that while Node C cannot verify Node A directly, it can verify Node B, which in turn can verify Node A. That is, anytime a call tandems through multiple nodes to reach its eventual destination, the verification process can remain intact if Node B verifies Node A and then passes the result on to Node C. Now, instead of verifying Node A, Node C can verify Node B, using additional information provided out of band. This mechanism can be used to pass verification status intact over an arbitrary number of hops, verifying at the first hop and then relaying thereafter. However, if at any hop, verification of the directly upstream node fails, then this status should be lost.

It is important to recognize the security limitations of this approach. While a cooperative standard such as that described allows for tandemed calls to be treated as equally valid as direct peer-to-peer calls, it relies on trusting not just the central source of routing truth, but also every node through which the call has passed. If any node between the source and destination is rogue or malicious, it could, in theory, rewrite the number to another network number (the case of an invalid number format can be ignored, since this could be detected). Downstream nodes are now unaware that the call has been spoofed, but since the next node trusts the rogue node (because of the central routing server) and downstream nodes, in turn, trust each upstream node, by way of the central routing server, the risk of an internal spoofing attack remains. Thus, this extension allows for flexibility in call routing but must be balanced against the risk of internal attack vectors and should be used only when all network nodes can be considered "trusted", in addition to the central routing server. Accordingly, in some environments, this might not be an issue, while in others, this could reintroduce some of the security problems that the verification procedures outlined here are intended to mitigate. If maximal security is required, upstream node judgment should not be used and the call should be required to complete peer-to-peer to the destination.

4. Verification Standards

4.1. Code Usage

A sequence of codes is recommended for succintly conveying verification status to other nodes and optionally for internal usage as well. The length of these codes will vary depending on the number of conditions that may be relevant for consideration and the number of network interconnections between environments of different numberspaces. Generally, codes ending in 0 are taken to mean legitimate and verified calls, that is, calls which the verification mechanisms detect no issues with. Codes ending in other digits are taken to refer to various other problems which could indicate spoofing or some other problem which has caused verification of the call to fail. Once assigned, codes should generally not be changed. Codes are transmitted on all calls leaving a node for another in-network node. This allows calls entering a different numberspace to be verified against a foreign numberspace and retain the actual origin identification.

Any suitable protocol may be used for transmitting verification status between nodes. To ensure the viability of verification, all member nodes need to support the procedures, and a common protocol should be supported. With the Session Initiation Protocol (SIP), this would take the form of custom SIP headers. With Inter-Asterisk Exchange version 2 (IAX2), this would take the form of IAX2 variables.

4.2. Code Assignments

Per this specification, PhreakNet has standardized 2-digit codes for use in hobbyist networks. The first digit refers to the network of origin and the second digit refers to a common verification indicator status. The two digits in combination are collectively referred to as the Caller Verification Status (CVS) code.

Following are the verification indicators denoted by the trailing digit.

Table 1
Last Digit Verification Status
0 Success (All Good)
1 Failure (General)
2 Failure (Anonymous)
3 Unassigned
4 Unassigned
5 Failure (ANI Fail)
6 Unassigned
7 Failure (Verification Procedure Failure)
8 Failure (Blacklisted)
9 Failure (Tandem Hopping)

Following are the network codes denoted by the leading digit.

Table 2
First Digit Network Source
0 Reserved (Internal)
6 PSTN (Other)
7 PhreakNet
8 Unassigned
9 Reserved (Other)

The assignment of network identifiers for calls originating from the Public Switched Telephone Network (PSTN) is admittedly arbitrary. This is done so that calls entering private VoIP networks from the PSTN can be appropriately flagged. Since calls from outside a private VoIP environment may not actually be verifiable (by these or other procedures), the use of the trailing "0" indicator should be taken to mean that spoofing was not detected, but this is not an assurance that it did not happen.

5. Security Considerations

Where relevant, limitations of the verification techniques discussed have been raised. The most notable one is the security risk introduced by allowing for chaining or tandeming of calls through a network to retain their original verification status merely by passing it along and verifying each upstream node in turn. In sensitive or high-security contexts, this flexibility should not be permitted. Future improvements upon the techniques discussed would entail a convenient way to provide a way for Node A to prove to any future downstream node, any arbitrary number of hops later, its identity in a way that could be successfully and accurately verified while preventing tampering, having no possibility of false positives or false negatives, and consisting of a relatively small amount of data that can be sent over a low-bandwidth data link.

6. References

6.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.

6.2. Informative References

Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure Telephone Identity Problem Statement and Requirements", RFC 7340, DOI 10.17487/RFC7340, , <>.


Many thanks to Brian Clancy for inspiration and comments throughout the process.

Authors' Addresses

Naveen Albert
United States