要約

  • RFC 5192はPAAアドレスを優先順に並べ、PaCにその順で試すよう求める。しかし順序は受信時点の実行入力であり、現在の健全性や将来のPANA成功を証明しない。
  • 新しいDHCP交換で異なる順序を受け取ったなら新しい版として保存すべきである。在行中の試行を後の版へ付け替えると、正しかった行動が監査上の違反に変わる。

順序を持つ設定は、値だけでなく時間を持つ。RFC 5192のオプションには明示的な版番号はない。それでも、どのDHCP交換からどの並びを受け取ったかを保存しなければ、クライアントの実行を説明できない。

DHCPv4では136番オプションが32ビットのPAAアドレスを運び、長さは4の倍数でなければならない。DHCPv6では40番オプションが128ビットアドレスを運び、長さは16の倍数でなければならない。どちらも優先順であり、PaCはその順で試す。

ここで規定されるのは、受信したリストに対する順序である。後から届いたリストが過去の意思決定を書き換えるとは書かれていない。

リスト版と試行版を結ぶ

各受信オプションには、DHCPトランザクション、family、interface、server、relay、時刻、raw bytes、検証結果からなる不変の識別子を与える。復号後のアドレスとordinalもその版に属する。

候補試行は list_version と ordinal を参照する。Aへの試行が版1から始まり、その途中で版2が到着しても、Aの由来は版1のままである。ローカル方針が試行を中止してBへ切り替えるなら、その中止命令を別のイベントとして残す。

単に配列を上書きすると、原因と結果が逆転する。監査者は「なぜ新しい第一候補BよりAを先に試したのか」と問うが、正しい答えは「Aを選んだ時には版2が存在しなかった」である。

優先順位はヘルスチェックではない

オプションはアドレスと順序を運ぶ。応答時間、負荷、PAA identity、capability、失敗理由、retry deadline、PANA resultは運ばない。

したがって第一候補がtimeoutしてもRFC 5192と矛盾しない。第二候補が成功しても、第一候補の順序が誤りだったとは限らない。順序はサーバが与えた実行優先度であり、端点の現在状態は実行時に観測される別の事実である。

記録は勝者だけを残してはいけない。各候補について開始、終了、network observation、PANA message、terminal reasonを保存する。後続の成功が先行失敗を消すと、failoverが動いた証拠まで消える。

Requestとdeliveryは同じではない

PaCはDHCPv4のParameter Request ListまたはDHCPv6のOption Request OptionでPAAオプションを要求すべきである。一方、設定済みサーバは明示的要求がなくてもオプションを送るべきである。

そのため、応答にオプションがあることからクライアントの要求を推定できない。版を作る際にはrequest setとresponse setを分けて保存する。

この差は更新でも重要である。最初の交換で要求し、後の交換では要求していない場合でも、サーバからリストが届くことはあり得る。観測されたパケットだけが、その交換の事実を決める。

不在はセキュリティ方針ではない

RFC 5192は、このオプションでPANA使用を交渉することを禁じる。存在を「PANA必須」、不在を「PANA不要」と解釈すれば、オプションを削除できる攻撃者がdowngradeを起こせる。

不在はその応答の性質である。PANAを要求する方針は別のauthorityを持つ。別の発見法を使うか、fail closedにするかは明示的なローカル方針として記録する。

版管理はこの分離にも役立つ。版1にオプションがあり版2にないとき、セキュリティ方針まで自動的に消えてはならない。変化したのは観測であって、必ずしも義務ではない。

構造検証の失敗を空リストにしない

IPv4 payloadの長さが4で割り切れない、またはIPv6が16で割り切れない場合、アドレス境界を正確に作れない。RFC 5192は残余を切り捨てる回復策を与えていない。

raw lengthとcaptured length、bytes、validator versionを残し、無効として扱う。option absentとoption invalidはユーザー症状が似ても原因が違う。

IANA登録は136と40のcodepointを確認するが、具体的なpacketの正しさやdeploymentを証明しない。registry、message、runtimeは別々の層である。

DHCPコンテキストを失わない

DHCPv4とDHCPv6はtransaction、server、relay、lease、Renew、Rebindの文脈を持つ。RFC 5192は更新時にリストが必ず変わるとは述べない。しかし、実際に異なる応答を受けたなら差分は事実である。

また、dual-stackの二つのリストをどう競争させるかも規定しない。parallel race、family preference、timeout、cacheは実装選択であり、policy versionとして残すべきである。

インターフェースを越えて古い候補を再利用する場合も同じである。再利用は設計判断であって、同じアドレスが見えたから自動的に正当化されるものではない。

実際の交換で保護を証明する

RFC 5192は、アクセス認証前にオプションを届けるDHCP交換が多くのネットワークでintegrity protectionもorigin authenticationも持たないと警告する。改変・挿入された応答は、認証要求のinterceptやaccess denialを行うrogue PAAへPaCを導き得る。

DHCP認証仕様が存在しても、個別交換が保護された証拠にはならない。適用機構、検証identity、結果を交換ごとに保存する。

保護されたリストでも候補のhealthまでは保証しない。provenance、endpoint observation、PANA outcomeを段階別に扱うことが必要である。

時系列としての発見

運用オブジェクトは、DHCP request、response、option validation、list version、selection decision、candidate attempts、chosen peer、PANA sessionを順にリンクする。どれも後の成功で上書きしない。

これにより「版1のAを試行中、版2でBが第一へ変更、ローカル方針によりAを完了後Bを試行」という説明が可能になる。単一のcurrent addressでは不可能である。

Heng Luの現実層の考え方では、後から現れた記録が過去の実行を統治してはならない。記録はその時点の現実を保存し、変更は新しい現実として追加する。版管理は技術的な整理ではなく、因果関係を守る仕組みである。

Sources

  1. RFC 5192 HTML
  2. RFC 5192 text
  3. RFC 5192 record
  4. Datatracker RFC 5192
  5. RFC 5192 history
  6. RFC 5192 references
  7. RFC 5192 errata
  8. RFC 2131
  9. RFC 2131 record
  10. RFC 2132
  11. RFC 8415
  12. RFC 8415 record
  13. RFC 3315
  14. RFC 5191
  15. RFC 3748
  16. RFC 3118
  17. IANA BOOTP/DHCP parameters
  18. Heng Lu — On Reality Layers
  19. Heng Lu — Minimum Initial Specification
  20. Heng Lu — Running-Code Primacy