RFC 7610 - DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7610
タイトル : RFC 7610 - DHCPv6-Shield：不正なDHCPv6サーバーからの保護
翻訳編集 : 自動生成

[要約] 要約：RFC 7610は、DHCPv6-Shieldというプロトコルを紹介しており、これは不正なDHCPv6サーバーからの攻撃を防ぐためのものです。目的：このRFCの目的は、DHCPv6-Shieldを使用してネットワーク上のクライアントを不正なDHCPv6サーバーから保護することです。

Internet Engineering Task Force (IETF)                           F. Gont
Request for Comments: 7610                        SI6 Networks / UTN-FRH
BCP: 199                                                          W. Liu
Category: Best Current Practice                      Huawei Technologies
ISSN: 2070-1721                                          G. Van de Velde
                                                          Alcatel-Lucent
                                                             August 2015

DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers

DHCPv6-Shield：不正なDHCPv6サーバーからの保護

Abstract

概要

This document specifies a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers. It is based on DHCPv6 packet filtering at the layer 2 device at which the packets are received. A similar mechanism has been widely deployed in IPv4 networks ('DHCP snooping'); hence, it is desirable that similar functionality be provided for IPv6 networks. This document specifies a Best Current Practice for the implementation of DHCPv6-Shield.

このドキュメントでは、スイッチドネットワークに接続されたホストを不正なDHCPv6サーバーから保護するためのメカニズムについて説明します。これは、パケットが受信されるレイヤー2デバイスでのDHCPv6パケットフィルタリングに基づいています。同様のメカニズムがIPv4ネットワークに広く展開されています（「DHCPスヌーピング」）。したがって、IPv6ネットワークに同様の機能を提供することが望まれます。このドキュメントでは、DHCPv6-Shieldを実装するためのベストカレントプラクティスを規定しています。

Status of This Memo

本文書の状態

This memo documents an Internet Best Current Practice.

このメモは、インターネットの現在のベストプラクティスを文書化したものです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7610.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7610で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1. Introduction ....................................................3
   2. Requirements Language ...........................................3
   3. Terminology .....................................................3
   4. DHCPv6-Shield Configuration .....................................5
   5. DHCPv6-Shield Implementation Requirements .......................5
   6. Security Considerations .........................................7
   7. References ......................................................9
      7.1. Normative References .......................................9
      7.2. Informative References ....................................10
   Acknowledgements ..................................................11
   Authors' Addresses ................................................12

1. Introduction

1. はじめに

This document specifies DHCPv6-Shield, a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers [RFC3315]. The basic concept behind DHCPv6-Shield is that a layer 2 device filters DHCPv6 messages intended for DHCPv6 clients (henceforth, "DHCPv6-server messages"), according to a number of different criteria. The most basic filtering criterion is that DHCPv6-server messages are discarded by the layer 2 device unless they are received on specific ports of the layer 2 device.

このドキュメントでは、スイッチドネットワークに接続されたホストを不正なDHCPv6サーバーから保護するメカニズムであるDHCPv6-Shieldを規定しています[RFC3315]。 DHCPv6-Shieldの背後にある基本的な概念は、レイヤー2デバイスが、さまざまな基準に従って、DHCPv6クライアント向けのDHCPv6メッセージ（以降、「DHCPv6-serverメッセージ」）をフィルタリングすることです。最も基本的なフィルタリング基準は、レイヤー2デバイスの特定のポートで受信されない限り、DHCPv6サーバーメッセージがレイヤー2デバイスによって破棄されることです。

Before the DHCPv6-Shield device is deployed, the administrator specifies the layer 2 port(s) on which DHCPv6-server messages are to be allowed. Only those ports to which a DHCPv6 server or relay is to be connected should be specified as such. Once deployed, the DHCPv6-Shield device inspects received packets and allows (i.e., passes) DHCPv6-server messages only if they are received on layer 2 ports that have been explicitly configured for such purpose.

DHCPv6-Shieldデバイスを展開する前に、管理者はDHCPv6-serverメッセージを許可するレイヤー2ポートを指定します。 DHCPv6サーバーまたはリレーが接続されるポートのみをそのように指定する必要があります。 DHCPv6-Shieldデバイスは展開されると、受信したパケットを検査し、そのような目的のために明示的に構成されたレイヤー2ポートで受信された場合にのみ、DHCPv6-serverメッセージを許可（つまり、通過）します。

DHCPv6-Shield is analogous to the Router Advertisement Guard (RA-Guard) mechanism [RFC6104] [RFC6105] [RFC7113], intended for protection against rogue Router Advertisement [RFC4861] messages.

DHCPv6-Shieldは、Router Advertisement Guard（RA-Guard）メカニズム[RFC6104] [RFC6105] [RFC7113]に類似しており、不正なルーターアドバタイズメント[RFC4861]メッセージからの保護を目的としています。

We note that DHCPv6-Shield mitigates only DHCPv6-based attacks against hosts. Attack vectors based on other messages meant for network configuration (such as ICMPv6 Router Advertisements) are not addressed by DHCPv6-Shield itself. In a similar vein, DHCPv6-Shield does not mitigate attacks against DHCPv6 servers (e.g., Denial of Service).

DHCPv6-Shieldはホストに対するDHCPv6ベースの攻撃のみを軽減することに注意してください。ネットワーク構成用の他のメッセージ（ICMPv6ルーターアドバタイズメントなど）に基づく攻撃ベクトルは、DHCPv6-Shield自体では対処されません。同様に、DHCPv6-ShieldはDHCPv6サーバーに対する攻撃（サービス拒否など）を緩和しません。

2. Requirements Language

2. 要件言語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。

3. Terminology

3. 用語

DHCPv6-Shield:

DHCPv6-シールド：

The set of filtering rules specified in this document, meant to mitigate attacks that employ DHCPv6-server packets.

このドキュメントで指定されている一連のフィルタリングルールは、DHCPv6サーバーパケットを使用する攻撃を軽減するためのものです。

DHCPv6-Shield device:

DHCPv6-Shieldデバイス：

A layer 2 device (typically a layer 2 switch) that enforces the filtering policy specified in this document.

このドキュメントで指定されているフィルタリングポリシーを適用するレイヤー2デバイス（通常はレイヤー2スイッチ）。

For the purposes of this document, the terms "IPv6 Extension Header", "First Fragment", "IPv6 Header Chain", and "Upper-Layer Header" are used as specified in [RFC7112]:

このドキュメントでは、[RFC7112]で指定されている「IPv6拡張ヘッダー」、「最初のフラグメント」、「IPv6ヘッダーチェーン」、および「上位レイヤーヘッダー」という用語が使用されています。

IPv6 Extension Header:

IPv6拡張ヘッダー：

IPv6 Extension Headers are defined in Section 4 of [RFC2460]. As a result of [RFC7045], [IANA-PROTO] provides a list of assigned Internet Protocol Numbers and designates which of those protocol numbers also represent IPv6 Extension Headers.

IPv6拡張ヘッダーは、[RFC2460]のセクション4で定義されています。 [RFC7045]の結果として、[IANA-PROTO]は割り当てられたインターネットプロトコル番号のリストを提供し、それらのプロトコル番号のどれがIPv6拡張ヘッダーも表すかを指定します。

First Fragment:

最初のフラグメント：

An IPv6 fragment with a Fragment Offset equal to 0.

フラグメントオフセットが0のIPv6フラグメント。

IPv6 Header Chain:

IPv6ヘッダーチェーン：

The IPv6 Header Chain contains an initial IPv6 header, zero or more IPv6 Extension Headers, and optionally, a single Upper-Layer Header. If an Upper-Layer Header is present, it terminates the IPv6 Header Chain; otherwise, the "No Next Header" value (Next Header = 59) terminates it.

IPv6ヘッダーチェーンには、初期IPv6ヘッダー、0個以上のIPv6拡張ヘッダー、およびオプションで単一の上位層ヘッダーが含まれます。上位層ヘッダーが存在する場合は、IPv6ヘッダーチェーンを終了します。それ以外の場合は、「次のヘッダーなし」の値（次のヘッダー= 59）で終了します。

The first member of the IPv6 Header Chain is always an IPv6 header. For a subsequent header to qualify as a member of the IPv6 Header Chain, it must be referenced by the "Next Header" field of the previous member of the IPv6 Header Chain. However, if a second IPv6 header appears in the IPv6 Header Chain, as is the case when IPv6 is tunneled over IPv6, the second IPv6 header is considered to be an Upper-Layer Header and terminates the IPv6 Header Chain. Likewise, if an Encapsulating Security Payload (ESP) header appears in the IPv6 Header Chain, it is considered to be an Upper-Layer Header, and it terminates the IPv6 Header Chain.

IPv6ヘッダーチェーンの最初のメンバーは常にIPv6ヘッダーです。後続のヘッダーがIPv6ヘッダーチェーンのメンバーとして適格となるには、IPv6ヘッダーチェーンの前のメンバーの「次のヘッダー」フィールドで参照される必要があります。ただし、IPv6がIPv6を介してトンネリングされる場合のように、2番目のIPv6ヘッダーがIPv6ヘッダーチェーンに表示される場合、2番目のIPv6ヘッダーは上位レイヤーヘッダーと見なされ、IPv6ヘッダーチェーンを終了します。同様に、カプセル化セキュリティペイロード（ESP）ヘッダーがIPv6ヘッダーチェーンに表示される場合、それは上位層ヘッダーと見なされ、IPv6ヘッダーチェーンを終了します。

Upper-Layer Header:

上層ヘッダー：

In the general case, the Upper-Layer Header is the first member of the Header Chain that is neither an IPv6 header nor an IPv6 Extension Header. However, if either an ESP header or a second IPv6 header occurs in the IPv6 Header Chain, it is considered to be an Upper-Layer Header, and it terminates the IPv6 Header Chain.

一般的な場合、Upper-Layerヘッダーは、IPv6ヘッダーでもIPv6拡張ヘッダーでもないヘッダーチェーンの最初のメンバーです。ただし、IPv6ヘッダーチェーンでESPヘッダーまたは2番目のIPv6ヘッダーのいずれかが発生した場合、それは上位レイヤーヘッダーと見なされ、IPv6ヘッダーチェーンを終了します。

Neither the upper-layer payload nor any protocol data following the upper-layer payload is considered to be part of the IPv6 Header Chain. In a simple example, if the Upper-Layer Header is a TCP header, the TCP payload is not part of the IPv6 Header Chain. In a more complex example, if the Upper-Layer Header is an ESP header, neither the payload data nor any of the fields that follow the payload data in the ESP header are part of the IPv6 Header Chain.

上位層のペイロードも、上位層のペイロードに続くプロトコルデータも、IPv6ヘッダーチェーンの一部とは見なされません。簡単な例では、Upper-LayerヘッダーがTCPヘッダーの場合、TCPペイロードはIPv6ヘッダーチェーンの一部ではありません。より複雑な例では、Upper-LayerヘッダーがESPヘッダーである場合、ペイロードデータも、ESPヘッダーのペイロードデータに続くフィールドもIPv6ヘッダーチェーンの一部ではありません。

4. DHCPv6-Shield Configuration

4. DHCPv6-Shield構成

Before being deployed for production, the DHCPv6-Shield device is explicitly configured with respect to which layer 2 ports are allowed to receive DHCPv6 packets destined to DHCPv6 clients (i.e., DHCPv6-server messages). Only those layer 2 ports explicitly configured for such purpose are allowed to receive DHCPv6 packets to pass to DHCPv6 clients.

本番環境に展開する前に、DHCPv6-Shieldデバイスは、どのレイヤー2ポートがDHCPv6クライアント宛てのDHCPv6パケット（つまり、DHCPv6-serverメッセージ）を受信できるかに関して明示的に構成されています。このような目的で明示的に構成されたレイヤー2ポートのみが、DHCPv6パケットを受信してDHCPv6クライアントに渡すことができます。

5. DHCPv6-Shield Implementation Requirements

5. DHCPv6-Shield実装要件

Following are the filtering rules that are enforced as part of a DHCPv6-Shield implementation on those ports that are not allowed to receive DHCPv6 packets to DHCPv6 clients:

DHCPv6クライアントへのDHCPv6パケットの受信を許可されていないポートでのDHCPv6-Shield実装の一部として適用されるフィルタリングルールは次のとおりです。

1. DHCPv6-Shield implementations MUST parse the entire IPv6 Header Chain present in the packet to identify whether or not it is a DHCPv6 packet meant for a DHCPv6 client (i.e., a DHCPv6-server message).

1. DHCPv6-Shield実装は、パケットに存在するIPv6ヘッダーチェーン全体を解析して、それがDHCPv6クライアント向けのDHCPv6パケットであるかどうか（つまり、DHCPv6-serverメッセージ）を識別する必要があります。

RATIONALE: DHCPv6-Shield implementations MUST NOT enforce a limit on the number of bytes they can inspect (starting from the beginning of the IPv6 packet), since this could introduce false negatives: DHCP6-server packets received on ports not allowed to receive such packets could be allowed simply because the DHCPv6-Shield device does not parse the entire IPv6 Header Chain present in the packet.

根拠：DHCPv6-Shield実装は、（IPv6パケットの先頭から開始して）検査できるバイト数に制限を強制してはなりません。これは、偽陰性を引き起こす可能性があるためです：そのようなパケットの受信を許可されていないポートで受信されたDHCP6-serverパケットDHCPv6-Shieldデバイスがパケット内に存在するIPv6ヘッダーチェーン全体を解析しないため、許可される可能性があります。

2. When parsing the IPv6 Header Chain, if the packet is a First Fragment (i.e., a packet containing a Fragment Header with the Fragment Offset set to 0) and it fails to contain the entire IPv6 Header Chain (i.e., all the headers starting from the IPv6 header up to, and including, the Upper-Layer Header), DHCPv6-Shield MUST drop the packet and ought to log the packet drop event in an implementation-specific manner as a security fault.

2. IPv6ヘッダーチェーンの解析時に、パケットが最初のフラグメント（つまり、フラグメントオフセットが0に設定されたフラグメントヘッダーを含むパケット）であり、IPv6ヘッダーチェーン全体（つまり、 DHCPv6-Shieldは、Upper-LayerヘッダーまでのIPv6ヘッダー）でパケットをドロップする必要があり、セキュリティフォールトとして実装固有の方法でパケットドロップイベントを記録する必要があります。

RATIONALE: Packets that fail to contain the entire IPv6 Header Chain could otherwise be leveraged for circumventing DHCPv6-Shield. [RFC7112] requires that the First Fragment (i.e., the fragment with the Fragment Offset set to 0) contain the entire IPv6 Header Chain. [RFC7112] also allows intermediate systems such as routers to drop packets that fail to comply with this requirement.

根拠：IPv6ヘッダーチェーン全体を含まないパケットは、DHCPv6-Shieldを回避するために利用される可能性があります。 [RFC7112]では、最初のフラグメント（つまり、フラグメントオフセットが0に設定されたフラグメント）にIPv6ヘッダーチェーン全体が含まれている必要があります。 [RFC7112]では、ルーターなどの中間システムが、この要件に準拠しないパケットをドロップすることもできます。

NOTE: This rule should only be applied to IPv6 fragments with a Fragment Offset of 0 (non-First Fragments can be safely passed, since they will never reassemble into a complete datagram if they are part of a DHCPv6 packet meant for a DHCPv6 client received on a port where such packets are not allowed).

注：このルールは、フラグメントオフセットが0のIPv6フラグメントにのみ適用する必要があります（非最初のフラグメントは、受信したDHCPv6クライアント向けのDHCPv6パケットの一部である場合、完全なデータグラムに再構成されないため、安全に渡されます。そのようなパケットが許可されていないポートで）。

3. DHCPv6-Shield MUST provide a configuration knob that controls whether or not packets with unrecognized Next Header values are dropped; this configuration knob MUST default to "drop". When parsing the IPv6 Header Chain, if the packet contains an unrecognized Next Header value and the configuration knob is configured to "drop", DHCPv6-Shield MUST drop the packet and ought to log the packet drop event in an implementation-specific manner as a security fault.

3. DHCPv6-Shieldは、認識されない次のヘッダー値を持つパケットがドロップされるかどうかを制御する構成ノブを提供する必要があります。この設定ノブはデフォルトで「ドロップ」する必要があります。 IPv6ヘッダーチェーンを解析するときに、パケットに認識されない次のヘッダー値が含まれ、構成ノブが「ドロップ」するように構成されている場合、DHCPv6-Shieldはパケットをドロップし、実装固有の方法でパケットドロップイベントを記録する必要があります。セキュリティ違反。

RATIONALE: An unrecognized Next Header value could possibly identify an IPv6 Extension Header and thus be leveraged to conceal a DHCPv6-server packet (since there is no way for DHCPv6-Shield to parse past unrecognized Next Header values [IPV6-UEH]). [RFC7045] requires that nodes be configurable with respect to whether or not packets with unrecognized headers are forwarded and allows the default behavior to be that such packets be dropped.

根拠：認識されない次のヘッダー値はIPv6拡張ヘッダーを識別し、DHCPv6-serverパケットを隠すために利用される可能性があります（DHCPv6-Shieldが過去の認識されない次のヘッダー値を解析する方法がないため[IPV6-UEH]）。 [RFC7045]は、認識されないヘッダーを持つパケットが転送されるかどうかに関してノードが構成可能であることを要求し、そのようなパケットがドロップされるというデフォルトの動作を許可します。

4. When parsing the IPv6 Header Chain, if the packet is identified to be a DHCPv6 packet meant for a DHCPv6 client, DHCPv6-Shield MUST drop the packet and SHOULD log the packet drop event in an implementation-specific manner as a security alert.

4. IPv6ヘッダーチェーンを解析するときに、パケットがDHCPv6クライアント向けのDHCPv6パケットであると識別された場合、DHCPv6-Shieldはパケットをドロップし、セキュリティアラートとして実装固有の方法でパケットドロップイベントを記録する必要があります（SHOULD）。

RATIONALE: Ultimately, the goal of DHCPv6-Shield is to drop DHCPv6 packets destined to DHCPv6 clients (i.e., DHCPv6-server messages) that are received on ports that have not been explicitly configured to allow the receipt of such packets.

根拠：最終的に、DHCPv6-Shieldの目標は、そのようなパケットの受信を許可するように明示的に構成されていないポートで受信されたDHCPv6クライアント宛てのDHCPv6パケット（つまり、DHCPv6-serverメッセージ）をドロップすることです。

5. In all other cases, DHCPv6-Shield MUST pass the packet as usual.

5. それ以外の場合はすべて、DHCPv6-Shieldは通常どおりパケットを渡す必要があります。

NOTE: For the purpose of enforcing the DHCPv6-Shield filtering policy, an ESP header [RFC4303] should be considered to be an "upper-layer protocol" (that is, it should be considered the last header in the IPv6 Header Chain). This means that packets employing ESP would be passed by the DHCPv6-Shield device to the intended destination. If the destination host does not have a security association with the sender of the aforementioned IPv6 packet, the packet would be dropped. Otherwise, if the packet is considered valid by the IPsec implementation at the receiving host and encapsulates a DHCPv6 message, what to do with such a packet is up to the receiving host.

注：DHCPv6-Shieldフィルタリングポリシーを適用する目的で、ESPヘッダー[RFC4303]は「上位層プロトコル」と見なす必要があります（つまり、IPv6ヘッダーチェーンの最後のヘッダーと見なす必要があります）。これは、ESPを使用するパケットがDHCPv6-Shieldデバイスによって目的の宛先に渡されることを意味します。宛先ホストに前述のIPv6パケットの送信者とのセキュリティアソシエーションがない場合、パケットはドロップされます。そうでない場合、パケットが受信ホストのIPsec実装によって有効であると見なされ、DHCPv6メッセージをカプセル化する場合、そのようなパケットをどう処理するかは受信ホスト次第です。

The rules above indicate that if a packet is dropped due to this filtering policy, the packet drop event should be logged in an implementation-specific manner as a security fault. It is useful for the logging mechanism to include a per-port drop counter dedicated to DHCPv6-Shield packet drops.

上記のルールは、このフィルタリングポリシーが原因でパケットがドロップされた場合、パケットドロップイベントをセキュリティ障害として実装固有の方法でログに記録する必要があることを示しています。 DHCPv6-Shieldパケットドロップ専用のポートごとのドロップカウンターを含めると、ロギングメカニズムに役立ちます。

In order to protect current end-node IPv6 implementations, Rule #2 has been defined such that the default is for packets that cannot be positively identified as not being DHCPv6-server packets (because the packet is a fragment that fails to include the entire IPv6 Header Chain) to be dropped. This means that, at least in theory, DHCPv6-Shield could result in false-positive blocking of some legitimate (non-DHCPv6-server) packets. However, as noted in [RFC7112], IPv6 packets that fail to include the entire IPv6 Header Chain are virtually impossible to police with stateless filters and firewalls; hence, they are unlikely to survive in real networks. [RFC7112] requires that hosts employing fragmentation include the entire IPv6 Header Chain in the First Fragment (the fragment with the Fragment Offset set to 0), thus eliminating the aforementioned false positives.

現在のエンドノードIPv6実装を保護するために、ルール＃2は、デフォルトがDHCPv6サーバーパケットでないと明確に識別できないパケット用に定義されています（パケットはIPv6全体を含めることができないフラグメントであるため）ヘッダーチェーン）が削除されます。これは、少なくとも理論的には、DHCPv6-Shieldによって、一部の正当な（DHCPv6-server以外の）パケットが偽陽性でブロックされる可能性があることを意味します。ただし、[RFC7112]で述べられているように、IPv6ヘッダーチェーン全体を含めることができないIPv6パケットは、ステートレスフィルターとファイアウォールでポリシングすることは事実上不可能です。したがって、実際のネットワークでは存続しそうにありません。 [RFC7112]では、フラグメンテーションを使用するホストに最初のフラグメント（フラグメントオフセットが0に設定されたフラグメント）にIPv6ヘッダーチェーン全体を含める必要があるため、前述の偽陽性を排除します。

The aforementioned filtering rules implicitly handle the case of fragmented packets: if the DHCPv6-Shield device fails to identify the upper-layer protocol as a result of the use of fragmentation, the corresponding packets would be dropped.

前述のフィルタリングルールは断片化されたパケットのケースを暗黙的に処理します。DHCPv6-Shieldデバイスが断片化の使用の結果として上位層プロトコルを識別できない場合、対応するパケットはドロップされます。

Finally, we note that IPv6 implementations that allow overlapping fragments (i.e., that do not comply with [RFC5722]) might still be subject of DHCPv6-based attacks. However, a recent assessment of IPv6 implementations [SI6-FRAG] with respect to their fragment reassembly policy seems to indicate that most current implementations comply with [RFC5722].

最後に、フラグメントのオーバーラップを許可する（つまり、[RFC5722]に準拠しない）IPv6実装は、DHCPv6ベースの攻撃の対象になる可能性があることに注意してください。ただし、フラグメント再構成ポリシーに関するIPv6実装[SI6-FRAG]の最近の評価は、現在のほとんどの実装が[RFC5722]に準拠していることを示しているようです。

6. Security Considerations

6. セキュリティに関する考慮事項

The recommendations in this document represent the ideal behavior of a DHCPv6-Shield device. However, in order to implement DHCPv6-Shield on the fast path, it may be necessary to limit the depth into the packet that can be scanned before giving up. In circumstances where there is such a limitation, it is recommended that implementations drop packets after attempting to find a protocol header up to that limit, whatever it is. Ideally, such devices should be configurable with a list of protocol header identifiers so that if new transport protocols are standardized after the device is released, they can be added to the list of protocol header types that the device recognizes. Since any protocol header that is not a UDP header would be passed by the DHCPv6-Shield algorithm, this would allow such devices to avoid blocking the use of new transport protocols. When an implementation must stop searching for recognizable header types in a packet due to such limitations, the device SHOULD be configurable to either pass or drop that packet.

このドキュメントの推奨事項は、DHCPv6-Shieldデバイスの理想的な動作を表しています。ただし、高速パスにDHCPv6-Shieldを実装するために、あきらめる前にスキャンできるパケットの深さを制限する必要がある場合があります。そのような制限がある状況では、実装は、それが何であれ、その制限までのプロトコルヘッダーを見つけようとした後、パケットをドロップすることをお勧めします。理想的には、デバイスが解放された後に新しいトランスポートプロトコルが標準化された場合に、デバイスが認識するプロトコルヘッダータイプのリストに追加できるように、そのようなデバイスはプロトコルヘッダー識別子のリストで設定可能である必要があります。 UDPヘッダーではないプロトコルヘッダーはDHCPv6-Shieldアルゴリズムによって渡されるため、このようなデバイスは、新しいトランスポートプロトコルの使用をブロックすることを回避できます。このような制限のために、実装がパケット内の認識可能なヘッダータイプの検索を停止する必要がある場合、デバイスは、そのパケットを渡すかドロップするように構成可能である必要があります（SHOULD）。

The mechanism specified in this document can be used to mitigate DHCPv6-based attacks against hosts. Attack vectors based on other messages meant for network configuration (such as ICMPv6 Router Advertisements) are out of the scope of this document. Additionally, the mechanism specified in this document does not mitigate attacks against DHCPv6 servers (e.g., Denial of Service).

このドキュメントで指定されているメカニズムは、ホストに対するDHCPv6ベースの攻撃を緩和するために使用できます。ネットワーク構成用の他のメッセージ（ICMPv6ルーターアドバタイズメントなど）に基づく攻撃ベクトルは、このドキュメントの範囲外です。さらに、このドキュメントで指定されているメカニズムは、DHCPv6サーバーに対する攻撃（サービス拒否など）を緩和しません。

If deployed in a layer 2 domain with several cascading switches, there will be an ingress port on the host's local switch that will need to be enabled for receiving DHCPv6-server messages. However, this local switch will be reliant on the upstream devices filtering out rogue DHCPv6-server messages, as the local switch has no way of determining which upstream DHCP-server messages are valid. Therefore, in order to be effective, DHCPv6-Shield should be deployed and enabled on all layer 2 switches of a given layer 2 domain.

複数のカスケードスイッチを備えたレイヤー2ドメインに展開する場合、ホストのローカルスイッチに入力ポートがあり、DHCPv6サーバーメッセージを受信できるようにする必要があります。ただし、ローカルスイッチには有効なアップストリームDHCPサーバーメッセージを判別する方法がないため、このローカルスイッチは、不正なDHCPv6サーバーメッセージを除外するアップストリームデバイスに依存します。したがって、効果的にするためには、DHCPv6-Shieldを展開して、特定のレイヤー2ドメインのすべてのレイヤー2スイッチで有効にする必要があります。

As noted in Section 5, IPv6 implementations that allow overlapping fragments (i.e., that do not comply with [RFC5722]) might still be subject to DHCPv6-based attacks. However, most current implementations seem to comply with [RFC5722] and hence forbid IPv6 overlapping fragments.

セクション5で述べたように、フラグメントの重複を許可する（つまり、[RFC5722]に準拠しない）IPv6実装は、依然としてDHCPv6ベースの攻撃を受ける可能性があります。ただし、現在のほとんどの実装は[RFC5722]に準拠しているため、IPv6の重複フラグメントを禁止しています。

We note that if an attacker sends a fragmented DHCPv6 packet on a port not allowed to receive such packets, the First Fragment would be dropped, and the rest of the fragments would be passed. This means that the victim node would tie memory buffers for the aforementioned fragments, which would never reassemble into a complete datagram. If a large number of such packets were sent by an attacker, and the victim node failed to implement proper resource management for the fragment reassembly buffer, this could lead to a Denial of Service (DoS). However, this does not really introduce a new attack vector, since an attacker could always perform the same attack by sending a forged fragmented datagram in which at least one of the fragments is missing. [CPNI-IPv6] discusses some resource management strategies that could be implemented for the fragment reassembly buffer.

攻撃者がフラグメント化されたDHCPv6パケットを、そのようなパケットの受信を許可されていないポートに送信すると、最初のフラグメントがドロップされ、残りのフラグメントが渡されることに注意してください。これは、被害者ノードが前述のフラグメントのメモリバッファを結合することを意味し、完全なデータグラムに再構成されることはありません。このようなパケットが攻撃者から大量に送信され、被害者ノードがフラグメント再構成バッファーの適切なリソース管理を実装できなかった場合、サービス拒否（DoS）につながる可能性があります。ただし、攻撃者は少なくとも1つのフラグメントが欠落している偽造フラグメント化データグラムを送信することで常に同じ攻撃を実行できるため、これは実際には新しい攻撃ベクトルを導入しません。 [CPNI-IPv6]は、フラグメント再構成バッファーに実装できるいくつかのリソース管理戦略について説明します。

Additionally, we note that the security of a site employing DHCPv6-Shield could be further improved by deploying [RFC7513] to mitigate IPv6 address spoofing attacks.

さらに、DHCPv6-Shieldを採用しているサイトのセキュリティは、[RFC7513]を導入してIPv6アドレススプーフィング攻撃を緩和することにより、さらに改善できる可能性があることに注意してください。

Finally, we note that other mechanisms for mitigating attacks based on DHCPv6-server messages are available that have different deployment considerations. For example, [SECURE-DHCPV6] allows for authentication of DHCPv6-server packets if the IPv6 addresses of the DHCPv6 servers can be pre-configured at the client nodes.

最後に、DHCPv6サーバーメッセージに基づく攻撃を軽減するために、導入に関する考慮事項が異なる他のメカニズムも利用できることに注意してください。たとえば、[SECURE-DHCPV6]は、DHCPv6サーバーのIPv6アドレスをクライアントノードで事前構成できる場合、DHCPv6-serverパケットの認証を許可します。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.

[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<http://www.rfc-editor.org/info/ rfc2460>。

[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.

[RFC3315] Droms、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315 、DOI 10.17487 / RFC3315、2003年7月、<http://www.rfc-editor.org/info/rfc3315>。

[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <http://www.rfc-editor.org/info/rfc4303>.

[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、DOI 10.17487 / RFC4303、2005年12月、<http://www.rfc-editor.org/info/rfc4303>。

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.

[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<http：/ /www.rfc-editor.org/info/rfc4861>。

[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, DOI 10.17487/RFC5722, December 2009, <http://www.rfc-editor.org/info/rfc5722>.

[RFC5722] Krishnan、S。、「Handling of Overlapping IPv6 Fragments」、RFC 5722、DOI 10.17487 / RFC5722、2009年12月、<http://www.rfc-editor.org/info/rfc5722>。

[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, DOI 10.17487/RFC7045, December 2013, <http://www.rfc-editor.org/info/rfc7045>.

[RFC7045] Carpenter、B。およびS. Jiang、「IPv6拡張ヘッダーの送信と処理」、RFC 7045、DOI 10.17487 / RFC7045、2013年12月、<http://www.rfc-editor.org/info/rfc7045> 。

[RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of Oversized IPv6 Header Chains", RFC 7112, DOI 10.17487/RFC7112, January 2014, <http://www.rfc-editor.org/info/rfc7112>.

[RFC7112] Gont、F.、Manral、V。、およびR. Bonica、「特大IPv6ヘッダーチェーンの影響」、RFC 7112、DOI 10.17487 / RFC7112、2014年1月、<http://www.rfc-editor.org / info / rfc7112>。

7.2. Informative References

7.2. 参考引用

[CPNI-IPv6] Gont, F., "Security Assessment of the Internet Protocol version 6 (IPv6)", UK Centre for the Protection of National Infrastructure, (available on request).

[CPNI-IPv6] Gont、F。、「インターネットプロトコルバージョン6（IPv6）のセキュリティ評価」、国立インフラストラクチャ保護センター（リクエストに応じて利用可能）。

[IANA-PROTO] IANA, "Protocol Numbers", <http://www.iana.org/assignments/protocol-numbers>.

[IANA-PROTO] IANA、「プロトコル番号」、<http://www.iana.org/assignments/protocol-numbers>。

[IPV6-UEH] Gont, F., Liu, W., Krishnan, S., and H. Pfeifer, "IPv6 Universal Extension Header", Work in Progress, draft-gont-6man-rfc6564bis-00, April 2014.

[IPV6-UEH] Gont、F.、Liu、W.、Krishnan、S。、およびH. Pfeifer、「IPv6 Universal Extension Header」、Work in Progress、draft-gont-6man-rfc6564bis-00、2014年4月。

[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Problem Statement", RFC 6104, DOI 10.17487/RFC6104, February 2011, <http://www.rfc-editor.org/info/rfc6104>.

[RFC6104] Chown、T。およびS. Venaas、「Rogue IPv6 Router Advertisement Problem Statement」、RFC 6104、DOI 10.17487 / RFC6104、2011年2月、<http://www.rfc-editor.org/info/rfc6104>。

[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 10.17487/RFC6105, February 2011, <http://www.rfc-editor.org/info/rfc6105>.

[RFC6105] Levy-Abegnoli、E.、Van de Velde、G.、Popoviciu、C。、およびJ. Mohacsi、「IPv6ルーターアドバタイズメントガード」、RFC 6105、DOI 10.17487 / RFC6105、2011年2月、<http：// www.rfc-editor.org/info/rfc6105>。

[RFC7113] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", RFC 7113, DOI 10.17487/RFC7113, February 2014, <http://www.rfc-editor.org/info/rfc7113>.

[RFC7113] Gont、F。、「IPv6ルーターアドバタイズメントガード（RA-Guard）の実装に関するアドバイス」、RFC 7113、DOI 10.17487 / RFC7113、2014年2月、<http://www.rfc-editor.org/info/rfc7113 >。

[RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address Validation Improvement (SAVI) Solution for DHCP", RFC 7513, DOI 10.17487/RFC7513, May 2015, <http://www.rfc-editor.org/info/rfc7513>.

[RFC7513] Bi、J.、Wu、J.、Yao、G。、およびF. Baker、「DHCPのソースアドレス検証改善（SAVI）ソリューション」、RFC 7513、DOI 10.17487 / RFC7513、2015年5月、<http： //www.rfc-editor.org/info/rfc7513>。

[SECURE-DHCPV6] Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs", Work in Progress, draft-ietf-dhc-secure-dhcpv6-07, September 2012.

[SECURE-DHCPV6] Jiang、S。およびS. Shen、「CGAを使用したセキュアDHCPv6」、作業中、draft-ietf-dhc-secure-dhcpv6-07、2012年9月。

[SI6-FRAG] SI6 Networks, "IPv6 NIDS evasion and improvements in IPv6 fragmentation/reassembly", 2012, <http://blog.si6networks.com/2012/02/ ipv6-nids-evasion-and-improvements-in.html>.

[SI6-FRAG] SI6ネットワーク、「IPv6 NIDS回避とIPv6フラグメンテーション/再構成の改善」、2012、<http://blog.si6networks.com/2012/02/ ipv6-nids-evasion-and-improvements-in。 html>。

Acknowledgements

謝辞

The authors would like to thank Mike Heard, who provided detailed feedback on earlier draft versions of this document and helped a lot in producing a technically sound document throughout the whole publication process.

著者は、このドキュメントの以前のドラフトバージョンに関する詳細なフィードバックを提供し、公開プロセス全体を通じて技術的に健全なドキュメントを作成するのに多大な貢献をしてくれたMike Heardに感謝します。

The authors would like to thank (in alphabetical order) Ben Campbell, Jean-Michel Combes, Sheng Jiang, Ted Lemon, Pete Resnick, Carsten Schmoll, Juergen Schoenwaelder, Robert Sleigh, Donald Smith, Mark Smith, Hannes Tschofenig, Eric Vyncke, and Qin Wu for providing valuable comments on earlier draft versions of this document.

著者は、ベンキャンベル、ジャンミッシェルコムズ、シェンジャン、テッドレモン、ピートレズニック、カルステンシュモール、ユルゲンシェーンヴェルダー、ロバートスレイ、ドナルドスミス、マークスミス、ハンネスチョフェニグ、エリックヴィンケ、およびこのドキュメントの以前のドラフトバージョンに貴重なコメントを提供してくださったQin Wu氏。

Part of Section 3 of this document was borrowed from [RFC7112], authored by Fernando Gont, Vishwas Manral, and Ron Bonica.

このドキュメントのセクション3の一部は、Fernando Gont、Vishwas Manral、およびRon Bonicaによって作成された[RFC7112]から借用されました。

This document is heavily based on [RFC7113], authored by Fernando Gont. Thus, the authors would like to thank the following individuals for providing valuable comments on [RFC7113]: Ran Atkinson, Karl Auer, Robert Downie, Washam Fan, David Farmer, Mike Heard, Marc Heuse, Nick Hilliard, Ray Hunter, Joel Jaeggli, Simon Perreault, Arturo Servin, Gunter Van de Velde, James Woodyatt, and Bjoern A. Zeeb.

この文書は、Fernando Gontによって作成された[RFC7113]に大きく基づいています。したがって、著者は[RFC7113]に関する貴重なコメントを提供してくれた次の人物に感謝したいと思います。 Simon Perreault、Arturo Servin、Gunter Van de Velde、James Woodyatt、Bjoern A. Zeeb。

The authors would like to thank Joel Jaeggli for his advice and guidance throughout the IETF process.

著者は、IETFプロセス全体を通して彼のアドバイスとガイダンスを提供してくれたJoel Jaeggliに感謝します。

Fernando Gont would like to thank Diego Armando Maradona for his magic and inspiration.

フェルナンドゴントは、ディエゴアルマンドマラドーナの魔法とインスピレーションに感謝します。

Authors' Addresses

著者のアドレス

Fernando Gont SI6 Networks / UTN-FRH Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina

フェルナンドゴンSI6ネットワーク/ UTN-FRHエヴァリストキャリーゴ2644ブエノスアイレス州ハエド1706アルゼンチン

   Phone: +54 11 4650 8472
   Email: fgont@si6networks.com
   URI:   http://www.si6networks.com

Will (Shucheng) Liu Huawei Technologies Bantian, Longgang District Shenzhen 518129 China

will（Shu成）l IU hu Aはテクノロジー禁止の日であり、長いだけの地区は非常に現実的です518129中国

   Email: liushucheng@huawei.com

Gunter Van de Velde Alcatel-Lucent Copernicuslaan 50 Antwerp, Antwerp 2018 Belgium

Gunter Van de Velde Alcatel-Lucent Copernicuslaan 50アントワープ、アントワープ2018ベルギー

   Phone: +32 476 476 022
   Email: gunter.van_de_velde@alcatel-lucent.com