要約

  • 9月提出の個人Internet-Draftは、既存RPKIとは別の階層型登録簿でIPv4/IPv6資源の保護委任を扱う案だ。依存側に既存の認可を除外する義務は課していない。
  • 保護側の起点認可が最終・確認済みになる前にRPKI由来VRPを消せば、その利用者の検証では既存ROAが有効でもNotFoundになり得る。報告済みの障害ではない。

委任先が鍵を持つことと、上位者がその認可を取り消せないことは別だ。RPKIの下位CAが秘密鍵を自主管理していても、親CAには証明書を失効させる経路が残る。Joseph Gerschが9月18日に提出した個人草案は、独立した資源登録簿の状態遷移によって、保護された範囲への上位者の回収や競合発行を制限しようとする。ただし、ルーターを新しい検証方式へ一斉に移す設計ではない。両者の間で情報を集約する依存側が、どの起点認可を配るか決める。

保護は記録を一つ書けば成立するものではない。草案では、最終状態、保有者による確認、暫定期間の終了が揃って初めて不可逆となる。その前に保有者が選ぶ回復方針も記録しなければならない。RIRやRDAP、RPKIから読み込んだ情報は当初「主張された」状態にとどまり、確認そのものではない。外部に出す起点認可は確認済みかつ最終の状態に基づく。ログに見えたばかりの移転を、直ちに既存認可の削除根拠にしてはいけないという順序だ。

既存のRFC 8416はSLURMによるローカルな追加とフィルターを許す。草案の第10.6節が注意するのは、その二つの操作の非対称性である。保護登録簿からVRPを足すだけなら、旧来のRPKI VRPは残る。フィルターを読み込むと、正当な既存認可が依存側の視野から消え得る。読み込みは利用者ごとの政策判断で、草案が強制するものではない。しかも第10.5節によれば、保護プレフィックスだけを指定した単純な除外では、より短いプレフィックスのROAがmaxLengthで保護範囲を覆う場合を取りこぼす。部分的な除外には、範囲を限定した代替データか、もっと表現力のある仕組みが必要になる。

実際の切替で怖いのは空白期間だ。古いVRPを先に除き、保護側の認可がまだ最終・確認済みでなければ、その依存側では経路がNotFoundになり得る。Invalidと同義ではなく、転送が止まるかどうかは運用者のポリシー次第だ。草案は実際の停止を報告していない。輸出されたVRP集合しか受け取らない側は、保有者の署名が輸出物に付かないため、輸出者も信頼しなければならない。

著者は許可型チェーン上での概念実証を述べる一方、独立した実装、実運用の確定性設定、大規模な測定を今後の課題に挙げる。SIDROPSのメールでは一参加者が作業範囲に疑問を示し、著者は議長の判断に委ねた。作業部会が採用を決めたわけではない。Datatrackerも個人草案として扱う。現時点の判断対象は新制度の完成度を断定することではなく、既存RPKIを排除するローカル操作の責任だ。

出典