22. セキュリティ上の考慮事項

この節では, メッセージ交換, リレー動作, DUID, IA_NA, IA_TA, IA_PD, DHCP オプション, RKAP 認証, IANA レジストリ, 規範的要件, 付録のオプション出現マトリクスを含む DHCPv6 に関する RFC 本文を保持する.

RFC 原文

22.  セキュリティ上の考慮事項

   この節では, privacy に関係しないセキュリティ上の考慮事項を論じる.
   privacy に特化した議論については Section 23 を参照.

   DHCP への脅威は本質的に insider threat である (DHCP ポートが企業の
   perimeter gateway でブロックされている, 適切に構成されたネットワーク
   を想定する).  ただし gateway の構成にかかわらず, insider と outsider
   による潜在的な攻撃は同じである.

   DHCP にはクライアントとサーバ間の end-to-end 暗号化がない.  そのため,
   hijacking, tampering, eavesdropping の各攻撃はいずれも起こり得る.
   一部のネットワーク環境 (以下で論じる) は, これらの攻撃を最小化する
   ために各種の手段で保護できる.

   クライアントとサーバの双方に共通する脅威は, "resource-exhaustion" DoS
   攻撃である.  典型的には, これらの攻撃は利用可能な割り当て済みアドレス
   または委任可能プレフィックスの枯渇, あるいは CPU またはネットワーク
   帯域の枯渇を伴い, 共有リソースが存在する場合には常に存在する.  この種
   の枯渇攻撃の一部は, 適切なサーバポリシーによって部分的に緩和できる.
   例えば, 1 つのクライアントが取得できる lease の最大数を制限する,
   1 つのクライアントが decline できる lease 数を制限する, 1 つの
   クライアントが一定期間内に送信できるメッセージ数を制限する, などである.

22.1.  クライアントのセキュリティ上の考慮事項

   DHCP クライアントに特有の攻撃の 1 つは, クライアントに誤った構成情報を
   提供する意図で悪意あるサーバを設置することである.  その動機は,
   クライアントが何らかのサービス (DNS や NTP など) の正当なサーバでは
   なく悪意あるサーバと通信するようにする "man-in-the-middle" 攻撃を
   行うことかもしれない.  悪意あるサーバは, クライアントの誤設定を通じて
   DoS 攻撃を行うこともできる.  この攻撃により, クライアントからのすべての
   ネットワーク通信が失敗する.

   悪意ある DHCP サーバは, SOL_MAX_RT (Section 21.24 を参照) および
   INF_MAX_RT (Section 21.25 を参照) オプションによって, クライアントの
   SOL_MAX_RT および INF_MAX_RT パラメータを不当に大きな値に設定させる
   可能性がある.  これにより, 他に有効な応答が受信されない場合に,
   クライアントが DHCP プロトコルトランザクションを完了するまでに過度の
   遅延が生じる可能性がある.  クライアントが有効な DHCP サーバからの応答も
   受信すると仮定すれば, SOL_MAX_RT と INF_MAX_RT の大きな値は影響しない.

   DHCP クライアントに対する別の脅威は, 誤ってまたは偶然に構成された
   DHCP サーバから生じる.  それらのサーバは, DHCP クライアント要求に対して
   意図せず誤った構成パラメータで応答する.

   クライアント実装が reconfigure mechanism をサポートする場合,
   Section 22.3 を参照.

22.2.  サーバのセキュリティ上の考慮事項

   DHCP サーバに特有の脅威は, 無効なクライアントが有効なクライアントを
   装うことである.  その動機は, サービスの窃取や, さまざまな不正目的の
   ために監査を回避することである可能性がある.

   relay agent とサーバの間で交換されるメッセージは, man-in-the-middle
   攻撃または DoS 攻撃を行うために使用され得る.  サーバと relay agent の
   間の通信, および relay agent 間の通信は, [RFC8213] に記述されるように
   IPsec の使用によって認証および暗号化できる.

   しかし, relay agent とサーバ間の IPsec に手動構成された pre-shared key
   を使用しても, replay された DHCP メッセージに対する防御にはならない.
   replay されたメッセージは, 処理リソースの枯渇による DoS 攻撃にはなり
   得るが, 誤設定や, 割り当て可能アドレスおよび委任可能プレフィックスなど
   他のリソースの枯渇による攻撃にはならない.

   サーバ実装が reconfigure mechanism をサポートする場合, Section 22.3 を
   参照.

22.3.  Reconfigure のセキュリティ上の考慮事項

   Section 20.4 で説明される RKAP は, 悪意ある DHCP サーバが Reconfigure
   メッセージを使用してクライアントに DoS または man-in-the-middle 攻撃を
   行うことに対する保護を提供する.  このプロトコルは, DHCP サーバが
   クライアントへ鍵を平文で送信する最初のメッセージを傍受できる攻撃者に
   よって侵害される可能性がある.

   Reconfigure メッセージを通じた攻撃の機会があるため, DHCP クライアントは
   認証を含まない Reconfigure メッセージ, または認証プロトコルの検証処理に
   合格しない Reconfigure メッセージをすべて MUST 破棄する.

   DHCP クライアントは, 悪意あるサーバから Reconfigure メッセージを受信する
   ことによっても攻撃を受ける可能性がある.  そのメッセージにより,
   クライアントはそのサーバから誤った構成情報を取得する.  クライアントは
   応答 (Renew, Rebind, または Information-request メッセージ) を relay
   agent 経由で送信するため, その応答は DHCP メッセージが relay される
   サーバだけに受信される.  それにもかかわらず, 悪意あるサーバは
   Reconfigure メッセージをクライアントに送信し, その後 (適切な遅延後に)
   クライアントが受け入れる Reply メッセージを送信できる.  したがって,
   クライアントとサーバの間のネットワーク経路上にない悪意あるサーバでも,
   クライアントに対して Reconfigure 攻撃を行える可能性がある.
   暗号学的に健全で容易に予測できない transaction ID を使用することも,
   このような攻撃が成功する確率を低下させる.

22.4.  緩和に関する考慮事項

   下記のように配備される場合, さまざまなネットワーク環境もセキュリティの
   レベルを提供する.

   *  企業ネットワークや工場ネットワークでは, [IEEE8802.1x] に基づく
      認証の使用により, 未知または信頼されないクライアントがネットワークに
      接続することを防止できる.  ただし, 接続されたクライアントが良好な
      DHCP またはネットワーク上の actor であることを必ずしも保証しない.

   *  クライアントが通常 switch port に接続される有線ネットワークでは,
      switch がポートへ配送されるトラフィックを制限するため, DHCP multicast
      (または unicast) トラフィックの snooping は困難になる.  クライアントの
      DHCP メッセージ (All_DHCP_Relay_Agents_and_Servers への multicast) は,
      DHCP サーバ (または relay) の switch port にのみ転送され, すべての
      ポートには転送されない.  また, サーバ (または relay) の unicast 応答は
      対象クライアントのポートにのみ配送され, すべてのポートには配送されない.

   *  公衆ネットワーク (喫茶店や空港の Wi-Fi ネットワークなど) では, 無線の
      到達範囲内にいる他者が DHCP やその他のトラフィックを snoop することが
      可能である.  しかしこれらの環境では, Section 23 で示される privacy
      considerations に従うなら, DHCP トラフィック自体 (クライアントから
      サーバへ, またはサーバからクライアントへ) から学べることは, あったと
      しても非常に少ない.  privacy considerations に従わないデバイスであって
      も, 後続の通信からいずれ利用可能になる情報 (デバイスの Media Access
      Control (MAC) アドレスなど) 以外に学べることはほとんどない.  また,
      すべてのクライアントは通常よく似た構成詳細を受け取るため, 自ら DHCP
      request を開始する悪意ある actor は, そのような情報の多くを知ることが
      できる.  上で述べたように, 1 つの脅威は, 初期の
      Solicit/Advertise/Request/Reply 交換が監視されるとクライアントの RKAP
      key が知られ, 早すぎる再構成が引き起こされ得ることである.  ただし,
      これはこれらのネットワークで直接の client-to-client 通信を禁止するか,
      [RFC7610] および [RFC7513] を使用することで比較的容易に防止できる.

   rogue server による攻撃の多くは, [RFC7610] および [RFC7513] に記述される
   メカニズムを利用することで緩和できる.