総合面接：RPKIとBGPルートオリジン検証をどう説明するか？

プロンプトと適用可能なコンテキスト

面接官が、誤ったASからアナウンスされたプレフィックスを提示し、そのアナウンスがアドレス保持者によって認可されているかどうかをどのように判断するか尋ねてきます。RPKI、Route Origin Authorizations（ROA）、およびBGP Prefix Origin Validation（ROV）について説明し、ROVが検証するのはAS_PATH全体ではなくオリジンASであることを明確に伝えてください。これはネットワーク、CDN、クラウドプラットフォーム、インフラストラクチャ関連の職種に適しています。

面接官がテストしていること

優れた回答は、RPKIを「暗号化されたBGP」と呼ぶのではなく、「どのASがどのプレフィックスを発信（オリジネーション）するよう認可されているか」から始まります。候補者は、VRPとBGPルートプレフィックスおよびオリジンASがどのように比較されてValid、Invalid、またはNotFoundが生成されるか、ポリシーがそれらの状態をどのように消費するか、キャッシュ間で差異が生じる理由、そしてInvalidのフィルタリングがなぜ巻き添え被害を引き起こす可能性があるかを説明する必要があります。「RPKIはあらゆるハイジャックを防ぐ」という回答は、候補者がその適用境界を理解していないことを示します。

最初に明確にすべき質問

保護しているのはプレフィックスのオリジンなのか、それとも完全なAS_PATHの検証なのか？ ROVが答えるのは前者のみです。
議論しているのはROAの発行、ルータによる検証、それともインバウンドポリシーのフィルタリングのどれか？これらは異なるコントロールポイントです。
冗長化されたROAキャッシュと明確なキャッシュ停止ポリシーがあるか？キャッシュ停止によって、突如すべてのルートがInvalidになるようなことがあってはなりません。
優先事項はセキュリティ、到達性、それともロールバックの速度か？厳格なフィルタリングには変更ウィンドウとオブザーバビリティ（可観測性）が必要です。

30秒での回答

「プレフィックス保持者に、オリジンASと最大プレフィックス長（maximum prefix length）を認可するROAを発行してもらいます。バリデータが署名されたオブジェクトを処理してVRPを生成し、BGPスピーカーがルートプレフィックスとASPATHの右端にあるオリジンASを比較します。カバーしており一致していればValid、カバーしているが一致しなければInvalid、カバーするVRPがなければNotFoundとなります。ポリシーによってInvalidを拒否し、NotFoundを個別に処理できますが、これはオリジンを保護するものであり、ASPATHの各ホップを保護するものではありません。分散キャッシュは一時的に不整合になる可能性があるため、展開前にはROAのカバレッジ、キャッシュの鮮度、ロールバック手順、および到達性を確認します。」

ステップごとの詳細な回答

認可を定義する。 ROAは、IPプレフィックス、最大プレフィックス長、および認可されたオリジンASをバインドする署名付きオブジェクトです。どのASがどのプレフィックスを発信できるかを規定するものであり、すべてのBGP属性に署名するわけではありません。
検証データを構築する。 RPKIは、リソース証明書、署名付きオブジェクト、および分散リポジトリに依存しています。バリデータはこれらを定期的に取得および検証してローカルVRPを構築します。BGPスピーカーは、ルートごとに完全な証明書検証を行う代わりにローカルキャッシュを使用します。
3つの状態を計算する。 ルートは、VRPがそのプレフィックスをカバーしオリジンASと一致するときはValid、カバーするVRPが存在するもののどれも一致しないときはInvalid、プレフィックスをカバーするVRPが存在しないときはNotFoundになります。より具体的な（more-specific）ルートであっても、ROAの最大長を満たす必要があります。
ポリシーと連携させる。 インバウンドポリシーは状態とマッチングさせることができます。一般的には、Invalidを拒否し、NotFoundはログ記録や信頼度を下げる処理を行い、Validを受け入れます。誤ったROAやキャッシュの問題が大規模な障害を引き起こさないよう、ポリシーはロールバック可能にしておきます。
キャッシュの境界を明記する。 RFC 6811では、グローバルなRPKIを緩やかな一貫性（loosely consistent）を持つ分散ビューとして定義しています。キャッシュは異なるタイミングで更新されるため、一時的に差異が生じることがあります。単一のルートアラートを即座に攻撃と決めつけるのではなく、VRPのタイムスタンプ、キャッシュセッション、および状態の分布を監視します。
保護の境界を説明する。 ROVは不正なオリジンや一部のハイジャックを緩和できます。NISTはこれを、関連する設定ミスや悪意ある攻撃を低減するための標準ベースのプラットフォームと位置づけています。中間ASが正しく動作したことを証明するものではなく、単独ですべてのルートリークを阻止できるわけではありません。
安全な展開を計画する。 観察モードから開始し、InvalidとNotFoundを検査し、限定されたネイバーのセットに対して拒否を有効化します。各変更の前に、ROAの最大長、冗長なアナウンス、およびロールバックコマンドを確認します。実施後は、到達性、Invalidのボリューム、キャッシュの健全性、およびアラートの遅延を監視します。

高品質な回答例

「この問題を認可、検証、ポリシーの3つに分解して考えます。プレフィックス保持者は、許可されたオリジンASと最大プレフィックス長を指定したROAを発行します。RPKIバリデータが署名付きオブジェクトをチェックしてVRPを生成し、BGPスピーカーが受信した各プレフィックスをASPATHのオリジンASと比較します。カバーしており一致すればValid、カバーしているが一致しなければInvalid、カバーするオブジェクトがなければNotFoundです。ルータはInvalidを拒否し、NotFoundを個別のポリシー選択として扱うことができますが、これはASPATH全体を検証したり、すべてのルートリークを解決したりするわけではありません。観察モードで展開し、ROAのカバレッジと最大長を確認し、キャッシュの鮮度と到達性を監視した上で、ロールバック手段を確保しながら段階的にフィルタリングを有効化します。」

よくある間違い

兆候 → 「RPKIはAS_PATH全体を検証する。」 失敗の理由 → RFC 6811の状態判定は、プレフィックスのカバレッジとオリジンASを比較するものです。 修正方法 → ROVをオリジン検証と呼び、パスの完全性については別の制御策を挙げてください。
兆候 → 「ROAのないルートは悪意がある。」 失敗の理由 → NotFoundはカバーするデータが存在しないことを意味し、アナウンスが虚偽であることを意味するわけではありません。 修正方法 → NotFoundとInvalidを異なるポリシー入力として扱ってください。
兆候 → 「キャッシュが停止すると、すべてのルートがInvalidになる。」 失敗の理由 → 分散キャッシュは利用不能になったり古くなったりすることがあります。急なフィルタリングはインシデントを拡大させるおそれがあります。 修正方法 → キャッシュの健全性チェック、古いデータの安全な取り扱い、およびロールバックについて説明してください。
兆候 → 「ROAの最大長を適当に設定する。」 失敗の理由 → 短すぎると正当なmore-specificアナウンスが無効化され、長すぎると認可範囲が過度に拡大します。 修正方法 → 実際のアナウンスセットからmaxLengthを導き出してください。

フォローアップの質問と回答

なぜROAのないルートはInvalidではなくNotFoundになるのですか？

Invalidになるには、カバーするVRPが存在し、かつその認可されたオリジンが一致しないことが必要です。カバーするVRPが存在しない場合、状態はNotFoundになります。ポリシーによって証拠がないルートをどう扱うかは選択できますが、証拠の不在は不正なオリジンの証明にはなりません。

ROAが誤って発行された場合はどうなりますか？

正当なルートがInvalidになり、厳格なポリシーを持つネイバーによって拒否される可能性があります。ROAを取り消すか修正し、リポジトリとキャッシュの更新を待ちます。状態の変化を監視し、一時的なポリシーロールバック経路を確保しておきます。

RPKIでルートリークを防ぐことはできますか？

必ずしも防げるとは限りません。ROVはオリジンASが認可されているかどうかをチェックするだけであり、そのASが認可されていないネイバーにプレフィックスを伝播してしまう可能性は残ります。ルートリークを減らすには、プレフィックスフィルタ、ネイバーロール（neighbor roles）、およびエクスポートポリシーが必要です。

フィルタリングによって到達性が損なわれていないことをどのように確認しますか？

ロギングモードから開始し、ROAと最大長をサンプリングしながらValid、Invalid、NotFoundをルーティングテーブルと比較します。段階的に拒否を有効化し、到達性プローブ、キャッシュの健全性、ネイバーセッション、Invalidのボリュームを監視し、いずれかのシグナルが悪化した場合はポリシーをロールバックします。