要約

  • RFC 5417 は DHCPv4 と DHCPv6 に別々の CAPWAP アクセスコントローラー用オプションを定め、設定済みの DHCP サーバーが順序付きのアドレス一覧を返す。
  • WTP は一覧を使い、示された順にコントローラーを試すべきだが、その順序だけでは到達性も相手の正当性も証明されない。セッション確立時の相互認証は DTLS が担う。

起動の記録をたどると、CAPWAP の制御セッションより先に DHCP 応答が現れる。RFC 5417 が定めるのは、この応答にアクセスコントローラー（AC）の探索順を載せる方法だ。無線終端点（WTP）が受け取るのは優先順付きの候補であり、成立済みの接続でも認証済みの相手でもない。

DHCPv4 のオプション 138 は 32 ビットの IPv4 アドレス一覧で、アドレスデータの長さは 4 オクテットの倍数になる。DHCPv6 のオプション 52 は 128 ビットの IPv6 アドレス一覧で、長さは 16 オクテットの倍数でなければならない。WTP の代理として動く DHCP クライアントは、パラメーター要求リストに該当するオプションを含める必要がある。サーバーが適切なポリシーと AC アドレス一覧を持つ場合に、そのオプションが返される。

ここでの優先順位は、稼働状況を自動測定した結果ではなく、サーバー設定の入力である。RFC 5417 は AC を利用優先度の順に並べると定め、オプションを受け取った WTP は一覧を探索に利用してよいとする。また、受信した順で記録を試すべきだとする。この順番は起動時の経路を左右するが、サービスを保証しない。IP アドレスが到達可能になるわけでも、先頭の AC が WTP を受け入れると保証されるわけでもない。

IPv4 と IPv6 の一覧を、仕様が定めていない一つの順位表にまとめるのも危険だ。RFC 5417 は各オプション内の順番を規定する一方、二つのアドレスファミリーを横断した順位を示していない。両方の先頭候補に同じ意味を持たせるなら、運用側がそれを設定と確認手順に反映させる必要がある。

アドレス一覧に載ったことは、コントローラーが信頼できることを意味しない。DHCP は接続先候補を示すが、その後の CAPWAP 発見とセッション確立は別の手順だ。RFC 5415 は発見メッセージからセッションまでの流れを定めている。RFC 5417 のセキュリティ考慮事項は、攻撃者が DHCP 応答を改変または挿入すると、WTP が不正な AC に向かい、呼び出し要求の傍受やサービス拒否につながる可能性を指摘する。CAPWAP はセッション確立時に DTLS を使って相手を認証しなければならない。

この認証境界があるからといって、起動経路を軽視してよいわけではない。RFC 5417 によると、多くのネットワークでは DHCP のやり取りはネットワークアクセス認証より前に行われ、完全性保護も送信元認証もない。機密性の高い環境では、このオプションだけで接続先を決めるべきではない。RFC 5415 は WTP が利用できる別の発見手順も定めている。DHCP が候補と優先順を示し、後段の認証済み交換が相手を受け入れるか判断する、という段階分けが要点だ。

IANA の DHCP 登録簿では、オプション 138 は OPTION_CAPWAP_AC_V4、オプション 52 は OPTION_CAPWAP_AC_V6 として、現在も RFC 5417 を参照している。これは番号が登録されている証拠であり、現行製品の対応状況や、失敗時に個々の WTP がどう動くかを示すものではない。

運用チームが追うべきなのは、単独のオプション番号ではなく連鎖全体である。WTP が要求したか、DHCP サーバーがスコープごとに何をどの順で返したか、各アドレスが到達できるか、CAPWAP 発見が何を返したか、DTLS が意図した相手を認証したか。オプション 138 または 52 を含むパケットは、DHCP が何を運んだかを示す。それだけでは、期待する AC に到達して制御セッションを確立したとは言えない。

RFC 5417 は、DHCP の方針が無線機器の管理面探索順に影響することを認めながら、設定上の優先度を稼働中の選出やセキュリティ判定に見立てない。コントローラー移行では段階を分けるほど判断しやすい。リストは意図を表し、発見は候補を試し、DTLS は次へ進む相手を認証する。

出典