Prompt and context
Several telephone service providers cannot guarantee that SIP signaling carries a PASSporT end to end. Based on RFC 9888, design an out-of-band Call Placement Service (CPS) and explain discovery, submission and retrieval, mTLS authorization, expiry, gateway interoperability, and privacy risks.
RFC 9888 targets large service providers that cannot reliably carry PASSporTs through SIP. An OOB Authentication Service (OOB-AS) submits a PASSporT to a CPS over HTTP, and an OOB Verification Service (OOB-VS) retrieves it by pull or receives it by push. The interview tests trust boundaries and object lifetime, not a generic REST bucket.
What the interviewer evaluates
The interviewer looks for clear responsibilities among STIR credentials, PASSporTs, the CPS, OOB-AS, and OOB-VS; a trustworthy CPS advertisement and telephone-number-range authorization model; mTLS, quotas, and short freshness windows against forgery, replay, and flooding; and a concrete explanation of multi-provider retrieval, gateway conversion, metadata privacy, and failure policy.
Clarifying questions
Participants and network boundaries
Identify who signs the PASSporT, who operates the destination provider's CPS, whether OOB-VS pulls or subscribes to pushes, and which paths cross a PSTN gateway or legacy network.
Authenticity and privacy goals
Clarify whether the system must prove caller identity, reduce number spoofing, or also hide call metadata. In RFC 9888's provider model, the CPS is operated by a call participant, so its privacy assumptions differ from an open Internet OOB service.
Latency and retention
Define the maximum delay allowed before showing a call indicator, clock skew tolerance, and whether a PASSporT is needed only until verification. A CPS is not a long-term archive.
30-second answer
“I would publish a signed CPS advertisement binding an SPC or telephone-number range to an HTTPS URI. OOB-AS would submit PASSporTs over mTLS using a trusted STIR credential; the CPS would authorize the destination, apply quotas, and retain each object only through its freshness window. OOB-VS could pull after a call arrives or subscribe to pushes by range. A multi-provider CPS must authorize reads using the PASSporT destination and TNAuthList. Gateways only translate within a delegated scope. I would measure expiry, duplicates, unauthorized requests, and latency, and document the metadata collection boundary.”
Step-by-step solution
Step 1: Map trust and data flow
OOB-AS creates or carries the PASSporT and submits it to the destination CPS. The CPS accepts it under the advertisement and local policy. OOB-VS receives only destination ranges it is authorized to verify. Verification still checks the PASSporT signature, orig, dest, and freshness; arriving from a CPS does not replace cryptographic verification.
Step 2: Publish a secure CPS advertisement
The advertisement maps an SPC or telephone-number range to an HTTPS CPS URI. It should be signed by a trusted STIR credential, and the receiver compares the signer TNAuthList with the advertised range. This prevents any credential holder from hijacking a range. Discovery may use configuration, a database, or secured DNS, but caches need versioning and expiry.
Step 3: Authorize submissions
OOB-AS establishes TLS with the CPS, preferably mTLS, and the CPS checks that the certificate belongs to an allowed submitting provider. Apply quotas by provider, range, and rate; reject unknown credentials, wrong destinations, and floods. Return observable acceptance, rejection, and duplicate statuses without exposing internal policy details that help attackers probe the service.
Step 4: Enforce retention and freshness
Keep a PASSporT only as long as retrieval requires and never beyond its freshness interval; RFC 9888 describes a maximum of 60 seconds for this provider flow. Deduplicate using orig, dest, a call identifier, and PASSporT-specific data so that the same object cannot be replayed indefinitely. Expiry must be an enforced invariant, not an occasional cleanup job.
Step 5: Support pull and push retrieval
In pull mode, OOB-VS queries the CPS after receiving a call without an embedded PASSporT. In push mode, it subscribes by range or SPC and receives objects proactively. A multi-provider CPS checks the PASSporT dest before delivering it to a provider. Push failure does not extend signature freshness; verification should distinguish “not available yet” from “invalid.”
Step 6: Constrain gateways and fallback
A gateway may extract a PASSporT from a SIP INVITE and submit it to a CPS serving legacy PSTN providers, or translate an OOB object for a downstream protocol. Its credential must have an explicit delegated scope and cannot grant network-wide authority. Whether to continue an unverified call, delay it, or block it when CPS is unavailable is a product and regulatory policy decision.
Step 7: Cover privacy, operations, and drills
The CPS sees call metadata, so limit fields, retention, and audit access. Track submission success, unauthorized requests, duplicates, expiries, pull latency, push backlog, and quota rejection by provider. Test certificate revocation, overlapping ranges, replay, cross-provider reads, altered advertisements, PSTN gateway loss, and partial CPS outages.
Model answer
I would first register participants and authorization ranges. Each destination provider publishes a STIR-signed CPS advertisement binding its SPC or telephone-number range to an HTTPS URI. OOB-AS submits PASSporTs over mTLS; the CPS validates the credential, destination, range, and quota, then retains the object only through freshness. RFC 9888 describes a maximum retention of 60 seconds. OOB-VS can pull after an unsigned call arrives or subscribe to pushes. A multi-provider CPS authorizes reads using dest and TNAuthList. A PSTN gateway may extract or translate only within delegated scope. The service distinguishes missing, expired, and invalid credentials, applies an explicit fallback policy, audits metadata access, and measures flooding, replay, latency, and quota rejection.
Common mistakes
- Mistake: Treating the CPS as public object storage. → Why it fails: Unauthorized writes and reads enable forgery, leakage, and flooding. → Fix: Use trusted credentials, mTLS, range authorization, and provider quotas.
- Mistake: Retaining PASSporTs for long-term investigation. → Why it fails: A longer window increases replay and metadata exposure. → Fix: Use a short TTL tied to verification and enforce deletion.
- Mistake: Authorizing reads only by orig. → Why it fails: Multi-provider access must also constrain dest and the provider's TNAuthList. → Fix: Authorize the destination range at both submission and retrieval.
- Mistake: Trusting a PASSporT after gateway extraction. → Why it fails: Moving the object between protocols does not replace verification. → Fix: Preserve verification and give the gateway minimal delegation.
Follow-ups and responses
What if an OOB-AS mTLS certificate leaks?
Revoke it, stop its submission authority, and isolate its provider scope. Already submitted objects still require PASSporT freshness and signature validation; connection identity alone is insufficient.
Why sign the CPS advertisement?
The advertisement determines where a PASSporT should be submitted. Signing binds the CPS URI to an SPC or telephone-number range and prevents redirection to an attacker-controlled collector.
Pull or push retrieval?
Pull is simple and triggered by actual calls. Push can reduce verification delay but needs subscription authorization, backlog handling, and revocation. Large deployments can combine them by provider and number range.
Should a call be blocked when the CPS is unavailable?
Separate an anti-spoofing indicator from a regulatory block. Ordinary calls may continue with an unverified label; high-risk flows may delay or block, but the policy, timeout, and false-positive metrics must be explicit.