Summary
- RFC 5221 は、動的更新と中央制御だけでなく、ノード別、アプリケーション別、インターフェース別の振る舞いと、次ホップ選択との協調を要求している。
- 必要なのは、制御者の権限、完全性、配信、適用範囲、反映、経路同期、選択されたアドレス対、相手到達性、アプリケーション結果を分けて残すポリシー状態の受領書である。
百パーセント配信の次に残る問い
管理画面は全端末が最新版を受信したと報告する。署名エラーはなく、構成エージェントも正常である。配信という作業については、強い証拠だ。しかし、その画面は、二つのインターフェースを持つ端末のどちらで規則が使われたか、特定アプリケーションの例外が残ったか、次ホップが更新後も同じかを答えない。
2008 年の RFC 5221 は、単一の配信方式を標準化した文書ではない。既定のアドレス選択規則を更新する仕組みに必要な条件を整理している。動的な更新と中央制御に加え、ノード、アプリケーション、インターフェースに応じたポリシー、そして次ホップ選択との協調を求めた。
中央側が同じ表を送ることと、各判断が正しいことは別の性質である。均一性は管理上の成果だが、適用性は現場の文脈を含む成果である。
ポリシーは一つの状態ではない
まず、制御者が対象集団へ発行する権限を持つ必要がある。次に、ポリシーが改変されず、意図したノードへ届き、意図した版として反映されなければならない。その後、その規則が実際のアプリケーションとインターフェースに該当するかを確認する。
さらに、前提とした経路情報が現在も有効で、次ホップと整合していなければならない。スタックが期待した送信元と宛先を選び、相手へ到達し、アプリケーションが目的を果たして初めて結果となる。
各段階は独立して失敗できる。正しい署名は対象範囲の権限を証明しない。反映済みという応答はローカル例外を証明しない。規則への一致は経路の新鮮さを証明しない。アドレス対の選択は相手の応答を証明しない。接続成立も利用者の成果を自動的には証明しない。
「配備済み」という一語をやめ、時刻、版、対象、判断、責任者を段階ごとに保存する必要がある。
全体モデルと端末の現在はずれる
中央の制御者は、収集された情報から全体像を作り、版を承認して配信する。端末は、まさにその瞬間のインターフェース、ルータ情報、アプリケーション呼び出しを使う。どちらにも障害がなくても、観測時刻が違えばモデルは食い違う。
移動端末が接続先を変える。新しいインターフェースが現れる。ルータの優先度が更新される。長時間接続が版の切り替えをまたぐ。中央の表が五分前には適切でも、現在の判断には古いことがある。
RFC 5221 がノード別、アプリケーション別、インターフェース別の差を残すよう求める理由はここにある。「全サイト向け」とだけ記した規則は、誰のどの判断に対する規則かという主語を失う。一貫して届く誤りは、ばらつく誤りより発見しにくい。
アドレスと次ホップは同じ結果を作る
RFC 5221 は次ホップ選択との協調を求める。RFC 4191 は、ホストがルータ優先度やより具体的な経路を受け取れることを説明する。これらは特定製品が二つの面を正しく同期している証明ではない。ただし、別々の正常性だけでは足りないことは明らかにする。
アドレス規則は、あるトポロジーや運用意図を前提に送信元や宛先を優先する。経路状態はパケットを実際にどこへ渡すかを決める。ポリシーと経路が別の時刻や別のインターフェースを表していれば、個々の部品が正常でも組合せは誤る。
監査単位はファイルではなく判断である。ノード、アプリケーション、インターフェース、版、一致規則、候補、選択対、経路、次ホップ、時刻、相手応答、アプリケーション結果を一つの追跡記録にする。そこで初めて「反映済み」を検証可能な主張へ変えられる。
安全性は受信許可で終わらない
RFC 5221 は、ポリシー情報の漏えい、悪意ある注入や変更によるトラフィック転送先の変更、制御者へのサービス妨害を挙げる。従って認証と完全性は必要である。しかし、それだけでは、正しい対象へ正しい規則が出されたかを説明できない。
範囲を含む認可、古い版の再利用防止、有効期限、発行履歴、安全な縮退、制御者不在時の動作、ローカル例外の保存が必要になる。署名が正しい古い版と、現在適用できる版は別状態である。真正な制御者でも、あるアプリケーション集団に対する権限を持たない場合がある。
セキュリティ記録は、オブジェクトを受け入れた事実だけでなく、そのオブジェクトが作った判断まで追わなければならない。
この資料が証明しないこと
RFC 5221 は要求事項であり、導入実績ではない。ある仕組みが全条件を満たすこと、ある事業者が危険な表を配信したこと、現在のネットワークで注入攻撃が起きたことは証明しない。RFC 3484 は歴史的な既定規則で、RFC 6724 に置き換えられた。本稿は古い表の復活を求めない。
RFC 5220 の半閉鎖ネットワークや戻り経路問題も扱わない。アドレス族の順位付けや接続競争を提案する記事でもない。結論は限定的である。中央配信の成功は、範囲、経路同期、通信結果の成功ではない。
ポリシー状態の受領書を残す
重要な版ごとに、制御者の身元と権限、承認、正確なハッシュと版、対象ノード、アプリケーション、インターフェース条件、発行と失効、配信と反映、例外、経路前提、判断の標本、制御者停止時の動作、戻し条件、アプリケーション結果を保存する。
拒否した端末、古い版、規則のないインターフェース、ローカル上書き、想定外のアドレス対、新しい経路状態、応答しない相手、フォールバックは雑音ではない。それらがポリシーの実際の境界を描く。
Lu Heng の現実優先と主体の明示という考え方を当てはめれば、証拠の所有者も分かれる。制御チームは発行を、端末チームは反映を、ネットワークチームは経路を、アプリケーション所有者は結果を証明する。一者の記録を他者の証明として流用してはならない。
Sources
- RFC 5221:アドレス選択機構の要件
- RFC 3484:IPv6 の既定アドレス選択
- RFC 6724:IPv6 の既定アドレス選択
- RFC 4191:既定ルータ優先度と詳細経路
- RFC 3493:IPv6 基本ソケット拡張
- RFC 5220:既定アドレス選択の問題
- Lu Heng:製品は主張ではなく現実
- Lu Heng:稼働するコードを第一に
- Lu Heng:インターネットガバナンスの代理問題
追加の標準記録
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
