RFC 7113 - Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7113
タイトル : RFC 7113 - IPv6ルーターアドバタイズメントガード（RA-Guard）の実装に関するアドバイス
翻訳編集 : 自動生成

[要約] RFC 7113は、IPv6ルータ広告ガード（RA-Guard）の実装アドバイスを提供するものであり、IPv6ネットワークにおけるルータ広告の悪用を防ぐためのガイドラインです。目的は、RA-Guardの実装に関するベストプラクティスを提供し、ネットワークのセキュリティを向上させることです。

Internet Engineering Task Force (IETF)                           F. Gont
Request for Comments: 7113                           Huawei Technologies
Updates: 6105                                              February 2014
Category: Informational
ISSN: 2070-1721

Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)

IPv6ルーターアドバタイズメントガード（RA-Guard）の実装に関するアドバイス

Abstract

概要

The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages. Many existing IPv6 deployments rely on RA-Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers. This document describes the evasion techniques that affect the aforementioned implementations and formally updates RFC 6105, such that the aforementioned RA-Guard evasion vectors are eliminated.

IPv6ルーターアドバタイズメントガード（RA-Guard）メカニズムは、偽造されたICMPv6ルーターアドバタイズメッセージに基づく攻撃ベクトルを軽減するために一般的に採用されています。既存の多くのIPv6展開は、前述の攻撃ベクトルに対する最初の防御線としてRA-Guardに依存しています。ただし、RA-Guardの一部の実装では、IPv6拡張ヘッダーを採用することで回避されやすいことが判明しています。このドキュメントでは、前述の実装に影響を与え、RFC 6105を正式に更新する回避手法について説明します。これにより、前述のRA-Guard回避ベクトルが排除されます。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 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/rfc7113.

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

著作権表示

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 . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Evasion Techniques for Some RA-Guard Implementations . . . . .  3
     2.1.  Attack Vector Based on IPv6 Extension Headers  . . . . . .  3
     2.2.  Attack Vector Based on IPv6 Fragmentation  . . . . . . . .  4
   3.  RA-Guard Implementation Advice . . . . . . . . . . . . . . . .  6
   4.  Other Implications . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Appendix A.  Assessment Tools  . . . . . . . . . . . . . . . . . . 12

1. Introduction

1. はじめに

IPv6 Router Advertisement Guard (RA-Guard) is a mitigation technique for attack vectors based on ICMPv6 Router Advertisement [RFC4861] messages. [RFC6104] describes the problem statement of "Rogue IPv6 Router Advertisements", and [RFC6105] specifies the "IPv6 Router Advertisement Guard" functionality.

IPv6ルーターアドバタイズメントガード（RA-Guard）は、ICMPv6ルーターアドバタイズメント[RFC4861]メッセージに基づく攻撃ベクトルの緩和技術です。 [RFC6104]は「不正なIPv6ルーターアドバタイズメント」の問題ステートメントを説明し、[RFC6105]は「IPv6ルーターアドバタイズメントガード」機能を指定しています。

The concept behind RA-Guard is that a Layer-2 (L2) device filters ICMPv6 Router Advertisement messages, according to a number of different criteria. The most basic filtering criterion is that Router Advertisement messages are discarded by the L2 device unless they are received on a specified port of the L2 device. Clearly, the effectiveness of RA-Guard relies on the ability of the L2 device to identify ICMPv6 Router Advertisement messages.

RA-Guardの背後にある概念は、レイヤー2（L2）デバイスが、さまざまな基準に従って、ICMPv6ルーターアドバタイズメッセージをフィルタリングすることです。最も基本的なフィルタリング基準は、ルーターアドバタイズメッセージがL2デバイスの指定されたポートで受信されない限り、L2デバイスによって破棄されることです。明らかに、RA-Guardの効果は、L2デバイスがICMPv6ルーターアドバタイズメントメッセージを識別する能力に依存しています。

Some popular RA-Guard implementations have been found to be easy to circumvent by employing IPv6 Extension Headers [CPNI-IPv6]. This

一部の一般的なRA-Guard実装は、IPv6拡張ヘッダー[CPNI-IPv6]を使用することで簡単に回避できることがわかっています。この

document describes such evasion techniques and provides advice to RA-Guard implementers such that the aforementioned evasion vectors can be eliminated.

ドキュメントは、そのような回避手法を説明し、前述の回避ベクトルを排除できるようにRA-Guardの実装者にアドバイスを提供します。

It should be noted that the previously mentioned techniques could also be exploited to evade network monitoring tools such as NDPMon [NDPMon], ramond [ramond], and rafixd [rafixd], and could probably be exploited to perform stealth DHCPv6 [RFC3315] attacks.

前述の手法は、NDPMon [NDPMon]、ramond [ramond]、rafixd [rafixd]などのネットワーク監視ツールを回避するために悪用される可能性があり、ステルスDHCPv6 [RFC3315]攻撃を実行するために悪用される可能性があることに注意してください。

2. Evasion Techniques for Some RA-Guard Implementations

2. 一部のRA-Guard実装の回避手法

The following subsections describe two different vectors that have been found to be effective for the evasion of popular implementations of RA-Guard. Section 2.1 describes an attack vector based on the use of IPv6 Extension Headers with ICMPv6 Router Advertisement messages, which may be used to circumvent the RA-Guard protection of those implementations that fail to process an entire IPv6 header chain when trying to identify the ICMPv6 Router Advertisement messages. Section 2.2 describes an attack method based on the use of IPv6 fragmentation, possibly in conjunction with the use of IPv6 Extension Headers. This later vector has been found to be effective against all existing implementations of RA-Guard.

次のサブセクションでは、RA-Guardの一般的な実装の回避に効果的であることが判明した2つの異なるベクトルについて説明します。セクション2.1では、ICMPv6ルーターアドバタイズメッセージでのIPv6拡張ヘッダーの使用に基づく攻撃ベクトルについて説明します。これは、ICMPv6ルーターを識別しようとするときにIPv6ヘッダーチェーン全体の処理に失敗する実装のRA-Guard保護を回避するために使用できます。広告メッセージ。セクション2.2では、IPv6拡張ヘッダーの使用と組み合わせて、IPv6フラグメンテーションの使用に基づく攻撃方法について説明します。この後者のベクターは、RA-Guardの既存のすべての実装に対して効果的であることが判明しています。

2.1. Attack Vector Based on IPv6 Extension Headers

2.1. IPv6拡張ヘッダーに基づく攻撃ベクトル

While there is currently no legitimate use for IPv6 Extension Headers in ICMPv6 Router Advertisement messages, Neighbor Discovery [RFC4861] implementations allow the use of Extension Headers with these messages, by simply ignoring the received options. Some RA-Guard implementations try to identify ICMPv6 Router Advertisement messages by simply looking at the "Next Header" field of the fixed IPv6 header, rather than following the entire header chain. As a result, such implementations fail to identify any ICMPv6 Router Advertisement messages that include any Extension Headers (for example, a Hop-by-Hop Options header, a Destination Options header, etc.), and can be easily circumvented.

現在、ICMPv6ルーターアドバタイズメッセージでIPv6拡張ヘッダーを使用する正当な方法はありませんが、近隣探索[RFC4861]実装では、受信したオプションを無視するだけで、これらのメッセージで拡張ヘッダーを使用できます。一部のRA-Guard実装は、ヘッダーチェーン全体をたどるのではなく、固定IPv6ヘッダーの「次のヘッダー」フィールドを確認するだけでICMPv6ルーターアドバタイズメッセージを識別しようとします。その結果、このような実装では、拡張ヘッダー（ホップバイホップオプションヘッダー、宛先オプションヘッダーなど）を含むICMPv6ルーターアドバタイズメッセージを識別できず、簡単に回避できます。

The following figure illustrates the structure of ICMPv6 Router Advertisement messages that implement this evasion technique:

次の図は、この回避手法を実装するICMPv6ルーター通知メッセージの構造を示しています。

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |NH=60|       |NH=58|        |                                |
      +-+-+-+       +-+-+-+        +                                +
      | IPv6 Header |  Dst Opt Hdr |  ICMPv6 Router Advertisement   |
      +             +              +                                +
      |             |              |                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.2. Attack Vector Based on IPv6 Fragmentation

2.2. IPv6フラグメンテーションに基づく攻撃ベクトル

This section presents a different attack vector, which has been found to be effective against all implementations of RA-Guard. The basic idea behind this attack vector is that if the forged ICMPv6 Router Advertisement is fragmented into at least two fragments, the L2 device implementing RA-Guard would be unable to identify the attack packet and would thus fail to block it.

このセクションでは、RA-Guardのすべての実装に対して効果的であることが判明している別の攻撃ベクトルについて説明します。この攻撃ベクトルの背後にある基本的な考え方は、偽造されたICMPv6ルーターアドバタイズメントが少なくとも2つのフラグメントにフラグメント化されている場合、RA-Guardを実装するL2デバイスは攻撃パケットを識別できず、そのためパケットをブロックできないということです。

A first variant of this attack vector would be an original ICMPv6 Router Advertisement message preceded with a Destination Options header, which results in two fragments. The following figure illustrates the "original" attack packet, prior to fragmentation, and the two resulting fragments that are actually sent as part of the attack.

この攻撃ベクトルの最初の変種は、宛先オプションヘッダーが前にある元のICMPv6ルーターアドバタイズメントメッセージで、2つのフラグメントが発生します。次の図は、フラグメント化前の「元の」攻撃パケットと、実際に攻撃の一部として送信される2つのフラグメントを示しています。

Original Packet:

元のパケット：

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |NH=60|       |NH=58|                           |           |
       +-+-+-+       +-+-+-+                           +           +
       | IPv6 Header |          Dst Opt Hdr            | ICMPv6 RA |
       +             +                                 +           +
       |             |                                 |           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

First Fragment:

最初のフラグメント：

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |NH=44|       |NH=60|       |NH=58|                 |
       +-+-+-+       +-+-+-+       +-+-+-+                 +
       | IPv6 Header |   Frag Hdr  |      Dst Opt Hdr      |
       +             +             +                       +
       |             |             |                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Second Fragment:

2番目のフラグメント：

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |NH=44|       |NH=60|       |             |           |
       +-+-+-+       +-+-+-+       +             +           +
       | IPv6 Header |   Frag Hdr  | Dst Opt Hdr | ICMPv6 RA |
       +             +             +             +           +
       |             |             |             |           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should be noted that the "Hdr Ext Len" field of the Destination Options header is present in the First Fragment (rather than the second). Therefore, it is impossible for a device processing only the second fragment to locate the ICMPv6 header contained in that fragment, since it is unknown how many bytes should be "skipped" to get to the next header following the Destination Options header.

Destination Optionsヘッダーの「Hdr Ext Len」フィールドは、（2番目ではなく）最初のフラグメントにあることに注意してください。したがって、2番目のフラグメントのみを処理するデバイスがそのフラグメントに含まれるICMPv6ヘッダーを見つけることはできません。宛先オプションヘッダーに続く次のヘッダーに到達するために「スキップ」するバイト数が不明であるためです。

Thus, by leveraging the use of the Fragment Header together with the use of the Destination Options header, the attacker is able to conceal the type and contents of the ICMPv6 message he is sending (an ICMPv6 Router Advertisement in this example). Unless the L2 device were to implement IPv6 fragment reassembly, it would be impossible for the device to identify the ICMPv6 type of the message.

したがって、攻撃者は、フラグメントヘッダーの使用と宛先オプションヘッダーの使用を併用することで、送信するICMPv6メッセージ（この例ではICMPv6ルーターアドバタイズメント）のタイプと内容を隠すことができます。 L2デバイスがIPv6フラグメント再構成を実装しない限り、デバイスがメッセージのICMPv6タイプを識別することは不可能です。

An L2 device could, however, at least detect that an ICMPv6 message (of some type) is being sent, since the "Next Header" field of the Destination Options header contained in the First Fragment is set to "58" (ICMPv6).

ただし、最初のフラグメントに含まれる宛先オプションヘッダーの「次のヘッダー」フィールドが「58」（ICMPv6）に設定されているため、L2デバイスは少なくとも（あるタイプの）ICMPv6メッセージが送信されていることを検出できます。

This idea can be taken further, such that it is also impossible for the L2 device to detect that the attacker is sending an ICMPv6 message in the first place. This can be achieved with an original ICMPv6 Router Advertisement message preceded with two Destination Options headers that results in two fragments. The following figure illustrates the "original" attack packet, prior to fragmentation, and the two resulting packets that are actually sent as part of the attack.

L2デバイスが攻撃者が最初にICMPv6メッセージを送信していることを検出することも不可能であるように、この考えはさらに取り入れることができます。これは、元のICMPv6ルーターアドバタイズメントメッセージの前に2つの宛先オプションヘッダーがあり、2つのフラグメントになることで実現できます。次の図は、フラグメンテーション前の「元の」攻撃パケットと、実際に攻撃の一部として送信される2つの結果のパケットを示しています。

Original Packet:

元のパケット：

    +-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |NH=60|         |NH=60|       |NH=58|       |           |
    +-+-+-+         +-+-+-+       +-+-+-+       +           +
    |  IPv6 header  | Dst Opt Hdr | Dst Opt Hdr | ICMPv6 RA |
    +               +             +             +           +
    |               |             |             |           |
    +-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

First Fragment:

最初のフラグメント：

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |NH=44|       |NH=60|       |NH=60|                   |
    +-+-+-+       +-+-+-+       +-+-+-+                   +
    | IPv6 header |   Frag Hdr  |       Dst Opt Hdr       |
    +             +             +                         +
    |             |             |                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    Second Fragment:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |NH=44|       |NH=60|       |           |NH=58|       |           |
    +-+-+-+       +-+-+-+       +           +-+-+-+       +           +
    | IPv6 header |   Frag Hdr  | Dst O Hdr | Dst Opt Hdr | ICMPv6 RA |
    +             +             +           +             +           +
    |             |             |           |             |           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In this variant, the "Next Header" field of the Destination Options header contained in the First Fragment is set to "60" (Destination Options header); thus, it is impossible for a device processing only the First Fragment to detect that an ICMPv6 message is being sent in the first place.

このバリアントでは、最初のフラグメントに含まれる宛先オプションヘッダーの「次のヘッダー」フィールドは「60」（宛先オプションヘッダー）に設定されます。したがって、最初のフラグメントのみを処理するデバイスが、最初にICMPv6メッセージが送信されていることを検出することは不可能です。

The second fragment presents the same challenges as the second fragment of the previous variant. That is, it would be impossible for a device processing only the second fragment to locate the second Destination Options header (and hence the ICMPv6 header), since the "Hdr Ext Len" field of the first Destination Options header is present in the First Fragment (rather than the second).

2番目のフラグメントは、前のバリアントの2番目のフラグメントと同じ課題を提示します。つまり、最初のフラグメントに最初の宛先オプションヘッダーの「Hdr Ext Len」フィールドが存在するため、2番目のフラグメントのみを処理するデバイスが2番目の宛先オプションヘッダー（およびICMPv6ヘッダー）を見つけることは不可能です。（2番目ではなく）。

3. RA-Guard Implementation Advice

3. RA-Guardの実装に関するアドバイス

The following filtering rules must be implemented as part of an RA-Guard implementation on ports that face interfaces that are not allowed to send ICMPv6 Router Advertisement messages, such that the vulnerabilities discussed in this document are eliminated:

このドキュメントで説明されている脆弱性を排除するために、ICMPv6ルーターアドバタイズメッセージの送信を許可されていないインターフェイスに面するポートに、RA-Guard実装の一部として次のフィルタリングルールを実装する必要があります。

1. If the IPv6 Source Address of the packet is not a link-local address (fe80::/10), RA-Guard must pass the packet.

1. パケットのIPv6送信元アドレスがリンクローカルアドレス（fe80 :: / 10）ではない場合、RA-Guardはパケットを渡す必要があります。

RATIONALE: This prevents RA-Guard from dedicating processing cycles to filtering packets that originate off-net and that, if they are RA's, would not be accepted by the host. Section 6.1.2 of [RFC4861] requires nodes to discard Router Advertisement messages if their IPv6 Source Address is not a link-local address.

根拠：これにより、RA-Guardがオフネットから発信されたパケットのフィルタリングに専用の処理サイクルを費やさなくなり、RAの場合、ホストによって受け入れられなくなります。 [RFC4861]のセクション6.1.2では、IPv6送信元アドレスがリンクローカルアドレスではない場合、ノードがルーターアドバタイズメッセージを破棄する必要があります。

2. If the Hop Limit is not 255, RA-Guard must pass the packet.

2. ホップ制限が255でない場合、RA-Guardはパケットを渡す必要があります。

RATIONALE: This prevents RA-Guard from dedicating processing cycles to filtering packets that originate off-net and that, if they are RA's, would not be accepted by the destination host. Section 6.1.2 of [RFC4861] requires nodes to discard Router Advertisement messages if their Hop Limit is not 255.

根拠：これにより、RA-Guardがオフネットから発信されたパケットのフィルタリングに専用の処理サイクルを費やし、RAの場合、宛先ホストによって受け入れられなくなります。 [RFC4861]のセクション6.1.2では、ホップ制限が255でない場合、ノードはルーター通知メッセージを破棄する必要があります。

3. RA-Guard must parse the entire IPv6 header chain present in the packet, to identify whether the packet is a Router Advertisement message.

3. RA-Guardは、パケットに存在するIPv6ヘッダーチェーン全体を解析して、パケットがルーターアドバタイズメッセージであるかどうかを識別する必要があります。

NOTE: RA-Guard 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 positives: legitimate packets could be dropped simply because the RA-Guard device does not parse the entire IPv6 header chain present in the packet. An implementation that has such an implementation-specific limit must not claim compliance with this specification, and must pass the packet when such implementation-specific limit is reached.

注：RA-Guardの実装では、検査できるバイト数に制限を設けないでください（IPv6パケットの先頭から開始）。これにより、誤検知が発生する可能性があります。RA-Guardデバイスが単純な理由で正当なパケットがドロップされる可能性がありますパケットに存在するIPv6ヘッダーチェーン全体を解析しません。このような実装固有の制限がある実装は、この仕様への準拠を主張してはならず、そのような実装固有の制限に達したときにパケットを渡す必要があります。

4. 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), RA-Guard must drop the packet and should log the packet drop event in an implementation-specific manner as a security fault.

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

RATIONALE: [RFC7112] specifies that the First Fragment (i.e., the fragment with the Fragment Offset set to 0) must contain the entire IPv6 header chain, and allows intermediate systems such as routers to drop those packets that fail to comply with this requirement.

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

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 Router Advertisement received on a port where such packets are not allowed).

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

5. When parsing the IPv6 header chain, if the packet is identified to be an ICMPv6 Router Advertisement message or the packet contains an unrecognized Next Header value [IANA-IP-PROTO], RA-Guard must drop the packet, and should log the packet drop event in an implementation-specific manner as a security fault. RA-Guard must provide a configuration knob that controls whether packets with unrecognized Next Header values are dropped; this configuration knob must default to "drop".

5. IPv6ヘッダーチェーンを解析するときに、パケットがICMPv6ルーターアドバタイズメントメッセージであると識別された場合、またはパケットに認識できない次のヘッダー値[IANA-IP-PROTO]が含まれている場合、RA-Guardはパケットをドロップする必要があり、パケットドロップをログに記録する必要があります。セキュリティ障害として実装固有の方法でイベント。 RA-Guardは、認識されない次のヘッダー値を持つパケットをドロップするかどうかを制御する構成ノブを提供する必要があります。この設定ノブはデフォルトで「ドロップ」にする必要があります。

RATIONALE: By definition, Router Advertisement messages are required to originate on-link, have a link-local IPv6 Source Address, and have a Hop Limit value of 255 [RFC4861]. [RFC7045] requires that nodes be configurable with respect to whether packets with unrecognized headers are forwarded, and allows the default behavior to be that such packets be dropped.

根拠：定義により、ルーターアドバタイズメッセージはリンク上で発信され、リンクローカルIPv6送信元アドレスを持ち、ホップ制限値が255 [RFC4861]である必要があります。 [RFC7045]は、認識されないヘッダーを持つパケットが転送されるかどうかに関してノードが構成可能であることを要求し、そのようなパケットがドロップされるというデフォルトの動作を許可します。

6. In all other cases, RA-Guard must pass the packet as usual.

6. その他すべての場合、RA-Guardは通常どおりパケットを渡す必要があります。

NOTE: For the purpose of enforcing the RA-Guard filtering policy, an Encapsulating Security Payload (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 RA-Guard 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 Router Advertisement message, it is up to the receiving host what to do with such a packet.

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

If a packet is dropped due to this filtering policy, then the packet drop event should be logged in an implementation-specific manner as a security fault. The logging mechanism should include a drop counter dedicated to RA-Guard packet drops.

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

In order to protect current end-node IPv6 implementations, Rule #4 has been defined as a default rule to drop packets that cannot be positively identified as not being Router Advertisement (RA) messages (because the packet is a fragment that fails to include the entire IPv6 header chain). This means that, at least in theory, RA-Guard could result in false-positive blocking of some legitimate non-RA packets that could not be positively identified as being non-RA. In order to reduce the likelihood of false positives, Rule #1 and Rule #2 require that packets that would not pass the required validation checks for RA messages (Section 6.1.2 of [RFC4861]) be passed without further inspection. In any case, as noted in [RFC7112], IPv6 packets that fail to include the entire IPv6 header chain are virtually impossible to police with state-less filters and firewalls and, hence, 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実装を保護するために、ルール＃4はルーターアドバタイズメント（RA）メッセージでないと明確に識別できないパケットをドロップするデフォルトルールとして定義されています（パケットは、 IPv6ヘッダーチェーン全体）。これは、少なくとも理論的には、RA-Guardは、非RAであると明確に識別できない一部の正当な非RAパケットを偽陽性でブロックする可能性があることを意味します。誤検知の可能性を減らすために、ルール＃1およびルール＃2では、RAメッセージに必要な検証チェック（[RFC4861]のセクション6.1.2）に合格しないパケットは、さらに検査せずに通過する必要があります。いずれの場合でも、[RFC7112]に記載されているように、IPv6ヘッダーチェーン全体を含めることができないIPv6パケットは、ステートレスフィルターとファイアウォールでポリシングすることは事実上不可能であるため、実際のネットワークでは存続する可能性は低いです。 [RFC7112]は、フラグメンテーションを使用するホストが最初のフラグメント（フラグメントオフセットが0に設定されたフラグメント）にIPv6ヘッダーチェーン全体を含めることを要求するため、前述の誤検知を排除します。

This filtering policy assumes that host implementations require that the IPv6 Source Address of ICMPv6 Router Advertisement messages be a link-local address and that they discard the packet if this check fails, as required by the current IETF specifications [RFC4861]. Additionally, it assumes that hosts require the Hop Limit of Neighbor Discovery messages to be 255, and that they discard those packets otherwise.

このフィルタリングポリシーは、ホストの実装でICMPv6ルーターアドバタイズメッセージのIPv6送信元アドレスがリンクローカルアドレスである必要があり、現在のIETF仕様[RFC4861]で要求されているように、このチェックが失敗した場合にパケットを破棄することを前提としています。さらに、ホストは近隣探索のホップ制限メッセージが255である必要があり、そうでない場合はそれらのパケットを破棄すると想定しています。

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

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

Finally, we note that IPv6 implementations that allow overlapping fragments (i.e., that do not comply with [RFC5722]) might still be subject of RA-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実装は、RAベースの攻撃の対象となる可能性があることに注意してください。ただし、フラグメントの再構成ポリシーに関するIPv6実装[SI6-FRAG]の最近の評価は、現在のほとんどの実装が[RFC5722]に準拠していることを示しているようです。

4. Other Implications

4. その他の影響

A similar concept to that of RA-Guard has been implemented for protecting against forged DHCPv6 messages. Such protection can be circumvented with the same techniques discussed in this document, and the countermeasures for such evasion attack are analogous to those described in Section 3 of this document.

RA-Guardと同様の概念が、偽造DHCPv6メッセージから保護するために実装されています。このような保護は、このドキュメントで説明されているのと同じ手法で回避できます。このような回避攻撃の対策は、このドキュメントのセクション3で説明されている対策と類似しています。

[DHCPv6-Shield] specifies a mechanism to protect against rogue DHCPv6 servers, while taking into consideration the evasion techniques discussed in this document.

[DHCPv6-Shield]は、このドキュメントで説明されている回避手法を考慮しながら、不正なDHCPv6サーバーから保護するメカニズムを指定しています。

5. Security Considerations

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

This document describes a number of techniques that have been found to be effective to circumvent popular RA-Guard implementations and provides advice to RA-Guard implementers such that those evasion vulnerabilities are eliminated.

このドキュメントでは、一般的なRA-Guardの実装を回避するのに効果的であることが判明しているいくつかの手法について説明し、回避の脆弱性が排除されるようにRA-Guardの実装者にアドバイスを提供します。

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

セクション3で述べたように、フラグメントのオーバーラップを許可する（つまり、[RFC5722]に準拠しない）IPv6実装は、依然としてRAベースの攻撃の対象となる可能性があります。ただし、現在のほとんどの実装は[RFC5722]に準拠しているようです。

We note that if an attacker sends a fragmented ICMPv6 Router Advertisement message on a port not allowed to send 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 IPv6 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 forged fragmented datagrams in which at least one of the fragments is missing. [CPNI-IPv6] discusses some resource management strategies that could be implemented for the IPv6 fragment reassembly buffer.

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

We note that the most effective and efficient mitigation for these attacks would rely on the prohibiting the use of IPv6 fragmentation with Router Advertisement messages (as specified by [RFC6980]), such that the RA-Guard functionality is easier to implement. However, since such mitigation would require an update to existing implementations, it cannot be relied upon in the short or near term.

これらの攻撃に対する最も効果的かつ効率的な緩和策は、ルーターアドバタイズメントメッセージ（[RFC6980]で指定）でのIPv6フラグメンテーションの使用禁止に依存するため、RAガード機能の実装が容易になることに注意してください。ただし、このような緩和策では既存の実装を更新する必要があるため、短期的または短期的に信頼することはできません。

Finally, we note that RA-Guard only mitigates attack vectors based on ICMPv6 Router advertisement messages. Protection against similar attacks based on other messages (such as DCHPv6) is considered out of the scope of this document and is left for other documents (e.g., [DHCPv6-Shield]).

最後に、RA-GuardはICMPv6ルーターアドバタイズメントメッセージに基づく攻撃ベクトルのみを軽減することに注意してください。他のメッセージ（DCHPv6など）に基づく同様の攻撃に対する保護は、このドキュメントの範囲外と見なされ、他のドキュメント（[DHCPv6-Shield]など）に残されています。

6. Acknowledgements

6. 謝辞

The author would like to thank Ran Atkinson, who provided very detailed comments and suggested text that was incorporated into this document.

著者は、このドキュメントに組み込まれた非常に詳細なコメントと提案されたテキストを提供したRan Atkinsonに感謝します。

The author would like to thank 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, for providing valuable comments on earlier versions of this document.

著者は、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、 Bjoern A. Zeeb、このドキュメントの以前のバージョンに関する貴重なコメントを提供してくださった。

The author would like to thank Arturo Servin, who presented this document at IETF 81.

著者は、この文書をIETF 81で発表したArturo Servinに感謝します。

This document resulted from the project "Security Assessment of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by Fernando Gont on behalf of the UK Centre for the Protection of National Infrastructure (CPNI).

このドキュメントは、国立インフラストラクチャ保護センター（CPNI）に代わってフェルナンドゴントが実施したプロジェクト「インターネットプロトコルバージョン6（IPv6）のセキュリティ評価」[CPNI-IPv6]に基づいています。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.

[RFC3315] Droms、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315、July 2003 。

[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.

[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.

[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月。

[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, December 2009.

[RFC5722] Krishnan、S。、「Handling of Overlapping IPv6 Fragments」、RFC 5722、2009年12月。

[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011.

[RFC6105] Levy-Abegnoli、E.、Van de Velde、G.、Popoviciu、C.、J。Mohacsi、「IPv6 Router Advertisement Guard」、RFC 6105、2011年2月。

[RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery", RFC 6980, August 2013.

[RFC6980] Gont、F。、「IPv6ネイバー探索によるIPv6フラグメンテーションのセキュリティ上の影響」、RFC 6980、2013年8月。

[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, December 2013.

[RFC7045] Carpenter、B。およびS. Jiang、「IPv6拡張ヘッダーの送信と処理」、RFC 7045、2013年12月。

[RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of Oversized IPv6 Header Chains", RFC 7112, January 2014.

[RFC7112] Gont、F.、Manral、V。、およびR. Bonica、「特大のIPv6ヘッダーチェーンの影響」、RFC 7112、2014年1月。

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）のセキュリティ評価」、英国国家インフラ保護センター（リクエストに応じて入手可能）。

[DHCPv6-Shield] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6- Shield: Protecting Against Rogue DHCPv6 Servers", Work in Progress, October 2013.

[DHCPv6-Shield] Gont、F.、Liu、W。、およびG. Van de Velde、「DHCPv6- Shield：Protecting Against Rogue DHCPv6 Servers」、Work in Progress、2013年10月。

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

[IANA-IP-PROTO] IANA、「割り当てられたインターネットプロトコル番号」、<http://www.iana.org/assignments/protocol-numbers/>。

[NDPMon] "NDPMon - IPv6 Neighbor Discovery Protocol Monitor", <http://ndpmon.sourceforge.net/>.

[NDPMon]「NDPMon-IPv6近隣探索プロトコルモニター」、<http://ndpmon.sourceforge.net/>。

[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Problem Statement", RFC 6104, February 2011.

[RFC6104] Chown、T。およびS. Venaas、「Rogue IPv6 Router Advertisement Problem Statement」、RFC 6104、2011年2月。

[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>。

[SI6-IPv6] "SI6 Networks' IPv6 toolkit", <http://www.si6networks.com/tools/ipv6toolkit>.

[SI6-IPv6]「SI6ネットワークのIPv6ツールキット」、<http://www.si6networks.com/tools/ipv6toolkit>。

[THC-IPV6] "The Hacker's Choice IPv6 Attack Toolkit", <http://www.thc.org/thc-ipv6/>.

[THC-IPV6]「The Hacker's Choice IPv6 Attack Toolkit」、<http://www.thc.org/thc-ipv6/>。

[rafixd] "rafixd", <http://www.kame.net/dev/cvsweb2.cgi/kame/ kame/kame/rafixd/>.

「らふぃｘｄ」 ”らふぃｘｄ”、＜ｈっｔｐ：／／ｗっｗ。かめ。ねｔ／でｖ／ｃｖすぇｂ２。ｃぎ／かめ／かめ／かめ／らふぃｘｄ／＞。

[ramond] "ramond", <http://ramond.sourceforge.net/>.

[ramond]「ramond」、<http://ramond.sourceforge.net/>。

Appendix A. Assessment Tools

付録A.評価ツール

[SI6-IPv6] is a publicly available set of tools (for Linux, *BSD, and Mac OS) that implements the techniques described in this document.

[SI6-IPv6]は、このドキュメントで説明されている手法を実装する公的に利用可能なツールのセット（Linux、* BSD、およびMac OS用）です。

[THC-IPV6] is a publicly available set of tools (for Linux) that implements some of the techniques described in this document.

[THC-IPV6]は、このドキュメントで説明されている手法の一部を実装する、公的に利用可能なツール（Linux用）のセットです。

Author's Address

著者のアドレス

Fernando Gont Huawei Technologies Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina

Fernando Gont Huawei Technologies Evaristo Carriego 2644ブエノスアイレス州ハエド1706アルゼンチン

   Phone: +54 11 4650 8472
   EMail: fgont@si6networks.com