プロンプトとコンテキスト
複数の電話通信事業者は、SIPシグナリングがエンドツーエンドでPASSporTを伝送することを保証できません。RFC 9888に基づいてアウトオブバンド（OOB）のCall Placement Service（CPS）を設計し、ディスカバリ、送信と取得、mTLS認可、有効期限、ゲートウェイの相互運用性、およびプライバシーリスクについて説明してください。
RFC 9888は、SIP経由でPASSporTを確実に伝送できない大規模な通信事業者を対象としています。OOB Authentication Service（OOB-AS）はHTTP経由でCPSにPASSporTを送信し、OOB Verification Service（OOB-VS）はプルによって取得するか、プッシュによって受信します。面接では、汎用的なRESTバケットではなく、信頼境界とオブジェクトの有効期間が評価されます。
面接官が評価するポイント
面接官は、STIRクレデンシャル、PASSporT、CPS、OOB-AS、およびOOB-VS間の明確な責務分担、信頼できるCPSアドバタイズメントと電話番号帯認可モデル、偽造・リプレイ・フラッディング対策としてのmTLS・クォータ・短い鮮度ウィンドウ、そしてマルチプロバイダー取得、ゲートウェイ変換、メタデータのプライバシー、障害ポリシーに関する具体的な説明を評価します。
明確にすべき前提条件
参加者とネットワーク境界
誰がPASSporTに署名するのか、着信側事業者のCPSを誰が運用するのか、OOB-VSがプルするのかプッシュを購読するのか、そしてどのパスがPSTNゲートウェイやレガシーネットワークを通過するのかを特定します。
真正性とプライバシーの目標
システムが発信者番号の真正性を証明するのか、番号偽装（スプーフィング）を低減するのか、あるいは通話メタデータも秘匿する必要があるのかを明確にします。RFC 9888のプロバイダーモデルでは、CPSは通話参加者によって運用されるため、そのプライバシー前提はオープンなインターネットOOBサービスとは異なります。
レイテンシと保持期間
着信表示を行う前に許容される最大遅延、クロックスキューの許容範囲、およびPASSporTが検証完了までのみ必要かどうかを定義します。CPSは長期的なアーカイブではありません。
30秒の回答
「SPCまたは電話番号帯をHTTPS URIに紐付ける署名付きCPSアドバタイズメントを公開します。OOB-ASは信頼されたSTIRクレデンシャルを使用してmTLS経由でPASSporTを送信し、CPSは宛先を認可してクォータを適用し、各オブジェクトを鮮度ウィンドウの間のみ保持します。OOB-VSは着信後にプルするか、番号帯ごとにプッシュを購読できます。マルチプロバイダーCPSは、PASSporTの宛先とTNAuthListを使用して読み取りを認可する必要があります。ゲートウェイは委任されたスコープ内でのみ変換を行います。有効期限切れ、重複、不正リクエスト、レイテンシを計測し、メタデータ収集の境界を文書化します。」
ステップバイステップのソリューション
ステップ 1: 信頼とデータフローのマッピング
OOB-ASはPASSporTを作成または伝送し、着信側CPSに送信します。CPSはアドバタイズメントとローカルポリシーに基づいてこれを受理します。OOB-VSは、検証が認可されている宛先範囲のみを受信します。検証側では引き続きPASSporTの署名、orig、dest、および鮮度を検証します。CPSから届いたからといって暗号学的検証を省略できるわけではありません。
ステップ 2: 安全なCPSアドバタイズメントの公開
アドバタイズメントは、SPCまたは電話番号帯をHTTPS CPS URIにマッピングします。これは信頼されたSTIRクレデンシャルで署名される必要があり、受信者は署名者のTNAuthListとアドバタイズされた範囲を比較します。これにより、特定のクレデンシャル保持者が範囲をハイジャックするのを防ぎます。ディスカバリには設定、データベース、またはセキュアDNSを使用できますが、キャッシュにはバージョニングと有効期限が必要です。
ステップ 3: 送信の認可
OOB-ASはCPSとの間でTLS（望ましくはmTLS）を確立し、CPSは証明書が許可された送信事業者のものであることを確認します。プロバイダー、番号帯、レートごとにクォータを適用し、未知のクレデンシャル、不正な宛先、フラッディングを拒否します。攻撃者がサービスを探る手掛かりとならないよう、内部ポリシーの詳細を露出させることなく、観測可能な受理、拒否、重複ステータスを返します。
ステップ 4: 保持期間と鮮度の適用
PASSporTは取得に必要な期間のみ保持し、鮮度インターバルを超えて保持してはなりません。RFC 9888では、このプロバイダーフローに対して最大60秒と規定されています。同一オブジェクトが無期限にリプレイされないよう、orig、dest、通話識別子、およびPASSporT固有のデータを使用して重複を排除します。有効期限切れの処理は、臨時のクリーンアップジョブではなく、強制される不変条件（invariant）である必要があります。
ステップ 5: プルおよびプッシュ取得のサポート
プルモードでは、OOB-VSは埋め込みPASSporTのない着信を受信した後にCPSに問い合わせます。プッシュモードでは、番号帯またはSPCによって購読し、プロアクティブにオブジェクトを受信します。マルチプロバイダーCPSは、事業者に配信する前にPASSporTのdestをチェックします。プッシュの失敗によって署名の鮮度が延長されることはありません。検証処理は「まだ利用できない」と「無効」を区別する必要があります。
ステップ 6: ゲートウェイとフォールバックの制約
ゲートウェイは、SIP INVITEからPASSporTを抽出してレガシーPSTN事業者にサービスを提供するCPSに送信したり、ダウンストリームプロトコル用にOOBオブジェクトを変換したりする場合があります。そのクレデンシャルには明示的に委任されたスコープが必要であり、ネットワーク全体の権限を付与することはできません。CPSが利用できない場合に未検証の通話を継続するか、遅延させるか、ブロックするかは、プロダクトおよび規制ポリシーの判断となります。
ステップ 7: プライバシー、運用、訓練の網羅
CPSは通話メタデータを閲覧できるため、フィールド、保持期間、監査アクセスを制限します。送信成功率、不正リクエスト、重複、期限切れ、プルレイテンシ、プッシュバックログ、プロバイダーごとのクォータ拒否を追跡します。証明書の失効、範囲の重複、リプレイ、プロバイダー間での不正読み取り、アドバタイズメントの改ざん、PSTNゲートウェイのパケット損失、部分的なCPS障害をテストします。
模範解答
まず、参加者と認可範囲を登録します。各着信側プロバイダーは、SPCまたは電話番号帯をHTTPS URIに紐付けるSTIR署名付きCPSアドバタイズメントを公開します。OOB-ASはmTLS経由でPASSporTを送信します。CPSはクレデンシャル、宛先、番号帯、クォータを検証し、オブジェクトを鮮度期間中のみ保持します。RFC 9888では最大保持期間は60秒とされています。OOB-VSは未署名の着信後にプルするか、プッシュを購読できます。マルチプロバイダーCPSはdestとTNAuthListを使用して読み取りを認可します。PSTNゲートウェイは委任されたスコープ内でのみ抽出または変換を行います。サービスは、欠落、期限切れ、無効なクレデンシャルを区別し、明示的なフォールバックポリシーを適用し、メタデータアクセスを監査し、フラッディング、リプレイ、レイテンシ、クォータ拒否を計測します。
よくある間違い
- 間違い: CPSをパブリックなオブジェクトストレージとして扱う。 → 失敗の理由: 不正な書き込みや読み取りにより、偽造、漏洩、フラッディングが発生します。 → 修正方法: 信頼できるクレデンシャル、mTLS、番号帯認可、プロバイダークォータを使用します。
- 間違い: 長期的な調査のためにPASSporTを保持する。 → 失敗の理由: 保持期間が長くなると、リプレイやメタデータ漏洩のリスクが高まります。 → 修正方法: 検証に紐付いた短いTTLを使用し、削除を強制します。
- 間違い: origのみで読み取りを認可する。 → 失敗の理由: マルチプロバイダーアクセスでは、destおよびプロバイダーのTNAuthListも制約する必要があります。 → 修正方法: 送信と取得の両方で宛先範囲を認可します。
- 間違い: ゲートウェイによる抽出後にPASSporTを盲信してしまう。 → 失敗の理由: プロトコル間でオブジェクトを移動しても検証の代わりにはなりません。 → 修正方法: 暗号検証を維持し、ゲートウェイには最小限の委任権限のみを与えます。
フォローアップ質問と回答
OOB-ASのmTLS証明書が漏洩した場合はどうなりますか？
証明書を失効させ、その送信権限を停止し、そのプロバイダースコープを隔離します。すでに送信されたオブジェクトについても、PASSporTの鮮度と署名検証が依然として必要です。接続の身元証明だけでは不十分です。
なぜCPSアドバタイズメントに署名するのですか？
アドバタイズメントはPASSporTをどこに送信すべきかを決定します。署名によりCPS URIがSPCまたは電話番号帯に紐付けられ、攻撃者が管理するコレクターへのリダイレクトを防止します。
取得はプルとプッシュのどちらにすべきですか？
プルはシンプルで、実際の通話によってトリガーされます。プッシュは検証遅延を減らすことができますが、購読認可、バックログ処理、失効管理が必要です。大規模な導入では、プロバイダーや番号帯ごとにこれらを組み合わせることができます。
CPSが利用できない場合、通話をブロックすべきですか？
スプーフィング防止インジケーターと規制による通話ブロックは切り離して考える必要があります。通常の通話は未検証ラベルを付けて継続させ、リスクの高いフローは遅延またはブロックする運用が考えられますが、ポリシー、タイムアウト、誤検知メトリクスを明確にしておく必要があります。