要約

  • InvalidからValidに変わった後、複数上流のネットワークでは測定地点の半数が到達性を回復するまで中央値9分。単一上流では12分だった。
  • ValidからInvalidに変わると順序が逆転する。測定地点の半数が到達不能になるまで、複数上流は42分、単一上流は30分かかった。

上流が二つあれば、経路は早く戻ることがある。同じ二つの経路が、ROAの変更後も経路を長く残すこともある。理由は上流ごとにRPKIの更新を取り込む時刻が違うからだ。

この結果は、RIPE 93で発表されたRPKI状態変更のデータプレーンへの伝播測定から出ている。研究はRIPEリポジトリーで検証済みペイロードを変えた約25,000件の変更を追い、そのうち単一の変化から到達性の回復または喪失を観測できる約1,500件を切り出した。変更を検出すると、300を超えるCAIDA Arkノードからtracerouteを送り、1時間追跡した。

ここでいう時間は、ROAを編集してからでも、最初のバリデーターが取得してからでもない。測定地点の半数がそのプレフィックスへ再び到達できるようになった時、または到達できなくなった時までを測っている。データベースの更新と、通信を運ぶネットワークの変化は別の時計で進む。

有効に戻るときは、複数上流が効く

経路がInvalidからValidに変わった後、測定地点の半数が到達性を回復するまでの中央値は、複数上流で9分、単一上流で12分だった。上流が一つ増えれば、どちらかのバリデーターが新しい情報を先に取得して処理する機会も増える。

中央値の差だけではない。複数上流の分布では、遅い側の尾も短かった。それぞれの上流は別のrelying-partyソフトウェアを動かし、別々の間隔でデータを取得する。独立した更新経路が二つあれば、少なくとも一方が新しい許可を早めに知る可能性が高まる。

複数接続がROAをValidにするわけではない。ROAは起点ASへの許可を示し、バリデーターは公開オブジェクトから状態を計算する。測定された差はその後、上流とルーターが新しい状態を扱う段階に現れる。

無効になるときは、経路が長く残る

変化の向きを逆にすると、結果も逆になる。それまでValidだった経路がInvalidになった後、測定地点の半数が到達性を失うまで、単一上流の中央値は30分、複数上流は42分だった。

バックアップ経路は自分の仕事を続けている。一つの上流がRPKIの状態を更新して経路の扱いを変えても、もう一つのバリデーターが新しい状態をまだ取得していなければ、その経路を引き続き広報することがある。独立した経路が多いほど、移行中もどれかが見える可能性が増す。

障害対応でこの違いは大きい。Invalidは全世界に対する停止命令ではない。各ネットワークがローカルポリシーに従って扱いを決め、バリデーターも同時には更新されない。その間、BGPはまだ広報されている経路を選ぶ。制御プレーンの状態が変わった後も、データプレーンが通信を運ぶことがある。

研究対象は単一起点のケースで、より具体的なカバー経路があるケースは除外された。tracerouteは1時間で終了している。9分、12分、30分、42分は、この条件で観測された到達性変化の中央値だ。運用現場で必要なのは、中央値を自社の復旧時刻に置き換えることではなく、どのプレフィックスを、どの上流が、いつ処理したかを確かめることだ。観測点の数値は比較に役立つが、障害時の経路台帳を代わりに作ってはくれない。

一度の変更に、いくつもの時計

ROAを変更して到達性に反映されるまでには、リポジトリーの公開、バリデーターの取得と検証、状態計算、ルーターへの配布、ローカルポリシーの適用、データプレーンの収束がある。

研究チームはRIPEリポジトリーの配信元を監視し、最適化したバリデーターで早い信号を得た。発表者によると、比較対象の公開バリデーターより最低57秒早く、中央値では5分先行した。この差を使い、多くのネットワークが反応する前にtracerouteを始めた。これは測定手法であり、RIPE NCCがあらゆるバリデーターの取得間隔を決めているという話ではない。

運用者にとって「RPKI更新済み」は、顧客への回答として粗すぎる。リポジトリーの公開時刻が示すのはオブジェクトが出た時点だ。各バリデーターが取得した時刻、ルーターが新状態を使った時刻、プローブから経路が消えた時刻は別々に記録する。RIPE 93の30〜42分という中央値は、その間も測定地点の一部で到達性が続いたことを表している。

出典：RIPE 93の発表概要と録画；RIPE 93全体会議の公式記録；RFC 6811：BGPプレフィックス起点検証。