Summary

  • APNICの公開ステータス履歴は、RSC検証サービスが10月6日01:30から02:45 UTCまで保守中で、展開方針の変更を行っていたと記録した。
  • 02:45に保守完了となり、同時刻のRSSはコンポーネントをOperationalと表示し、平均応答時間を780ミリ秒と記した。

APNICのステータス履歴では、rsc-verifier.apnic.net が10月6日に75分間の保守状態に置かれた。作業中の更新は、展開方針の変更に伴い、保守時間中にエンドポイントが利用できなくなる可能性を示していた。02:45 UTCに記録は「Maintenance completed」へ移行し、ステータスRSSも同時刻にコンポーネントをOperationalと表示した。平均応答時間は780ミリ秒と記録されている。

これはサービス状態の遷移を示すもので、リリースノートではない。公開記録にはソフトウェアの版や変更内容、影響を受けた利用者数、検証失敗、受け入れ試験の結果はない。780ミリ秒は保守終了時にフィードが示した平均値であり、稼働率の保証でも、すべての利用者がオブジェクトを検証できた証明でもない。

公開検証サービスはRPKI Signed Checklist（RSC）を確認する一つの手段にすぎないため、この区別が重要だ。APNICの説明では、RSCは資源保有者が特定のIP資源やASNに結び付いた証明書でファイルや文書に署名できるRPKIオブジェクトである。受領者はrpki-clientを使ってローカルで署名を検証するか、APNICの公開サービスを使える。ウェブサイトは確認を容易にするが、署名の権威そのものではない。

したがって記録から言えるのは、APNICの公開RSC検証エンドポイントが保守状態に入り、記録上の終了時刻にOperationalへ戻ったことまでだ。RSCの署名、証明書発行、リポジトリ公開、ROA処理、BGP経路が中断したことは示していない。特定のRSCが保守中に検証できたかも分からない。ローカル検証は別の経路だが、適切なツールと必要なRPKIデータが必要になる。

この線引きはAPNICの別の最近の告知にも当てはまる。10月1日の告知はRSC検証サービスを含む8サービスに影響した別のロードバランサー障害を説明しているが、確認した公開情報はその事象と10月6日の保守を結び付けていない。10月13日の告知はさらに別のエンドポイント、RPKI rsyncサービスを対象としていた。これらを一続きの停止として扱う根拠はない。

BYOIP、顧客の受け入れ、資源保有の証明にRSCを使う運用者にとって、オンライン検証器は相手とのやり取りを簡素化する。堅牢な手順では、相手がローカル検証を受け入れるか、どの実装を認めるか、どの資源範囲を確認するか、結果をどう保存するかを定めておく。そうすれば、ウェブサイトの可用性はアクセスの問題にとどまり、暗黙の暗号学的依存にはならない。

出典