RFC4890 日本語訳
4890 Recommendations for Filtering ICMPv6 Messages in Firewalls. E.Davies, J. Mohacsi. May 2007. (Format: TXT=83479 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Davies
Request for Comments: 4890 Consultant
Category: Informational J. Mohacsi
NIIF/HUNGARNET
May 2007
コメントを求めるワーキンググループE.デイヴィース要求をネットワークでつないでください: 4890年のコンサルタントカテゴリ: 情報のJ.Mohacsi NIIF/HUNGARNET2007年5月
Recommendations for Filtering ICMPv6 Messages in Firewalls
ファイアウォールでICMPv6メッセージをフィルターにかけるための推薦
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
In networks supporting IPv6, the Internet Control Message Protocol version 6 (ICMPv6) plays a fundamental role with a large number of functions, and a correspondingly large number of message types and options. ICMPv6 is essential to the functioning of IPv6, but there are a number of security risks associated with uncontrolled forwarding of ICMPv6 messages. Filtering strategies designed for the corresponding protocol, ICMP, in IPv4 networks are not directly applicable, because these strategies are intended to accommodate a useful auxiliary protocol that may not be required for correct functioning.
IPv6を支持するネットワークでは、インターネット・コントロール・メッセージ・プロトコルバージョン6(ICMPv6)はメッセージタイプと対応する多くのオプションで基本的な役割をプレーします。 ICMPv6はIPv6の機能に不可欠ですが、ICMPv6メッセージの非制御の推進に関連している多くのセキュリティリスクがあります。 対応するプロトコルのために設計されたフィルタリング戦略、ICMP、IPv4では、ネットワークは直接適切ではありません、これらの戦略が正しい機能に必要でないかもしれない役に立つ補助のプロトコルに対応することを意図するので。
This document provides some recommendations for ICMPv6 firewall filter configuration that will allow propagation of ICMPv6 messages that are needed to maintain the functioning of the network but drop messages that are potential security risks.
このドキュメントはネットワークの機能を維持しますが、潜在的セキュリティリスクであるメッセージを落とすのに必要であるICMPv6メッセージの伝播を許すICMPv6ファイアウォールフィルタ構成のためのいくつかの推薦を提供します。
Davies & Mohacsi Informational [Page 1] RFC 4890 ICMPv6 Filtering Recommendations May 2007
2007年5月に推薦をフィルターにかけるデイヴィースとMohacsiの情報[1ページ]のRFC4890ICMPv6
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Classifying ICMPv6 Messages . . . . . . . . . . . . . . . . . 6
2.1. Error and Informational ICMPv6 Messages . . . . . . . . . 6
2.2. Addressing of ICMPv6 . . . . . . . . . . . . . . . . . . . 6
2.3. Network Topology and Address Scopes . . . . . . . . . . . 7
2.4. Role in Establishing and Maintaining Communication . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
3.1. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 9
3.2. Probing . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Redirection Attacks . . . . . . . . . . . . . . . . . . . . 9
3.4. Renumbering Attacks . . . . . . . . . . . . . . . . . . . 10
3.5. Problems Resulting from ICMPv6 Transparency . . . . . . . 10
4. Filtering Recommendations . . . . . . . . . . . . . . . . . . 10
4.1. Common Considerations . . . . . . . . . . . . . . . . . . 11
4.2. Interaction of Link-Local Messages with
Firewall/Routers and Firewall/Bridges . . . . . . . . . . 12
4.3. Recommendations for ICMPv6 Transit Traffic . . . . . . . . 13
4.3.1. Traffic That Must Not Be Dropped . . . . . . . . . . . 14
4.3.2. Traffic That Normally Should Not Be Dropped . . . . . 14
4.3.3. Traffic That Will Be Dropped Anyway -- No Special
Attention Needed . . . . . . . . . . . . . . . . . . . 15
4.3.4. Traffic for Which a Policy Should Be Defined . . . . . 16
4.3.5. Traffic That Should Be Dropped Unless a Good Case
Can Be Made . . . . . . . . . . . . . . . . . . . . . 17
4.4. Recommendations for ICMPv6 Local Configuration Traffic . . 18
4.4.1. Traffic That Must Not Be Dropped . . . . . . . . . . . 18
4.4.2. Traffic That Normally Should Not Be Dropped . . . . . 19
4.4.3. Traffic That Will Be Dropped Anyway -- No Special
Attention Needed . . . . . . . . . . . . . . . . . . . 19
4.4.4. Traffic for Which a Policy Should Be Defined . . . . . 20
4.4.5. Traffic That Should Be Dropped Unless a Good Case
Can Be Made . . . . . . . . . . . . . . . . . . . . . 21
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1. Normative References . . . . . . . . . . . . . . . . . . . 21
6.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Notes on Individual ICMPv6 Messages . . . . . . . . . 24
A.1. Destination Unreachable Error Message . . . . . . . . . . 24
A.2. Packet Too Big Error Message . . . . . . . . . . . . . . . 24
A.3. Time Exceeded Error Message . . . . . . . . . . . . . . . 25
A.4. Parameter Problem Error Message . . . . . . . . . . . . . 25
A.5. ICMPv6 Echo Request and Echo Response . . . . . . . . . . 26
A.6. Neighbor Solicitation and Neighbor Advertisement
Messages . . . . . . . . . . . . . . . . . . . . . . . . . 26
A.7. Router Solicitation and Router Advertisement Messages . . 27
A.8. Redirect Messages . . . . . . . . . . . . . . . . . . . . 27
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 ICMPv6メッセージ. . . . . . . . . . . . . . . . . 6 2.1を分類します。 誤りと情報のICMPv6メッセージ. . . . . . . . . 6 2.2。 ICMPv6. . . . . . . . . . . . . . . . . . . 6 2.3のアドレシング。 ネットワーク形態とアドレスは.72.4を見ます。 コミュニケーション. . . . 7 3を確立して、維持することにおける役割。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 8 3.1。 サービス不能攻撃. . . . . . . . . . . . . . . . 9 3.2。 調べ. . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3。 リダイレクション攻撃. . . . . . . . . . . . . . . . . . . . 9 3.4。 攻撃. . . . . . . . . . . . . . . . . . . 10 3.5に番号を付け替えさせます。 ICMPv6透明. . . . . . . 10 4から生じることにおける問題。 推薦. . . . . . . . . . . . . . . . . . 10 4.1をフィルターにかけます。 一般的な問題. . . . . . . . . . . . . . . . . . 11 4.2。 ファイアウォール/ルータとファイアウォール/橋. . . . . . . . . . 12 4.3とのリンクローカルのメッセージの相互作用。 ICMPv6トランジット交通. . . . . . . . 13 4.3.1のための推薦。 .144.3に.2に落としてはいけない交通 通常、.144.3に.3に落とされるはずがない交通 とにかく落とされる交通--どんな特別な注意も.4に.154.3を必要としませんでした。 方針が.164.3に.5に定義されるべきである交通 .174.4に良い弁護をすることができないなら落とされるべきである交通。 ICMPv6のローカルの構成交通. . 18 4.4.1のための推薦。 .184.4に.2に落としてはいけない交通 通常、.194.4に.3に落とされるはずがない交通 とにかく落とされる交通--どんな特別な注意も.4に.194.4を必要としませんでした。 方針が.204.4に.5に定義されるべきである交通 .215に良い弁護をすることができないなら落とされるべきである交通。 承認. . . . . . . . . . . . . . . . . . . . . . . 21 6。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.1。 引用規格. . . . . . . . . . . . . . . . . . . 21 6.2。 有益な参照. . . . . . . . . . . . . . . . . . 22付録A.は個々のICMPv6メッセージ. . . . . . . . . 24でA.1に注意します。 目的地の手の届かないエラーメッセージ. . . . . . . . . . 24A.2。 パケット、大き過ぎるエラーメッセージ. . . . . . . . . . . . . . . 24A.3。 時間はエラーメッセージ. . . . . . . . . . . . . . . 25A.4を超えていました。 パラメタ問題エラーメッセージ. . . . . . . . . . . . . 25A.5。 ICMPv6は要求とエコー応答. . . . . . . . . . 26A.6を反響します。 隣人の懇願と隣人広告メッセージ. . . . . . . . . . . . . . . . . . . . . . . . . 26A.7。 ルータ懇願とルータ通知メッセージ. . 27A.8。 メッセージ. . . . . . . . . . . . . . . . . . . . 27を向け直してください。
Davies & Mohacsi Informational [Page 2] RFC 4890 ICMPv6 Filtering Recommendations May 2007
2007年5月に推薦をフィルターにかけるデイヴィースとMohacsiの情報[2ページ]のRFC4890ICMPv6
A.9. SEND Certificate Path Messages . . . . . . . . . . . . . . 27
A.10. Multicast Listener Discovery Messages . . . . . . . . . . 27
A.11. Multicast Router Discovery Messages . . . . . . . . . . . 28
A.12. Router Renumbering Messages . . . . . . . . . . . . . . . 28
A.13. Node Information Query and Reply . . . . . . . . . . . . . 28
A.14. Mobile IPv6 Messages . . . . . . . . . . . . . . . . . . . 28
A.15. Unused and Experimental Messages . . . . . . . . . . . . . 29
Appendix B. Example Script to Configure ICMPv6 Firewall Rules . . 30
A.9。 証明書経路メッセージ. . . . . . . . . . . . . . 27A.10を送ってください。 マルチキャストリスナー発見メッセージ. . . . . . . . . . 27A.11。 マルチキャストルータ発見メッセージ. . . . . . . . . . . 28A.12。 メッセージ. . . . . . . . . . . . . . . 28A.13に番号を付け替えさせるルータ。 ノード情報質問と回答. . . . . . . . . . . . . 28A.14。 モバイルIPv6メッセージ. . . . . . . . . . . . . . . . . . . 28A.15。 ICMPv6ファイアウォール規則. . 30を構成する未使用の、そして、実験しているメッセージ. . . . . . . . . . . . . 29付録B.例のスクリプト
1. Introduction
1. 序論
When a network supports IPv6 [RFC2460], the Internet Control Message Protocol version 6 (ICMPv6) [RFC4443] plays a fundamental role including being an essential component in establishing and maintaining communications both at the interface level and for sessions to remote nodes. This means that overly aggressive filtering of ICMPv6 by firewalls may have a detrimental effect on the establishment and maintenance of IPv6 communications. On the other hand, allowing indiscriminate passage of all ICMPv6 messages can be a major security risk. This document recommends a set of rules that seek to balance effective IPv6 communication against the needs of site security.
ネットワークがIPv6[RFC2460]を支持すると、インターネット・コントロール・メッセージ・プロトコルバージョン6(ICMPv6)[RFC4443]はインタフェースレベルにおけるセッションコミュニケーションを遠隔ノードに確立して、維持する際に必須成分であることを含む基本的な役割をプレーします。 これは、ファイアウォールのそばのICMPv6のひどく攻撃的なフィルタリングがIPv6コミュニケーションの設立と維持に有害な影響を持っているかもしれないことを意味します。 他方では、すべてのICMPv6メッセージの無差別の通路を許容するのは、主要な危険人物であるかもしれません。 このドキュメントはサイトセキュリティの必要性に対して有効なIPv6コミュニケーションのバランスをとろうとする1セットの規則を推薦します。
In a few cases, the appropriate rules will depend on whether the firewall is protecting
いくつかの場合では、適切な規則はファイアウォールが保護されているかどうかによるでしょう。
o an individual host,
o 個々のホスト
o an end site where all ICMPv6 messages originate or terminate
within the site, or
o またはすべてのICMPv6メッセージがサイトの中で由来するか、または終わる端のサイト。
o a transit site such as an Internet Service Provider's site where
some ICMPv6 messages will be passing through.
o いくつかのICMPv6メッセージが通り抜けるインターネットサービスプロバイダのサイトなどのトランジットサイト。
The document suggests alternative rules appropriate to each situation where it is relevant. It also notes some situations where alternative rules could be adopted according to the nature of the work being carried out on the site and consequent security policies. In general, Internet Service Providers should not filter ICMPv6 messages transiting their sites so that all the necessary communication elements are available to their customers to decide and filter according to their policy.
ドキュメントはそれが関連している各状況に適切な代替の規則を示します。 また、それはサイトで行われる仕事の本質によると、代替の規則を採用できたいくつかの状況と結果の安全保障政策に注意します。 一般に、インターネットサービスプロバイダがそれらのサイトを通過するICMPv6メッセージをフィルターにかけるべきでないので、彼らの方針によると、決めて、フィルターにかける彼らの顧客にとって、すべての必要なコミュニケーション要素が有効です。
Readers familiar with ICMPv6 can skip to the recommended filtering rules in Section 4 and an example configuration script for Linux Netfilter in Appendix B.
ICMPv6に詳しい読者はリナックスNetfilterのためにAppendix Bでセクション4のお勧めのフィルタリング規則と例の構成スクリプトまでスキップできます。
Davies & Mohacsi Informational [Page 3] RFC 4890 ICMPv6 Filtering Recommendations May 2007
2007年5月に推薦をフィルターにかけるデイヴィースとMohacsiの情報[3ページ]のRFC4890ICMPv6
ICMPv6 has a large number of functions defined in a number of sub- protocols, and there are a correspondingly large number of messages and options within these messages. The functions currently defined fall into a number of categories:
ICMPv6は多くのサブプロトコルで機能の多くを定義させます、そして、これらのメッセージの中にメッセージと対応する多くのオプションがあります。 現在定義されている機能は多くのカテゴリになります:
Returning Error Messages
戻っているエラーメッセージ
* Returning error messages to the source if a packet could not
be delivered. Four different error messages, each with a
number of sub-types, are specified in [RFC4443].
* パケットを届けることができないなら、エラーメッセージをソースに返します。 4つの異なったエラーメッセージ(多くのサブタイプがあるそれぞれ)が[RFC4443]で指定されます。
Connection Checking
接続の照合
* Simple monitoring of connectivity through echo requests and
responses used by the ping and traceroute utilities. The
Echo Request and Echo Response messages are specified in
[RFC4443].
* ピングとトレースルートユーティリティによって使用されるエコー要求と応答による接続性の簡単なモニター。 Echo RequestとEcho Responseメッセージは[RFC4443]で指定されます。
Discovery Functions
発見機能
* Finding neighbors (both routers and hosts) connected to the
same link and determining their IP and link layer addresses.
These messages are also used to check the uniqueness of any
addresses that an interface proposes to use (Duplicate
Address Detection - DAD). Four messages -- Neighbor
Solicitation (NS), Neighbor Advertisement (NA), Router
Solicitation (RS) and Router Advertisement (RA) -- are
specified in [RFC2461].
* 隣人(ルータとホストの両方)を見つけるのは同じリンクと彼らのIPとリンクレイヤアドレスを決定すると接続しました。 また、これらのメッセージは、インタフェースが使用するよう提案するどんなアドレスのユニークさもチェックするのに使用されます(写しAddress Detection--DAD)。 4つのメッセージ(隣人Solicitation(NS)、Neighbor Advertisement(NA)、Router Solicitation(RS)、およびRouter Advertisement(RA))が[RFC2461]で指定されます。
* Ensuring that neighbors remain reachable using the same IP
and link layer addresses after initial discovery (Neighbor
Unreachability Discovery - NUD) and notifying neighbors of
changes to link layer addresses. Uses NS and NA [RFC2461].
* 隣人が初期の発見(隣人Unreachabilityディスカバリー--NUD)の後に同じIPとリンクレイヤアドレスを使用することで届いたままで残っているのを確実にして、変化の隣人がリンクするように通知するのがアドレスを層にします。 用途のナノ秒とNa[RFC2461。]
* Finding routers and determining how to obtain IP addresses
to join the subnets supported by the routers. Uses RS and
RA [RFC2461].
* ルータを見つけて、ルータによって支持されたサブネットを接合するためにIPアドレスを得る方法を決定します。 用途RSとRA[RFC2461]。
* If stateless autoconfiguration of hosts is enabled,
communicating prefixes and other configuration information
(including the link Maximum Transmission Unit (MTU) and
suggested hop limit default) from routers to hosts. Uses RS
and RA [RFC2462].
* ホストの国がない自動構成が可能にされるなら、ルータからホストまで接頭語と他の設定情報(リンクMaximum Transmission Unit(MTU)と提案されたホップ限界デフォルトを含んでいる)を伝えます。 用途RSとRA[RFC2462]。
* When using SEcure Neighbor Discovery (SEND) to authenticate
a router attached to a link, the Certificate Path
Solicitation and Advertisement messages specified in
[RFC3971] are used by hosts to retrieve the certificates
* リンクに付けられたルータを認証するのに、SEcure Neighborディスカバリー(SEND)を使用するとき、[RFC3971]で指定されたCertificate Path SolicitationとAdvertisementメッセージは、証明書を検索するのにホストによって使用されます。
Davies & Mohacsi Informational [Page 4] RFC 4890 ICMPv6 Filtering Recommendations May 2007
2007年5月に推薦をフィルターにかけるデイヴィースとMohacsiの情報[4ページ]のRFC4890ICMPv6
documenting the trust chain between a trust anchor and the
router from the router.
ルータから信用アンカーとルータの間の信用チェーンを記録します。
* Determining the MTU along a path. The Packet Too Big error
message is essential to this function [RFC1981].
* 経路に沿ってMTUを決定します。 Packet Too Bigエラーメッセージはこの機能[RFC1981]に不可欠です。
* Providing a means to discover the IPv6 addresses associated
with the link layer address of an interface (the inverse of
Neighbor Discovery, where the link layer address is
* インタフェースのリンクレイヤアドレスに関連しているIPv6アドレスを発見する手段を提供する、(Neighborディスカバリーの逆。(そこでは、リンクレイヤアドレスがそうです)。
discovered given an IPv6 address). Two messages, Inverse
Neighbor Discovery Solicitation and Advertisement messages,
are specified in [RFC3122].
IPv6が記述する発見された当然のこと) 2つのメッセージ(Inverse NeighborディスカバリーSolicitationとAdvertisementメッセージ)が、[RFC3122]で指定されます。
* Communicating which multicast groups have listeners on a
link to the multicast capable routers connected to the link.
Uses messages Multicast Listener Query, Multicast Listener
Report (two versions), and Multicast Listener Done (protocol
version 1 only) as specified in Multicast Listener Discovery
MLDv1 [RFC2710] and MLDv2 [RFC3810].
* どのマルチキャストグループにリスナーがマルチキャストのできるルータへのリンクの上にいるかを伝えるのがリンクに接続しました。 Multicast ListenerディスカバリーMLDv1[RFC2710]とMLDv2[RFC3810]の用途のメッセージのMulticast Listener Query、Multicast Listener Report(2つのバージョン)、および指定されるとしてのMulticast Listener Done(プロトコルバージョン1専用)。
* Discovering multicast routers attached to the local link.
Uses messages Multicast Router Advertisement, Multicast
Router Solicitation, and Multicast Router Termination as
specified in Multicast Router Discovery [RFC4286].
* マルチキャストルータを発見するのは地方のリンクに付きました。 Multicast Routerディスカバリー[RFC4286]の指定されるとしての用途のメッセージのMulticast Router Advertisement、Multicast Router Solicitation、およびMulticast Router Termination。
Reconfiguration Functions
再構成機能
* Redirecting packets to a more appropriate router on the
local link for the destination address or pointing out that
a destination is actually on the local link even if it is
not obvious from the IP address (where a link supports
multiple subnets). The Redirect message is specified in
[RFC2461].
* 送付先アドレスのために地方のリンクの上により適切なルータにパケットを向け直すか、またはそれがIPアドレス(リンクが複数のサブネットを支持するところ)から明白でなくても実際に地方のリンクの上に目的地があると指摘します。 Redirectメッセージは[RFC2461]で指定されます。
* Supporting renumbering of networks by allowing the prefixes
advertised by routers to be altered. Uses NS, NA, RS and RA
together with the Router Renumbering message specified in
[RFC2894].
* 接頭語を許容するのによるネットワークのサポートの番号を付け替えることは、変更されるためにルータで広告を出しました。 Router Renumberingメッセージに伴う用途NS、NA、RS、およびRAは[RFC2894]で指定しました。
Mobile IPv6 Support
モバイルIPv6サポート
* Providing support for some aspects of Mobile IPv6 especially
dealing with the IPv6 Mobile Home Agent functionality
provided in routers and needed to support a Mobile node
homed on the link. The Home Agent Address Discovery Request
and Reply and the Mobile Prefix Solicitation and
Advertisement messages are specified in [RFC3775].
* ルータに提供されて、モバイルノードをサポートするのに必要であるIPv6のモバイルホームエージェントの機能性に特に対処するモバイルIPv6のいくつかの局面のサポートを提供するのはリンクの上に家へ帰りました。 ホームエージェントAddressディスカバリーRequest、Reply、モバイルPrefix Solicitation、およびAdvertisementメッセージは[RFC3775]で指定されます。
Davies & Mohacsi Informational [Page 5] RFC 4890 ICMPv6 Filtering Recommendations May 2007
2007年5月に推薦をフィルターにかけるデイヴィースとMohacsiの情報[5ページ]のRFC4890ICMPv6
Experimental Extensions
実験的な拡大
* An experimental extension to ICMPv6 specifies the ICMP Node
Information Query and Response messages that can be used to
retrieve some basic information about nodes [RFC4620].
* ICMPv6への実験的な拡大はノード[RFC4620]に関する何らかの基本情報を検索するのに使用できるICMP Node情報QueryとResponseメッセージを指定します。
* The SEAmless IP MOBility (SEAMOBY) working group specified a
pair of experimental protocols that use an ICMPv6 message
specified in [RFC4065] to help in locating an access router
and moving the attachment point of a mobile node from one
access router to another.
* SEAmless IP MOBility(SEAMOBY)ワーキンググループはアクセスルータの場所を見つけるのを手伝うために[RFC4065]で指定されて、1つのアクセスルータから別のものへ可動のノードの付着点を移しながらICMPv6メッセージを使用する1組の実験プロトコルを指定しました。
Many of these messages should only be used in a link-local context rather than end-to-end, and filters need to be concerned with the type of addresses in ICMPv6 packets as well as the specific source and destination addresses.
これらのメッセージの多くが終わらせる終わりよりむしろリンクローカルの関係で使用されるだけであるべきです、そして、フィルタは特定のソースと送付先アドレスと同様にICMPv6パケットのアドレスのタイプに関係がある必要があります。
Compared with the corresponding IPv4 protocol, ICMP, ICMPv6 cannot be treated as an auxiliary function with packets that can be dropped in most cases without damaging the functionality of the network. This means that firewall filters for ICMPv6 have to be more carefully configured than was the case for ICMP, where typically a small set of blanket rules could be applied.
対応するIPv4プロトコルと比較されています、ICMP、多くの場合、ネットワークの機能性を破損しないで落とすことができるパケットで補助の機能としてICMPv6を扱うことができません。 これは、ICMPv6のためのファイアウォールフィルタがICMPのためのケースより慎重に構成されていなければならないことを意味します、小さい総括的な規則を通常適用できたところで。
2. Classifying ICMPv6 Messages
2. ICMPv6メッセージを分類します。
2.1. Error and Informational ICMPv6 Messages
2.1. 誤りと情報のICMPv6メッセージ
ICMPv6 messages contain an eight-bit Type field interpreted as an integer between 0 and 255. Messages with Type values less than or equal to 127 are Error messages. The remainder are Informational messages. In general terms, Error messages with well-known (standardized) Type values would normally be expected to be allowed to be sent to or pass through firewalls, and may be essential to the establishment and maintenance of communications (see Section 2.4) whereas Informational messages will generally be the subject of policy rules, and those passing through end site firewalls can, in many but by no means all cases, be dropped without damaging IPv6 communications.
ICMPv6メッセージは0〜255の整数として解釈された8ビットのType分野を含んでいます。 Type値より127があるメッセージはErrorメッセージです。 残りはInformationalメッセージです。 一般に、Informationalメッセージは政策ルールの対象になるでしょう、そして、あいまいな言葉で、周知(標準化される)のタイプ値があるErrorメッセージは、通常、ファイアウォールを送るか、または通り抜けるのが許容されると予想されて、コミュニケーションの設立と維持に不可欠であるかもしれませんが(セクション2.4を見てください)、多くにもかかわらず、決してすべての場合では、ダメージが大きいIPv6コミュニケーションなしで終わりのサイトファイアウォールを通り抜けるものは落とすことができません。
2.2. Addressing of ICMPv6
2.2. ICMPv6のアドレシング
ICMPv6 messages are sent using various kinds of source and destination address types and scopes. The source address is usually a unicast address, but during address autoconfiguration message exchanges, the unspecified address (::) is also used as a source address [RFC2462].
ICMPv6メッセージに様々な種類の源を使用させて、送付先アドレスは、タイプして、見られます。 通常ユニキャストアドレスですが、アドレス自動構成交換処理の間ソースアドレスはそうです、不特定のアドレス、(:、:、)、また、ソースアドレス[RFC2462]として、使用されます。
Davies & Mohacsi Informational [Page 6] RFC 4890 ICMPv6 Filtering Recommendations May 2007
2007年5月に推薦をフィルターにかけるデイヴィースとMohacsiの情報[6ページ]のRFC4890ICMPv6
Multicast Listener Discovery (MLD) Report and Done messages are sent with a link-local address as the IPv6 source address, if a valid address is available on the interface. If a valid link-local address is not available (e.g., one has not been configured), the message is sent with the unspecified address (::) as the IPv6 source address. Subsequently, the node will generate new MLD Report messages with proper link-local source address once it has been configured [RFC3590].
マルチキャストListenerディスカバリー(MLD)は報告します、そして、リンクローカルアドレスと共にIPv6ソースアドレスとしてDoneメッセージを送ります、有効なアドレスがインタフェースで利用可能であるなら。 有効なリンクローカルアドレスが利用可能でないなら(例えば1つは構成されていません)、不特定のアドレスと共にメッセージを送る、(:、:、)、IPv6ソースアドレスとして。 次に、それがいったん構成されると[RFC3590]、ノードは適切なリンク地元筋アドレスで新しいMLD Reportメッセージを発生させるでしょう。
The destination address can be either a well-known multicast address, a generated multicast address such as the solicited-node multicast address, an anycast address, or a unicast address. While many ICMPv6 messages use multicast addresses most of the time, some also use unicast addresses. For instance, the Router Advertisement messages are sent to the all-nodes multicast address when unsolicited, but can also be sent to a unicast address in response to a specific Router Solicitation, although this is rarely seen in current implementations.
送付先アドレスは周知のマルチキャストアドレス、請求されたノードマルチキャストアドレス、anycastアドレス、またはユニキャストアドレスなどの発生しているマルチキャストアドレスであるかもしれません。 また、多くのICMPv6メッセージがたいていマルチキャストアドレスを使用している間、或るものはユニキャストアドレスを使用します。 例えば、Router Advertisementメッセージを求められていないときに、オールノードマルチキャストアドレスに送りますが、また、特定のRouter Solicitationに対応してユニキャストアドレスに送ることができます、これは現在の実現ではめったに見られませんが。
2.3. Network Topology and Address Scopes
2.3. ネットワーク形態とアドレスの範囲
ICMPv6 messages can be classified according to whether they are meant for end-to-end communications or local communications within a link. There are also messages that we can classify as 'any-to-end', which can be sent from any point within a path back to the source; typically, these are used to announce an error in processing the original packet. For instance, the address resolution messages are solely for local communications [RFC2461], whereas the Destination Unreachable messages are any-to-end in nature. Generally, end-to-end and any-to-end messages might be expected to pass through firewalls depending on policies but local communications must not.
それらがエンド・ツー・エンド通信かローカルのコミュニケーションのためにリンクの中に意味されるかどうかによると、ICMPv6メッセージを分類できます。 私たちが経路の中の任意な点からソースに送って戻すことができる'終わりまでのいずれも'として分類できるメッセージもあります。 通常、これらは、オリジナルのパケットを処理する際に誤りを発表するのに使用されます。 例えば、アドレス解決メッセージは唯一ローカルのコミュニケーション[RFC2461]のためのものですが、終わりまでDestination Unreachableメッセージは自然でいずれでもあります。 一般に、終わりから終わりと終わるいずれもメッセージが方針によるファイアウォールを通り抜けると予想されるかもしれませんが、ローカルのコミュニケーションは予想されてはいけません。
Local communications will use link-local addresses in many cases but may also use global unicast addresses when configuring global addresses, for example. Also, some ICMPv6 messages used in local communications may contravene the usual rules requiring compatible scopes for source and destination addresses.
ローカルのコミュニケーションは多くの場合リンクローカルのアドレスを使用するでしょうが、また、例えばグローバルなアドレスを構成するとき、グローバルなユニキャストアドレスを使用するかもしれません。 また、ローカルのコミュニケーションで使用されるいくつかのICMPv6メッセージがソースと送付先アドレスのためにコンパチブル範囲を必要とする普通の規則に違反するかもしれません。
2.4. Role in Establishing and Maintaining Communication
2.4. コミュニケーションを確立して、維持することにおける役割
Many ICMPv6 messages have a role in establishing or maintaining communications to and from the firewall and such messages have to be accepted by firewalls for local delivery. Generally, a firewall will also be acting as a router so that all the messages that might be used in configuring a router interface need to be accepted and generated. These messages should not transit through a firewall that is also acting as a router as they are normally intended for use within a link.
多くのICMPv6メッセージには、ファイアウォールとファイアウォールからのコミュニケーションを確立するか、または維持することにおける役割があります、そして、ファイアウォールは地方の配送のためにそのようなメッセージを受け入れなければなりません。 また、一般に、ファイアウォールがルータとして作動するので、ルータインタフェースを構成する際に使用されるかもしれないすべてのメッセージが、受け入れられて、発生する必要があります。 それらはまた、ルータとして作動しているファイアウォールを通したトランジットですが、これらのメッセージは通常、リンクの中の使用のために意図していた状態でそうするべきではありません。
Davies & Mohacsi Informational [Page 7] RFC 4890 ICMPv6 Filtering Recommendations May 2007
2007年5月に推薦をフィルターにかけるデイヴィースとMohacsiの情報[7ページ]のRFC4890ICMPv6
On the other hand, most ICMPv6 error messages traveling end-to-end or any-to-end are essential to the establishment and maintenance of communications. These messages must be passed through firewalls and might also be sent to and from firewalls to assist with establishment and maintenance of communications. For example, the Packet Too Big error message is needed to determine the MTU along a path both when a communication session is established initially and later if the path is rerouted during the session.
他方では、終わらせる終わりか終わるいずれも旅行するほとんどのICMPv6エラーメッセージがコミュニケーションの設立と維持に不可欠です。 これらのメッセージをファイアウォールを通り抜けなければならなくて、また、コミュニケーションの設立と維持を助けるためにファイアウォールとファイアウォールから送るかもしれません。 例えば、Packet Too Bigエラーメッセージが、ともに経路がセッションの間、別ルートで送られるならコミュニケーションセッションが初めは、そして、後で確立されるとき、経路に沿ってMTUを決定するのに必要です。
The remaining ICMPv6 messages that are not associated with communication establishment or maintenance will normally be legitimately attempting to pass through a firewall from inside to out or vice versa, but in most cases decisions as to whether or not to allow them to pass can be made on the basis of local policy without interfering with IPv6 communications.
逆もまた同様です、外のファイアウォールを通して内部より移る通常、設立か維持が、合法的に試みるコミュニケーションか多くの場合IPv6コミュニケーションを妨げることのないローカルの方針に基づいてする通るのを許容するのをあることができるかどうかに関する決定だけに関連づけられない残っているICMPv6メッセージ。
The filtering rules for the various message roles will generally be different.
一般に、様々なメッセージの役割のためのフィルタリング規則は異なるでしょう。
3. Security Considerations
3. セキュリティ問題
This memo recommends filtering configurations for firewalls designed to minimize the security vulnerabilities that can arise in using the many different sub-protocols of ICMPv6 in support of IPv6 communication.
このメモは、IPv6コミュニケーションを支持してICMPv6の多くの異なったサブプロトコルを使用する際に起こることができるセキュリティの脆弱性を最小にするように設計されたファイアウォールに構成をフィルターにかけることを勧めます。
A major concern is that it is generally not possible to use IPsec or other means to authenticate the sender and validate the contents of many ICMPv6 messages. To a large extent, this is because a site can legitimately expect to receive certain error and other messages from almost any location in the wider Internet, and these messages may occur as a result of the first message sent to a destination. Establishing security associations with all possible sources of ICMPv6 messages is therefore impossible.
主要な関心事は一般に、IPsecか送付者を認証して、多くのICMPv6メッセージのコンテンツを有効にする他の手段を使用するのが可能でないということです。 これがサイトが、より広いインターネットのほとんどどんな位置からもある誤りと他のメッセージを受け取ると合法的に予想できるから大体において、であるこれらのメッセージは目的地に送られた最初のメッセージの結果、現れるかもしれません。 したがって、ICMPv6メッセージのすべての可能な源とのセキュリティ協会を設立するのは不可能です。
The inability to establish security associations to protect some messages that are needed to establish and maintain communications means that alternative means have to be used to reduce the vulnerability of sites to ICMPv6-based attacks. The most common way of doing this is to establish strict filtering policies in site firewalls to limit the unauthenticated ICMPv6 messages that can pass between the site and the wider Internet. This makes control of ICMPv6 filtering a delicate balance between protecting the site by dropping some of the ICMPv6 traffic passing through the firewall and allowing enough of the traffic through to make sure that efficient communication can be established.
コミュニケーションを確立して、維持するのに必要であるいくつかのメッセージを保護するセキュリティ協会を設立できないことは、代替の手段がICMPv6ベースの攻撃にサイトの脆弱性を減少させるのに使用されなければならないことを意味します。 これをする最も一般的な方法はサイトと、より広いインターネットの間で終わることができるunauthenticated ICMPv6メッセージを制限するために厳しいフィルタリング方針をサイトファイアウォールに確立することです。 これはファイアウォールを通り抜けながら何らかのICMPv6交通を落として、効率的なコミュニケーションを確立できるのを確実にすることができるくらい交通の通ることを許すことによってサイトを保護することの間の高感度天秤をフィルターにかけるICMPv6のコントロールを作ります。
Davies & Mohacsi Informational [Page 8] RFC 4890 ICMPv6 Filtering Recommendations May 2007
2007年5月に推薦をフィルターにかけるデイヴィースとMohacsiの情報[8ページ]のRFC4890ICMPv6
SEND [RFC3971] has been specified as a means to improve the security of local ICMPv6 communications. SEND sidesteps security association bootstrapping problems that would result if IPsec was used. SEND affects only link-local messages and does not limit the filtering that firewalls can apply, and its role in security is therefore not discussed further in this document.
SEND[RFC3971]はローカルのICMPv6コミュニケーションのセキュリティを向上させる手段として指定されました。 SENDはIPsecが使用されるなら結果として生じるセキュリティ協会ブートストラップ法問題を回避します。 SENDはリンクローカルのメッセージだけに影響して、ファイアウォールが当てはまることができるフィルタリングを制限しません、そして、したがって、安全にさらに本書では役割について議論しません。
Firewalls will normally be used to monitor ICMPv6 to control the following security concerns:
通常、ファイアウォールは以下の安全上の配慮を制御するためにICMPv6をモニターするのに使用されるでしょう:
3.1. Denial-of-Service Attacks
3.1. サービス不能攻撃
ICMPv6 can be used to cause a denial of service (DoS) in a number of ways, including simply sending excessive numbers of ICMPv6 packets to destinations in the site and sending error messages that disrupt established communications by causing sessions to be dropped. Also, if spurious communication establishment or maintenance messages can be infiltrated onto a link, it might be possible to invalidate legitimate addresses or disable interfaces.
多くの道におけるサービス(DoS)の否定を引き起こすのにICMPv6を使用できます、単に過度の数のICMPv6パケットをサイトの目的地に送って、セッションが落とされることを引き起こすことによって通信の確立したシステムを遮断するエラーメッセージを送るのを含んでいて。 また、偽りのコミュニケーション設立か維持メッセージにリンクに浸透できるなら、正統のアドレスを無効にするか、またはインタフェースを無能にするのも可能であるかもしれません。
3.2. Probing
3.2. 調べます。
A major security consideration is preventing attackers from probing the site to determine the topology and identify hosts that might be vulnerable to attack. Carefully crafted but, often, malformed messages can be used to provoke ICMPv6 responses from hosts thereby informing attackers of potential targets for future attacks. However, the very large address space of IPv6 makes probing a less effective weapon as compared with IPv4 provided that addresses are not allocated in an easily guessable fashion. This subject is explored in more depth in [SCAN-IMP].
主要な警備上の配慮によって、攻撃者は攻撃するためにトポロジーを決定して、傷つきやすいかもしれないホストを特定するためにサイトを調べることができません。 その結果、ホストからICMPv6応答を引き起こすのに今後の攻撃のために仮想ターゲットについて攻撃者に知らせながら、慎重に作られましたが、しばしば奇形のメッセージを使用できます。 しかしながら、IPv6の非常に大きいアドレス空間はアドレスが容易に推測可能なファッションで割り当てられなければIPv4と比べてそれほど有効でない兵器を調べるようにします。 この対象は[SCAN-IMP]の、より多くの深さで探られます。
3.3. Redirection Attacks
3.3. リダイレクション攻撃
A redirection attack could be used by a malicious sender to perform man-in-the-middle attacks or divert packets either to a malicious monitor or to cause DoS by blackholing the packets. These attacks would normally have to be carried out locally on a link using the Redirect message. Administrators need to decide if the improvement in efficiency from using Redirect messages is worth the risk of malicious use. Factors to consider include the physical security of the link and the complexity of addressing on the link. For example, on an open wireless link, redirection would be a serious hazard due to the lack of physical security. On the other hand, with a wired link in a secure building with complex addressing and redundant routers, the efficiency gains might well outweigh the small risk of a rogue node being connected.
悪意がある送付者は、介入者攻撃を実行するか、悪意があるモニターにパケットを紛らす、またはパケットをblackholingすることによってDoSを引き起こすのにリダイレクション攻撃を使用できました。 通常、これらの攻撃が、リンクの上にRedirectメッセージを使用することで局所的に行われなければならないでしょう。 管理者は、Redirectメッセージを使用するのからの効率における改良は悪意がある使用のリスクの価値があるかどうか決める必要があります。 考える要素はリンクの物理的なセキュリティとリンクの上のアドレシングの複雑さを含んでいます。 例えば、物理的なセキュリティの不足のためにリダイレクションは開いている無線のリンクの上では、重大な危険でしょう。 他方では、ワイヤードなリンクが複雑なアドレシングと余分なルータがある安全なビルにある状態で、効率利得はたぶん接続される凶暴なノードの低いリスクより重いでしょう。
Davies & Mohacsi Informational [Page 9] RFC 4890 ICMPv6 Filtering Recommendations May 2007
2007年5月に推薦をフィルターにかけるデイヴィースとMohacsiの情報[9ページ]のRFC4890ICMPv6
3.4. Renumbering Attacks
3.4. 攻撃に番号を付け替えさせます。
Spurious Renumbering messages can lead to the disruption of a site. Although Renumbering messages are required to be authenticated with IPsec, so that it is difficult to carry out such attacks in practice, they should not be allowed through a site boundary firewall. On the other hand, a site may employ multiple "layers" of firewalls. In this case, Renumbering messages might be expected to be allowed to transit interior firewalls but not pass across the outer boundary.
偽りのRenumberingメッセージはサイトの分裂につながることができます。 実際にはそのような攻撃を行うのが難しいようにIPsecと共に認証されるためにRenumberingメッセージを必要としますが、サイト境界ファイアウォールを通してそれらを許容するべきではありません。 他方では、サイトは複数の「層」のファイアウォールを使うかもしれません。 この場合、Renumberingメッセージは、トランジットの内部のファイアウォールに許容されていますが、外側境界の向こう側に通らないと予想されるかもしれません。
3.5. Problems Resulting from ICMPv6 Transparency
3.5. ICMPv6透明から生じることにおける問題
Because some ICMPv6 error packets need to be passed through a firewall in both directions, malicious users can potentially use these messages to communicate between inside and outside, bypassing administrative inspection. For example, it might be possible to carry out a covert conversation through the payload of ICMPv6 error messages or tunnel inappropriate encapsulated IP packets in ICMPv6 error messages. This problem can be alleviated by filtering ICMPv6 errors using a deep packet inspection mechanism to ensure that the packet carried as a payload is associated with legitimate traffic to or from the protected network.
いくつかのICMPv6誤りパケットが、ファイアウォールを両方の方向に通り抜ける必要があるので、悪意あるユーザーは潜在的に内部と外部の間で交信するこれらのメッセージを使用できます、管理点検を迂回させて。 例えば、ICMPv6エラーメッセージのペイロードを通してひそかな会話を行うか、またはICMPv6エラーメッセージで不適当な要約のIPパケットにトンネルを堀るのが可能であるかもしれません。 ペイロードがネットワーク、または、保護されたネットワークからの正統の交通に関連しているのでパケットが運ばれたのを保証するのに深いパケット点検メカニズムを使用することでICMPv6誤りをフィルターにかけることによって、この問題を軽減できます。
4. Filtering Recommendations
4. 推薦をフィルターにかけます。
When designing firewall filtering rules for ICMPv6, the rules can be divided into two classes:
ICMPv6のためにファイアウォールフィルタリング規則を設計するとき、規則を2つのクラスに分割できます:
o Rules for ICMPv6 traffic transiting the firewall, with some minor
variations for
o ICMPv6がファイアウォールを通過しながら取引するいくつかの小さい方の変化で、統治します。
* firewalls protecting end sites or individual hosts, and
* そして端のサイトか個々のホストを保護するファイアウォール。
* firewalls protecting transit sites
* トランジットサイトを保護するファイアウォール
o Rules for ICMPv6 directed to interfaces on the firewall
o ファイアウォールの上にインタフェースに向けられたICMPv6のための規則
Firewalls integrated with an individual host ("end host firewalls")
can be treated as end site firewalls, but the special considerations
discussed in Section 4.2 may be relevant because the firewall is not
a router.
個々のホスト(「終わりのホストファイアウォール」)について統合しているファイアウォールを終わりのサイトファイアウォールとして扱うことができますが、ファイアウォールがルータでないので、セクション4.2で議論した特別な問題は関連しているかもしれません。
Davies & Mohacsi Informational [Page 10] RFC 4890 ICMPv6 Filtering Recommendations May 2007
2007年5月に推薦をフィルターにかけるデイヴィースとMohacsiの情報[10ページ]のRFC4890ICMPv6
This section suggests some common considerations that should be borne in mind when designing filtering rules and then categorizes the rules for each class. The categories are:
このセクションは、フィルタリング規則を設計するとき覚えておかれるべきであるいくつかの一般的な問題を示して、次に、各クラスのために規則を分類します。 カテゴリは以下の通りです。
o Messages that must not be dropped: usually because establishment
or maintenance of communications will be prevented or severely
impacted.
o 下げてはいけないメッセージ: 通常、コミュニケーションの設立かメインテナンスに防ぐか、または厳しく影響を与えるので。
o Messages that should not be dropped: administrators need to have a
very good reason for dropping this category.
o 下げられるべきでないメッセージ: 管理者はこのカテゴリを下げる非常に十分な理由を必要とします。
o Messages that may be dropped in firewall/routers, but these
messages may already be targeted to drop for other reasons (e.g.,
because they are using link-local addresses) or because the
protocol specification would cause the messages to be rejected if
they had passed through a router. Special considerations apply to
transit traffic if the firewall is not a router as discussed in
Section 4.2.
o ファイアウォール/ルータで下げられるかもしれないメッセージ、他の理由で低下するために狙うか(例えば、リンクローカルのアドレスを使用しているので)、またはルータを通り抜けたなら、プロトコル仕様は拒絶されるべきメッセージを引き起こすでしょう、したがって、これらの唯一のメッセージが既にそうです。 特別な問題はファイアウォールがセクション4.2で議論するようにルータでないならトランジットトラフィックに適用されます。
o Messages that administrators may or may not want to drop depending
on local policy.
o ローカルの方針によって、そうしたいかもしれないか、または管理者がそうしたがっていないかもしれないというメッセージは低下します。
o Messages that administrators should consider dropping (e.g., ICMP
node information name lookup queries).
o 管理者が、低下すると考えるべきであるというメッセージ(例えば、ICMPノード情報名前ルックアップ質問)。
More detailed analysis of each of the message types can be found in Appendix A.
Appendix Aでメッセージタイプ各人の、より詳細な分析を見つけることができます。
4.1. Common Considerations
4.1. 一般的な問題
Depending on the classification of the message to be filtered (see Section 2), ICMPv6 messages should be filtered based on the ICMPv6 type of the message and the type (unicast, multicast, etc.) and scope (link-local, global unicast, etc.) of source and destination addresses. In some cases, it may be desirable to filter on the Code field of ICMPv6 error messages.
フィルターにかけられるのであるべき(セクション2を見ます)メッセージの分類によって、ICMPv6メッセージはソースと送付先アドレスのメッセージのICMPv6タイプ、タイプ(ユニキャスト、マルチキャストなど)、および範囲(リンク地方の、そして、グローバルなユニキャストなど)に基づいてフィルターにかけられるべきです。 いくつかの場合、ICMPv6のCodeフィールドでエラーメッセージをフィルターにかけるのは望ましいかもしれません。
Messages that can be authenticated on delivery, probably because they contain an IPsec AH header or ESP header with authentication, may be subject to less strict policies than messages that cannot be authenticated. In the remainder of this section, we are generally considering what should be configured for unauthenticated messages. In many cases, it is not realistic to expect more than a tiny fraction of the messages to be authenticated.
たぶん認証でIPsec AHヘッダーか超能力ヘッダーを含んでいるので配送のときに認証できるメッセージは認証できないメッセージより少ない厳しい政策を受けることがあるかもしれません。 一般に、このセクションの残りでは、私たちは、何が非認証されたメッセージのために構成されるべきであるかを考えています。 多くの場合、認証されるべきメッセージに小さい断片以上を予想するのは現実的ではありません。
Where messages are not essential to the establishment or maintenance of communications, local policy can be used to determine whether a message should be allowed or dropped.
メッセージがコミュニケーションの設立かメインテナンスに不可欠でないところに、ローカルの方針をメッセージが許容されるべきであるかどうか決定するのに使用するか、または下げることができます。
Davies & Mohacsi Informational [Page 11] RFC 4890 ICMPv6 Filtering Recommendations May 2007
2007年5月に推薦をフィルターにかけるデイヴィースとMohacsiの情報[11ページ]のRFC4890ICMPv6
Depending on the capabilities of the firewall being configured, it may be possible for the firewall to maintain state about packets that may result in error messages being returned or about ICMPv6 packets (e.g., Echo Requests) that are expected to receive a specific response. This state may allow the firewall to perform more precise checks based on this state, and to apply limits on the number of ICMPv6 packets accepted incoming or outgoing as a result of a packet traveling in the opposite direction. The capabilities of firewalls to perform such stateful packet inspection vary from model to model, and it is not assumed that firewalls are uniformly capable in this respect.
構成されていて、ファイアウォールの能力によって、ファイアウォールがエラーメッセージをもたらすかもしれない返されるパケットの周り、または、特定の応答を受けると予想されるICMPv6パケット(例えば、Echo Requests)の周りに関して状態を維持するのは、可能であるかもしれません。 この州は、ファイアウォールにこの状態に基づくより正確なチェックを実行して、入って来るか、またはの結果、外向的であると受け入れられたICMPv6パケットの数における限界を当てはまらせるかもしれません。 モデルによってファイアウォールがそのようなステートフルパケットインスペクションを実行する能力は異なります、そして、ファイアウォールがこの点で一様にできると思われません。
Firewalls that are able to perform deep packet inspection may be able to check the header fields in the start of the errored packet that is carried by ICMPv6 error messages. If the embedded packet has a source address that does not match the destination of the error message, the packet can be dropped. This provides a partial defense against some possible attacks on TCP that use spoofed ICMPv6 error messages, but the checks can also be carried out at the destination. For further information on these attacks see [ICMP-ATTACKS].
深いパケット点検を実行できるファイアウォールはICMPv6エラーメッセージによって運ばれるerroredパケットの始めでヘッダーフィールドをチェックできるかもしれません。 埋め込まれたパケットにエラーメッセージの目的地に合っていないソースアドレスがあるなら、パケットを下げることができます。 これはTCPに対するいくつかの可能な攻撃に対する使用がICMPv6にエラーメッセージを偽造しましたが、また、目的地でチェックを行うことができるという部分的なディフェンスを提供します。 これらの攻撃の詳細に関しては、[ICMP-ATTACKS]を見てください。
In general, the scopes of source and destination addresses of ICMPv6 messages should be matched, and packets with mismatched addresses should be dropped if they attempt to transit a router. However, some of the address configuration messages carried locally on a link may legitimately have mismatched addresses. Node implementations must accept these messages delivered locally on a link, and administrators should be aware that they can exist.
一般に、ソースの範囲とICMPv6メッセージの送付先アドレスは合わせられるべきです、そして、トランジットにルータを試みるなら、ミスマッチしているアドレスがあるパケットは下げられるべきです。 しかしながら、リンクで局所的に伝えられるアドレス構成メッセージの或るものは合法的にアドレスにミスマッチしたかもしれません。 ノード実装はリンクの上に局所的に提供されたこれらのメッセージを受け入れなければなりません、そして、管理者は彼らが存在できるのを意識しているべきです。
ICMPv6 messages transiting firewalls inbound to a site may be treated differently depending on whether they are addressed to a node on the site or to some other node. For end sites, packets addressed to nodes not on the site should be dropped, but would generally be forwarded by firewalls on transit sites.
それらがサイトのノード、または、ある他のノードに扱われるかどうかに異なってよって、サイトへの本国行きのファイアウォールを通過するICMPv6メッセージは扱われるかもしれません。 端のサイトにおいて、ノードに扱われたパケットを、サイトで下げるべきではありませんが、一般に、ファイアウォールはトランジットサイトで進めるでしょう。
4.2. Interaction of Link-Local Messages with Firewall/Routers and
Firewall/Bridges
4.2. ファイアウォール/ルータとファイアウォール/ブリッジとのリンクローカルのメッセージの相互作用
Firewalls can be implemented both as IP routers (firewall/routers) and as link layer bridges (e.g., Ethernet bridges) that are transparent to the IP layer although they will actually be inspecting the IP packets as they pass through (firewall/bridges).
IPルータ(ファイアウォール/ルータ)として通り抜けるとき実際にIPパケットを点検していますが、IP層に透明なリンクレイヤブリッジ(例えば、イーサネットブリッジ)(ファイアウォール/ブリッジ)としてファイアウォールを実装することができます。
Many of the messages used for establishment and maintenance of communications on the local link will be sent with link-local addresses for at least one of their source and destination. Routers conforming to the IPv6 standards will not forward these packets; there is no need to configure additional rules to prevent these
少なくともそれらのソースと目的地の1つのリンクローカルのアドレスと共に地方のリンクにおけるコミュニケーションの設立とメインテナンスに使用されるメッセージの多くを送るでしょう。 IPv6規格に従うルータはこれらのパケットを進めないでしょう。 これらを防ぐために付則を構成する必要は全くありません。
Davies & Mohacsi Informational [Page 12] RFC 4890 ICMPv6 Filtering Recommendations May 2007
2007年5月に推薦をフィルターにかけるデイヴィースとMohacsiの情報[12ページ]のRFC4890ICMPv6
packets traversing a firewall/router, although administrators may wish to configure rules that would drop these packets for insurance and as a means of monitoring for attacks. Also, the specifications of ICMPv6 messages intended for use only on the local link specify various measures that would allow receivers to detect if the message had passed through a router, including:
管理者が保険と攻撃のためのモニターの手段としてこれらのパケットを下げる規則を構成したがっているかもしれませんが、ファイアウォール/ルータを横断するパケット。 また、地方のリンクだけにおける使用のために意図するICMPv6メッセージの仕様はメッセージがルータを通り抜けたかどうか検出するために受信機を許容する様々な測定を指定します、である:
o Requiring that the hop limit in the IPv6 header is set to 255 on
transmission. Receivers verify that the hop limit is still 255,
to ensure that the packet has not passed through a router.
o IPv6ヘッダーのホップ限界がトランスミッションのときに255に設定されるのが必要です。 受信機は、それでも、ホップ限界がパケットがルータを通り抜けていないのを保証するためには255であることを確かめます。
o Checking that the source address is a link-local unicast address.
o ソースアドレスがリンクローカルのユニキャストアドレスであることをチェックします。
Accordingly, it is not essential to configure firewall/router rules to drop out-of-specification packets of these types. If they have non-link-local source and destination addresses, allowing them to traverse the firewall/router, they would be rejected because of the checks performed at the destination. Again, firewall administrators may still wish to configure rules to log or drop such out-of- specification packets.
それに従って、これらのタイプのパケットを仕様の外に下げるためにファイアウォール/ルータ規則を構成するのは不可欠ではありません。 ファイアウォール/ルータを横断するのを許容して、彼らに非リンクの地元筋と送付先アドレスがあるなら、それらは目的地で実行されたチェックで拒絶されるでしょう。 ファイアウォール管理者が規則をログに構成したいか、または一方、まだそのようなものを脱落していたがっているかもしれない、-、仕様パケットについて。
For firewall/bridges, slightly different considerations apply. The physical links on either side of the firewall/bridge are treated as a single logical link for the purposes of IP. Hence, the link local messages used for discovery functions on the link must be allowed to transit the transparent bridge. Administrators should ensures that routers and hosts attached to the link containing the firewall/bridge are built to the correct specifications so that out-of-specification packets are actually dropped as described in the earlier part of this section.
ファイアウォール/ブリッジに関しては、わずかに異なった問題は適用されます。 ファイアウォール/ブリッジのどちらかの側面の物理的なリンクはIPの目的のために単一の論理的なリンクとして扱われます。 したがって、ローカルのメッセージが発見機能にリンクの上に使用したリンクにトランジットへの透明なブリッジを許容しなければなりません。 管理者は確実にするべきです。ファイアウォール/ブリッジを含むリンクへのルータと添付のホストが正しい仕様に築き上げられるのでパケットが実際にこのセクションの以前の部分で説明されるように仕様の外に下げられるのを確実にします。
An end host firewall can generally be thought of as a special case of a firewall/bridge, but the only link-local messages that need to be allowed through are those directed to the host's interface.
特殊なものとしてファイアウォール/ブリッジについて一般に終わりのホストファイアウォールを考えることができますが、リンクローカルの許容されるそうしなければならない唯一のメッセージがホストのインタフェースに向けられたものです。
4.3. Recommendations for ICMPv6 Transit Traffic
4.3. ICMPv6トランジットトラフィックのための推薦
This section recommends rules that should be applied to ICMPv6 traffic attempting to transit a firewall.
このセクションはトランジットにファイアウォールを試みるICMPv6トラフィックに適用されるべきである規則を推薦します。
Davies & Mohacsi Informational [Page 13] RFC 4890 ICMPv6 Filtering Recommendations May 2007
2007年5月に推薦をフィルターにかけるデイヴィースとMohacsiの情報[13ページ]のRFC4890ICMPv6
4.3.1. Traffic That Must Not Be Dropped
4.3.1. 下げてはいけないトラフィック
Error messages that are essential to the establishment and maintenance of communications:
コミュニケーションの設立とメインテナンスに不可欠のエラーメッセージ:
o Destination Unreachable (Type 1) - All codes o Packet Too Big (Type 2) o Time Exceeded (Type 3) - Code 0 only o Parameter Problem (Type 4) - Codes 1 and 2 only
o 目的地Unreachable(1をタイプする)--すべてがo Packet Too Big(2をタイプする)o Time Exceeded(3をタイプする)--コード0oだけParameter Problem(4をタイプする)--コード1と2だけをコード化します。
Appendix A.4 suggests some more specific checks that could be performed on Parameter Problem messages if a firewall has the necessary packet inspection capabilities.
付録A.4はファイアウォールに必要なパケット点検能力があるならParameter Problemメッセージに実行されるかもしれないそれ以上の特定のチェックを勧めます。
Connectivity checking messages:
接続性照合メッセージ:
o Echo Request (Type 128) o Echo Response (Type 129)
o エコーRequest(128をタイプする)o Echo Response(タイプ129)
For Teredo tunneling [RFC4380] to IPv6 nodes on the site to be possible, it is essential that the connectivity checking messages are allowed through the firewall. It has been common practice in IPv4 networks to drop Echo Request messages in firewalls to minimize the risk of scanning attacks on the protected network. As discussed in Section 3.2, the risks from port scanning in an IPv6 network are much less severe, and it is not necessary to filter IPv6 Echo Request messages.
サイトのIPv6ノードへのTeredoトンネリング[RFC4380]が可能であるように、接続性照合メッセージがファイアウォールを通して許容されているのは、不可欠です。 IPv4ネットワークでは、保護されたネットワークに対するスキャン攻撃の危険を最小にするファイアウォールのEcho Requestメッセージを下げるのは、一般的な習慣です。 セクション3.2で議論するように、IPv6ネットワークでスキャンされるポートからのリスクはあまりそれほど厳しくはありません、そして、IPv6 Echo Requestメッセージをフィルターにかけるのは必要ではありません。
4.3.2. Traffic That Normally Should Not Be Dropped
4.3.2. 通常、下げられるはずがないトラフィック
Error messages other than those listed in Section 4.3.1:
それら以外のエラーメッセージはセクション4.3.1でリストアップされました:
o Time Exceeded (Type 3) - Code 1 o Parameter Problem (Type 4) - Code 0
o 時間Exceeded(3をタイプする)--コード1o Parameter Problem(4をタイプする)--コード0
Mobile IPv6 messages that are needed to assist mobility:
移動性を補助するのに必要であるモバイルIPv6メッセージ:
o Home Agent Address Discovery Request (Type 144) o Home Agent Address Discovery Reply (Type 145) o Mobile Prefix Solicitation (Type 146) o Mobile Prefix Advertisement (Type 147)
o ホームエージェントAddressディスカバリーRequest(144をタイプする)oホームのエージェントAddressディスカバリーReply(145をタイプする)oモバイルPrefix Solicitation(146をタイプする)oモバイルPrefix Advertisement(タイプ147)
Administrators may wish to apply more selective rules as described in Appendix A.14 depending on whether the site is catering for mobile nodes that would normally be at home on the site and/or foreign mobile nodes roaming onto the site.
管理者はサイトが通常、サイトに移動しながらサイト、そして/または、外国モバイルノードの上のホームにあるモバイルノードを満たしているかどうかによって、Appendix A.14で説明されるように、より選択している規則を適用したがっているかもしれません。
Davies & Mohacsi Informational [Page 14] RFC 4890 ICMPv6 Filtering Recommendations May 2007
2007年5月に推薦をフィルターにかけるデイヴィースとMohacsiの情報[14ページ]のRFC4890ICMPv6
4.3.3. Traffic That Will Be Dropped Anyway -- No Special Attention
Needed
4.3.3. とにかく下げられるトラフィック--注意は必要ではありません特別な。
The messages listed in this section are all involved with local management of nodes connected to the logical link on which they were initially transmitted. All these messages should never be propagated beyond the link on which they were initially transmitted. If the firewall is a firewall/bridge rather than a firewall/router, these messages should be allowed to transit the firewall as they would be intended for establishing communications between the two physical parts of the link that are bridged into a single logical link.
このセクションでリストアップされたメッセージはノードのそれらが初めは伝えられた論理的なリンクに接続される現地管理職者にすべてかかわります。 これらのすべてのメッセージがそれらが初めは伝えられたリンクを超えて決して伝播されるべきであるというわけではありません。 ファイアウォールがファイアウォール/ルータよりむしろファイアウォール/ブリッジであるなら、彼らが単一の論理的なリンクにブリッジされるリンクの2つの物理的な部分のコミュニケーションを確立するために意図するようにトランジットへのファイアウォールはこれらのメッセージに許容されるべきです。
During normal operations, these messages will have destination addresses, mostly link local but in some cases global unicast addresses, of interfaces on the local link. No special action is needed to filter messages with link-local addresses in a firewall/ router. As discussed in Section 4.1, these messages are specified so that either the receiver is able to check that the message has not passed through a router or it will be dropped at the first router it encounters.
通常操作の間、これらのメッセージは送付先アドレス、ほとんど地方の、しかし、いくつかの場合グローバルなユニキャストが扱う地方のリンクの上のインタフェースのリンクを持つでしょう。 どんな特別な動きも、ファイアウォール/ルータにおけるリンクローカルのアドレスでメッセージをフィルターにかけるのに必要ではありません。 セクション4.1で議論するように、これらのメッセージは受信機が、メッセージがルータを通り抜けていないのをチェックできるか、またはそれが遭遇する最初のルータで下げられるように指定されます。
Administrators may also wish to consider providing rules in firewall/ routers to catch illegal packets sent with hop limit = 1 to avoid ICMPv6 Time Exceeded messages being generated for these packets.
また、管理者は、ICMPv6 Time Exceededメッセージを避けるためにホップ限界=1と共に送られた不法なパケットがこれらのパケットのために生成されるのを捕らえるためにファイアウォール/ルータに規則を提供すると考えたがっているかもしれません。
Address Configuration and Router Selection messages (must be received with hop limit = 255):
ConfigurationとRouter Selectionがメッセージ(ホップ限界=255で受け取らなければならない)であると扱ってください:
o Router Solicitation (Type 133) o Router Advertisement (Type 134) o Neighbor Solicitation (Type 135) o Neighbor Advertisement (Type 136) o Redirect (Type 137) o Inverse Neighbor Discovery Solicitation (Type 141) o Inverse Neighbor Discovery Advertisement (Type 142)
o ルータSolicitation(133をタイプする)o Router Advertisement(134をタイプする)o Neighbor Solicitation(135をタイプする)o Neighbor Advertisement(136をタイプする)o Redirect(137をタイプする)o Inverse NeighborディスカバリーSolicitation(141をタイプする)o Inverse NeighborディスカバリーAdvertisement(タイプ142)
Link-local multicast receiver notification messages (must have link- local source address):
リンクローカルのマルチキャスト受信機通知メッセージ(リンク地元筋アドレスを持たなければなりません):
o Listener Query (Type 130) o Listener Report (Type 131) o Listener Done (Type 132) o Listener Report v2 (Type 143)
o リスナーQuery(130をタイプする)o Listener Report(131をタイプする)o Listener Done(132をタイプする)o Listener Report v2(タイプ143)
Davies & Mohacsi Informational [Page 15] RFC 4890 ICMPv6 Filtering Recommendations May 2007
2007年5月に推薦をフィルターにかけるデイヴィースとMohacsiの情報[15ページ]のRFC4890ICMPv6
SEND Certificate Path notification messages (must be received with hop limit = 255):
SEND Certificate Path通知メッセージ(ホップ限界=255で受け取らなければなりません):
o Certificate Path Solicitation (Type 148) o Certificate Path Advertisement (Type 149)
o 証明書Path Solicitation(148をタイプする)o Certificate Path Advertisement(タイプ149)
Multicast Router Discovery messages (must have link-local source address and hop limit = 1):
マルチキャストRouterディスカバリーメッセージ(リンク地元筋アドレスを持って、限界=1を飛び越さなければなりません):
o Multicast Router Advertisement (Type 151) o Multicast Router Solicitation (Type 152) o Multicast Router Termination (Type 153)
o マルチキャストRouter Advertisement(151をタイプする)o Multicast Router Solicitation(152をタイプする)o Multicast Router Termination(タイプ153)
4.3.4. Traffic for Which a Policy Should Be Defined
4.3.4. 方針が定義されるべきであるトラフィック
The message type that the experimental Seamoby protocols are using will be expected to have to cross site boundaries in normal operation. Transit sites must allow these messages to transit the site. End site administrators should determine if they need to support these experiments and otherwise messages of this type should be dropped:
実験Seamobyプロトコルが使用しているメッセージタイプは通常の操作におけるサイト境界に交差しなければならないと予想されるでしょう。 トランジットサイトはこれらのメッセージにトランジットへのサイトを許容しなければなりません。 終わりのサイトの管理者は、彼らが、これらの実験をサポートする必要であるかどうかと決心するべきです、そして、さもなければ、このタイプに関するメッセージは下げられるべきです:
o Seamoby Experimental (Type 150)
o Seamoby実験的です。(タイプ150)
Error messages not currently defined by IANA:
o Unallocated Error messages (Types 5-99 inclusive and 102-126
inclusive)
エラーメッセージは現在、IANAで定義しませんでした: o Unallocated Errorメッセージ(5-99 包括的であって、102-126 包括的に、タイプします)
The base ICMPv6 specification suggests that error messages that are not explicitly known to a node should be forwarded and passed to any higher-level protocol that might be able to interpret them. There is a small risk that such messages could be used to provide a covert channel or form part of a DoS attack. Administrators of end sites should be aware of this and determine whether they wish to allow these messages through the firewall. Firewalls protecting transit sites must allow all types of error messages to transit the site but may adopt different policies for error messages addressed to nodes within the site.
ベースICMPv6仕様は、明らかにノードに知られていないエラーメッセージがそれらを解釈できるかもしれないどんな上位レベル・プロトコルにも転送されて、通過されるべきであると示唆します。 DoS攻撃のひそかなチャンネルかフォーム部分を提供するのにそのようなメッセージを使用できた低いリスクがあります。 端のサイトの管理者は、これを意識していて、それらがこれらのメッセージのファイアウォールに通ることを許したがっているかどうかと決心するべきです。 トランジットサイトを保護するファイアウォールは、トランジットへのエラーメッセージのすべてのタイプにサイトを許容しなければなりませんが、サイトの中のノードに扱われたエラーメッセージのために異なった方針を採るかもしれません。
All informational messages with types not explicitly assigned by IANA, currently:
現在IANAによって明らかに選任されていないタイプがあるすべての通報メッセージ:
o Unallocated Informational messages (Types 154-199 inclusive and
202-254 inclusive).
o Unallocated Informationalメッセージ(154-199 包括的であって、202-254 包括的に、タイプします)。
Note that the base ICMPv6 specification requires that received informational messages with unknown types must be silently discarded. Transit sites must allow these messages to transit the site. End
静かに未知のタイプで通報メッセージを受けたICMPv6仕様が必要とするベースを捨てなければならないことに注意してください。 トランジットサイトはこれらのメッセージにトランジットへのサイトを許容しなければなりません。 終わり
Davies & Mohacsi Informational [Page 16] RFC 4890 ICMPv6 Filtering Recommendations May 2007
2007年5月に推薦をフィルターにかけるデイヴィースとMohacsiの情報[16ページ]のRFC4890ICMPv6
site administrators can either adopt a policy of allowing all these messages through the firewall, relying on end hosts to drop unrecognized messages, or drop all such messages at the firewall. Different policies could be adopted for inbound and outbound messages.
サイトの管理者はこれらのすべてのメッセージのファイアウォールに通ることを許す方針を採ることができます、ファイアウォールで認識されていないメッセージを下げるか、またはそのようなすべてのメッセージを下げるために終わりのホストに頼って。 本国行きの、そして、外国行きのメッセージのために異なった方針を採ることができました。
If administrators choose to implement policies that drop currently unallocated error or informational messages, it is important to review the set of messages affected in case new message types are assigned by IANA.
管理者が、現在「非-割り当て」られた誤りを下げる方針か通報メッセージを実装するのを選ぶなら、新しいメッセージタイプがIANAによって選任されるといけないので影響を受けるメッセージのセットを見直すのは重要です。
4.3.5. Traffic That Should Be Dropped Unless a Good Case Can Be Made
4.3.5. 良い弁護をすることができないなら下げられるべきであるトラフィック
Node Information enquiry messages should generally not be forwarded across site boundaries. Some of these messages will be using non- link-local unicast addresses so that they will not necessarily be dropped by address scope limiting rules:
一般に、サイト境界の向こう側にノード情報調査メッセージを転送するべきではありません。 これらのメッセージのいくつかがそれらが必ず規則を制限するアドレスの範囲によって下げられるというわけではないように、リンクローカルのユニキャスト非アドレスを使用するでしょう:
o Node Information Query (Type 139) o Node Information Response (Type 140)
o ノード情報Query(139をタイプする)o Node情報Response(タイプ140)
Router Renumbering messages should not be forwarded across site boundaries. As originally specified, these messages may use a site scope multicast address or a site local unicast address. They should be caught by standard rules that are intended to stop any packet with a multicast site scope or site local destination being forwarded across a site boundary provided these are correctly configured. Since site local addresses have now been deprecated, it seems likely that changes may be made to allow the use of unique local addresses or global unicast addresses. Should this happen, it will be essential to explicitly filter these messages at site boundaries. If a site has internal as well as boundary firewalls, individual policies should be established for the internal firewalls depending on whether or not the site wishes to use Router Renumbering:
サイト境界の向こう側にルータRenumberingメッセージを転送するべきではありません。 元々指定されるように、これらのメッセージはサイト範囲マルチキャストアドレスかサイトのローカルのユニキャストアドレスを使用するかもしれません。 それらは正しくこれらを構成するならサイト境界の向こう側にマルチキャストサイト範囲かサイトの地方の目的地を進めていてどんなパケットも止めることを意図する標準の規則で捕らえられるべきです。 サイトのローカルのアドレスが現在推奨しないので、変更がユニークなローカルのアドレスかグローバルなユニキャストアドレスの使用を許すと行われそうです。 これが起こると、サイト境界で明らかにこれらのメッセージをフィルターにかけるのは不可欠でしょう。 サイトがそうしたなら、境界ファイアウォールと同様に内部であり、独特の方針はサイトがRouter Renumberingを使用したがっているかどうかによる内部のファイアウォールに確立されるべきです:
o Router Renumbering (Type 138)
o ルータの番号を付け替えること(タイプ138)
Messages with types in the experimental allocations:
実験的な配分におけるタイプがあるメッセージ:
o Types 100, 101, 200, and 201.
o タイプ100、101、200、および201。
Messages using the extension type numbers until such time as ICMPv6 needs to use such extensions:
ICMPv6のような時間が、そのような拡張子を使用する必要があるまで、拡張子を使用するメッセージが数をタイプします:
o Types 127 and 255.
o タイプ127と255。
Davies & Mohacsi Informational [Page 17] RFC 4890 ICMPv6 Filtering Recommendations May 2007
2007年5月に推薦をフィルターにかけるデイヴィースとMohacsiの情報[17ページ]のRFC4890ICMPv6
4.4. Recommendations for ICMPv6 Local Configuration Traffic
4.4. ICMPv6の地方の構成トラフィックのための推薦
This section recommends filtering rules for ICMPv6 traffic addressed to an interface on a firewall. For a small number of messages, the desired behavior may differ between interfaces on the site or private side of the firewall and the those on the public Internet side of the firewall.
このセクションは、ファイアウォールの上にインタフェースに扱われたICMPv6トラフィックのために規則をフィルターにかけることを勧めます。 少ない数のメッセージに関しては、望まれた行動はファイアウォールのサイトか個人的な側面と公共のインターネットは面があるファイアウォールのオンであるものの上のインタフェースの間で異なるかもしれません。
4.4.1. Traffic That Must Not Be Dropped
4.4.1. 下げてはいけないトラフィック
Error messages that are essential to the establishment and maintenance of communications:
コミュニケーションの設立とメインテナンスに不可欠のエラーメッセージ:
o Destination Unreachable (Type 1) - All codes o Packet Too Big (Type 2) o Time Exceeded (Type 3) - Code 0 only o Parameter Problem (Type 4) - Codes 1 and 2 only
o 目的地Unreachable(1をタイプする)--すべてがo Packet Too Big(2をタイプする)o Time Exceeded(3をタイプする)--コード0oだけParameter Problem(4をタイプする)--コード1と2だけをコード化します。
Connectivity checking messages:
接続性照合メッセージ:
o Echo Request (Type 128) o Echo Response (Type 129)
o エコーRequest(128をタイプする)o Echo Response(タイプ129)
As discussed in Section 4.3.1, dropping connectivity checking messages will prevent the firewall being the destination of a Teredo tunnel and it is not considered necessary to disable connectivity checking in IPv6 networks because port scanning is less of a security risk.
セクション4.3.1で議論するように、接続性照合メッセージを下げるのは、ファイアウォールがTeredoトンネルの目的地であることを防ぐでしょう、そして、それはセキュリティリスクでポートスキャンが、より少ないのでIPv6ネットワークを預ける接続性を無効にするのに必要であると考えられません。
There are a number of other sets of messages that play a role in configuring the node and maintaining unicast and multicast communications through the interfaces of a node. These messages must not be dropped if the node is to successfully participate in an IPv6 network. The exception to this is the Redirect message for which an explicit policy decision should be taken (see Section 4.4.4).
ノードのインタフェースを通してノードを構成して、ユニキャストとマルチキャストコミュニケーションを維持することにおける役割を果たす他の多くのメッセージがあります。 ノードが首尾よくIPv6ネットワークに参加することであるならこれらのメッセージを下げてはいけません。 これへの例外は明白な政策決定が取られるべきであるRedirectメッセージ(セクション4.4.4を見る)です。
Address Configuration and Router Selection messages:
ConfigurationとRouter Selectionがメッセージであると扱ってください:
o Router Solicitation (Type 133) o Router Advertisement (Type 134) o Neighbor Solicitation (Type 135) o Neighbor Advertisement (Type 136) o Inverse Neighbor Discovery Solicitation (Type 141) o Inverse Neighbor Discovery Advertisement (Type 142)
o ルータSolicitation(133をタイプする)o Router Advertisement(134をタイプする)o Neighbor Solicitation(135をタイプする)o Neighbor Advertisement(136をタイプする)o Inverse NeighborディスカバリーSolicitation(141をタイプする)o Inverse NeighborディスカバリーAdvertisement(タイプ142)
Davies & Mohacsi Informational [Page 18] RFC 4890 ICMPv6 Filtering Recommendations May 2007
2007年5月に推薦をフィルターにかけるデイヴィースとMohacsiの情報[18ページ]のRFC4890ICMPv6
Link-Local Multicast Receiver Notification messages:
リンクローカルのMulticast Receiver Notificationメッセージ:
o Listener Query (Type 130) o Listener Report (Type 131) o Listener Done (Type 132) o Listener Report v2 (Type 143)
o リスナーQuery(130をタイプする)o Listener Report(131をタイプする)o Listener Done(132をタイプする)o Listener Report v2(タイプ143)
SEND Certificate Path Notification messages:
SEND Certificate Path Notificationメッセージ:
o Certificate Path Solicitation (Type 148) o Certificate Path Advertisement (Type 149)
o 証明書Path Solicitation(148をタイプする)o Certificate Path Advertisement(タイプ149)
Multicast Router Discovery messages:
マルチキャストRouterディスカバリーメッセージ:
o Multicast Router Advertisement (Type 151) o Multicast Router Solicitation (Type 152) o Multicast Router Termination (Type 153)
o マルチキャストRouter Advertisement(151をタイプする)o Multicast Router Solicitation(152をタイプする)o Multicast Router Termination(タイプ153)
4.4.2. Traffic That Normally Should Not Be Dropped
4.4.2. 通常、下げられるはずがないトラフィック
Error messages other than those listed in Section 4.4.1:
それら以外のエラーメッセージはセクション4.4.1でリストアップされました:
o Time Exceeded (Type 3) - Code 1 o Parameter Problem (Type 4) - Code 0
o 時間Exceeded(3をタイプする)--コード1o Parameter Problem(4をタイプする)--コード0
4.4.3. Traffic That Will Be Dropped Anyway -- No Special Attention
Needed
4.4.3. とにかく下げられるトラフィック--注意は必要ではありません特別な。
Router Renumbering messages must be authenticated using IPsec, so it is not essential to filter these messages even if they are not allowed at the firewall/router:
IPsecを使用することでルータRenumberingメッセージを認証しなければならないので、それらがファイアウォール/ルータで許容されていなくても、これらのメッセージをフィルターにかけるのは不可欠ではありません:
o Router Renumbering (Type 138)
o ルータの番号を付け替えること(タイプ138)
Mobile IPv6 messages that are needed to assist mobility:
移動性を補助するのに必要であるモバイルIPv6メッセージ:
o Home Agent Address Discovery Request (Type 144) o Home Agent Address Discovery Reply (Type 145) o Mobile Prefix Solicitation (Type 146) o Mobile Prefix Advertisement (Type 147)
o ホームエージェントAddressディスカバリーRequest(144をタイプする)oホームのエージェントAddressディスカバリーReply(145をタイプする)oモバイルPrefix Solicitation(146をタイプする)oモバイルPrefix Advertisement(タイプ147)
It may be desirable to drop these messages, especially on public interfaces, if the firewall is not also providing mobile home agent services, but they will be ignored otherwise.
これらのメッセージを下げるのは望ましいかもしれません、また、ファイアウォールが移動住宅エージェントサービスを提供していませんが、それらが別の方法で無視されて特に公共のインタフェースで。
Davies & Mohacsi Informational [Page 19] RFC 4890 ICMPv6 Filtering Recommendations May 2007
2007年5月に推薦をフィルターにかけるデイヴィースとMohacsiの情報[19ページ]のRFC4890ICMPv6
The message used by the experimental Seamoby protocols may be dropped but will be ignored if the service is not implemented:
実験Seamobyプロトコルによって使用されるメッセージは、下げられるかもしれませんが、サービスが実装されないと、無視されるでしょう:
o Seamoby Experimental (Type 150)
o Seamoby実験的です。(タイプ150)
4.4.4. Traffic for Which a Policy Should Be Defined
4.4.4. 方針が定義されるべきであるトラフィック
Redirect messages provide a significant security risk, and administrators should take a case-by-case approach to whether firewalls, routers in general, and other nodes should accept these messages:
再直接のメッセージは重要なセキュリティリスクを提供します、そして、管理者はファイアウォール、一般に、ルータ、および他のノードがこれらのメッセージを受け入れるはずであるかどうかへのその場その場のアプローチを取るべきです:
o Redirect (Type 137)
o 再直接(タイプ137)
Conformant nodes must provide configuration controls that allow nodes to control their behavior with respect to Redirect messages so that it should only be necessary to install specific filtering rules under special circumstances, such as if Redirect messages are accepted on private interfaces but not public ones.
ConformantノードがノードがRedirectメッセージに関して彼らの振舞いを制御できる構成管理を備えなければならないので、単に特定のフィルタリング規則を特殊事情の下にインストールするのが必要であるべきです、個人的なインタフェースでRedirectメッセージを受け入れるか、しかし、どんな公共のもののようにも、そうしません。
If a node implements the experimental Node Information service, the administrator needs to make an explicit decision as to whether the node should respond to or accept Node Information messages on each interface:
ノードが実験的なNode情報サービスを実装するなら、管理者は、ノードが各インタフェースでNode情報メッセージを応じるはずであるか、または受け入れるはずであるかどうかに関して明白な決定をする必要があります:
o Node Information Query (Type 139) o Node Information Response (Type 140)
o ノード情報Query(139をタイプする)o Node情報Response(タイプ140)
It may be possible to disable the service on the node if it is not wanted, in which case these messages will be ignored and no filtering is necessary.
これらのメッセージが無視されて、フィルターにかけないどのケースが必要であるかでそれが欲しくないなら、ノードの上でサービスを無効にするのは可能であるかもしれません。
Error messages not currently defined by IANA:
エラーメッセージは現在、IANAで定義しませんでした:
o Unallocated Error messages (Types 5-99 inclusive and 102-126
inclusive)
o Unallocated Errorメッセージ(5-99 包括的であって、102-126 包括的に、タイプします)
The base ICMPv6 specification suggests that error messages that are not explicitly known to a node should be forwarded and passed to any higher-level protocol that might be able to interpret them. There is a small risk that such messages could be used to provide a covert channel or form part of a DoS attack. Administrators should be aware of this and determine whether they wish to allow these messages to be sent to the firewall.
ベースICMPv6仕様は、明らかにノードに知られていないエラーメッセージがそれらを解釈できるかもしれないどんな上位レベル・プロトコルにも転送されて、通過されるべきであると示唆します。 DoS攻撃のひそかなチャンネルかフォーム部分を提供するのにそのようなメッセージを使用できた低いリスクがあります。 管理者は、これを意識していて、彼らがファイアウォールに送られるべきこれらのメッセージを許したがっているかどうかと決心するべきです。
Davies & Mohacsi Informational [Page 20] RFC 4890 ICMPv6 Filtering Recommendations May 2007
2007年5月に推薦をフィルターにかけるデイヴィースとMohacsiの情報[20ページ]のRFC4890ICMPv6
4.4.5. Traffic That Should Be Dropped Unless a Good Case Can Be Made
4.4.5. 良い弁護をすることができないなら下げられるべきであるトラフィック
Messages with types in the experimental allocations:
実験的な配分におけるタイプがあるメッセージ:
o Types 100, 101, 200, and 201.
o タイプ100、101、200、および201。
Messages using the extension type numbers until such time as ICMPv6 needs to use such extensions:
ICMPv6のような時間が、そのような拡張子を使用する必要があるまで、拡張子を使用するメッセージが数をタイプします:
o Types 127 and 255.
o タイプ127と255。
All informational messages with types not explicitly assigned by IANA, currently:
現在IANAによって明らかに選任されていないタイプがあるすべての通報メッセージ:
o Types 154-199 inclusive and 202-254 inclusive.
o 154-199 包括的であって、202-254 包括的に、タイプします。
Note that the base ICMPv6 specification requires that received informational messages with unknown types must be silently discarded.
静かに未知のタイプで通報メッセージを受けたICMPv6仕様が必要とするベースを捨てなければならないことに注意してください。
5. Acknowledgements
5. 承認
Pekka Savola created the original IPv6 Security Overview document, which contained suggestions for ICMPv6 filter setups. This information has been incorporated into this document. He has also provided important comments. Some analysis of the classification of ICMPv6 messages and the term 'any-to-end' were used by Jari Arkko in a document relating to ICMPv6 and IKE.
ペッカSavolaはオリジナルのIPv6 Security Overviewドキュメントを作成しました。(それは、ICMPv6フィルタセットアップのための提案を含みました)。 この情報をこのドキュメントに組み入れてあります。 また、彼は重要なコメントを提供しました。 ICMPv6メッセージの分類の何らかの分析と'終わるいずれ'という用語は、ICMPv6とIKEに関連しながら、ドキュメントでヤリArkkoによって使用されました。
The Netfilter configuration script in Appendix B was contributed by Suresh Krishnan.
Appendix BのNetfilter構成スクリプトはSureshクリシュナンによって寄付されました。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] マッキャン、J.、デアリング、S.、およびJ.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、1996インチ年8月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol,
Version 6 (IPv6) Specification", RFC 2460,
December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2461]Narten、T.、Nordmark、E.、およびW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2462] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、1998年12月。
Davies & Mohacsi Informational [Page 21] RFC 4890 ICMPv6 Filtering Recommendations May 2007
2007年5月に推薦をフィルターにかけるデイヴィースとMohacsiの情報[21ページ]のRFC4890ICMPv6
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999.
[RFC2710] デアリング、S.、フェナー、W.、およびB.ハーバーマン、「IPv6"、RFC2710、1999年10月のためのマルチキャストリスナー発見(MLD)。」
[RFC2894] Crawford, M., "Router Renumbering for IPv6",
RFC 2894, August 2000.
[RFC2894] クロフォード、M.、「IPv6"、RFC2894、2000年8月のためのルータの番号を付け替えること」。
[RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for
Inverse Discovery Specification", RFC 3122,
June 2001.
[RFC3122]コンタ、A.、「逆さの発見仕様のためのIPv6隣人発見への拡大」、RFC3122、2001年6月。
[RFC3590] Haberman, B., "Source Address Selection for the
Multicast Listener Discovery (MLD) Protocol",
RFC 3590, September 2003.
[RFC3590]ハーバーマン、B.、「マルチキャストリスナー発見(MLD)プロトコルのためのソースアドレス選択」、RFC3590、2003年9月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[RFC3775] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
March 2005.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4065] Kempf, J., "Instructions for Seamoby and Experimental
Mobility Protocol IANA Allocations", RFC 4065,
July 2005.
[RFC4065] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005.
[RFC4286] Haberman, B. and J. Martin, "Multicast Router
Discovery", RFC 4286, December 2005.
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, December 2005.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443,
March 2006.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4620] Crawford, M. and B. Haberman, "IPv6 Node Information
Queries", RFC 4620, August 2006.
[RFC4620] Crawford, M. and B. Haberman, "IPv6 Node Information Queries", RFC 4620, August 2006.
6.2. Informative References
6.2. Informative References
[ICMP-ATTACKS] Gont, F., "ICMP attacks against TCP", Work
in Progress, October 2006.
[ICMP-ATTACKS] Gont, F., "ICMP attacks against TCP", Work in Progress, October 2006.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6",
RFC 3041, January 2001.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
Davies & Mohacsi Informational [Page 22] RFC 4890 ICMPv6 Filtering Recommendations May 2007
Davies & Mohacsi Informational [Page 22] RFC 4890 ICMPv6 Filtering Recommendations May 2007
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[SCAN-IMP] Chown, T., "IPv6 Implications for Network Scanning",
Work in Progress, March 2007.
[SCAN-IMP] Chown, T., "IPv6 Implications for Network Scanning", Work in Progress, March 2007.
[netfilter] netfilter.org, "The netfilter.org project",
Firewalling, NAT and Packet Mangling for Linux ,
2006, <http://www.netfilter.org/>.
[netfilter] netfilter.org, "The netfilter.org project", Firewalling, NAT and Packet Mangling for Linux , 2006, <http://www.netfilter.org/>.
Davies & Mohacsi Informational [Page 23] RFC 4890 ICMPv6 Filtering Recommendations May 2007
Davies & Mohacsi Informational [Page 23] RFC 4890 ICMPv6 Filtering Recommendations May 2007
Appendix A. Notes on Individual ICMPv6 Messages
Appendix A. Notes on Individual ICMPv6 Messages
A.1. Destination Unreachable Error Message
A.1. Destination Unreachable Error Message
Destination Unreachable (Type 1) error messages [RFC4443] are sent any-to-end between unicast addresses. The message can be generated from any node that a packet traverses when the node is unable to forward the packet for any reason except congestion.
Destination Unreachable (Type 1) error messages [RFC4443] are sent any-to-end between unicast addresses. The message can be generated from any node that a packet traverses when the node is unable to forward the packet for any reason except congestion.
Destination Unreachable messages are useful for debugging, but are also important to speed up cycling through possible addresses, as they can avoid the need to wait through timeouts and hence can be part of the process of establishing or maintaining communications. It is a common practice in IPv4 to refrain from generating ICMP Destination Unreachable messages in an attempt to hide the networking topology and/or service structure. The same idea could be applied to IPv6, but this can slow down connection if a host has multiple addresses, some of which are deprecated, as they may be when using privacy addresses [RFC3041]. If policy allows the generation of ICMPv6 Destination Unreachable messages, it is important that nodes provide the correct reason code, one of: no route to destination, administratively prohibited, beyond scope of source address, address unreachable, port unreachable, source address failed ingress/egress policy, or reject route to destination.
Destination Unreachable messages are useful for debugging, but are also important to speed up cycling through possible addresses, as they can avoid the need to wait through timeouts and hence can be part of the process of establishing or maintaining communications. It is a common practice in IPv4 to refrain from generating ICMP Destination Unreachable messages in an attempt to hide the networking topology and/or service structure. The same idea could be applied to IPv6, but this can slow down connection if a host has multiple addresses, some of which are deprecated, as they may be when using privacy addresses [RFC3041]. If policy allows the generation of ICMPv6 Destination Unreachable messages, it is important that nodes provide the correct reason code, one of: no route to destination, administratively prohibited, beyond scope of source address, address unreachable, port unreachable, source address failed ingress/egress policy, or reject route to destination.
A.2. Packet Too Big Error Message
A.2. Packet Too Big Error Message
Packet Too Big (Type 2) error messages [RFC4443] are sent any-to-end between unicast addresses. The message can be generated from any node that a packet traverses on the path when the node is unable to forward the packet because the packet is too large for the MTU of the next link. This message is vital to the correct functioning of Path MTU Discovery and hence is part of the establishment and maintenance of communications. Since routers are not allowed to fragment packets, informing sources of the need to fragment large packets is more important than for IPv4. If these messages are not generated when appropriate, hosts will continue to send packets that are too large or may assume that the route is congested. Effectively, parts of the Internet will become inaccessible.
Packet Too Big (Type 2) error messages [RFC4443] are sent any-to-end between unicast addresses. The message can be generated from any node that a packet traverses on the path when the node is unable to forward the packet because the packet is too large for the MTU of the next link. This message is vital to the correct functioning of Path MTU Discovery and hence is part of the establishment and maintenance of communications. Since routers are not allowed to fragment packets, informing sources of the need to fragment large packets is more important than for IPv4. If these messages are not generated when appropriate, hosts will continue to send packets that are too large or may assume that the route is congested. Effectively, parts of the Internet will become inaccessible.
If a network chooses to generate packets that are no larger than the Guaranteed Minimum MTU (1280 octets) and the site's links to the wider Internet have corresponding MTUs, Packet Too Big messages should not be expected at the firewall and could be dropped if they arrive.
If a network chooses to generate packets that are no larger than the Guaranteed Minimum MTU (1280 octets) and the site's links to the wider Internet have corresponding MTUs, Packet Too Big messages should not be expected at the firewall and could be dropped if they arrive.
Davies & Mohacsi Informational [Page 24] RFC 4890 ICMPv6 Filtering Recommendations May 2007
Davies & Mohacsi Informational [Page 24] RFC 4890 ICMPv6 Filtering Recommendations May 2007
A.3. Time Exceeded Error Message
A.3. Time Exceeded Error Message
Time Exceeded (Type 3) error messages [RFC4443] can occur in two contexts:
Time Exceeded (Type 3) error messages [RFC4443] can occur in two contexts:
o Code 0 are generated at any node on the path being taken by the
packet and sent, any-to-end between unicast addresses, if the Hop
Limit value is decremented to zero at that node.
o Code 0 are generated at any node on the path being taken by the packet and sent, any-to-end between unicast addresses, if the Hop Limit value is decremented to zero at that node.
o Code 1 messages are generated at the destination node and sent
end-to-end between unicast addresses if all the segments of a
fragmented message are not received within the reassembly time
limit.
o Code 1 messages are generated at the destination node and sent end-to-end between unicast addresses if all the segments of a fragmented message are not received within the reassembly time limit.
Code 0 messages can be needed as part of the establishment of communications if the path to a particular destination requires an unusually large number of hops.
Code 0 messages can be needed as part of the establishment of communications if the path to a particular destination requires an unusually large number of hops.
Code 1 messages will generally only result from congestion in the network, and it is less essential to propagate these messages.
Code 1 messages will generally only result from congestion in the network, and it is less essential to propagate these messages.
A.4. Parameter Problem Error Message
A.4. Parameter Problem Error Message
The great majority of Parameter Problem (Type 4) error messages will be generated by the destination node when processing destination options and other extension headers, and hence are sent end-to-end between unicast addresses. Exceptionally, these messages might be generated by any node on the path if a faulty or unrecognized hop-by- hop option is included or from any routing waypoint if there are faulty or unrecognized destination options associated with a Type 0 routing header. In these cases, the message will be sent any-to-end using unicast source and destination addresses.
The great majority of Parameter Problem (Type 4) error messages will be generated by the destination node when processing destination options and other extension headers, and hence are sent end-to-end between unicast addresses. Exceptionally, these messages might be generated by any node on the path if a faulty or unrecognized hop-by- hop option is included or from any routing waypoint if there are faulty or unrecognized destination options associated with a Type 0 routing header. In these cases, the message will be sent any-to-end using unicast source and destination addresses.
Parameter Problem Code 1 (Unrecognized Next Header) and Code 2 (Unrecognized IPv6 Option) messages may result if a node on the path (usually the destination) is unable to process a correctly formed extension header or option. If these messages are not returned to the source, communication cannot be established, as the source would need to adapt its choice of options probably because the destination does not implement these capabilities. Hence, these messages need to be generated and allowed for effective IPv6 communications.
Parameter Problem Code 1 (Unrecognized Next Header) and Code 2 (Unrecognized IPv6 Option) messages may result if a node on the path (usually the destination) is unable to process a correctly formed extension header or option. If these messages are not returned to the source, communication cannot be established, as the source would need to adapt its choice of options probably because the destination does not implement these capabilities. Hence, these messages need to be generated and allowed for effective IPv6 communications.
Code 0 (Erroneous Header) messages indicate a malformed extension header generally as a result of incorrectly generated packets. Hence, these messages are useful for debugging purposes, but it is unlikely that a node generating such packets could establish communications without human intervention to correct the problem.
Code 0 (Erroneous Header) messages indicate a malformed extension header generally as a result of incorrectly generated packets. Hence, these messages are useful for debugging purposes, but it is unlikely that a node generating such packets could establish communications without human intervention to correct the problem.
Davies & Mohacsi Informational [Page 25] RFC 4890 ICMPv6 Filtering Recommendations May 2007
Davies & Mohacsi Informational [Page 25] RFC 4890 ICMPv6 Filtering Recommendations May 2007
Code 2 messages, only, can be generated for packets with multicast destination addresses.
Code 2 messages, only, can be generated for packets with multicast destination addresses.
It is possible that attackers may seek to probe or scan a network by deliberately generating packets with unknown extension headers or options or with faulty headers. If nodes generate Parameter Problem error messages in all cases and these outgoing messages are allowed through firewalls, the attacker may be able to identify active addresses that can be probed further or learn about the network topology. The vulnerability could be mitigated whilst helping to establish communications if the firewall was able to examine such error messages in depth and was configured to only allow Parameter Problem messages for headers that had been standardized but were not supported in the protected network. If the network administrator believes that all nodes in the network support all legitimate extension headers, then it would be reasonable to drop all outgoing Parameter Problem messages. Note that this is not a major vulnerability in a well-designed IPv6 network because of the difficulties of performing scanning attacks (see Section 3.2).
It is possible that attackers may seek to probe or scan a network by deliberately generating packets with unknown extension headers or options or with faulty headers. If nodes generate Parameter Problem error messages in all cases and these outgoing messages are allowed through firewalls, the attacker may be able to identify active addresses that can be probed further or learn about the network topology. The vulnerability could be mitigated whilst helping to establish communications if the firewall was able to examine such error messages in depth and was configured to only allow Parameter Problem messages for headers that had been standardized but were not supported in the protected network. If the network administrator believes that all nodes in the network support all legitimate extension headers, then it would be reasonable to drop all outgoing Parameter Problem messages. Note that this is not a major vulnerability in a well-designed IPv6 network because of the difficulties of performing scanning attacks (see Section 3.2).
A.5. ICMPv6 Echo Request and Echo Response
A.5. ICMPv6 Echo Request and Echo Response
Echo Request (Type 128) uses unicast addresses as source addresses, but may be sent to any legal IPv6 address, including multicast and anycast addresses [RFC4443]. Echo Requests travel end-to-end. Similarly, Echo Responses (Type 129) travel end-to-end and would have a unicast address as destination and either a unicast or anycast address as source. They are mainly used in combination for monitoring and debugging connectivity. Their only role in establishing communication is that they are required when verifying connectivity through Teredo tunnels [RFC4380]: Teredo tunneling to IPv6 nodes on the site will not be possible if these messages are blocked. It is not thought that there is a significant risk from scanning attacks on a well-designed IPv6 network (see Section 3.2), and so connectivity checks should be allowed by default.
Echo Request (Type 128) uses unicast addresses as source addresses, but may be sent to any legal IPv6 address, including multicast and anycast addresses [RFC4443]. Echo Requests travel end-to-end. Similarly, Echo Responses (Type 129) travel end-to-end and would have a unicast address as destination and either a unicast or anycast address as source. They are mainly used in combination for monitoring and debugging connectivity. Their only role in establishing communication is that they are required when verifying connectivity through Teredo tunnels [RFC4380]: Teredo tunneling to IPv6 nodes on the site will not be possible if these messages are blocked. It is not thought that there is a significant risk from scanning attacks on a well-designed IPv6 network (see Section 3.2), and so connectivity checks should be allowed by default.
A.6. Neighbor Solicitation and Neighbor Advertisement Messages
A.6. Neighbor Solicitation and Neighbor Advertisement Messages
ICMPv6 Neighbor Solicitation and Neighbor Advertisement (Type 135 and 136) messages are essential to the establishment and maintenance of communications on the local link. Firewalls need to generate and accept these messages to allow them to establish and maintain interfaces onto their connected links.
ICMPv6 Neighbor Solicitation and Neighbor Advertisement (Type 135 and 136) messages are essential to the establishment and maintenance of communications on the local link. Firewalls need to generate and accept these messages to allow them to establish and maintain interfaces onto their connected links.
Davies & Mohacsi Informational [Page 26] RFC 4890 ICMPv6 Filtering Recommendations May 2007
Davies & Mohacsi Informational [Page 26] RFC 4890 ICMPv6 Filtering Recommendations May 2007
Note that the address scopes of the source and destination addresses on Neighbor Solicitations and Neighbor Advertisements may not match. The exact functions that these messages will be carrying out depends on the mechanism being used to configure IPv6 addresses on the link (Stateless, Stateful, or Static configuration).
Note that the address scopes of the source and destination addresses on Neighbor Solicitations and Neighbor Advertisements may not match. The exact functions that these messages will be carrying out depends on the mechanism being used to configure IPv6 addresses on the link (Stateless, Stateful, or Static configuration).
A.7. Router Solicitation and Router Advertisement Messages
A.7. Router Solicitation and Router Advertisement Messages
ICMPv6 Router Solicitation and Router Advertisement (Type 133 and 134) messages are essential to the establishment and maintenance of communications on the local link. Firewalls need to generate (since the firewall will generally be behaving as a router) and accept these messages to allow them to establish and maintain interfaces onto their connected links.
ICMPv6 Router Solicitation and Router Advertisement (Type 133 and 134) messages are essential to the establishment and maintenance of communications on the local link. Firewalls need to generate (since the firewall will generally be behaving as a router) and accept these messages to allow them to establish and maintain interfaces onto their connected links.
A.8. Redirect Messages
A.8. Redirect Messages
ICMPv6 Redirect Messages (Type 137) are used on the local link to indicate that nodes are actually link-local and communications need not go via a router, or to indicate a more appropriate first-hop router. Although they can be used to make communications more efficient, they are not essential to the establishment of communications and may be a security vulnerability, particularly if a link is not physically secured. Conformant nodes are required to provide configuration controls that suppress the generation of Redirect messages and allow them to be ignored on reception. Using Redirect messages on, for example, a wireless link without link level encryption/authentication is particularly hazardous because the link is open to eavesdropping and packet injection.
ICMPv6 Redirect Messages (Type 137) are used on the local link to indicate that nodes are actually link-local and communications need not go via a router, or to indicate a more appropriate first-hop router. Although they can be used to make communications more efficient, they are not essential to the establishment of communications and may be a security vulnerability, particularly if a link is not physically secured. Conformant nodes are required to provide configuration controls that suppress the generation of Redirect messages and allow them to be ignored on reception. Using Redirect messages on, for example, a wireless link without link level encryption/authentication is particularly hazardous because the link is open to eavesdropping and packet injection.
A.9. SEND Certificate Path Messages
A.9. SEND Certificate Path Messages
SEND [RFC3971] uses two messages (Certificate Path Solicitation and Advertisement - Types 148 and 149) sent from nodes to supposed routers on the same local link to obtain a certificate path that will allow the node to authenticate the router's claim to provide routing services for certain prefixes. If a link connected to a firewall/ router is using SEND, the firewall must be able to exchange these messages with nodes on the link that will use its routing services.
SEND [RFC3971] uses two messages (Certificate Path Solicitation and Advertisement - Types 148 and 149) sent from nodes to supposed routers on the same local link to obtain a certificate path that will allow the node to authenticate the router's claim to provide routing services for certain prefixes. If a link connected to a firewall/ router is using SEND, the firewall must be able to exchange these messages with nodes on the link that will use its routing services.
A.10. Multicast Listener Discovery Messages
A.10. Multicast Listener Discovery Messages
Multicast Listener Discovery (MLD) version 1 [RFC2710] (Listener Query, Listener Report, and Listener Done - Types 130, 131, and 132) and version 2 [RFC3810] (Listener Query and Listener Report version 2 - Types 130 and 143) messages are sent on the local link to communicate between multicast-capable routers and nodes that wish to join or leave specific multicast groups. Firewalls need to be able
Multicast Listener Discovery (MLD) version 1 [RFC2710] (Listener Query, Listener Report, and Listener Done - Types 130, 131, and 132) and version 2 [RFC3810] (Listener Query and Listener Report version 2 - Types 130 and 143) messages are sent on the local link to communicate between multicast-capable routers and nodes that wish to join or leave specific multicast groups. Firewalls need to be able
Davies & Mohacsi Informational [Page 27] RFC 4890 ICMPv6 Filtering Recommendations May 2007
Davies & Mohacsi Informational [Page 27] RFC 4890 ICMPv6 Filtering Recommendations May 2007
to generate Listener messages in order to establish communications and may generate all the messages if they also provide multicast routing services.
to generate Listener messages in order to establish communications and may generate all the messages if they also provide multicast routing services.
A.11. Multicast Router Discovery Messages
A.11. Multicast Router Discovery Messages
Multicast Router Discovery [RFC4286] (Router Advertisement, Router Solicitation, and Router Termination - Types 151, 152, and 153) messages are sent by nodes on the local link to discover multicast- capable routers on the link, and by multicast-capable routers to notify other nodes of their existence or change of state. Firewalls that also act as multicast routers need to process these messages on their interfaces.
Multicast Router Discovery [RFC4286] (Router Advertisement, Router Solicitation, and Router Termination - Types 151, 152, and 153) messages are sent by nodes on the local link to discover multicast- capable routers on the link, and by multicast-capable routers to notify other nodes of their existence or change of state. Firewalls that also act as multicast routers need to process these messages on their interfaces.
A.12. Router Renumbering Messages
A.12. Router Renumbering Messages
ICMPv6 Router Renumbering (Type 138) command messages can be received and results messages sent by routers to change the prefixes that they advertise as part of Stateless Address Configuration [RFC2461], [RFC2462]. These messages are sent end-to-end to either the all- routers multicast address (site or local scope) or specific unicast addresses from a unicast address.
ICMPv6 Router Renumbering (Type 138) command messages can be received and results messages sent by routers to change the prefixes that they advertise as part of Stateless Address Configuration [RFC2461], [RFC2462]. These messages are sent end-to-end to either the all- routers multicast address (site or local scope) or specific unicast addresses from a unicast address.
Router Renumbering messages are required to be protected by IPsec authentication since they could be readily misused by attackers to disrupt or divert site communications. Renumbering messages should generally be confined to sites for this reason.
Router Renumbering messages are required to be protected by IPsec authentication since they could be readily misused by attackers to disrupt or divert site communications. Renumbering messages should generally be confined to sites for this reason.
A.13. Node Information Query and Reply
A.13. Node Information Query and Reply
ICMPv6 Node Information Query and Reply (Type 139 and 140) messages defined in [RFC4620] are sent end-to-end between unicast addresses, and they can also be sent to link-local multicast addresses. They can, in theory, be sent from any node to any other, but it would generally not be desirable for nodes outside the local site to be able to send queries to nodes within the site. Also, these messages are not required to be authenticated.
ICMPv6 Node Information Query and Reply (Type 139 and 140) messages defined in [RFC4620] are sent end-to-end between unicast addresses, and they can also be sent to link-local multicast addresses. They can, in theory, be sent from any node to any other, but it would generally not be desirable for nodes outside the local site to be able to send queries to nodes within the site. Also, these messages are not required to be authenticated.
A.14. Mobile IPv6 Messages
A.14. Mobile IPv6 Messages
Mobile IPv6 [RFC3775] defines four ICMPv6 messages that are used to support mobile operations: Home Agent Address Discovery Request, Home Agent Address Discovery Reply, Mobile Prefix Solicitation, and ICMP Mobile Prefix Advertisement (Type 144, 145, 146, and 147) messages. These messages are sent end-to-end between unicast addresses of a mobile node and its home agent. They must be expected to be sent from outside a site and must traverse site-boundary firewalls to reach the home agent in order for Mobile IPv6 to function. The two
Mobile IPv6 [RFC3775] defines four ICMPv6 messages that are used to support mobile operations: Home Agent Address Discovery Request, Home Agent Address Discovery Reply, Mobile Prefix Solicitation, and ICMP Mobile Prefix Advertisement (Type 144, 145, 146, and 147) messages. These messages are sent end-to-end between unicast addresses of a mobile node and its home agent. They must be expected to be sent from outside a site and must traverse site-boundary firewalls to reach the home agent in order for Mobile IPv6 to function. The two
Davies & Mohacsi Informational [Page 28] RFC 4890 ICMPv6 Filtering Recommendations May 2007
Davies & Mohacsi Informational [Page 28] RFC 4890 ICMPv6 Filtering Recommendations May 2007
Mobile prefix messages should be protected by the use of IPsec authentication.
Mobile prefix messages should be protected by the use of IPsec authentication.
o If the site provides home agents for mobile nodes, the firewall
must allow incoming Home Agent Address Discovery Request and
Mobile Prefix Solicitation messages, and outgoing Home Agent
Address Discovery Reply and ICMP Mobile Prefix Advertisement
messages. It may be desirable to limit the destination addresses
for the incoming messages to links that are known to support home
agents.
o If the site provides home agents for mobile nodes, the firewall must allow incoming Home Agent Address Discovery Request and Mobile Prefix Solicitation messages, and outgoing Home Agent Address Discovery Reply and ICMP Mobile Prefix Advertisement messages. It may be desirable to limit the destination addresses for the incoming messages to links that are known to support home agents.
o If the site is prepared to host roaming mobile nodes, the firewall
must allow outgoing Home Agent Address Discovery Request and
Mobile Prefix Solicitation messages, and incoming Home Agent
Address Discovery Reply and ICMP Mobile Prefix Advertisement
messages.
o If the site is prepared to host roaming mobile nodes, the firewall must allow outgoing Home Agent Address Discovery Request and Mobile Prefix Solicitation messages, and incoming Home Agent Address Discovery Reply and ICMP Mobile Prefix Advertisement messages.
o Administrators may find it desirable to prevent static nodes that
are normally resident on the site from behaving as mobile nodes by
dropping Mobile IPv6 messages from these nodes.
o Administrators may find it desirable to prevent static nodes that are normally resident on the site from behaving as mobile nodes by dropping Mobile IPv6 messages from these nodes.
A.15. Unused and Experimental Messages
A.15. Unused and Experimental Messages
A large number of ICMPv6 Type values are currently unused. These values have not had a specific function registered with IANA. This section describes how to treat messages that attempt to use these Type values in a way of which the network administrator (and hence the firewall) is not aware.
A large number of ICMPv6 Type values are currently unused. These values have not had a specific function registered with IANA. This section describes how to treat messages that attempt to use these Type values in a way of which the network administrator (and hence the firewall) is not aware.
[RFC4443] defines a number of experimental Type values for ICMPv6 Error and Informational messages, which could be used in site- specific ways. These messages should be dropped by transit networks and at site edges. They should also not be propagated within sites unless the network administrator is explicitly made aware of usage.
[RFC4443] defines a number of experimental Type values for ICMPv6 Error and Informational messages, which could be used in site- specific ways. These messages should be dropped by transit networks and at site edges. They should also not be propagated within sites unless the network administrator is explicitly made aware of usage.
The codes reserved for future extension of the ICMPv6 Type space should currently be dropped as this functionality is as yet undefined.
The codes reserved for future extension of the ICMPv6 Type space should currently be dropped as this functionality is as yet undefined.
Any ICMPv6 Informational messages of which the firewall is not aware should be allowed to transit through the firewall but should not be accepted for local delivery on any of its interfaces.
Any ICMPv6 Informational messages of which the firewall is not aware should be allowed to transit through the firewall but should not be accepted for local delivery on any of its interfaces.
Unknown ICMPv6 Error messages should be allowed to pass through transit networks. At end site boundaries any incoming ICMPv6 Error messages of which the firewall is not aware may be allowed through the firewall in line with the specification in [RFC4443], which requests delivery of unknown error messages to higher-layer protocol
Unknown ICMPv6 Error messages should be allowed to pass through transit networks. At end site boundaries any incoming ICMPv6 Error messages of which the firewall is not aware may be allowed through the firewall in line with the specification in [RFC4443], which requests delivery of unknown error messages to higher-layer protocol
Davies & Mohacsi Informational [Page 29] RFC 4890 ICMPv6 Filtering Recommendations May 2007
Davies & Mohacsi Informational [Page 29] RFC 4890 ICMPv6 Filtering Recommendations May 2007
processes. However, administrators may wish to disallow forwarding of these incoming messages as a potential security risk. Unknown outgoing Error messages should be dropped as the administrator should be aware of all messages that could be generated on the site.
processes. However, administrators may wish to disallow forwarding of these incoming messages as a potential security risk. Unknown outgoing Error messages should be dropped as the administrator should be aware of all messages that could be generated on the site.
Also, the SEAMOBY working group has had an ICMPv6 message (Type 150) allocated for experimental use in two protocols. This message is sent end-to-end and may need to pass through firewalls on sites that are supporting the experimental protocols.
Also, the SEAMOBY working group has had an ICMPv6 message (Type 150) allocated for experimental use in two protocols. This message is sent end-to-end and may need to pass through firewalls on sites that are supporting the experimental protocols.
Appendix B. Example Script to Configure ICMPv6 Firewall Rules
Appendix B. Example Script to Configure ICMPv6 Firewall Rules
This appendix contains an example script to implement most of the rules suggested in this document when using the Netfilter packet filtering system for Linux [netfilter]. When used with IPv6, the 'ip6tables' command is used to configure packet filtering rules for the Netfilter system. The script is targeted at a simple enterprise site that may or may not support Mobile IPv6.
This appendix contains an example script to implement most of the rules suggested in this document when using the Netfilter packet filtering system for Linux [netfilter]. When used with IPv6, the 'ip6tables' command is used to configure packet filtering rules for the Netfilter system. The script is targeted at a simple enterprise site that may or may not support Mobile IPv6.
#!/bin/bash
# Set of prefixes on the trusted ("inner") side of the firewall
export INNER_PREFIXES="2001:DB8:85::/60"
# Set of hosts providing services so that they can be made pingable
export PINGABLE_HOSTS="2001:DB8:85::/64"
# Configuration option: Change this to 1 if errors allowed only for
# existing sessions
export STATE_ENABLED=0
# Configuration option: Change this to 1 if messages to/from link
# local addresses should be filtered.
# Do not use this if the firewall is a bridge.
# Optional for firewalls that are routers.
export FILTER_LINK_LOCAL_ADDRS=0
# Configuration option: Change this to 0 if the site does not support
# Mobile IPv6 Home Agents - see Appendix A.14
export HOME_AGENTS_PRESENT=1
# Configuration option: Change this to 0 if the site does not support
# Mobile IPv6 mobile nodes being present on the site -
# see Appendix A.14
export MOBILE_NODES_PRESENT=1
#!/bin/bash # Set of prefixes on the trusted ("inner") side of the firewall export INNER_PREFIXES="2001:DB8:85::/60" # Set of hosts providing services so that they can be made pingable export PINGABLE_HOSTS="2001:DB8:85::/64" # Configuration option: Change this to 1 if errors allowed only for # existing sessions export STATE_ENABLED=0 # Configuration option: Change this to 1 if messages to/from link # local addresses should be filtered. # Do not use this if the firewall is a bridge. # Optional for firewalls that are routers. export FILTER_LINK_LOCAL_ADDRS=0 # Configuration option: Change this to 0 if the site does not support # Mobile IPv6 Home Agents - see Appendix A.14 export HOME_AGENTS_PRESENT=1 # Configuration option: Change this to 0 if the site does not support # Mobile IPv6 mobile nodes being present on the site - # see Appendix A.14 export MOBILE_NODES_PRESENT=1
ip6tables -N icmpv6-filter ip6tables -A FORWARD -p icmpv6 -j icmpv6-filter
ip6tables -N icmpv6-filter ip6tables -A FORWARD -p icmpv6 -j icmpv6-filter
# Match scope of src and dest else deny # This capability is not provided for in base ip6tables functionality # An extension (agr) exists which may support it. #@TODO@
# Match scope of src and dest else deny # This capability is not provided for in base ip6tables functionality # An extension (agr) exists which may support it. #@TODO@
Davies & Mohacsi Informational [Page 30] RFC 4890 ICMPv6 Filtering Recommendations May 2007
Davies & Mohacsi Informational [Page 30] RFC 4890 ICMPv6 Filtering Recommendations May 2007
# ECHO REQUESTS AND RESPONSES # ===========================
# ECHO REQUESTS AND RESPONSES # ===========================
# Allow outbound echo requests from prefixes which belong to the site
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type echo-request -j ACCEPT
done
# Allow outbound echo requests from prefixes which belong to the site for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ --icmpv6-type echo-request -j ACCEPT done
# Allow inbound echo requests towards only predetermined hosts
for pingable_host in $PINGABLE_HOSTS
do
ip6tables -A icmpv6-filter -p icmpv6 -d $pingable_host \
--icmpv6-type echo-request -j ACCEPT
done
# Allow inbound echo requests towards only predetermined hosts for pingable_host in $PINGABLE_HOSTS do ip6tables -A icmpv6-filter -p icmpv6 -d $pingable_host \ --icmpv6-type echo-request -j ACCEPT done
if [ "$STATE_ENABLED" -eq "1" ]
then
# Allow incoming and outgoing echo reply messages
# only for existing sessions
ip6tables -A icmpv6-filter -m state -p icmpv6 \
--state ESTABLISHED,RELATED --icmpv6-type \
echo-reply -j ACCEPT
else
# Allow both incoming and outgoing echo replies
for pingable_host in $PINGABLE_HOSTS
do
# Outgoing echo replies from pingable hosts
ip6tables -A icmpv6-filter -p icmpv6 -s $pingable_host \
--icmpv6-type echo-reply -j ACCEPT
done
# Incoming echo replies to prefixes which belong to the site
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type echo-reply -j ACCEPT
done
fi
if [ "$STATE_ENABLED" -eq "1" ] then # Allow incoming and outgoing echo reply messages # only for existing sessions ip6tables -A icmpv6-filter -m state -p icmpv6 \ --state ESTABLISHED,RELATED --icmpv6-type \ echo-reply -j ACCEPT else # Allow both incoming and outgoing echo replies for pingable_host in $PINGABLE_HOSTS do # Outgoing echo replies from pingable hosts ip6tables -A icmpv6-filter -p icmpv6 -s $pingable_host \ --icmpv6-type echo-reply -j ACCEPT done # Incoming echo replies to prefixes which belong to the site for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ --icmpv6-type echo-reply -j ACCEPT done fi
# Deny icmps to/from link local addresses
# If the firewall is a router:
# These rules should be redundant as routers should not forward
# link local addresses but to be sure...
# DO NOT ENABLE these rules if the firewall is a bridge
if [ "$FILTER_LINK_LOCAL_ADDRS" -eq "1" ]
then
ip6tables -A icmpv6-filter -p icmpv6 -d fe80::/10 -j DROP
# Deny icmps to/from link local addresses # If the firewall is a router: # These rules should be redundant as routers should not forward # link local addresses but to be sure... # DO NOT ENABLE these rules if the firewall is a bridge if [ "$FILTER_LINK_LOCAL_ADDRS" -eq "1" ] then ip6tables -A icmpv6-filter -p icmpv6 -d fe80::/10 -j DROP
Davies & Mohacsi Informational [Page 31] RFC 4890 ICMPv6 Filtering Recommendations May 2007
Davies & Mohacsi Informational [Page 31] RFC 4890 ICMPv6 Filtering Recommendations May 2007
ip6tables -A icmpv6-filter -p icmpv6 -s fe80::/10 -j DROP
fi
ip6tables -A icmpv6-filter -p icmpv6 -s fe80::/10 -j DROP fi
# Drop echo replies which have a multicast address as a
# destination
ip6tables -A icmpv6-filter -p icmpv6 -d ff00::/8 \
--icmpv6-type echo-reply -j DROP
# Drop echo replies which have a multicast address as a # destination ip6tables -A icmpv6-filter -p icmpv6 -d ff00::/8 \ --icmpv6-type echo-reply -j DROP
# DESTINATION UNREACHABLE ERROR MESSAGES # ======================================
# DESTINATION UNREACHABLE ERROR MESSAGES # ======================================
if [ "$STATE_ENABLED" -eq "1" ]
then
# Allow incoming destination unreachable messages
# only for existing sessions
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -m state -p icmpv6 \
-d $inner_prefix \
--state ESTABLISHED,RELATED --icmpv6-type \
destination-unreachable -j ACCEPT
done
else
# Allow incoming destination unreachable messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type destination-unreachable -j ACCEPT
done
fi
if [ "$STATE_ENABLED" -eq "1" ] then # Allow incoming destination unreachable messages # only for existing sessions for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -m state -p icmpv6 \ -d $inner_prefix \ --state ESTABLISHED,RELATED --icmpv6-type \ destination-unreachable -j ACCEPT done else # Allow incoming destination unreachable messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ --icmpv6-type destination-unreachable -j ACCEPT done fi
# Allow outgoing destination unreachable messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type destination-unreachable -j ACCEPT
done
# Allow outgoing destination unreachable messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ --icmpv6-type destination-unreachable -j ACCEPT done
# PACKET TOO BIG ERROR MESSAGES # =============================
# PACKET TOO BIG ERROR MESSAGES # =============================
if [ "$STATE_ENABLED" -eq "1" ]
then
# Allow incoming Packet Too Big messages
# only for existing sessions
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -m state -p icmpv6 \
if [ "$STATE_ENABLED" -eq "1" ] then # Allow incoming Packet Too Big messages # only for existing sessions for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -m state -p icmpv6 \
Davies & Mohacsi Informational [Page 32] RFC 4890 ICMPv6 Filtering Recommendations May 2007
Davies & Mohacsi Informational [Page 32] RFC 4890 ICMPv6 Filtering Recommendations May 2007
-d $inner_prefix \
--state ESTABLISHED,RELATED \
--icmpv6-type packet-too-big \
-j ACCEPT
done
else
# Allow incoming Packet Too Big messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type packet-too-big -j ACCEPT
done
fi
-d $inner_prefix \ --state ESTABLISHED,RELATED \ --icmpv6-type packet-too-big \ -j ACCEPT done else # Allow incoming Packet Too Big messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ --icmpv6-type packet-too-big -j ACCEPT done fi
# Allow outgoing Packet Too Big messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type packet-too-big -j ACCEPT
done
# Allow outgoing Packet Too Big messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ --icmpv6-type packet-too-big -j ACCEPT done
# TIME EXCEEDED ERROR MESSAGES # ============================
# TIME EXCEEDED ERROR MESSAGES # ============================
if [ "$STATE_ENABLED" -eq "1" ]
then
# Allow incoming time exceeded code 0 messages
# only for existing sessions
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -m state -p icmpv6 \
-d $inner_prefix \
--state ESTABLISHED,RELATED --icmpv6-type packet-too-big \
-j ACCEPT
done
else
# Allow incoming time exceeded code 0 messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type ttl-zero-during-transit -j ACCEPT
done
fi
if [ "$STATE_ENABLED" -eq "1" ] then # Allow incoming time exceeded code 0 messages # only for existing sessions for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -m state -p icmpv6 \ -d $inner_prefix \ --state ESTABLISHED,RELATED --icmpv6-type packet-too-big \ -j ACCEPT done else # Allow incoming time exceeded code 0 messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ --icmpv6-type ttl-zero-during-transit -j ACCEPT done fi
#@POLICY@ # Allow incoming time exceeded code 1 messages for inner_prefix in $INNER_PREFIXES do
#@POLICY@ # Allow incoming time exceeded code 1 messages for inner_prefix in $INNER_PREFIXES do
Davies & Mohacsi Informational [Page 33] RFC 4890 ICMPv6 Filtering Recommendations May 2007
Davies & Mohacsi Informational [Page 33] RFC 4890 ICMPv6 Filtering Recommendations May 2007
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type ttl-zero-during-reassembly -j ACCEPT
done
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ --icmpv6-type ttl-zero-during-reassembly -j ACCEPT done
# Allow outgoing time exceeded code 0 messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type ttl-zero-during-transit -j ACCEPT
done
# Allow outgoing time exceeded code 0 messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ --icmpv6-type ttl-zero-during-transit -j ACCEPT done
#@POLICY@
# Allow outgoing time exceeded code 1 messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type ttl-zero-during-reassembly -j ACCEPT
done
#@POLICY@ # Allow outgoing time exceeded code 1 messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ --icmpv6-type ttl-zero-during-reassembly -j ACCEPT done
# PARAMETER PROBLEM ERROR MESSAGES # ================================
# PARAMETER PROBLEM ERROR MESSAGES # ================================
if [ "$STATE_ENABLED" -eq "1" ]
then
# Allow incoming parameter problem code 1 and 2 messages
# for an existing session
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -m state -p icmpv6 \
-d $inner_prefix \
--state ESTABLISHED,RELATED --icmpv6-type \
unknown-header-type \
-j ACCEPT
ip6tables -A icmpv6-filter -m state -p icmpv6 \
-d $inner_prefix \
--state ESTABLISHED,RELATED \
--icmpv6-type unknown-option \
-j ACCEPT
done
fi
if [ "$STATE_ENABLED" -eq "1" ] then # Allow incoming parameter problem code 1 and 2 messages # for an existing session for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -m state -p icmpv6 \ -d $inner_prefix \ --state ESTABLISHED,RELATED --icmpv6-type \ unknown-header-type \ -j ACCEPT ip6tables -A icmpv6-filter -m state -p icmpv6 \ -d $inner_prefix \ --state ESTABLISHED,RELATED \ --icmpv6-type unknown-option \ -j ACCEPT done fi
# Allow outgoing parameter problem code 1 and code 2 messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type unknown-header-type -j ACCEPT
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
# Allow outgoing parameter problem code 1 and code 2 messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ --icmpv6-type unknown-header-type -j ACCEPT ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
Davies & Mohacsi Informational [Page 34] RFC 4890 ICMPv6 Filtering Recommendations May 2007
Davies & Mohacsi Informational [Page 34] RFC 4890 ICMPv6 Filtering Recommendations May 2007
--icmpv6-type unknown-option -j ACCEPT
done
--icmpv6-type unknown-option -j ACCEPT done
#@POLICY@
# Allow incoming and outgoing parameter
# problem code 0 messages
for inner_prefix in $INNER_PREFIXES
do
ip6tables -A icmpv6-filter -p icmpv6 \
--icmpv6-type bad-header \
-j ACCEPT
done
#@POLICY@ # Allow incoming and outgoing parameter # problem code 0 messages for inner_prefix in $INNER_PREFIXES do ip6tables -A icmpv6-filter -p icmpv6 \ --icmpv6-type bad-header \ -j ACCEPT done
# NEIGHBOR DISCOVERY MESSAGES # ===========================
# NEIGHBOR DISCOVERY MESSAGES # ===========================
# Drop NS/NA messages both incoming and outgoing
ip6tables -A icmpv6-filter -p icmpv6 \
--icmpv6-type neighbor-solicitation -j DROP
ip6tables -A icmpv6-filter -p icmpv6 \
--icmpv6-type neighbor-advertisement -j DROP
# Drop NS/NA messages both incoming and outgoing ip6tables -A icmpv6-filter -p icmpv6 \ --icmpv6-type neighbor-solicitation -j DROP ip6tables -A icmpv6-filter -p icmpv6 \ --icmpv6-type neighbor-advertisement -j DROP
# Drop RS/RA messages both incoming and outgoing
ip6tables -A icmpv6-filter -p icmpv6 \
--icmpv6-type router-solicitation -j DROP
ip6tables -A icmpv6-filter -p icmpv6 \
--icmpv6-type router-advertisement -j DROP
# Drop RS/RA messages both incoming and outgoing ip6tables -A icmpv6-filter -p icmpv6 \ --icmpv6-type router-solicitation -j DROP ip6tables -A icmpv6-filter -p icmpv6 \ --icmpv6-type router-advertisement -j DROP
# Drop Redirect messages both incoming and outgoing ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type redirect -j DROP
# Drop Redirect messages both incoming and outgoing ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type redirect -j DROP
# MLD MESSAGES # ============
# MLD MESSAGES # ============
# Drop incoming and outgoing # Multicast Listener queries (MLDv1 and MLDv2) ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 130 -j DROP
# Drop incoming and outgoing # Multicast Listener queries (MLDv1 and MLDv2) ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 130 -j DROP
# Drop incoming and outgoing Multicast Listener reports (MLDv1) ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 131 -j DROP
# Drop incoming and outgoing Multicast Listener reports (MLDv1) ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 131 -j DROP
# Drop incoming and outgoing Multicast Listener Done messages (MLDv1) ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 132 -j DROP
# Drop incoming and outgoing Multicast Listener Done messages (MLDv1) ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 132 -j DROP
# Drop incoming and outgoing Multicast Listener reports (MLDv2) ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 143 -j DROP
# Drop incoming and outgoing Multicast Listener reports (MLDv2) ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 143 -j DROP
# ROUTER RENUMBERING MESSAGES
# ROUTER RENUMBERING MESSAGES
Davies & Mohacsi Informational [Page 35] RFC 4890 ICMPv6 Filtering Recommendations May 2007
Davies & Mohacsi Informational [Page 35] RFC 4890 ICMPv6 Filtering Recommendations May 2007
# ===========================
# ===========================
# Drop router renumbering messages ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 138 -j DROP
# Drop router renumbering messages ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 138 -j DROP
# NODE INFORMATION QUERIES # ========================
# NODE INFORMATION QUERIES # ========================
# Drop node information queries (139) and replies (140) ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 139 -j DROP ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 140 -j DROP
# Drop node information queries (139) and replies (140) ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 139 -j DROP ip6tables -A icmpv6-filter -p icmpv6 --icmpv6-type 140 -j DROP
# MOBILE IPv6 MESSAGES # ====================
# MOBILE IPv6 MESSAGES # ====================
# If there are mobile ipv6 home agents present on the
# trusted side allow
if [ "$HOME_AGENTS_PRESENT" -eq "1" ]
then
for inner_prefix in $INNER_PREFIXES
do
#incoming Home Agent address discovery request
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type 144 -j ACCEPT
#outgoing Home Agent address discovery reply
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type 145 -j ACCEPT
#incoming Mobile prefix solicitation
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type 146 -j ACCEPT
#outgoing Mobile prefix advertisement
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type 147 -j ACCEPT
done
fi
# If there are mobile ipv6 home agents present on the # trusted side allow if [ "$HOME_AGENTS_PRESENT" -eq "1" ] then for inner_prefix in $INNER_PREFIXES do #incoming Home Agent address discovery request ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ --icmpv6-type 144 -j ACCEPT #outgoing Home Agent address discovery reply ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ --icmpv6-type 145 -j ACCEPT #incoming Mobile prefix solicitation ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ --icmpv6-type 146 -j ACCEPT #outgoing Mobile prefix advertisement ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ --icmpv6-type 147 -j ACCEPT done fi
# If there are roaming mobile nodes present on the
# trusted side allow
if [ "$MOBILE_NODES_PRESENT" -eq "1" ]
then
for inner_prefix in $INNER_PREFIXES
do
#outgoing Home Agent address discovery request
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type 144 -j ACCEPT
#incoming Home Agent address discovery reply
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
# If there are roaming mobile nodes present on the # trusted side allow if [ "$MOBILE_NODES_PRESENT" -eq "1" ] then for inner_prefix in $INNER_PREFIXES do #outgoing Home Agent address discovery request ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ --icmpv6-type 144 -j ACCEPT #incoming Home Agent address discovery reply ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
Davies & Mohacsi Informational [Page 36] RFC 4890 ICMPv6 Filtering Recommendations May 2007
Davies & Mohacsi Informational [Page 36] RFC 4890 ICMPv6 Filtering Recommendations May 2007
--icmpv6-type 145 -j ACCEPT
#outgoing Mobile prefix solicitation
ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
--icmpv6-type 146 -j ACCEPT
#incoming Mobile prefix advertisement
ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \
--icmpv6-type 147 -j ACCEPT
done
fi
--icmpv6-type 145 -j ACCEPT #outgoing Mobile prefix solicitation ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \ --icmpv6-type 146 -j ACCEPT #incoming Mobile prefix advertisement ip6tables -A icmpv6-filter -p icmpv6 -d $inner_prefix \ --icmpv6-type 147 -j ACCEPT done fi
# DROP EVERYTHING ELSE # ====================
# DROP EVERYTHING ELSE # ====================
ip6tables -A icmpv6-filter -p icmpv6 -j DROP
ip6tables -A icmpv6-filter -p icmpv6 -j DROP
Example Netfilter Configuration Script for ICMPv6 Filtering
Example Netfilter Configuration Script for ICMPv6 Filtering
Authors' Addresses
Authors' Addresses
Elwyn B. Davies Consultant Soham, Cambs UK
Elwyn B. Davies Consultant Soham, Cambs UK
Phone: +44 7889 488 335 EMail: elwynd@dial.pipex.com
Phone: +44 7889 488 335 EMail: elwynd@dial.pipex.com
Janos Mohacsi NIIF/HUNGARNET Victor Hugo u. 18-22 Budapest, H-1132 Hungary
Janos Mohacsi NIIF/HUNGARNET Victor Hugo u. 18-22 Budapest, H-1132 Hungary
Phone: +36 1 4503070 EMail: mohacsi@niif.hu
Phone: +36 1 4503070 EMail: mohacsi@niif.hu
Davies & Mohacsi Informational [Page 37] RFC 4890 ICMPv6 Filtering Recommendations May 2007
Davies & Mohacsi Informational [Page 37] RFC 4890 ICMPv6 Filtering Recommendations May 2007
Full Copyright Statement
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Davies & Mohacsi Informational [Page 38]
Davies & Mohacsi Informational [Page 38]
一覧
スポンサーリンク
