要約

  • ARINではCustomer ASNごとに固有のASPAを作り、そのProvider AS集合を変更する。人間には一社の追加でも、システム上は完全な集合の置換である。
  • ARINの説明は、RPKIデータベースへの即時反映、24時間以内の公開リポジトリ掲載、数分ごとのリポジトリ更新、独立バリデーターでの確認を分けている。成功は一つの時刻ではない。
  • 現行のIETF Internet-Draftは、非透過型ルートサーバーを含む全プロバイダーの和集合を求め、No AttestationとNot Provider+を区別する。欠落は重要だが、あらゆる経路が自動的に無効になるという意味ではない。
  • 変更前の認可済み集合、完全な変更後集合、原子的取引、発行物、外部観測を結ぶ差分受領証が必要だ。契約条件や内部トポロジーまで公開する必要はない。

ネットワーク運用の作業票は、意図を短く書く。「新しいトランジットを追加」「旧回線を撤去」「待機系を有効化」。その簡潔さは人を動かすにはよい。しかしASPAの更新内容を説明するには足りない。依拠側が読むのは追加命令ではなく、その時点でCustomer ASNが表明するプロバイダー集合だからだ。

たとえば、変更担当者が集合 {A, B} を読み、Cを加えた {A, B, C} を準備したとする。送信前に別の自動処理が非透過型ルートサーバーRを追加し、現状を {A, B, R} にした。最初の担当者が準備済みの集合を送れば、Rは消える。どちらの要求も正しい形式で、どちらも成功し得る。誤りは、後の書き込みが古い前提に立っていたことにある。

ARINの説明はこの集合性を見えやすくしている。複数のASNを持つ組織は、Customer ASNごとに固有のASPAオブジェクトを作る。ARIN Onlineで変更する対象はProvider ASの集合だ。RPKI REST APIは、customerAsId と providerAsIds を持つ aspaDelete と aspaAdd を記述し、ASPAとROAを一つの取引にまとめ、全件成功か全件失敗にできる。

原子性は必要な性質である。提出した束の半分だけが反映される事態を防ぐ。しかし、束全体が古いという問題は防がない。成功応答が証明するのは、ARINがその束を一体として受理したことだ。提出者が最新の集合を見ていたこと、公開リポジトリに新オブジェクトが現れたこと、依拠側が取得したことまでは証明しない。

差分を操作しても、署名されるのは状態である

管理画面が集合を一覧として見せるのは合理的だ。行を足し、行を消し、確認を押す。利用者の注意は差分に向かう。一方、暗号的な成果物は編集操作の履歴ではなく、編集後の完全な状態を表す。

ASPA profileの第29版Internet-Draftは、非透過型ルートサーバーのASNを含め、すべてのProvider ASを列挙するよう求める。同じ顧客に有効なASPAが複数ある場合、依拠側は和集合を作る。ただし有効期間のずれが競合を生むため、複数オブジェクトは避けるよう勧めている。verificationの第28版も、一つのASPAに全プロバイダーの和集合を入れる構成を勧める。

両文書はまだ最終RFCではない。改訂される可能性のある作業中の仕様である。その留保を外してはいけない。それでも、現在の実装や検証が向き合う意味単位は明確だ。一つのASNが抜けることは、単なる注記漏れではなく、完全であるはずの集合が別の主張をすることである。

安全な更新は、要求の中に前状態の正規ハッシュを持たせればよい。「このハッシュの集合を見て、次の完全集合に置き換える」と宣言する。現状態のハッシュが変わっていれば、ARINは競合として止め、新状態を返す。どのプロバイダーが商取引上正しいかをARINが推測する必要はない。認可者に判断を戻せばよい。

この小さな停止は、障害後の復元よりはるかに安い。古いブラウザー表示、APIログ、リポジトリの過去オブジェクト、バリデーターのキャッシュは、最初から同じ識別子で一つの記録を作るよう設計されていない。更新時点で前状態を保存しなければ、あとで正確に再構成できる保証はない。

「表明なし」と「集合にいない」は別の状態だ

verification draftは、プロバイダー認可の結果を区別する。顧客に利用可能なASPAエントリーがなければNo Attestation。プロバイダーが利用可能集合にいればProvider+。利用可能集合はあるが、そのプロバイダーがいなければNot Provider+である。

したがってASPAを削除することと、特定のプロバイダーを欠いた非空のASPAを公開することは同じではない。前者は利用可能な表明がない。後者は表明があり、その顧客—プロバイダー対を認めていない。単なる「更新済み」という履歴では、この差を追えない。

同時に、Not Provider+を見ただけで関連経路がすべて無効だと断言するのも誤りである。完全なASパス検証は、経路の方向、セグメント、利用可能な認可を組み合わせる。草案は、プロバイダーの欠落が後に経路を誤ってASPA Invalidにし得ると警告する。これはリスク機序であり、ARINで実際に起きた事故の報告ではない。

待機系の上流は時間問題をよく表す。草案はstandbyまたはemergency providerを事前登録するよう勧める。障害が始まってから追加すれば、ARINの受理、公開、各バリデーターの更新が復旧時間に入る。普段トラフィックを運ばない関係は、現用経路だけを見た編集で最も消えやすい。

非透過型ルートサーバーも同様だ。商務上「トランジット」と呼ばれていなくても、草案の意味では集合に必要になる。差分受領証が完全集合と役割メモを見せれば、ARINがトポロジーを推測せずとも、担当者は静かな構成要素を再確認できる。

緑色の成功表示には四つの時計がある

第一は認可の時計である。認可された人または自動処理が、どの前状態を見て、どの完全集合を承認したか。公開記録に個人名は要らない。役割区分と前状態ハッシュを示し、詳細な承認記録は制限領域に置ける。

第二は取引の時計だ。ARINが要求を受信し、認証し、検査し、原子的に受理した時刻。ASPAとROAが同じ取引に含まれるなら、共通IDと全件成否を結び付ける。公衆に不要なプレフィックスまで開示する必要はない。

第三は公開の時計である。ARINは変更がRPKIデータベースに直ちに反映され、24時間以内に公開リポジトリへ現れると説明する。同じページはリポジトリが数分ごとに更新されるともいう。24時間を通常所要時間とみなしてはいけない。発行オブジェクトのハッシュ、リポジトリまたはmanifest参照、定義済み監視点での初回観測時刻を実測すべきだ。

第四は消費の時計だ。バリデーターが資料を取得し、証明書チェーンを検証し、利用可能集合を組み立てる。結果には観測点、ソフトウェア、版、取得時刻が属する。一つの再現可能な観測は強い証拠だが、世界中の依拠側の同時収束を示すものではない。

これらを一つの「更新時刻」にまとめると、調査は境界を失う。意図から欠けていたのか、古い要求だったのか、公開がまだだったのか、バリデーターが古かったのか。それぞれ担当も対処も違う。証拠は境界ごとに時計を持たなければならない。

受領証は小さく、完全であればよい

最初にCustomer ASNと発行証明書またはCAの文脈を置く。変更前集合は正規順序で保存するか、取得可能な旧オブジェクト参照とハッシュを保存する。次に完全な提出集合を保存し、追加、削除、維持されたASNを二つの集合から算出する。

差分より完全集合を優先するのが要点だ。「Cを追加」だけではBが残ったか分からない。「Aを削除」だけでは最終状態が空か {B, C} か分からない。前後があれば第三者が差分を再計算でき、画面の要約文を信じる必要がない。

要求欄には要求ID、認証主体の役割区分、ペイロードハッシュ、前状態条件、受理時刻、結果を入れる。状態が違えば専用の競合として返す。ROAとの混合取引なら、その関連と原子性だけを公表し、不要な中身は伏せられる。

公開欄には発行ASPAオブジェクトのハッシュ、manifestまたはリポジトリ参照、初回公開観測を置く。検証欄にはバリデーターの観測点、ソフトウェアと版、取得時刻、観測した利用可能集合、試験した認可状態の変化を置く。

受領証自身にも履歴が要る。どの受領証により訂正・置換されたか、いつ失効したか、どの状態へ戻したかをリンクする。ロールバックも完全集合の新しい決定であり、誤状態が存在した事実を消す操作ではない。

役割情報はアクセスを分けられる。通常上流、非透過型ルートサーバー、待機系といった注記は承認に役立つが、署名ペイロードに入れる必要はない。公開層には署名集合と検証可能なハッシュを残し、契約上の理由は組織内にとどめる。

公開証拠と企業秘密は両立する

ASPAに含まれるプロバイダーASNはRPKIで公開消費される。そのことから、価格、流量、担当者名、保守時間、認証情報、内部トポロジーまで公開すべきだとは言えない。公開受領証は状態、ハッシュ、粗い役割、時刻、観測に限定できる。

バリデーターについても「監視点Xが版Yで時刻Zに集合Sを見た」と書けば十分に再現可能だ。「インターネット全体が見た」と広げる必要はない。複数観測は信頼を高めるが、それぞれ固有の視点である。

ARINは2026年3月、ASPAがARIN Onlineで全面利用可能になったと告知した。これは製品の提供状況であり、採用率や無欠陥性を示さない。ARIN 57でJohn Curranは、ASPAを実装し説明する役割と、利用すべきかを運用者が判断する役割を分けた。

ここで提案する受領証はその境界を守る。ARINがプロバイダー関係を決めるのではない。認証された決定を保存し、古い前提を拒み、オブジェクトを発行し、その結果がどこで観測されたかを示す。

ARINが実際の集合を紛失、並べ替え、遅延、誤公開したという証拠はない。特定経路がASPA Invalidになったとも主張しない。事故がないうちに統制を設計するのは合理的だ。変更時の前状態は安価に取れるが、失った前状態は高価な調査でも戻らない。

作業票では一社が変わる。署名では集合全体が変わる。両者の間に、消えない差分受領証を置くべきである。

情報源