1. draft-rescorla-fallback-01
STIR WG
Seoul
Nov 2016

2. Thread Necromancy Been a long time…
Charter: “the in-band mechanism must be sent to the IESG for approval and publication prior to the out-of-band mechanism.”
Voila (that’s rfc4474bis)
We’ve been very busy with the in-band work
However, tried to make sure we didn’t close any doors on out-of-band
Use certificates in common, say
We do have an out-of-band charter milestone even
Though we missed the date by a little

3. Do we still need it? Fixing end-to-end IP-IP is not enough
Which original RFC4474 assumptions failed?
SIP deployments mostly involve PSTN interworking
Thus still largely concerned with telephone numbers
Some IP-IP, but much IP-PSTN, PSTN-IP-PSTN, even PSTN-IP
Much problematic robocalling uses IP-PSTN
We also see IP-PSTN-IP
When a gateway has no IP route and drops to the PSTN, which eventually routes back to IP
Fixing end-to-end IP-IP is not enough

4. Limits of in-band RFC4474bis
It’s in-band – end-to-end IP-IP
At best, it addresses the SIP-to-SIP use case
Not going to help with SIP-to-PSTN, PSTN-to-PSTN
We did in-band first because existing deployments need it
Like the IPNNI, now the SHAKEN profile
Some IP-IP deployments may not pass Identity e2e
Difficult to anticipate what will survive administrative boundaries
PAI-based deployments should leak across trust boundaries
And some existing deployments might just block Identity
As they block all new headers; especially B2BUAs

5. PASSporT and out-of-band
PASSporT bridges the gap between in-band and out-of-band
An object format that could be carried by SIP, or another protocol
Some interest in adapting to Jingle (XMPP)
Potentially in WebRTC as well
PASSporT could also be stored for retrieval at a service
Out-of-band here refers to architectures where that happens somewhere along the signaling path
Depends on Internet enabled endpoints and/or gateways

6. Some use cases

7. Basic STIR Out of Band CPS Call Placement Service Store PASSporT
Retrieve
PASSporT
PSTN
Smart
Phone
Smart
Phone
POTS Call
Smart Phones are not just mobile phones, and not just end-user devices

8. Obvious Questions
Okay, how does the originating side know where to find a CPS?
How do we make sure the terminating side comes to exactly the same conclusion?
Need a service discovery mechanism
A few initial ideas in the draft now
And how do we manage the risk that someone other than the called party will fetch it?
Significant privacy concerns
These are the things its time to work on

9. Components of an OOB solution
A service for storing and retrieving PASSporT objects
Or a “Call Placement Service”, CPS
A discovery mechanism for the CPS
Needed both for storing and retrieving
This creates a rendez-vous function, effectively
Smart phones (not necessarily mobile)
Internet enabled: could be an IP PBX or whatever
A robust story about privacy

10. Another Case: IP-PSTN Gateways
CPS
Store
PASSporT
Retrieve
PASSporT
PSTN
SIP/STIR GW
SIP UA
Smart
Phone
POTS Call

11. … and its many cousins We can show a parallel flow for PSTN-IP
Again, where the PSTN endpoint is a smart phone that creates a PASSporT
Or even some local agent does it on behalf of the endpoint
These use cases can look a lot like tunneling
We can’t count on SS7 to carry a PASSporT
Could carry an indication that the original call was signed… but cryptographic assurance is superior
Some use cases where in-band and out-of-band are other used
Out-of-band beomes the “fallback”

12. IP-PSTN-IP even? Sure! CPS Store PASSporT Retrieve PASSporT PSTN
SIP/STIR
SIP/STIR GW GW
SIP UA
SIP UA
POTS Call

13. Well, let’s not get carried away
How do we know a GW is authorized to store it?
Should a GW need a pre-association with the CPS?
Most likely, the authority to store is really invested in the PASSporT itself
Multiple entities may be authorized to sign for the same “orig” in PASSporT
And how do we know a GW is authorized to retrieve it?
Same questions, really
Can’t predict where calls will land, so hard to encrypt for the target
But good CPS design could help…

14. CPS Design Questions
Store PASSporTs under the originating or terminating identity?
What is the key of the lookup?
Currently: terminating side queries for the originating number
Or store under something hashed instead?
Hash of originating TN and terminating TN
Still, possible for an adversary to compute all values offline
Maybe add timestamp of some kind? Expensive hash?
Also, implement polling prevention for single targets

15. Next Steps Already on the charter, targeting WG item adoption
Though not just this second
Given RFC4474bis/PASSporT/certs pass the IESG
Maybe have some virtual interim early next year to discuss further
Appreciate comments/thoughts
Crucial to have a good PSTN story for STIR
I think something along these lines could help