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 – Performance – 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 – Performance – 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.

PoP – Scenario #3 - Performance Challenges caching PoP certificates. Terminating SP must also process 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 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?

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 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). 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).