要約

  • RFC 3634 の CCC sub-option 10 は、4 octet 単位の IPv4 KDC アドレスを複数持ち、優先度の高い順に並べる。realm、transport、port、現在の健康状態、KDC identity は含まない。
  • DHCP 受領、端末への保存、候補選択、network contact、KDC 認証、ticket 発行、application 認証、SNMPv3 の結果は別々の証拠である。
  • 切替は端末任せの暗黙挙動にせず、list version、選択理由、error class、retry budget、fallback capacity、realm と identity を記録する必要がある。

配置を配ることと、状態を知ること

RFC 3634 の対象は CableHome の residential gateway だった。Kerberos 認証を経て安全な SNMPv3 関係へ進むため、DHCP の CCC option に KDC の場所を載せる。code 10、length、少なくとも一つの IPv4 address。length は 4 以上で 4 の倍数、複数なら優先度の降順である。

ここに health bit はない。realm、transport、port、TTL、weight、certificate fingerprint、ticket result もない。address は候補地を指すが、相手の状態や身元を述べない。

親の RFC 3495 では、Kerberos realm、AS の retry/backoff、AP の retry/backoff が別 sub-option になっている。同じ CCC の中にあるからといって、address がそれらの意味を持つわけではない。

先頭は「現在最良」ではない

優先度は DHCP 応答を作った時点の管理意図である。RFC 3634 は、待ち時間、fallback を許す error、失敗記憶、first address への復帰を完全には決めない。したがって firmware が違えば、同じ list から異なる path を選び得る。

RFC 4120 の DNS SRV は service、transport、realm、TTL、priority、weight、port、target を分ける。RFC 2782 は reachable target の順序と同一 priority 内の weight を扱う。それでも weight は static selection 用で、dynamic load の測定ではない。豊かな metadata でも health check にはならない。

RFC 6784 は後に DHCPv6 で priority、weight、transport、port、IPv6 address、realm を独立して持たせた。これは証拠項目を分離する良い比較だが、2003 年の option を書き換えない。

認証失敗で安全でも、運用は失敗し得る

RFC 3634 は DHCP の security に依存し、独自の保護を追加しない。誤った address は misdirection、DoS、man-in-the-middle の入口になる。CMTS filtering、certificate、Kerberos mutual authentication、network isolation、firewall は対策または前提として挙げられる。

偽 KDC が認証で止まれば trust boundary は守られる。しかし端末は時間と計算を使っている。全端末が同じ first address で止まれば、失敗は同期し、次の KDC に負荷が集中する。secure rejection は availability success ではない。

判断を復元できる記録

DHCP receipt には server、validation、transaction、configuration epoch、raw bytes を残す。次に端末が list を install した証拠を持つ。selection receipt には list hash、選択位置、attempt、timeout、直前の error と次へ進む rule を残す。

route、transport、port、contact はその後。KDC identity、realm、clock、cryptographic result はさらに別である。AS/TGS の request と reply、application AP exchange、security association、SNMP operation も順に確認する。

DHCPACK は ticket ではない。ticket は application success ではない。緑色の channel も管理結果までは保証しない。

証拠の範囲

本稿は operator、gateway、CMTS、KDC、realm、subscriber、incident、deployment を特定しない。Standards Track と IANA code 10 は仕様と登録を示すだけで、採用率を示さない。

RFC 3634 を主資料とし、RFC 3495 を CCC context、RFC 2131 と 3118 を DHCP delivery/security、RFC 4120 と 2782 を discovery comparison、RFC 6784 を後続仕様として用いる。RFC 5021 と 6251 は transport と TLS が別の証拠であることを示す。

Heng Lu の Running-Code Primacy、Minimum Initial Specification、Authority and Belief、Reality Layers は分析 lens として開示する。設定、権限、実行、観測を分離するためであり、実装事実の証明ではない。

先頭に置かれた理由は保存すべきだ。しかし稼働したという結論は、実行記録からしか得られない。

Sources