230 likes | 250 Views
Anti Spoofing / Caller Validation / Robocall Mitigation / Call Validation Display Or “What are you insane Americans up to now?!” NICC London 10 November 2016 Richard Shockey Chairman SIP Forum Shockey Consulting LLC richard@shockey.us +1 703 593 2683.
E N D
Anti Spoofing / Caller Validation / Robocall Mitigation / Call Validation DisplayOr “What are you insane Americans up to now?!”NICC London 10 November 2016Richard ShockeyChairman SIP ForumShockey Consulting LLC richard@shockey.us+1 703 593 2683 SHAKEN and STIRed: Thoughts on the Current State of: Work in progress Disclaimer: The following opinions are those of a deranged, raving lunatic and do not necessarily reflect the opinions of the SIP Forum or its member companies..
Leading Non-Profit IP Communications Industry Association • 16+ Years Old -- Founded in 2000 • 17K+ Individual Membership • Corporate “Full Members” that pay annual dues to support the work of the Forum • Academic Institutions and Research Orgs • Andrew Hutton of Unify is on our Board of Directors and he helped lead our work on SIPconnect 2.0 -- the Leading Profile for SIP Trunking
How We Got Here • We wanted competitive voice markets. We got them, consequently no good deed goes unpunished. • The Central issue now is restoring Trust in the Voice Networks. • Robocalls & Spoofing is the #1 complaint to the U.S. FCC and FTC. • https://consumercomplaints.fcc.gov/hc/en-us/articles/204009760-Consumer-Complaint-Charts-and-Data-Overview • U.S. Congress had held endless hearings. I was asked to testify. • https://energycommerce.house.gov/hearings-and-votes/hearings/modernizing-telephone-consumer-protection-act • Robocalls & Spoofing is the # 1 complaint to OFCOM and the UK ICO • https://ico.org.uk/action-weve-taken/nuisance-calls-and-messages/ • I wrote one of the reports. • http://stakeholders.ofcom.org.uk/binaries/market-data-research/Ofcom_VoIP_RPKI_Report.pdf • Robocalls & Spoofing is the # 1 complaint to the CRTC in Ottawa • London Action Plan • http://londonactionplan.org/news/commitment-to-international-cooperation-london-action-plan-members-sign-mou/
How We Got Here • Voice is still a $120 Billion dollar business across all the access platforms in the U.S. so there is actually a business case to make this work. • Do the math. That means the UK Telecom Industry is trying to protect about 30 Billion Pounds of annual revenue. • “A Billion Here, A Billion There.” It starts to add up to real money! • Shockey’s Law - “Money is the answer what is the question?” • The PSTN is undergoing a radical transition: • In the U.S. with VoLTE, SIP IMS IP-based voice will be 75% of the market in 3-4 years. Up from 35% today. The U.S. is disconnecting the copper at a fast and furious pace. • Existing PSTN Class 5 TDM/SS7 equipment is at or near End of Life [EOL] and cannot be modified. SIP is insecure and subject to all sorts of MiM attacks not to mention SBC’s. • TDM/SIP Gateways only complicate the security issue and are the biggest source of the problem.
STIR & SHAKEN • The IETF STIR (Secure Telephone Identity Revisited) Working Group is developing a mechanism to allow phone numbers to be “signed” at the origin, and “verified” at the termination. ATIS and the SIP Forum have proposed enhancements to make this mechanism practical in the near-term by allowing service providers to perform the “validation” and “verification” on the user’s behalf. Approval at the IETF is expected this year, and will set the stage for the following additional steps: • SHAKEN: A United States service provider profile for STIR will provide implementation guidelines and specify options within the protocol to ensure interoperability between all service providers. The ATIS/SIP Forum IP-NNI Task Force will complete this profile framework (SHAKEN). Additional enhancements to the profile will be developed in 2017. • Display Framework: A framework is required to allow for the display of validated Caller ID information to end users in a consistent and secure format. The ATIS/SIP Forum IP-NNI Task Force is developing this framework, with the initial deliverable expected by early 2017 . • Root Certificate Authority: the signing and verification of calling party information is based on certificates issued by a recognized certificate authority. ATIS is working with the IP-NNI task force to specify the technical requirements and operational procedures for the SHAKEN Root CA. • Testbed: ATIS is facilitating a testbed activity where they have developed a detailed test plan to validate the SHAKEN framework. This will verify the protocol and ensure interoperability between service providers. The STIR/SHAKEN Testbed is targeted to begin 4Q2016 and continue into 2017 and beyond.
So What Happened? The US Strike Force on Robocalls https://www.fcc.gov/news-events/events/2016/10/second-meeting-industry-led-robocall-strike-force 30 Plus U.S. Carriers and the Supplier Community. 130 direct participants. Organized by Chairman Tom Wheeler of the FCC and Chaired by Randall Stephenson, Chairman of the Board of AT&T Authentication Call Validation [ STIR / SHAKEN ] Empowering Consumer Choice Detection, Assessment, Traceback Mitigation Regulatory Support/Root Cause Removal
What STIR – SHAKEN is Proposing We are going to cryptographically sign the SIP/IMS Call Signaling for every single call in the U.S. network. Hopefully/Especially those coming from the International call gateways. STIR / SHAKEN use well-understood, well-deployed Public Key Infrastructure principals and techniques. [PKI] X.509 Certificates & JWD Identity headers RFC 7519 PKI is everywhere. Well-understood technology especially in Financial Services Private Cryptographic Credentials will be held by Originating Service Providers. Public Cryptographic Keys will have to be distributed to Service Providers. Originating Service providers will make an attestation or “affirm” the information contained in the SIP INVITE is true. That means the Caller ID among other data. If the Originating Service Provider cannot “affirm” the data in call then it MUST not sign the INVITE. The Terminating Service Provider will validate the claims in the INVITE and act accordingly.
What will be Attested to.. A. Full Attestation: The signing provider: is responsible for the origination of the call onto the IP based service provider voice network has a direct authenticated relationship with the customer and can identify the customer has established a verified association with the telephone number used for the call. Note: The legitimacy of the telephone number(s) the originator of the call can use is subject to signer specific policy B. Partial Attestation: The signing provider: is responsible for the origination of the call onto the telephone network has a direct authenticated relationship with the customer and can identify the customer has NOT established a verified association with the telephone number being used for the call Note: Each customer will have a unique identifier, The unique identifier also provides a reliable mechanism to identify the customer for forensic analysis or legal action where appropriate. C. Gateway Attestation: The signing provider: is the entry point of the call onto the telephone network has no relationship to the initiator of the call (e.g., international gateways). Note: The signature will provide a unique identifier of the node. (The signer is not asserting anything other than “this is the point where the call entered my network”.)
Signaling Verification Now at 3GPP CT 1 & 3 • Verstat Parameter • TN Validation Passes • TN Validation Failed • No TN Validation • Future: same values above for CNAM [Calling Name Delivery] • Security Considerations: • The Verification Function must drop a verstattel URI parameter received in an INVITE • If the terminating UE does not support the "verstat" parameter value, it must discard the parameter • The terminating UE will act on the "verstat" parameter value, if the 200 (OK) response to the UE REGISTER includes a Feature-Caps header field, as specified in RFC 6809°[190], with a "+g.3gpp.verstat" header field parameter tel URI parameter in the P-Asserted-Identity or FROM header field in a SIP requests P-Asserted-Identity: tel:+14085264000;verstat=TN-Validation-Passed
STIR/SHAKEN ATIS/SIP Forum Call Flows for Call Authentication / Verification It’s the last signaling hop we have had concerns about. (5) After Call Validation has been performed, what is the result and then what does the network or the consumer do? FCC has ruled we can block calls with consumer consent. Can this be combined with Enhanced CNAM?
The Originating SIP Signaling Might Look Like This. (This is what would go on the wire.) INVITE sip:test1@siptest.carrier.net SIP/2.0Via: SIP/2.0/UDP 10.36.78.177:60012;branch=z9hG4bK-524287-1---77ba17085d60f141;rportMax-Forwards: 69Contact: <sip:test2@69.241.19.12:50207;rinstance=9da3088f36cc528e>To: <sip:1000@siptest.carrier.net>From: "Test2"<sip:5712223333@siptest.comcast.net>;tag=614bdb40Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTICSeq: 2 INVITEAllow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, MESSAGE, OPTIONSContent-Type: application/sdpDate: Tue, 16 Aug 2016 19:23:38 GMTIdentity: lW84Z2BbPF8U4AWGg4eeKNlIYAq4j4KexICilTQJsfmEU23d2Nt7-ih1valSKqwzXYctvJqsGzs5NuqAFgrLqg;info=<https://cert-auth.poc.sys.carrier.net/example.crt>;alg=ES256;canon=eyJ0eXAiOiJwYXNzcG9ydCIsImFsZyI6IkVTMjU2IiwieDV1IjoiaHR0cHM6Ly9jZXJ0LWF1dGgucG9jLnN5cy5jb21jYXN0Lm5ldC9leGFtcGxlLmNlcnQifQ.eyJkZXN0Ijp7InVyaSI6WyJzaXA6MTAwMEBzaXB0ZXN0LmNvbWNhc3QubmV0Il19LCJpYXQiOiIxNDcxMzc1NDE4Iiwib3JpZyI6eyJ1cmkiOiJzaXA6NTcxMjIyMzMzM0BzaXB0ZXN0LmNvbWNhc3QubmV0In19Content-Length: 153v=0o=- 13103070023943130 1 IN IP4 10.36.78.177c=IN IP4 10.36.78.177t=0 0m=audio 54242 RTP/AVP 0a=sendrecv
Call Analytics Call Flow at Termination ANALYTICS ENGINE VERIFICATION SERVICE TELEPHONY APPLICATION SERVER CALL FLOW TERMINATING CALL FLOW USER ENTITY
What Data Needs to be Carried in the INVITE to the User Agent / Entity The current consensus is carry the validation data from the last hop to the Consumer/Enterprise User Entity via a set of new Call-INFO parameters. New IETF Drafts. Note the author… https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-callinfo-spam/ https://datatracker.ietf.org/doc/draft-schulzrinne-dispatch-status-unwanted/ What data and how much data is required? Origin ? Confidence Level? Call-Info: Termination_Report=<http://wwww.example.com/5974c8d942f120351143> ;purpose=info ;spam=85 ;type=fraud ;reason=“FCC_DNC list";text=”call your mother” Data set must be useable by all clients. SHAKEN/STIR Highly Valid for National Security / Emergency Services Personnel applications. U.S. GETS etc. We have a very very good story to tell for them.
Enhanced Call Validation Display Options [Good Call] Existing User Display is limited to 15 Character ASCII for CNAM [Calling Name Delivery] and the Calling Party Number. This is what needs to be enhanced. In mobile VoLTE, the handset is a SIP User Agent. Now we can do anything! Scenario 1 Calling party could display business name, address and potentially a picture as well based on Enhanced CNAM, but CNAM was not popular in the UK? Right? Calling party can display alternative number to protect Doctors privacy when responding to consumer inquiries. Protect Emergency Personnel from revealing their true Calling Party Number.
Enhanced Call Validation Display [REALLY BAD Call] Scenario 2 Network has no confidence in the signaling path whatsoever; data analytics indicates possible malicious call. Signaling to consumer indicates very high level of distrust in the call. Network can alternatively block the call based on clear consumer preference.
Applicable to all SIP/IMS platforms Cable today can optionally display Caller ID on TV platforms. This could be added in. A solution can work with any SIP-based Enterprise PBX system either On Premise or Hosted. SIP Forum could take the lead there based on our SIPconnect profiles. Incorporation into 3GPP IMS. We can’t fix POTS or TDM/SS7 nor do we want to.
STIR-SHAKEN / Strike Force / IETF /ATIS-SIP Forum / 3GPP • Multiple SDOs are still looking at various parts of this. It’s still a work in progress. • North American Carriers and providers using NANP [+1] numbers are considering implementation strategies now. • There is a strong desire/ demand /commitment to deploy. • Suppliers are already asking serious questions on U.S. timelines and roadmaps. • ATIS and the SIP Forum will commit to Best Current Practices, Certificate Management and Consumer Display Framework in 2017. • Perhaps an Industry-Wide Agreement on visual Consumer Indicators. • IMHO the Call Validation process will not be effective unless consumers have some sense of how the network judges the call session or the network can act in their behalf.
Other Issues to Be Resolved This will take some time and the powers that be need to understand that. The solution needs to be tested. Carriers are looking into this. ATIS numbering testbed. SIP Forum SIPit. Effects on Post Dial Delay, etc. The issuance of PKI credentials for the Service Providers should IMHO perfectly match the chain of authority for the Numbering Plan itself. That begs the question of OTT providers. Security Reliability and Interoperability are obvious considerations. Consensus on Default PKI Encryption [EC256]? We need rings of defense. STIR/SHAKEN is not a Silver Bullet. Lots of other ideas out there. A lot of them really bad like blacklists. There is no flash cut here.. Maybe direct support for enterprise PKI in the future.
Issues for the U.S. Specifically to Resolve • How will the Certificate Trust Anchor be constituted? • By who? Under what governance and by what statutory authority? • How much will it cost? • There will have to be a Policy on who gets X 509 credentials and why. • The running theory in the U.S. is use of the NECA Operating Carrier Number [OCN] as well as direct access to the NANP. Alternatively SIPD / Alt-SPID. It will be controlled. • Will all of this eventually be mandated by our regulator [FCC]? • I have heard the words “Notice of Inquiry [NOI] - Notice of Proposed Rule Making [NPRM]” – • Report and Order uttered in hushed tones. • Will the Carriers want cost recovery? • Implementing SHAKEN/STIR for Cable Operators is easy...not so easy for incumbents? • Are there privacy issues in inter-carrier data sharing and data analytics related? • Are there Legislative issues that need to be addressed? • Are there holes in “Authority to Act”? • The U.S. “Truth in Caller ID” Act is an oxymoron. Telephone Consumer Protection Act. • Proof of ‘intent’ to defraud is very difficult to prosecute.
We Need Your Help!The SIP Forum and ATIS have a Joint Venture on Network to Network Interfaces. We have 3 Classes of Membership: Full (Corporate) Members that financially support the Forum’s activities [Paid], and Participant (Individual) Members [Free] and Academic Members [Free].Please see me about Full Membership!! Through the SIP Forum, ANY UK Operator and its supplier ecosystem can participate in the ongoing deliberations. First sign up as a Participant member of the SIP Forum and then join the nni@sipforum.org mailing list. SIP Forum/ATIS NNI TF Landing pagehttp://www.sipforum.org/content/view/439/312/