Internet Engineering Task Force F. Hao
Internet-Draft University of Warwick
Intended status: Standards Track B. Thomas
Expires: 27 August 2025 Squire Technologies Ltd
S. Smith
trueCall Ltd
MA. Azad
Birmingham City University
23 February 2025

Caller ID Verification In Session Initiation Protocol
draft-hao-civ-00

Abstract

This document defines an extension to the INVITE header of the
Session Initiation Protocol (SIP) to support the Caller ID
Verification (CIV) protocol proposed by Wang et al. in ACM
Transactions on Privacy and Security (2023). CIV authenticates the
caller ID of an incoming call through a challenge-and-response
process. When receiving a call with a claimed phone number, the
called party holds the call and sends an INVITE request to that
number, carrying a short 4-digit challenge embedded as part of the
caller ID. A genuine caller should receive the challenge and respond
by echoing the same digits, e.g., through DTMF (Dual-Tone Multi-
Frequency). The proposed extension involves two changes to the
INVITE header. First, it adds a new options tag, "civ", in the
Supported header field. This tag indicates that the calling party
supports CIV. Second, it adds a special value "civ-veri-call" for
the Purpose parameter of the Call-Info header field. This value
indicates that the purpose of the INVITE request is to verify the
caller ID based on CIV. Compared with STIR/SHAKEN, CIV authenticates
the caller ID (not the carrier), does not require trusted certificate
authorities and works with both IP and non-IP networks.

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 https://datatracker.ietf.org/drafts/current/.

Hao, et al. Expires 27 August 2025 [Page 1]

Internet-Draft CIV February 2025

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 27 August 2025.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Overview of CIV . . . . . . . . . . . . . . . . . . . . . . . 5
3. Implementing CIV in the Telecom Cloud . . . . . . . . . . . . 8
3.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Case 1: a legitimate caller uses the unmodified number . 9
3.3. Case 2: a legitimate caller uses a modified number they
own . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4. Case 3: an illegitimate caller uses a modified number they
don’t own . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Compatibility modes . . . . . . . . . . . . . . . . . . . . . 12
5. CIV security policy . . . . . . . . . . . . . . . . . . . . . 13
5.1. Exception 1 (perform CIV even when the "civ" tag is
absent) . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Exception 2 (do not perform CIV even when the "civ" tag is
present) . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Working with non-IP networks . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1. CIV impacts on tracing . . . . . . . . . . . . . . . . . 16
7.2. Length of the challenge . . . . . . . . . . . . . . . . . 16
7.3. Downgrade attack . . . . . . . . . . . . . . . . . . . . 17
7.4. Missed call . . . . . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18

Hao, et al. Expires 27 August 2025 [Page 2]

Internet-Draft CIV February 2025

9.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19

1. Introduction

In a SIP network, it is easy to modify the caller ID using number
spoofing. Sometimes, there are legitimate reasons to alter the
caller ID, e.g., showing a single outgoing number for an organisation
or a toll-free number for the called party to dial back. However,
fraudsters and scammers frequently abuse number spoofing to hide
their identity or to pretend to call from trusted sources. This has
become a global problem in the Telecom industry.

STIR/SHAKEN [2] is perceived by many as the ultimate solution to
prevent caller ID spoofing attacks. It works by attaching a digital
signature (with a chain of certificates) to each outgoing call.
Although the FCC describes STIR/SHAKEN as a "caller ID authentication
technology" [8], technically, STIR/SHAKEN does not authenticate any
caller ID. Instead, it authenticates the carrier, based on checking
the carrier’s exclusive possession of a private signing key. That
however solves a different problem. This mismatch in the
authentication subject explains the root cause for real-world
failures where the receiver accepts a digitally signed call as
genuine under STIR/SHAKEN, but the caller ID is illegitimately
spoofed [9].

In STIR/SHAKEN, an originating carrier must include a claim (or so-
called attestation) as part of the signed content to say whether or
not the caller is authorized to use the caller ID. However, the
process the carrier must follow to carry out this important task,
especially when the claimed caller ID belongs to a different carrier,
is undefined. The Ofcom public consultation, published in June 2023
[11], highlighted the need for STIR/SHAKEN to have "a common
numbering database", available to Telecom providers to distinguish
legitimate and illegitimate modification of caller IDs, but creating
and managing such a database was deemed infeasible in Ofcom’s final
assessment report [12].

Hao, et al. Expires 27 August 2025 [Page 3]

Internet-Draft CIV February 2025

Besides the mismatch in the authentication subject, STIR/SHAKEN has
two further problems. First, verifying digital signatures requires a
public key infrastructure (PKI) to distribute certified public keys.
All Telecom providers must trust the certificate authorities (CAs) as
the root of trust and pay them for the certificate fees (the payment
is typically a percentage of a Telecom provider’s annual income).
However, scaling up this trust across borders is extremely difficult,
if not impossible. Second, the digital signature and the chain of
certificates typically involve transmitting kilobytes of digital
data, which non-IP networks (SS7) are not designed to support.

In February 2024, after a public consultation on whether the UK
should adopt STIR/SHAKEN, Ofcom published a final assessment report
[12] and concluded: " our assessment is that we should not proceed
with CLI authentication [STIR/SHAKEN] at this time". Ofcom's final
assessment report explains the limitations of STIR/SHAKEN as covered
above. The report also highlights the urgent need to investigate
alternatives to STIR/SHAKEN, which motivates this document.

This document describes an alternative solution to STIR/SHAKEN based
on a peer-reviewed paper published in ACM Transactions on Privacy and
Security by Wang et al. in 2023 [6]. The alternative solution is
called Caller ID Verification (CIV). While the original paper
presents proof-of-concept implementations of CIV by modifying the
software on the users' phones, this document proposes deploying CIV
in the Telecom cloud for best performance. The CIV protocol
specification remains the same.

Technically, CIV authenticate the caller ID, while STIR/SHAKEN
authenticates the carrier. They address different authentication
problems (although STIR/SHAKEN is often misdescribed - and
misunderstood by many - as a "caller ID authentication technology").
The challenge-response method proposed in this document could also be
used to strengthen certain aspects of STIR/SHAKEN, e.g., enabling the
originating carrier to check if the caller is authorized to use a
modified phone number that belongs to a different carrier. That may
be more practical than using a "common numbering database" [11].
However, the details are outside the scope of this document. The
document only considers the case that the terminating carrier (not
the originating carrier) performs the CIV check, since in our threat
model the caller ID presented by the originating carrier is not
trusted (even if it comes with a digital signature).

Hao, et al. Expires 27 August 2025 [Page 4]

Internet-Draft CIV February 2025

1.1. Requirements Language

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 [3] [4] when, and only when, they appear in all capitals, as shown
here.

2. Overview of CIV

At a high level, CIV is inspired by a call-back verification method
used in practice. To verify if the caller ID of an incoming call is
genuine, the receiver may just hang up and call back the displayed
number [10]. This call-back method ensures that the receiver talks
to the genuine caller who owns that number. However, the manual
call-back verification is slow and tedious. It may also incur a
charge to the verifying party.

CIV follows a similar approach, but it automates the verification
process in a secure and efficient manner without incurring a charge
to the verifying party. In CIV, the authentication of the caller ID
is defined based on checking the ownership of that number.
Accordingly, it distinguishes legitimate and illegitimate
modifications of the caller ID based on whether the caller owns the
number: if they do, they should receive a call-back to that number
and respond accordingly.

Supporting CIV in SIP [1] involves making two changes to the INVITE
header. First, we propose a new option tag "civ" in the Supported
header of INVITE. This tag indicates that the caller supports CIV.
Second, we propose a new value "civ-veri-call" for the Purpose
parameter in the Call-Info header of INVITE. The "civ-veri-call"
value, paired with a unique resource indicator (URI) that can be the
same as the URI in the TO header, indicates that the purpose of this
INVITE request is to verify the caller ID in the initial call based
on CIV.

Based on the two proposed changes, the CIV protocol in SIP works as
follows.

1. The calling party initiates an INVITE request, containing an
options tag "civ" in the Supported header to indicate support for
CIV.

2. When receiving this INVITE request, the called party holds the
call and sends an INVITE request to the displayed caller ID,
containing the value "civ-veri-call" for the Purpose parameter in
the Call-Info header. This INVITE request uses a caller ID that

Hao, et al. Expires 27 August 2025 [Page 5]

Internet-Draft CIV February 2025

contains a short challenge (4 random digits) in the last four
digits of the caller ID. The INVITE request is quickly
terminated before it is answered. Subsequently, the called party
unholds the call and waits for the response. The purpose for the
"civ-veri-call" value is to make this INVITE request lightweight:
Telecom networks that understand this value in the call path do
not need to reserve resources to prepare for voice conversation,
hence making call routing faster. For Telecom networks that do
not understand this value, they will route this INVITE request as
a normal call. CIV still works although at suboptimal speed.

3. If the original calling party is genuine, it should be able to
receive the challenge and send a response (by echoing the same 4
digits) through Dual-Tone Multi-Frequency (DTMF) in the initial
call to complete the authentication process. DTMF is universally
supported in both IP and non-IP Telecom networks.

The verification call needs to be matched with the initial call.
This can be done implicitly or explicitly. Suppose Alice calls Bob.
Within a short time period, if Alice receives a verification call
with the caller ID matching Bob's number (excluding the last four
digits), Alice matches this verification call to the initial call,
and processes the challenge accordingly. This matching is implicit.
Wherever possible, we recommend to implement an explicit matching
method below.

The explicit matching can be done based on the Session-ID header [5]
in the INVITE request. The session ID consists of 32 hexdecimal
values, and it uniquely identifies a communication session end-to-
end, from the originating device to the terminating device. Unlike
the Call-ID header field (which may be modified by intermediate
networks), the session ID remains the same throughout the session.
Therefore, we can utilize the session ID in CIV as follows. In the
initial call, the Session-ID header field contains a unique session
ID while the Remote parameter is null (32 zeros). In the
verification call, the Session-ID header field contains a different
session ID while the Remote parameter contains the same session ID as
in the initial call. The receiver of the verification call can
therefore explicitly match the verification call with the initial
call based on the session ID. The following shows examples of the
relevant headers in the INVITE request.

Example of the selected headers in the initial SIP call:

Hao, et al. Expires 27 August 2025 [Page 6]

Internet-Draft CIV February 2025

Example of the selected headers in the CIV verification call (note
that the last four digits of Bob's caller ID in the From header field
has been modified to contain a random challenge):

| To: "Alice" <sip:+14155551111@example.com>
| From: "Bob" <sip:+12345676853@example.com>; tag=a48s
| Call-Info: <sip:+14155551111@example.com>; purpose=civ-veri-call
| Session-ID: 47755a9de7794ba387653f2099600ef2;
| remote=ab30317f1a784dc48ff824d0d3715d86

Table 1 summarizes the differences between STIR/SHAKEN and CIV. One
fundamental difference is that STIR/SHAKEN authenticates the carrier,
while CIV authenticates the caller ID. Technically, STIR/SHAKEN uses
a digital signature and certificates, which require trusted
certificate authorities in a public key infrastructure, and the
transmission of kilobytes of data. By contrast, CIV only needs to
transmit 4 digits, which is well supported by both IP and non-IP
networks. The trade-off of CIV is that it requires a round trip to
complete the challenge-and-response process between the originating
and terminating carriers. This adds a round-trip delay to the
caller’s waiting time, but this delay is unnoticeable to the callee.
The extra delay is mostly dominated by the verification call setup,
which involves not only routing the call but also, more importantly,
allocating resources along the call path to prepare for the ensuing
phone conversation when the call is answered. However, in CIV, the
purpose of the verification call is only to transmit a short
challenge, not to establish a conversation. Hence, the "civ-veri-
call" value in the INVITE request serves to inform intermediate
providers to only route the call without allocating resources. This
makes the transmission of the challenge quicker with less consumption
of network resources.

Hao, et al. Expires 27 August 2025 [Page 7]

Internet-Draft CIV February 2025

Table 1: Comparison between STIR/SHAKEN and CIV

3. Implementing CIV in the Telecom Cloud

This document proposes to implement CIV in the Telecom cloud by
performing the challenge-response authentication process between the
originating and terminating carriers (instead of between the users'
phones). Assume Alice is the caller, and Bob is the callee. We
first consider the cases where both the originating and the
terminating carriers support CIV. Later we will discuss the
compatibility modes where only one or no carrier supports CIV in

Hao, et al. Expires 27 August 2025 [Page 8]

Internet-Draft CIV February 2025

Section 4.

3.1. Threat Model

In our threat model, we assume that the attacker can freely modify
the caller ID when initiating a call. The modified caller ID is
permitted by the originating carrier (who may add a digital
signature) and can pass through subsequent networks. We assume the
attacker is not able to intercept calls. We note that a powerful
adversary can intercept calls through the Law Enforcement Monitoring
Facility (LEMF), SIM swap, and SS7 hacking [7], but this is beyond
the capability of ordinary telephone scammers behind the number
spoofing attacks.

3.2. Case 1: a legitimate caller uses the unmodified number

In this case (most common), a legitimate caller (Alice) uses the
unmodified number (Alice’s number) as the caller ID. Figure 1
describes the steps of operations.

1. Alice initiates a call to Bob and uses her unmodified number as
the caller ID.

2. Alice’s carrier sends an INVITE request to Bob with Alice’s
unmodified caller ID, including the "civ" tag in the Supported
header.

3. Detecting the presence of the "civ" tag, Bob’s carrier holds the
incoming call and sends an INVITE request to Alice’s number as a
verification call. The INVITE request includes the "civ-veri-
call" value and random 4 digits embedded as the last four digits
of the caller ID as a challenge (the rest digits can follow the
same as Bob’s number). The verification call is quickly
terminated before it is answered, so it does not incur a charge.
Bob’s carrier connects Alice’s initial call and waits for a
response through DTMF.

4. Alice’s carrier retrieves the 4-digit challenge from the
verification call’s caller ID, and sends the same digits as a
response through DTMF in the initial call. Otherwise, it quietly
discards the challenge.

5. Bob’s carrier checks the received DTMF digits against the
challenge. If they match, the caller ID is "verified". Bob’s
phone starts ringing, showing the caller ID and the "verified"
status of this number. If Bob’s carrier does not receive the
response within a time limit or the received response does not
match the challenge, it should reject the call.

Hao, et al. Expires 27 August 2025 [Page 9]

Internet-Draft CIV February 2025

Alice's carrier Bob's carrier
gateway gateway
┌─┐ ┌─┐
│ │ 2. calls Bob from │ │
│ │ Alice's number │ │
1. calls Bob│ │───────────────────▶│ │ 5. rings from
┌───────┐ as Alice │ │ 3. sends challenge │ │ Alice's number┌───────┐
│Alice's│──────────▶│ │ to Alice's number │ │──────────────▶│ Bob's │
│ phone │ │ │◀───────────────────│ │(authenticated)│ phone │
└───────┘ │ │ │ │ └───────┘
│ │ 4. sends response │ │
│ │──────────────────▶ │ │
└─┘ └─┘

Figure 1: authenticated caller with an unmodified number

3.3. Case 2: a legitimate caller uses a modified number they own

In this case, the caller (Alice) modifies the caller ID to another
number (Alice2) she owns. Since Alice owns that number, she can
configure the call forwarding function, so that the verification call
sent to Alice2 is forwarded to Alice. The rest of the process is the
same as in Case 1. Figure 2 summarizes the steps of operations.

Hao, et al. Expires 27 August 2025 [Page 10]

Internet-Draft CIV February 2025

Alice's carrier Bob's carrier
gateway gateway
┌─┐ ┌─┐
│ │ 2. calls Bob from │ │
│ │ Alice2's number │ │
1. calls Bob│ │───────────────────▶│ │ 6. rings from
┌───────┐as Alice2 │ │ │ │ Alice2's number┌───────┐
│Alice's│─────────▶ │ │ │ │──────────────▶ │ Bob's │
│ phone │ │ │ 5. sends response │ │ (authenticated)│ phone │
└───────┘ │ │───────────────────▶│ │ └───────┘
║ │ │ │ │
║ │ │ │ │
║ Alices owns └─┘ └─┘
║ Alice2's ▲ │
║ number │ 4. forwards the │
║ │ challenge │
▼ ┌─┐ │
┌────────┐ │ │ │
│Alice2's│ │ │ │
│ phone │ │ │ 3. sends challenge │
└────────┘ │ │ to Alice2's number │
│ │◀────────────────────┘
│ │
│ │
Alice2's carrier │ │
gateway │ │
└─┘

Figure 2: authenticated caller with a legitimately modified number

Alice’s and Alice2’s numbers may belong to two different carriers or
the same carrier. In the case of two different carriers, Alice can
choose to forward only the CIV verification calls (identified by the
"civ-veri-call" value in the Call-Info header). In the case of the
same carrier, e.g., when a private branch exchange (PBX) is used to
show a single caller ID for all outgoing calls, a solution is needed
to maintain the state of outgoing calls and forward the verification
call to the respective caller. This can be done by updating the PBX
software or connecting PBX to a switch that maintains the states of
outgoing calls and matches them with the verification calls.

Hao, et al. Expires 27 August 2025 [Page 11]

Internet-Draft CIV February 2025

3.4. Case 3: an illegitimate caller uses a modified number they don’t
own

In this case, a spoofing attacker (Eve) modifies the number to one
(Alice) that he does not own. Figure 3 summarizes the steps of
operations. The first three steps are the same as in Case 1 and 2.
In Step 4, Alice's carrier receives the challenge from a quickly
terminated verification call. However, it finds no matching record
for Alice’s outgoing call and no call-forwarding configuration for
forwarding the verification call. It quietly discards the challenge.
In Step 5, since Bob’s carrier doesn’t receive a response, it should
reject the initial call after a time-out.

Eve's carrier Bob's carrier
gateway gateway
┌─┐ ┌─┐
│ │ 2. calls Bob from │ │
│ │ Alice's number │ │
1. calls Bob│ │───────────────────▶│ │
┌───────┐ as Alice │ │ │ │ ┌───────┐
│ Eve's │─────────▶ │ │ 5. Rejects call │ │ │ Bob's │
│ phone │ │ │ (time out) │ │ │ phone │
└───────┘ │ │◀───────────────────│ │ └───────┘
│ │ │ │
Eve doesn't │ │ │ │
own Alice's └─┘ └─┘
number │
│
│
┌─┐ │
┌────────┐ │ │ │
│Alice's │ │ │ │
│ phone │ │ │ 3. sends challenge │
└────────┘ │ │ to Alice's number │
│ │◀────────────────────┘
│ │
│ │
Alice's carrier │ │ 4. Discards
gateway │ │ challenge
└─┘

Figure 3: Unauthenticated caller with an illegitimately modified
number

4. Compatibility modes

Table 2 summarizes compatibility modes depending on whether the
originating or terminating carrier supports CIV.

Hao, et al. Expires 27 August 2025 [Page 12]

Internet-Draft CIV February 2025

1. Both carriers support CIV: This is covered in Section 3. After
successful authentication, the caller ID with an explicit
"verified" status shall be displayed on the user’s phone.
Otherwise, the call should be rejected at the gateway.

2. Only the terminating carrier supports CIV: The (unverified)
caller ID is displayed on the user’s phone. The "unverified"
status is explicit. The terminating carrier should explicitly
communicate this status to the user, e.g., through visual or
audio alerts.

3. Only the originating carrier supports CIV: The (unverified)
caller ID is displayed on the user’s phone. The "unverified"
status is implicit.

4. Neither party supports CIV: The (unverified) caller ID is
displayed on the user’s phone. The "unverified" status is
implicit.

Table 2: Summary of modes of operations for CIV

5. CIV security policy

In a normal CIV operation, the terminating carrier performs the
challenge-response authentication process when the initial call
indicates support for CIV. However, the terminating carrier may
define a security policy to allow two types of exceptions.

Hao, et al. Expires 27 August 2025 [Page 13]

Internet-Draft CIV February 2025

5.1. Exception 1 (perform CIV even when the "civ" tag is absent)

In the first exception case, the terminating carrier performs the CIV
check for an incoming call even if the call does not contain the
"civ" option tag (e.g., the call uses SS7 signalling instead of SIP).
This is appropriate when the terminating carrier already knows
through some out-of-band channels that the caller ID of the incoming
call supports CIV. The following are possible scenarios.

1. In some countries (e.g., the USA), carriers can access a central
shared database, namely, the Caller Names (CNAM) database.
Network providers may register support for CIV for certain phone
numbers on behalf of their customers by adding a flag in the CNAM
database. Since the terminating carriers can access the shared
CNAM database, it can retrieve information on whether a phone
number supports CIV. This is especially useful for non-IP
network providers (e.g., using SS7 instead of SIP) to indicate
support for CIV for phone numbers under their allocation.

2. In some countries (e.g., the UK), carriers can access a
distributed database, like the Do Not Originate (DNO) list. The
DNO list includes phone numbers used only for receiving calls but
not making outgoing calls. Similarly, there could be a CIV-
enabled list, including crucial phone numbers (e.g., immigration,
tax, and customs authorities) that are frequently used in a
caller ID spoofing attack and shall be protected. Any call with
the caller ID on the CIV-enabled list must pass the CIV check
before it is connected to the user. For practical reasons, the
size of the CIV-enabled list should be small.

5.2. Exception 2 (do not perform CIV even when the "civ" tag is
present)

In the second exception case, the terminating carrier does not
perform the CIV check even when the call contains the "civ" tag.
Instead, it immediately connects the call to the user as in the
current telecommunication system. However, it should explicitly
alert the receiver through visual or audio means that the caller ID
is unverified. The following are possible scenarios.

1. The called party is an emergency service (e.g., 999). We
recommend that all calls to an emergency service should be
exempted from the CIV checks even if the calling party supports
CIV. This is to minimize the call setup latency. Furthermore,
making spoofed calls to emergency services is not the modus
operandi for most scammers, and these calls can be traced by law
enforcement if required.

Hao, et al. Expires 27 August 2025 [Page 14]

Internet-Draft CIV February 2025

2. The called party has a call-forwarding setting for an incoming
call. The forwarded destination may be a voicemail or another
number. In the case of a voicemail, the terminating carrier
should perform CIV as normal before connecting the call to the
user or the voicemail machine. In the case of another number, we
should ensure that the CIV check is done only once. When the
call-forwarding is unconditional, the terminating carrier just
forwards the call. This does not affect how CIV normally works.
When the call-forwarding is conditional (e.g., busy, unanswered
and unreachable), the terminating carrier may need to ring the
user to test the conditions. The ringing will show a display of
the caller ID, however, the carrier should make it explicit that
the caller ID is "unverified". When the call-forward conditions
are satisfied, the carrier forwards the call. The terminating
carrier shall process the forwarded call normally according to
the CIV protocol.

6. Working with non-IP networks

In this document, we assume that calls originate from and terminate
at SIP-based Telecom clouds. However, there are scenarios where the
call originates from or terminates at a traditional non-IP network.
In that case, the challenge-response process in CIV still works
because non-IP network providers can always spoof the caller ID at
their switches and send/receive DTMF. However, CIV additionally
requires a mechanism to communicate support for CIV in the initial
call. This is achieved in SIP by adding a "civ" tag in the Supported
header. As SIP trunking is becoming a standard for connecting
business phone networks, using an extended SIP INVITE header to
indicate support for CIV should be sufficient for most carriers.

For a small number of carriers that use only SS7, it is possible to
indicate support for CIV by using an out-of-band channel. For
example, the originating carrier may indicate support for CIV for a
phone number in their range by adding a flag in the CNAM database (if
available), to which other carriers have shared access. Furthermore,
the terminating carrier may have a pre-distributed CIV-enabled list,
including important phone numbers that are known to support CIV.

In a non-IP network, we can no longer use the session ID header to
explicitly match the verification call with the initial call.
Instead, the matching will be done implicitly, based on the timing of
receiving a verification call after the initial call, and whether the
caller ID matches an expected pattern. We assume the attacker can
guess the dialed number and can make a spoofed verification call that
has the call line identification (CLI) as a dialed number prefix +
random 4 digits. The attacker will need to make sure the spoofed
verification call is made immediately after the initial call and

Hao, et al. Expires 27 August 2025 [Page 15]

Internet-Draft CIV February 2025

arrives at the receiver before the genuine verification call to win
the race. This is theoretically possible, but in the worst case,
this will only be a Denial of Service (DoS) attack, causing the wrong
challenge to be read and the challenge-response verification process
to fail. The originating carrier will need to call again. This DoS
attack is detectable with the call detail record (CDR) in the Telecom
cloud, which further limits its impact. We note that the use of the
session ID prevents this DoS attack by design since in our threat
model, the attacker cannot intercept calls and hence cannot obtain
other calls' session IDs. Any spoofed verification call with an
invalid session ID will be discarded by the carrier at the gateway.

7. Security Considerations

7.1. CIV impacts on tracing

The telephone system only works because each phone call resolves to a
single phone number hosted and allocated by a network operator - the
range holder for that number. The range holder can identify to whom
the number is allocated (which may need to be done via number
resellers). It also has the power to disable the number if
necessary. Scammers often use spoofed phone numbers to hide their
identity and to avoid being tracked down. Widespread adoption of CIV
would prevent calls using illegitimately spoofed numbers from getting
through. This would force telephone scammers to use phone numbers
that are allocated to them as their caller ID. Therefore they would
be traceable (via the range holder) and their service could be
terminated quickly.

7.2. Length of the challenge

A spoofing attacker will not receive the challenge but may try to
guess its value. For a challenge of n random digits, the probability
of guessing successfully is 1 in 10^n. A larger value of n decreases
the probability exponentially but at the cost of transmitting more
digits. We recommend n = 4 as a suitable trade-off, which
corresponds to a success rate of 0.01% by random guessing.
Consecutively failed guesses can be easily detected by the
terminating carrier, and could be dealt with accordingly, e.g., by
increasing the delay between calls.

Hao, et al. Expires 27 August 2025 [Page 16]

Internet-Draft CIV February 2025

7.3. Downgrade attack

To bypass CIV, a spoofing attacker may use a carrier that does not
support CIV or set up their own SIP server that does not include the
"civ" tag in the Supported header of the INVITE request. In this
downgrade attack, the call will be connected to the user but the
caller ID is unverified. If the terminating carrier supports CIV, it
should explicitly communicate the "unverified" status to the user,
e.g., through visual/audio alerts on the phone, or a pre-recorded
warning when the user answers the phone. If the terminating carrier
knows through some out-of-band channels that the caller ID supports
CIV, it should perform the CIV check even if the "civ" tag is not
present (see Section 5.1).

7.4. Missed call

In a normal CIV operation, the verification call is transmitted
between the two carriers, and is never shown to users. However, a
malicious carrier may include the "civ" tag in the INVITE request and
use a spoofed caller ID belonging to another carrier that does not
support CIV. This is similar to Figure 3 except that Alice’s gateway
does not support CIV. In this case, the verification call will be
passed onto the user’s phone and shown as a "missed call" with a
caller ID that may or may not be dialable. The presence of the
unknown "missed call" may confuse the user and cause a nuisance.
However, this attack has a limited impact. First, it happens only if
Alice’s carrier does not support CIV; otherwise, the call will have
been filtered at the gateway. Second, the attacker could make a
"missed call" to the user directly. In that case, the attacker can
set an arbitrary caller ID for the missed call, but in CIV, he has no
control over the caller ID of the verification call. Without CIV,
making "missed calls" with random caller IDs to a phone user is
always possible. This is deterred in practice since the gain is
limited and the source can be traced based on checking the call
detail records (CDRs) in the Telecom cloud. With CIV, an attacker
can use the terminating carrier to make "missed calls", but he loses
control of the caller ID display and tracing remains possible by
correlating the two related CDRs.

8. IANA Considerations

This document proposes a new options tag "civ" for the Supported
header of the INVITE request, and a new value "civ-veri-call" for the
Purpose parameter in the Call-Info header.

1. "civ": The presence of this tag in the Supported header of the
INVITE request indicates that the calling party supports CIV.
The terminating carrier should follow the challenge-response

Hao, et al. Expires 27 August 2025 [Page 17]

Internet-Draft CIV February 2025

authentication process to verify the caller ID. It passes the
call to the user’s phone showing the "verified" caller ID when
the authentication is successful and rejects the call otherwise.

2. "civ-veri-call": This particular value, paired the same URI as in
the TO header, indicates that the purpose of the current INVITE
is to make a verification call. The intermediate providers in
the call path should route this call without reserving resources
for voice conversation. When detecting the presence of this
value, the terminating carrier should process the INVITE request
as a verification call based on CIV. It shall not pass the call
to the user.

9. References

9.1. Normative References

[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.

[2] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC8224, February 2018,
<https://www.rfc-editor.org/info/rfc8224>.

[3] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[4] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[5] Jones, P., Salgueiro, G., Pearce, C., and P. Giralt, "End-
to-End Session Identification in IP-Based Multimedia
Communication Networks", RFC 7989, DOI 10.17487/RFC7989,
October 2016, <https://www.rfc-editor.org/info/rfc7989>.

Hao, et al. Expires 27 August 2025 [Page 18]

Internet-Draft CIV February 2025

[6] Wang, W., Delavar, M., Azad, M., Nabizadeh, F., Smith, S.,
and F. Hao, "Spoofing Against Spoofing: Towards Caller ID
Verification In Heterogeneous Telecommunication
Systems", ACM Transactions on Privacy and Security,
DOI 10.1145/3625546, December 2023,
<https://doi.org/10.1145/3625546>.

9.2. Informative References

[7] Anderson, R., "Security engineering: a guide to building
dependable distributed systems", John Wiley & Sons, 2020.

[8] FCC, "Combating spoofed robocalls with caller ID
authentication",
<https://www.fcc.gov/call-authentication>.

[9] FCC, "FCC settles spoofed AI-generated robocalls case",
August 2024, <https://www.fcc.gov/document/fcc-settles-
spoofed-ai-generated-robocalls-case>.

[10] Ofcom, "Number spoofing scams", January 2023,
<https://www.ofcom.org.uk/phones-and-broadband/scam-calls-
and-messages/phone-spoof-scam>.

[11] Ofcom, "Consultation: Calling Line Identification (CLI)
authentication - a potential approach to detecting and
blocking spoofed numbers", April 2023,
<https://www.ofcom.org.uk/phones-and-broadband/phone-
numbers/cli-authentication>.

[12] Ofcom, "Calling Line Identification (CLI) authentication
assessment and future roadmap", February 2024,
<https://www.ofcom.org.uk/siteassets/resources/documents/
phones-telecoms-and-internet/information-for-
industry/scams/calling-line-identification-cli-
authentication-assessment-and-future-roadmap>.

Acknowledgements

We thank ...

Authors' Addresses

Hao, et al. Expires 27 August 2025 [Page 19]

Internet-Draft CIV February 2025

Feng Hao
University of Warwick
Department of Computer Science
Coventry
CV4 7AL
United Kingdom
Email: feng.hao@warwick.ac.uk

Basil Thomas
Squire Technologies Ltd
Prospect House, Sandford Lane
Wareham
BH20 4DY
United Kingdom
Email: BThomas@squire-technologies.com

Steve Smith
trueCall Ltd
2 Old Palace Lane
Richmond
TW9 1PG
United Kingdom
Email: stevesmith@truecall.co.uk

Muhammad Ajmal Azad
Birmingham City University
Department of Computer Science
Birmingham
B5 5JU
United Kingdom
Email: Muhammadajmal.azad@bcu.ac.uk

Hao, et al. Expires 27 August 2025 [Page 20]