SHAKEN Jim McEachern Senior Technology Consultant ATIS December 2017.

Slides:



Advertisements
Similar presentations
Internet Protocol Security (IP Sec)
Advertisements

Energy Efficiency and Demand Response: Separate Efforts or Two Ends of a Continuum? A Presentation to: Association of Edison Illuminating Companies Reno,
Interoperability. So the real question: What does your enterprise strategy need to include to take advantage of cloud based services?
Web Authentication Nuts and Bolts: “Authentication Appliance” EDUCAUSE Dartmouth PKI Deployment Summit 7/27/2005 Presented by: Mark Franklin Dartmouth.
IETF 63 - Paris VOIPPEER BoF A Broadband Service Provider’s Perspective on VoIP Peering August 5, 2005 Presented by Jason Livingood.
IV-A 1 IV. Analytical extensions and policy issues.
1 Southern Africa Telecoms Fraud Management, Revenue Assurance and Network Security Meeting.
All Rights Reserved © Alcatel-Lucent 2006 UTelco Business Case Ross MacKinnon, WBG Marketing March 27, 2007
Jim McEachern Senior Technology Consultant ATIS July 8, 2015.
Shelter Employee Engagement & Development Survey
Timeline – Standards & Requirements
IP Transition: Testbeds
Status Update -- ATIS Robocalling and Caller ID Initiatives
STI Interworking with SIP-PBXs
TN Proof-of-Possession and Number Portability
Computer Network Collection of computers and devices connected by communications channels that facilitates communications among users and allows users.
GST Update for Assocham
SHAKEN Governance Authority Next Steps
Timeline - ATIS Involvement
Status Update -- ATIS Robocalling and Caller ID Initiatives
Improving the Defect Life Cycle Management Process
Number portability Dr. ZOUAKIA Rochdi ANRT
IP Router-Alert Considerations and usage
SHAKEN Governance Authority Criteria
EE 107 Fall 2017 Lecture 7 Serial Buses – I2C Direct Memory Access
Chris Wendt, David Hancock (Comcast)
Timeline - ATIS Involvement
Proposed ATIS Standard for Signing of SIP RPH
Verstat Related Best Practices
Reference Architecture and Call Flow Example for SIP RPH Signing
Analysis of Use of Separate Identity Header for SIP RPH Signing
NS/EP Service Provider Credential for SIP RPH Signing
RFC PASSporT Construction 6.2 Verifier Behavior
Proposal for Change/Improvements in STIR/SHAKEN Technical Report on SHAKEN APIs for a Centralized Signing and Signature Validation Server.
RFC PASSporT Construction 6.2 Verifier Behavior
RFC PASSporT Construction 6.2 Verifier Behavior
Doug Bellows – Inteliquent 10/4/2018
Thevenin and Norton “Equivalent” Circuits
Enterprise Scenarios August 2018.
SIP RPH and TN Signing Cross Relationship
TITLE: Baseline Display Guidelines SOURCE*: Hala Mowafy (Ericsson)
Thevenin and Norton “Equivalent” Circuits
Thévenin’s Theorem.
SHAKEN & Know Your Customer
TN-PoP Scenarios Jim McEachern Principal Technologist ATIS August 2018.
Change Proposals for SHAKEN Documents
SIP RPH Signing Use Cases
August 5, 2005 Presented by Jason Livingood
RFC Verifier Behavior Step 4: Check the Freshness of Date
SHAKEN Jim McEachern Senior Technology Consultant ATIS December 2017.
Proposal for Change/Improvements in STIR/SHAKEN Technical Report on SHAKEN APIs for a Centralized Signing and Signature Validation Server.
Incremental Assignment (fixed demand)
Issuing delegate certs to Customer AF using Cross-Certification
Thevenin and Norton “Equivalent” Circuits
IPNNI SHAKEN Enterprise Models: LEMON TWIST
In 5 minutes.
Doug Bellows – Inteliquent 3/18/2019
Enterprise Structure For Use Case Application of Various Token/Cert Proposals Presented by: Rebekah Johnson.
STIR/Shaken: Mitigating Illegal Robocalling and Caller ID Scams
SHAKEN for Presented to: Ericsson Contact:
Calling Party Identity
Enterprise Use Cases and A-Level Attestation
Enterprise Certificates DRAFT
Enterprise Use Cases and A-Level Attestation
Proposed Changes to STI-VS "iat" freshness check
STIR / SHAKEN for 911 use of SHAKEN 8/7/2019
Calling Party Identity
Enterprise Certificates
draft-ietf-stir-oob-02 Out of Band
Toll-Free Number Assignment and Administration – SHAKEN/STIR Delegate Certificates Enterprise Origination Julio Armenta
Presentation transcript:

SHAKEN Jim McEachern Senior Technology Consultant ATIS December 2017

PoP – Scenario #1 – Terminate PoP & Originate SHAKEN SP-A Analytics PoP SHAKEN PoP AS PoP VS STI AS STI VS … SP-B SP-C SP-D SP-Z

PoP – Scenario #2 – PoP E2E … SP-A Analytics PoP SP-B SP-C SP-D SP-Z AS PoP VS … SP-B SP-C SP-D SP-Z

PoP – Scenario #3 – PoP & SHAKEN SP-A Analytics PoP PoP AS PoP VS … SP-B SP-C SP-D SP-Z STI AS STI VS SHAKEN

PoP – Scenario #1 - Performance Originating SP must process PoP identity header and factor results into attestation in SHAKEN = No impact on terminating SP SP-A Analytics PoP SHAKEN PoP AS PoP VS STI AS STI VS … SP-B SP-C SP-D SP-Z + Originating SP can cache PoP certificates and refresh every time call is made from their customer PBx to any destination.

PoP – Scenario #2 – Local Cache + Originating SP does not need to do anything. = Terminating SP processes PoP identity header with complexity comparable to SHAKEN identity header. SP-A Analytics PoP PoP AS PoP VS … SP-B SP-C SP-D SP-Z - Terminating SP could cache PoP certificates but can only refresh every time call is made from a given customer PBx to a given VS function.

PoP – Scenario #2 – SP Cache + Originating SP does not need to do anything. = Terminating SP processes PoP identity header with complexity comparable to SHAKEN identity header. SP-A Analytics Cache PoP PoP AS PoP VS … SP-B SP-C SP-D SP-Z = - Terminating SP could provide a centralized cache for PoP certificates and refresh every time call is made from a given customer PBx to any VS function within the terminating SP network. - Incremental cost => terminating SP Incremental revenue => originating SP … especially with “bill and keep”. However, this may be a very small portion of overall SIP signalling load.

PoP – Scenario #3 - Performance Terminating SP must also process PoP identity header with complexity comparable to SHAKEN identity header. Challenges caching PoP certificates. SP-A Analytics PoP PoP AS PoP VS … SP-B SP-C SP-D SP-Z STI AS STI VS SHAKEN = = Terminating SP processes SHAKEN identity header. Originating SP generates normal SHAKEN identity header.

PoP – Scenario #1 - Traceback Traceback to the source of the “problem” (i.e., SP-A and enterprise) is complicated by having to go to SP-B and correlate SHAKEN origid with PoP certificate. SP-A - Analytics PoP SHAKEN PoP AS PoP VS STI AS STI VS … SP-B SP-C SP-D SP-Z Does knowing that SP-B originated the call onto the network add any value? =

PoP – Scenario #2 - Traceback Traceback points directly to the SP that issued the PoP certificate and then to the enterprise. + SP-A Analytics PoP PoP AS PoP VS … SP-B SP-C SP-D SP-Z = “Originating SP” role is equivalent to intermediate (transit) providers. -

PoP – Scenario #3 - Traceback Traceback points directly to the SP that issued the PoP certificate and then to the enterprise. + SP-A Analytics PoP PoP AS PoP VS … SP-B SP-C SP-D SP-Z STI AS STI VS SHAKEN = Traceback also points to the SP that originated the call onto the network. Is this information useful?

Other Considerations: Malformed Identity Headers Is there value in the originating SP verifying PoP Identity header to spot problems (e.g., hacked PBX) closer to the source? SP-A Analytics PoP SHAKEN PoP AS PoP VS STI AS STI VS … SP-B SP-C SP-D SP-Z

Other Considerations: Lawful Intercept Scenario 1 Do any of these scenarios have advantages or disadvantages for lawful intercept? Scenario 2 Scenario 3

Conclusions Allowing PoP Identity headers to go end-to-end does add some new responsibilities on the terminating SP: They must support PoP Identity headers Caching public certs is less efficient than for standard SHAKEN Centralized caching for all calls to terminating SP improves efficiency Bill & Keep may create misalignment between costs and benefits (though may be small) Terminating PoP Identity headers at the originating SP does not improve traceback, and may even complicate traceback. If PoP certs go end-to-end, the originating SP could add a second, SHAKEN Identity header if they needed to (e.g., if terminating SP could not verify PoP Identity header). Are there any implications for lawful intercept? Important to verify that allowing PoP Identity headers to go end-to-end does not cause problems for other use cases (e.g., NS/EP).