要約

  • RIPE NCCが公開したRIPE 93のRPKI更新概要は、予備分析でASPAオブジェクトからプロバイダーASNが最大9%漏れているとする。上流の記載忘れと、提供者も兼ねる相手を単なるピアと見なすことを挙げた。
  • RIPE NCCのASPA資料では、署名済みの一覧から実際の提供者が抜けると、その提供者経由の経路が拒否され得る。現行ダッシュボードにはBGPから得た上流候補の提示がない。

「ピア」の一語では足りない

運用台帳に「ピア」と書いた相手が、別の経路では上流にもなる。人間にはおなじみの曖昧さだが、ASPAの一覧は曖昧なまま署名できる。RIPE NCCはその隙間を、RIPE 93のRPKI更新概要で数値にした。予備分析によると、プロバイダーASNの最大9%がASPAオブジェクトから抜けている。ここで数えているのはプロバイダーASNであり、ASPAオブジェクトの9%やネットワークの9%ではない。

ASPAは、あるASの保有者が正当な上流として認めるASNを署名して公表する仕組みだ。鍵と署名が正しくても、書かれた一覧に欠員があればその欠員はそのまま公表される。暗号が証明するのは誰が申告したかという事実。相手が現場で何をしているかは、運用者が調べるしかない。

RIPE NCCのASPAガイドは境界を具体的に示す。上流プロバイダーに加え、ピアリングと提供者の両方の役割を持つ隣接AS、経路上で提供者のように見える非透過型ルートサーバーを含める。一方、横方向だけのピアや顧客は含めない。セッション名をコピーする作業ではなく、役割を洗い直す作業になる。

書かなかった名前は否定として読まれる

ガイドによると、署名済みASPAに提供者が載っていれば関係は Provider、同じASPAに載っていなければ Not Provider と扱われる。そもそもASPAがない場合は No Attestation。後者の不明と、前者の明示的な不一致は重みが違う。半分だけ正しい署名一覧は、実際の上流について否定的な判定を生む。

RIPE NCCは、漏れた提供者を通る経路が拒否される可能性を明記している。どの経路がどう扱われるかは受信側のASPA検証とフィルタ設定次第だ。公開概要には実際の経路拒否件数はない。いま確認すべきものは、契約したトランジット、混合役割の隣接AS、ルートサーバーの運用と、署名済みオブジェクトの差分だ。

現行のRPKIダッシュボードは、BGPに見える上流候補を示さない。RIPE NCCは今回、ASPAの提案機能を改善する計画を説明する予定だという。候補表示には観測した経路と時刻を添えるべきだろう。隣り合っていることは手掛かりだが、誰に上流権限を与えるかはAS保有者が決める。

数字の裏側も公開してほしい

「最大9%」の対象期間、分子・分母、役割判定方法は概要にない。それらを示す測定資料が出れば、どの範囲に当てはまる数字か判断できる。先にできるのは、緑色の署名表示ではなく現在の上流構成を見ながらASPAを点検することだ。

署名は申告者の名前を保証する。提供者の名簿は、動いているネットワークと照合して初めて役に立つ。

出典:RIPE 93 RPKI更新概要、RIPE NCC ASPAガイド、IETF ASPA検証ドラフト第29版。