ATIS 1000072-2016 Analysis of Mitigation Techniques for Calling Party Spoofing.pdf

1、 TECHNICAL REPORT ATIS-1000072 Analysis of Mitigation Techniques for Calling Party Spoofing As a leading technology and solutions development organization, the Alliance for Telecommunications Industry Solutions (ATIS) brings together the top global ICT companies to advance the industrys most pressin

2、g business priorities. ATIS nearly 200 member companies are currently working to address the All-IP transition, 5G, network functions virtualization, big data analytics, cloud services, device solutions, emergency services, M2M, cyber security, network evolution, quality of service, billing support,

3、 operations, and much more. These priorities follow a fast-track development lifecycle from design and innovation through standards, specifications, requirements, business use cases, software toolkits, open source solutions, and interoperability testing. ATIS is accredited by the American National S

4、tandards Institute (ANSI). The organization is the North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a founding Partner of the oneM2M global initiative, a member of and major U.S. contributor to the International Telecommunication Union (ITU), as well as a memb

5、er of the Inter-American Telecommunication Commission (CITEL). For more information, visit www.atis.org. Notice of Disclaimer Number Signaling and Validation Techniques (Secure Telephone Identity Revisited/Secure Handling of Asserted Identities Using Tokens STIR/SHAKEN Framework), including that of

6、the Calling Party and International Gateway;Certificate Granularity (Service Provider versus “per TN”); Blacklists (local and global); Whitelists (local and global); Honeypots; Post call notification (e.g., dial a “*” code after hanging up); Network verification of Session Initiation Protocol (SIP)

7、PAI/FROM for IP Private Branch Exchange (PBX) call originations; Do Not Originate; Call Detail Records (CDR) Trace. The mitigation techniques provided in this analysis also apply to illegitimate robocalls. 1.2 Purpose The purpose of this document is to provide an analysis of the available and propos

8、ed mitigation techniques, and guidance on standard approaches for addressing originating party spoofing. 1.3 Application ATIS member companies may rely on this paper to conduct meetings with policymakers at all levels of government who are dealing with constituents concerns about caller identificati

9、on services (caller ID) spoofing and robocalling. Those meetings may educate government officials about these practices and may involve advocacy against premature regulation and legislation that could cement solutions or create regulatory barriers to the flexibility industry needs to mitigate caller

10、 ID spoofing and robocalling. 2 Normative References The following standards contain provisions which, through reference in this text, constitute provisions of this Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreemen

11、ts based on this Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. ATIS-1000072 2 ATIS-0300114, Next Generation Network (NGN) Reference Document Caller ID and Caller ID Spoofing.1 Draft 3GPP TR 33.8de V0.4.0, Security study

12、on spoofed call detection and prevention. 3 Definitions, Acronyms, ATIS Verified Token; Secure Telephone Identity Revisited (STIR): signing parts of SIP messages based on RFC 4474bis; Blacklists (local and global); Whitelists (local and global); Honeypots; Post call notification (e.g., dial a “*” co

13、de after hanging up); Network Verification of SIP PAI/FROM for IP PBX call originations; Do Not Originate. The pros and cons analysis will address coverage (e.g., IP, circuit switched, wireless), availability, and deployment complexity. 6.1 3GPP PAI Trust Model 6.1.1 Description P-Asserted-Identity

14、and Privacy headers are defined in RFC 3325. The P-Asserted-Identity contains the caller ID information for the call on the INVITE SIP packet. The Privacy header contains information on which parts of the 2Table 5.2 is adapted from ATIS-0300105, Next Generation Interconnection Interoperability Forum

15、 (NGIIF) Auto Dialers Reference Document, Table 8.1, Robocall Matrix. ATIS-1000072 15 caller ID are private. In “trusted” networks, the identity of the Calling Party Number (CPN) is validated and placed in the SIP PAI header. 6.1.2 Pros Useful in “trusted” network deployments for IP to IP calls, ass

16、uming a “trusted” chain of trust between all service providers in the call path. 6.1.3 Cons Does not address CS originated calls. Can be modified by Man In The Middle (MITM) computer security attacks. IP PBXs send PAI to the originating SP, who is likely not authenticating use of the number. Not all

17、 networks are trusted thereby PAI is now tainted. Operational impact determining how to indicate trusted networks. Though the original intent of PAI was that only the contents of the PAI would be presented to the Called Party, carriers have been presenting the untrusted information contained in the

18、SIP FROM header to the Called Party if there is no PAI present. 6.2 Number Signing thereby good calls may be blocked. Spoofers quickly and easily move to different numbers as soon as they encounter blocking. Too easy for spoofers to utilize numbers from global whitelist pool. Administrative overhead

19、. Scalability. There are operational management needs for the white/blacklists if they are carrier-specific, and for customer-specific lists there will be repair issues when customers have some problems or confusion. The lists will need to be maintained and referenced in the termination of each call

20、, so there are routing issues and potential equipment augmentation and ongoing maintenance (even if cloud-based). To the extent these lists are scalable, more resources will need to be dedicated to maintain and manage the lists and ensure accuracy (e.g., a “good” number is not mistakenly included on

21、 a blacklist). 6.5 Whitelists (Local however, no mechanism is currently available that would allow the originating service provider to inform the terminating service provider, and intermediate service provider(s), as applicable, that specific phone numbers have been authenticated and others have not

22、 been authenticated. 7.2.2 Intermediate Service Provider In the call path, the originating carrier provides the call signaling. It is important that the intermediate service provider(s) then reliably passes the calling information in the signaling path to the downstream providers on the terminating

23、side, unaltered. 7.2.3 Terminating Service Provider A terminating service provider can apply spoofing mitigation techniques at the request of the end user. This could be done using techniques such as invoking a Calling Line ID check against a blacklist, and blocking certain calls prior to reaching t

24、he called party. The ability to reliably block unwanted calls and to prevent legitimate calls from being blocked in error is contingent on the integrity of the blacklist and on the accuracy of the calling party information in the call signaling. ATIS-1000072 22 8 Analysis of Mitigation Techniques Ju

25、st like with cybersecurity, protection against calling party spoofing has no silver bullet and can only be realized by a layered approach of mitigation techniques. The mitigation techniques provided in this analysis also apply to illegitimate robocalls. Even with the deployment of the STIR/SHAKEN fr

26、amework, traffic from CS originations and IP Gateways (International & Wholesale) will be an issue for robocalling/spoofing, therefore deployment of other mitigation techniques in a layered approach is required. Everyone has a role in the fight against calling party spoofing: FTC in prosecuting the

27、bad actors. The carriers in deploying an appropriate layering of mitigation techniques to protect their customers. These include mitigation techniques provided by 3rdparty platform/services facilitated by the serving carrier. Consumers in managing their communications. Only the consumer can choose t

28、o block a call/session on a per call/session basis, or give permission to the carrier or 3rdparty on their behalf. The layered approach of mitigation techniques needs to consider the following: Deployment of the STIR/SHAKEN framework. o The STIR/SHAKEN framework will provide a positive verification

29、to the user that they can trust the caller ID information received. With that said, it does not address CS origination/termination. o In addition, the framework can be used to identify if the source of the traffic is coming from an international gateway, and the customer with this knowledge and the

30、number can choose to receive the call or not. o The STIR/SHAKEN framework can be initially deployed using service provider-managed certificates as a more comprehensive and automated certificate management framework is developed and the policy around them is enhanced. Some form of post call reporting

31、 is a MUST, whether via a web portal, call center, or in/post-call signaling (e.g., *xx or indication in SIP BYE) to the terminating carrier or FTC, where appropriate and aligned with Customer Proprietary Network Information (CPNI) rules. Operationalize CDR tracing which provides a mechanism for ide

32、ntifying the source of the calling party spoofing in both CS, PS, and across CS-PS domains. Though parts maybe automated, it is mainly a manual process to start. DNO servers should be deployed at IP gateways, where the gateway blocks numbers that “should not be there” (e.g., 911 DNC List, government

33、 agencies). Blacklist/whitelists are useful, but require data analytics to be effective. Service Providers must verify numbers originating from IP PBXs. Likely performed by the service providers business subscriber Application Server. Considering a layered approach will be required, and since not all Service Providers are the same with respect to the traffic mix they serve, the Federal Communications Commission (FCC) should consider “Safe Harbor” versus prescriptively regulating mitigation techniques.