要約

  • GROWの作業文書が提案するsrc-membersは、RPSL集合の直近の参照を特定のIRRレジストリに結び付ける一方、その制約を子集合の再帰参照へ伝播させない。
  • 移行期には新しいリゾルバと旧来の利用者が同じ有効なオブジェクトから異なるポリシーを作り得るため、展開経路の受領記録と両結果の差分を承認単位にすべきである。

承認画面にRS-FIRSTと8,000件という数字が表示される。数時間後、別の生成基盤も8,000件を返す。件数が同じなら同じポリシーだろう、と人は考えやすい。しかし集合の中身が三つ入れ替わっていても件数は変わらない。中身まで一致していても、異なるミラーや探索順序に依存していれば、次回更新で差が現れる。

draft-ietf-grow-rpsl-registry-scoped-members-00は、この問題の入口にある曖昧さを狙う。RPSLのas-setとroute-setにsrc-membersを追加し、RIPE::AS-EXAMPLEのように主キーと参照元レジストリを一緒に書けるようにする提案だ。裸の集合名よりはるかに明確である。ただし、これは直近の検索指定であって、展開全体を一つのレジストリに固定する宣言ではない。

接頭辞が届くのは次のオブジェクトまで

RPSL集合はAS番号やプレフィックスを直接含めるだけでなく、別の集合を参照できる。その集合がさらに集合を参照し、グラフは深くなる。複数のIRRレジストリは独立しており、主キーの全世界的な一意性は保証されない。複数ソースをミラーするサーバには同名オブジェクトが共存し得る。

草案によれば、曖昧な検索は運用者が意図しないレジストリのオブジェクトを選び、意図しないルーティングポリシーを生成し得る。逆に正しいオブジェクトを見つけられず、受け入れるべきプレフィックスを落とすこともある。文書は経路漏えい、ハイジャックへの悪用、到達性の喪失というリスクを示すが、特定の新規事故や普及率を立証してはいない。本稿もそこを推測で埋めない。

対応リゾルバはsrc-membersのレジストリ名と主キーを両方照合しなければならない。指定されたレジストリを知らなければ一致する集合はない。無指定の同名オブジェクトへ静かにフォールバックすれば、作者が加えた情報を取り消すことになる。

重要なのは、その制約が次の階層に継承されない点だ。RIPEのRS-SECONDを選んだ後は、そのオブジェクト自身の属性を読む。子の参照にもsrc-membersがあれば別途レジストリを指定できる。membersまたはmp-membersしかなければ、既存のソース選択規則に戻る。親のRIPE::は子孫を拘束しない。

初期クエリの制限も同じである。ソフトウェアはルート集合を特定レジストリに限定する引数を受け付ける必要があるが、その限定を再帰検索へ適用してはならない。RIPE::RS-FIRSTから始めたという事実だけで、展開された全オブジェクトをRIPE由来とは呼べない。

互換用の影が別の意味を残す

草案は既存のmembersとmp-membersを温存する。旧ソフトウェアは新属性を理解せず、既存オブジェクトの更新にも時間がかかるからだ。権威レジストリは、src-membersからレジストリ接頭辞を外した各値が旧属性にも存在することを検証する。

利用者が新属性だけを送った場合、権威ソフトウェアは旧属性を自動生成することが推奨される。ただし利用者が旧属性も明示したなら書き換えてはならず、非権威サーバは生成してはならない。逆に、裸のRS-SECONDからRIPE::RS-SECONDを推定することは禁止される。失われた参照元は復元できない。

このため、一つの有効なオブジェクトに二つの読み方が残る。新しいリゾルバはRIPE::RS-SECONDを選ぶ。旧リゾルバは接頭辞を外したRS-SECONDを見て、自身の優先順位を使う。検証が保証するのは文字列上の対応であり、取得されるオブジェクトの同一性ではない。

RIPE::AS-OTHERとARIN::AS-OTHERを同じsrc-membersに並べることも許されない。新形式では別物でも、旧形式へ落とすと二つともAS-OTHERになる。互換表現が差を保持できないため、新しい表現力が制限される。

この設計は段階導入を可能にする。一方で、レジストリが受理したという事実と、全利用者が同じ結果を得るという事実を分けて考える必要がある。

展開来歴の受領記録

最終メンバー集合は計算経路を持たない。そこで本稿は、運用側の証拠として「展開来歴受領記録」を提案する。これはIETF草案の属性でも適合要件でもない。

最初に、ルート主キーと初期レジストリ制限、リゾルバの製品・版、src-members対応の有効状態を記録する。次に、利用可能だったレジストリとミラーの取得時刻、シリアル、スナップショットまたは内容ハッシュを固定する。

再帰の各辺には、親のレジストリと主キー、読んだ属性、記載どおりの子参照、明示選択か暗黙選択か、実際に選ばれたレジストリとオブジェクトハッシュを残す。未知レジストリ、欠落、衝突、循環、深さ制限、サイズ制限も結果の一部である。警告ログとして捨ててはいけない。

移行中は二つの出力を保存する。src-membersを理解する経路の結果と、現存する旧ツールが実際に作る結果である。件数ではなく正確な集合差を比較し、差を許可するなら審査者、理由、有効期限、影響する利用者、ロールバック権限を結び付ける。

さらに、ポリシーコンパイラの版、フィルタと正規化、生成物のハッシュ、変更番号、対象機器へつなぐ。これがなければ、正しいデータを取得した証拠と、審査済み生成物を配備した証拠がすり替わる。

証拠は権威を作らない

来歴が分かっても、IRRオブジェクトが経路起源の正当性を自動的に証明するわけではない。事業関係を検証せず、RPKIの代わりにもならない。受領記録が担うのは、データから配備候補へ至る判断を検査可能にすることだ。

秘密の公開も不要である。資格情報や完全なルータ設定を残さずとも、オブジェクトと出力のハッシュ、ソース識別子、判断者の役割、差分、変更参照を保存できる。

新旧結果の差は自動的な不合格ではない。新しい範囲指定が旧来の曖昧さを正しく除いた可能性がある。ただし旧生成器が組織のどこかで生きているなら、その読み方も実運用の一部だ。差分を契機に、対象利用者、意図する結果、移行期限と撤回方法を決めるべきである。

草案は循環参照の検出を必須とし、深さや展開量の制限を推奨する。これらの設定変更だけで最終集合が変わり得るため、受領記録から除外できない。

レジストリ接頭辞は一つの曖昧な判断を明示する。その判断を最終リストで再び消してしまえば、改善は監査へ届かない。ポリシーが先へ進む以上、証拠も最後まで進む必要がある。

情報源

  1. レジストリ範囲付きRPSLメンバーのDatatracker記録
  2. 現行草案の履歴
  3. 第00版HTML
  4. 第00版テキスト
  5. 第00版XML
  6. 前身草案の記録
  7. 前身草案の履歴
  8. 前身草案第01版
  9. GROWワーキンググループの任務
  10. GROWの文書一覧
  11. GROWによる採用通知
  12. 著者のソースリポジトリ
  13. RFC 2622：Routing Policy Specification Language
  14. RFC 4012：次世代RPSL
  15. RFC 2725：ルーティングポリシーシステムのセキュリティ
  16. RFC 2650：RPSLの実務利用
  17. RFC 7682：IRRとポリシー設定の考慮事項
  18. RFC 7909：RPKIによる経路起源検証の問題定義
  19. Lu Heng：最小初期仕様、将来判断の局所化、自発的採用
  20. Lu Heng：The Policy Mirror