[要約] RFC 6018は、IPv4およびIPv6のグレイネットに関するガイドラインです。その目的は、グレイネットのセキュリティリスクを理解し、適切な対策を講じるための指針を提供することです。
Internet Engineering Task Force (IETF) F. Baker
Request for Comments: 6018 Cisco Systems
Category: Informational W. Harrop
ISSN: 2070-1721 G. Armitage
Swinburne University of Technology
September 2010
IPv4 and IPv6 Greynets
IPv4およびIPv6 Greynets
Abstract
概要
This note discusses a feature to support building Greynets for IPv4 and IPv6.
このメモでは、IPv4とIPv6の構築グレイネットをサポートする機能について説明します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6018.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6018で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. History and Experience . . . . . . . . . . . . . . . . . . 3
2. Deploying Greynets . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Deployment Using Routing - Darknets . . . . . . . . . . . . 4
2.2. Deployment Using Sparse Address Space - Greynets . . . . . 4
2.3. Other Filters . . . . . . . . . . . . . . . . . . . . . . . 6
3. Implications for Router Design . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 8
Darknets, also called "Network Telescopes" among other things, have been deployed by several organizations (including CAIDA, Team Cymru, and the University of Michigan) to look at traffic directed to addresses in blocks that are not in actual use. Such traffic becomes visible by either direct capture (it is routed to a collector) or by virtue of its backscatter (its resulting in ICMP traffic or transport-layer resets).
とりわけ「ネットワーク望遠鏡」とも呼ばれるダークネットは、実際に使用されていないブロックのアドレスに向けられたトラフィックを調べるために、いくつかの組織（Caida、Team Cymru、Michigan大学を含む）によって展開されています。このようなトラフィックは、直接キャプチャ（コレクターにルーティングされる）または後方散乱（ICMPトラフィックまたは輸送層リセットをもたらす）によって表示されます。
Darknets, of course, have two problems. As their address spaces become known, attackers stop probing them, so they are less effective. Also, the administrators of those prefixes are pressured by Regional Internet Registry (RIR) policy and business requirements to deploy them in active networks.
もちろん、ダークネットには2つの問題があります。アドレススペースが知られるようになると、攻撃者はそれらを調査するのをやめているため、効果が低下します。また、これらのプレフィックスの管理者は、地域のインターネットレジストリ（RIR）ポリシーとビジネス要件によってプレッシャーをかけて、それらをアクティブなネットワークに展開します。
[Harrop] defines a 'Greynet' by extension, in these words:
[Harrop]は、これらの言葉で「greynet」を拡張して定義します。
Darknets are often proposed to monitor for anomalous, externally sourced traffic, and require large, contiguous blocks of unused IP addresses - not always feasible for enterprise network operators. We introduce and evaluate the Greynet - a region of IP address space that is sparsely populated with "darknet" addresses interspersed with active (or "lit") IP addresses. Based on a small sample of traffic collected within a university campus network we saw that relatively sparse greynets can achieve useful levels of network scan detection.
ダークネットは、異常な外部から調達されたトラフィックを監視するためにしばしば提案されており、未使用のIPアドレスの大規模で隣接するブロックが必要です。「Darknet」アドレスが散在するActive（または "lit"）IPアドレスが散在するIPアドレススペースの領域であるGreynetを紹介して評価します。大学のキャンパスネットワーク内で収集されたトラフィックの小さなサンプルに基づいて、比較的まばらなグレイネットが有用なレベルのネットワークスキャン検出を実現できることがわかりました。
In other words, instead of setting aside prefixes that an attacker might attempt to probe and in so doing court discovery, Harrop proposed that individual (or small groups of adjacent) addresses in subnets be set aside for the purpose, using different host identifiers in each subnet to make it more difficult for an address scan to detect them. The concept has value in the sense that it is harder to map the addresses or prefixes out of an attacker's search pattern, as their presence is more obscure. Harrop's research was carried out using IPv4 [RFC0791] and yielded interesting information.
言い換えれば、攻撃者が調査を試みる可能性のあるプレフィックスを脇に置き、裁判所の発見を行う際に、Harropは、それぞれの異なるホスト識別子を使用して、サブネット内の個々の（または隣接する小さなグループ）アドレスを目的のために取っておくことを提案しました。アドレススキャンがそれらを検出することをより困難にするサブネット。この概念は、攻撃者の検索パターンからアドレスまたは接頭辞をマッピングすることが困難であるという意味で価値があります。Harropの研究はIPv4 [RFC0791]を使用して実施され、興味深い情報が得られました。
The research supporting this proposal includes two prototypes, one with IPv4 [RFC0791] and one with IPv6 [RFC2460]. Both have limitations, being research experiments as opposed to deployment of a finished product.
この提案をサポートする研究には、IPv4 [RFC0791]とIPv6 [RFC2460]の2つのプロトタイプが含まれています。どちらにも制限があり、完成品の展開とは対照的に研究実験です。
The original research was done by Warren Harrop and documented in [Harrop]. This was IPv4-only. His premise was that one would put a virtual or physical machine on a LAN that one was not otherwise using, and use it to identify scans of various kinds. As reported in his paper, the concept worked effectively in a prototype deployment at the Centre for Advanced Internet Architectures (CAIA), Swinburne University of Technology. The basic reason was that there was a reasonable expectation on the part of a potential attacker that a given address might be represented, and there was no pattern that would enable the attacker to predict which addresses were being used in this way. CAIA developed and released a prototype FreeBSD-based Greynet system in 2008 built around this premise [Armitage].
元の研究はウォーレン・ハロップによって行われ、[Harrop]で文書化されました。これはIPv4のみでした。彼の前提は、それ以外の場合は使用していないLANに仮想または物理マシンを置き、それを使用してさまざまな種類のスキャンを特定するということでした。彼の論文で報告されているように、このコンセプトは、スウィンバーン工科大学の高度なインターネットアーキテクチャセンター（CAIA）でのプロトタイプの展開で効果的に機能しました。基本的な理由は、潜在的な攻撃者の側面に特定のアドレスが表される可能性があるという合理的な期待があり、攻撃者がこの方法で使用されているアドレスを予測できるようにするパターンはなかったことでした。CAIAは、2008年にプロトタイプFreeBSDベースのGreyNetシステムを開発およびリリースし、この前提を中心に構築されました[Armitage]。
Baker's addition to his concept started from the router, the idea that the router would be highly likely to encounter any such scan if it came from off-LAN, and the fact that the router would have to use Address Resolution Protocol (ARP) or Neighbor Discovery (ND) to identify -- or fail to identify -- the machine in question. In effect, any address that is not currently instantiated in the subnet acts as a Greynet trigger address. This clearly also works for any system that would implement ARP or ND, but the router is an obvious focal point in any subnet.
彼のコンセプトへのベイカーの追加はルーターから始まりました。ルーターがオフラーンから来た場合、ルーターがそのようなスキャンに遭遇する可能性が高いという考え、およびルーターがアドレス解像度プロトコル（ARP）または隣接する必要があるという事実問題のマシンを識別または識別しない、または識別できないディスカバリー（ND）。実際、サブネットに現在インスタンス化されていないアドレスは、グレイネットトリガーアドレスとして機能します。これは、ARPまたはNDを実装する任意のシステムでも明らかに機能しますが、ルーターはあらゆるサブネットの明らかな焦点です。
Tim Chown, of the School of Electronics and Computer Science, University of Southampton, offered privately to do some research on it, and had Owen Stephens do a Linux prototype in spring 2010. They demonstrated that the technology was straightforward to implement and in fact worked in a prototype IPv6 implementation.
サウサンプトン大学のエレクトロニクスアンドコンピューターサイエンススクールのTim Chownは、それについていくつかの調査を行うために個人的に申し出て、Owen Stephensに2010年春にLinuxプロトタイプを作成しました。プロトタイプIPv6実装。
The question that remains with IPv6 address scanning is the likelihood that the attack would occur at all. Chown originally argued in [RFC5157] that address scans were impossible due to the sheer number of possibilities. However, in September 2010 a report was made to NANOG of an IPv6 address scan. Additionally, there are ways to limit the field; for example, one can observe that a company buys a certain kind of machine or network interface card (NIC), and therefore its probable EUI-64 addresses are limited to a much smaller range than 2^64 -- more like 2^24 addresses on a given subnet -- or one can observe DNS, SMTP envelopes, Extensible Messaging and Presence Protocol (XMPP) messages, FTP, HTTP, etc., that carry IP addresses in other ways. Such attacks can be limited by the use of Privacy Addresses [RFC4941], which periodically change, rendering historical information less useful, but the fact is that such analytic methods exist.
IPv6アドレススキャンに残る問題は、攻撃がまったく発生する可能性があることです。元々は[RFC5157]で主張されていましたが、膨大な数の可能性があるため、スキャンに対処することは不可能であると述べています。ただし、2010年9月には、IPv6アドレススキャンのNanogに関するレポートが作成されました。さらに、フィールドを制限する方法があります。たとえば、企業が特定の種類のマシンまたはネットワークインターフェイスカード（NIC）を購入することを観察できます。したがって、その可能性のあるEUI-64アドレスは2^64よりもはるかに小さな範囲に制限されています。特定のサブネットでは、DNS、SMTPエンベロープ、拡張可能なメッセージングおよびプレゼンスプロトコル（XMPP）メッセージ、FTP、HTTPなどを観察できます。このような攻撃は、定期的に変化するプライバシーアドレス[RFC4941]の使用によって制限される可能性があり、履歴情報の有用性が低くなりますが、そのような分析方法が存在することです。
Corporate IT departments and other network operators frequently run collectors or other kinds of sensors. A collector is a computer system on the Internet that is expressly set up to attract and "trap" nefarious attempts to penetrate computer systems. Such systems may simply record the attempt or the datagram that initiated the attempt (darknets/Greynets), or they may act as a decoy, luring in potential attacks in order to study their activities and study their methods (honeypots).
企業のIT部門やその他のネットワークオペレーターは、頻繁にコレクターまたは他の種類のセンサーを運営しています。コレクターは、インターネット上のコンピューターシステムであり、コンピューターシステムに浸透しようとする不気味な試みを引き付けて「トラップ」するために明示的に設定されています。そのようなシステムは、試みを開始した試みまたはデータグラム（ダークネット/グレイネット）を単に記録するか、デコイとして機能し、活動を研究し、方法（ハニーポット）を研究するために潜在的な攻撃に誘惑する場合があります。
To accomplish this, we separate nefarious traffic from that which is likely normal and important, studying one and facilitating the other.
これを達成するために、私たちは否定的なトラフィックを正常で重要なものから分離し、一方を研究し、もう一方を促進します。
One obvious way to isolate and identify nefarious traffic is to realize that it is sent to a prefix or address that is not instantiated. If a campus uses an IPv4 /24 prefix or an IPv6 /56 prefix but contains less than 100 actual subnets, for example, we might use only odd numbered subnets (128 of the 256 available in that prefix), and not quite all of those. Knowing that the active prefixes are more specific and therefore attract appropriate traffic, we might also advertise the default prefix from the collector, attracting traffic directed to the uninstantiated prefixes in that routing domain.
悪意のあるトラフィックを分離して特定する1つの明白な方法は、インスタンス化されていない接頭辞またはアドレスに送信されていることを認識することです。キャンパスがIPv4 /24プレフィックスまたはIPv6 /56プレフィックスを使用しているが、100未満の実際のサブネットを含む場合、たとえば、奇数番号のサブネットのみを使用できます（そのプレフィックスで利用可能な256のうち128）。。アクティブな接頭辞がより具体的であり、したがって適切なトラフィックを引き付けることを知っているため、コレクターからデフォルトのプレフィックスを宣伝し、そのルーティングドメイン内のインチンス状のプレフィックスに向けられたトラフィックを引き付けることもできます。
A second question involves mimicking a host under attack; the collector may simply record this uninvited traffic, or may reply as a honeypot system.
2番目の質問には、攻撃を受けているホストを模倣することが含まれます。コレクターは、この招待されていないトラフィックを単に記録するか、ハニーポットシステムとして返信する場合があります。
IPv4 subnets usually have some unallocated space in them, if only because Classless Inter-Domain Routing (CIDR) allocates O(2^n) addresses to an IP subnet and there are not exactly that many systems there.
IPv4サブネットには、通常、クラスレスインタードメインルーティング（CIDR）がO（2^n）アドレスをIPサブネットに割り当てるという理由だけで、いくつかの未割り当てスペースがあります。
Similarly, with active IPv6 prefixes, even a very large switched LAN is likely to use a small fraction of the available addresses. This is by design, as discussed in Section 2.5.1 of [RFC4291]. If the addresses are distributed reasonably randomly among the possible values, the likelihood of an attacker guessing what addresses are in actual use is limited. This gives us an opportunity with respect to unused addresses within an IP prefix.
同様に、アクティブなIPv6プレフィックスを使用すると、非常に大きな切り替えLANでさえ、利用可能なアドレスのごく一部を使用する可能性があります。これは、[RFC4291]のセクション2.5.1で説明されているように、設計によるものです。アドレスが可能な値の間に合理的にランダムに分散されている場合、攻撃者が実際に使用するアドレスが制限されていると推測する可能性が限られています。これにより、IPプレフィックス内の未使用のアドレスに関する機会が与えられます。
Routers use IPv4 ARP [RFC0826] and IPv6 Neighbor Discovery [RFC4861] to determine the MAC (Media Access Control) address of a neighbor to which a datagram needs to be sent. Both specifications intend that when a datagram arrives at a router that serves the target prefix, but that doesn't know the MAC address of the intended destination, it should:
ルーターは、IPv4 ARP [RFC0826]およびIPv6 Neighbor Discovery [RFC4861]を使用して、データグラムを送信する必要がある隣接のMAC（メディアアクセス制御）アドレスを決定します。どちらの仕様も、データグラムがターゲットプレフィックスを提供するルーターに到着したときに、意図した宛先のMACアドレスがわからないことを意図しています。
o Enqueue the datagram,
o データグラムをenqueue、
o Emit a Neighbor Solicitation or ARP Request,
o 隣人の勧誘またはARPリクエストを放出し、
o Await a Neighbor Advertisement or ARP Response, and
o 隣人の広告またはARP応答を待っています
o On receipt, dequeue and forward the datagram.
o 受領して、dequeueとデータグラムを転送します。
Once the host's MAC address is in the router's tables (and in so doing the address proven valid), the matter is not an issue.
ホストのMACアドレスがルーターのテーブルにあると（そして、アドレスが有効であることが証明されている場合）、問題は問題ではありません。
In [Harrop], the Greynet is described as being instantiated on an end-host that replies to ARP Requests for all 'dark' IP addresses. However, a small modification to router behavior can augment this model. As well as queuing or dropping a datagram that has triggered an ARP Request or Neighbor Solicitation, the router forwards a copy of this datagram over an independent link to the Greynet's analytic equipment. This independent link may be a different physical interface, a circuit, VLAN, tunnel, UDP, or other encapsulation, or in fact any place such a datagram could be handled. Depending on the requirements of the receiving collector, one could also imagine summarizing information in a form similar to IP Flow Information Export (IPFIX) [RFC5101] [RFC5610].
[Harrop]では、Greynetは、すべての「暗い」IPアドレスのARP要求に応答するエンドホストにインスタンス化されていると説明されています。ただし、ルーターの動作に対するわずかな変更により、このモデルが増強される可能性があります。ARPリクエストまたはネイバーの勧誘をトリガーしたデータグラムをキューイングまたはドロップするだけでなく、ルーターはこのデータグラムのコピーをGreyNetの分析機器への独立したリンク上に転送します。この独立したリンクは、異なる物理インターフェイス、回路、VLAN、トンネル、UDP、またはその他のカプセル化、または実際にそのようなデータグラムを処理できる場所です。受信コレクターの要件に応じて、IPフロー情報エクスポート（IPFIX）[RFC5101] [RFC5610]に似た形式で情報を要約することも想像できます。
The analytic equipment will now receive two types of datagrams. Of most interest will be those destined for 'dark' IP addresses. Of less interest will be the irregular case where a datagram arrives for a legitimate local neighbor who has, for some temporary reason, no MAC address in the router's tables. Datagrams arriving for an IP destination for which an ARP reply (or Neighbor Advertisement) has not yet received might also be forwarded to the analytical equipment over the independent link -- or might not, if they are considered to be unlikely to provide new analytic information.
分析機器には、2種類のデータグラムが受信されます。最も興味深いのは、「暗い」IPアドレスに運命づけられているものです。関心が少ないのは、一時的な理由で、ルーターのテーブルにMACアドレスがない正当な地元の隣人のためにデータグラムが到着する不規則なケースです。ARPの返信（または近隣広告）がまだ受信していないIP宛先に到着するデータグラムは、独立したリンク上に分析機器に転送される可能性があります。。
Analytic equipment, depending on the router to recognize 'dark' IP addresses in this manner, can easily track arrival patterns of datagrams destined to unused parts of the network. It may also optionally choose to respond to such datagrams, acting as a honeypot to elicit further datagrams from the remote source.
分析機器は、この方法で「暗い」IPアドレスを認識するルーターに応じて、ネットワークの未使用の部分に運命づけられたデータグラムの到着パターンを簡単に追跡できます。また、オプションでそのようなデータグラムに応答することを選択し、リモートソースからさらにデータグラムを引き出すためのハニーポットとして機能します。
If the collector replies directly, the attacker may be able to identify the fact through information in or about the datagram - datagrams sent to the same IP subnet may come back with different TTL values, for example. Hence, it may be advisable for the collector to send the reply back through the tunnel and therefore as if from the same IP subnet. Naturally, the collector in this scenario should not respond to datagrams destined for 'lit' IP addresses -- the intended destination will eventually respond to the router's ARP or Neighbor Solicitation anyway.
コレクターが直接返信すると、攻撃者はデータグラムに関する情報またはデータグラムに関する情報を介して事実を識別できる場合があります。たとえば、同じIPサブネットに送信されたデータグラムが異なるTTL値で戻ってくる場合があります。したがって、コレクターがトンネルから返信を送り返すことをお勧めします。したがって、同じIPサブネットからのように。当然のことながら、このシナリオのコレクターは、「LIT」IPアドレス用に運命づけられたデータグラムに応答してはなりません。意図した宛先は、最終的にルーターのARPまたは隣人の勧誘に応答します。
One implication of this model is that distributed denial-of-service (DDoS) attacks terminate on router subnets within a network, as opposed to stopping on inter-router links.
このモデルの意味の1つは、分散型拒否（DDOS）攻撃が、ルーター間リンクで停止するのではなく、ネットワーク内のルーターサブネットで終了することです。
An obvious extension of the concept would include traffic identified by other filters as appropriate to send to the collector. For example, one might configure the system to forward traffic that fail a unicast Reverse Path Forwarding (uRPF) check [RFC2827] to the collector via the same tunnel.
概念の明らかな拡張には、コレクターに送信するために必要に応じて他のフィルターによって識別されるトラフィックが含まれます。たとえば、同じトンネルを介してコレクターにユニキャストリバースパス転送（urpf）をチェックする（urpf）故障したトラフィックを転送するシステムを構成する場合があります。
The implication for router design applies to the IPv4 ARP and IPv6 Neighbor Discovery algorithms. It might be interesting to provide, under configuration control, the ability to forward to an analytic system the arriving datagrams that trigger an ARP Request or Neighbor Solicit, and then fail to receive the intended response, to an interface, circuit, VLAN, or tunnel.
ルーター設計の意味は、IPv4 ARPおよびIPv6 Neighbor Discoveryアルゴリズムに適用されます。構成制御下で、ARPリクエストまたは隣人の勧誘をトリガーする到着したデータグラムを分析システムに転送する機能を提供することは興味深いかもしれません。。
This note describes a tool for managing IPv4 and IPv6 network security. Like any tool, it has limitations and possible attacks. If discarding traffic under overload is a good thing, then holding and subsequently forwarding the traffic instead places a potential load on the network and the router in question, and as such represents a possible attack. Such an attack has obvious mitigations, however; one simply selects (in a manner the operator deems appropriate) a subset of the traffic to forward and discards the rest. In addition, this attack is not new; it is only changed in character. A stream that would instantiate the attack today results in a load of ARP or Neighbor Solicit messages that all listening hosts must intelligently discard. The new attack additionally consumes bandwidth that is presumably set aside specifically for that purpose.
このメモは、IPv4およびIPv6ネットワークセキュリティを管理するためのツールについて説明しています。他のツールと同様に、制限と可能な攻撃があります。過負荷の下でトラフィックを廃棄することが良いことである場合、その後、トラフィックを保持して転送する代わりに、問題のネットワークとルーターに潜在的な負荷をかけるため、攻撃の可能性を表します。ただし、このような攻撃には明らかな緩和があります。単に（オペレーターが適切と見なす方法で）トラフィックのサブセットを選択して、残りを転送して廃棄するだけです。さらに、この攻撃は新しいものではありません。キャラクターのみが変更されます。今日の攻撃をインスタンス化するストリームは、すべてのリスニングホストがインテリジェントに破棄する必要があるARPまたは隣人の勧誘を大量に募集します。新しい攻撃はさらに、おそらくその目的のために特別に確保されている帯域幅を消費します。
The question of exactly what subset of traffic is interesting and economical to forward is intentionally left open. Key questions in algorithm design include what can be learned from a given sample (Are bursts happening? If so, with what data?), what the impact on the router and other equipment in question is, how that might be mitigated, etc. Possible selection algorithms dependent only on state and algorithms typically available in a router include:
トラフィックのサブセットがどのようなものであるかという問題は、意図的に開いたままにされています。アルゴリズムの設計の重要な質問には、特定のサンプルから学ぶことができること（バーストが発生しているのか？もしそうなら、どのデータで？）、問題のルーターや他の機器への影響は何ですか、それがどのように緩和される可能性があるかなどが含まれます。通常、ルーターで利用可能な状態およびアルゴリズムにのみ依存する選択アルゴリズムは次のとおりです。
o Select all datagrams that trigger an ARP Request or Neighbor Solicit.
o ARPリクエストをトリガーするすべてのデータグラムまたは隣人の勧誘を選択します。
o Select the subset of those that are not responded to within some stated interval and are therefore likely dark.
o 一部の指定された間隔内で応答されていないため、暗くなる可能性が高いサブセットのサブセットを選択します。
o Select the subset of those that are new; if the address is currently being solicited, forwarding redundant data may not be useful.
o 新しいもののサブセットを選択します。アドレスが現在勧誘されている場合、冗長データを転送することは役に立たないかもしれません。
o Select all datagrams up to some rate.
o すべてのデータグラムをある程度のレートまで選択します。
o Select all datagrams matching (or not matching) a specified filter rule.
o 指定されたフィルタールールを一致させる（または一致しない）すべてのデータグラムを選択します。
Algorithms for learning about Internet attack behavior by observing backscatter traffic have been used by CAIDA, University of Michigan, Team Cymru, and others. Harrop extended them in his research. This formulation of the notion originated in a discussion among the authors in 2005. This note grew out of a conversation with Paul Vixie and Rhette Marsh on Internet traffic sensors; they also made useful comments on it. Albert Manfredi commented on the distinction between a LAN (as defined by IEEE 802) and an IP subnet.
後方散乱トラフィックを観察することにより、インターネット攻撃行動について学習するためのアルゴリズムは、Caida、ミシガン大学、チームCymruなどによって使用されています。Harropは彼の研究で彼らを拡張しました。この概念の定式化は、2005年の著者の間での議論で生まれました。このメモは、インターネットトラフィックセンサーに関するPaul VixieやRhette Marshとの会話から生まれました。彼らはまた、それについて有用なコメントをしました。Albert Manfrediは、LAN（IEEE 802で定義されている）とIPサブネットの区別についてコメントしました。
Tim Chown [RFC5157] has observed that, at least at the time of writing that RFC, address scanning attacks in IPv6 have not been reported in the wild. However, as mentioned in Section 1.1 above, a (partial) scanning attack was recently reported on the NANOG mailing list. Rhette Marsh has suggested the structure of such an attack, however, and Fred Baker has suggested approaches based on addressing information exchanged by applications. Hence, we believe that such issues may be relevant to IPv6 in the future, when IPv6 is a more interesting target.
Tim Chown [RFC5157]は、少なくとも執筆時点では、RFCがIPv6での走査攻撃に対処していることが野生で報告されていないことを観察しています。ただし、上記のセクション1.1で述べたように、（部分的な）スキャン攻撃が最近NANOGメーリングリストで報告されました。しかし、Rhette Marshはそのような攻撃の構造を提案しており、Fred Bakerはアプリケーションによって交換された情報への対処に基づいてアプローチを提案しました。したがって、IPv6がより興味深いターゲットである場合、そのような問題は将来IPv6に関連する可能性があると考えています。
Tim Chown and Owen Stephens tested the proposal, and made useful comments that have been incorporated in this text. His fundamental comment was, however, that "it works".
Tim ChownとOwen Stephensは提案をテストし、このテキストに組み込まれている有用なコメントをしました。しかし、彼の基本的なコメントは、「それが機能する」ということでした。
[Harrop] Harrop, W. and G. Armitage, "Greynets: a definition and evaluation of sparsely populated darknets", IEEE LCN IEEE 30th Conference on Local Computer Networks, 2005.
[Harrop] Harrop、W。and G. Armitage、「Greynets：A Sparsely Fopulectulet Darknetsの定義と評価」、IEEE LCN IEEEローカルコンピューターネットワークに関する第30回会議、2005年。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[RFC0826] Plummer、D。、「イーサネットアドレス解像度プロトコル：または、ネットワークプロトコルアドレスをイーサネットハードウェア上の送信用のビットイーサネットアドレスに変換する」、STD 37、RFC 826、1982年11月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「Internet Protocol、Version 6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 4941、2007年9月。
[Armitage] Armitage, G., Harrop, W., Heyde, A., Parry, L., "Greynets: Passive Detection of Unsolicited Network Scans in Small ISP and Enterprise networks", CAIA, Swinburne University of Technology, December 2008, http://caia.swin.edu.au/greynets/.
[Armitage] Armitage、G.、Harrop、W.、Heyde、A.、Parry、L。、「Greynets：小規模ISPおよびエンタープライズネットワークでの未承諾ネットワークスキャンの受動的検出」、Caia、Swinburne University of Technology、2008年12月、http://caia.swin.edu.au/greynets/。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、BCP 38、RFC 2827、2000年5月。
[RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101] Claise、B。、「IPトラフィックフロー情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、RFC 5101、2008年1月。
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC 5157, March 2008.
[RFC5157] Chown、T。、「ネットワークスキャンに対するIPv6の影響」、RFC 5157、2008年3月。
[RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, "Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements", RFC 5610, July 2009.
[RFC5610] Boschi、E.、Trammell、B.、Mark、L。、およびT. Zseby、「IPフロー情報エクスポート（IPFIX）情報要素のタイプ情報のエクスポート」、RFC 5610、2009年7月。
Authors' Addresses
著者のアドレス
Fred Baker Cisco Systems Santa Barbara, California 93117 USA
フレッドベイカーシスコシステムサンタバーバラ、カリフォルニア93117 USA
EMail: fred@cisco.com
Warren Harrop Centre for Advanced Internet Architectures Swinburne University of Technology PO Box 218 John Street, Hawthorn, Victoria, 3122 Australia
ウォーレン・ハロップ・センター・フォー・アドバンスド・インターネット・アーキテクチャ・スウィンバーン・ユニバーシティ・オブ・テクノロジー・ポックス218ジョン・ストリート、ホーソーン、ビクトリア、3122オーストラリア
EMail: wazz@bud.cc.swin.edu.au
Grenville Armitage Centre for Advanced Internet Architectures Swinburne University of Technology PO Box 218 John Street, Hawthorn, Victoria, 3122 Australia
グレンビルアーミテージセンター高度なインターネットアーキテクチャスウィンバーン大学工科大学PO Box 218ジョンストリート、ホーソーン、ビクトリア、3122オーストラリア
EMail: garmitage@swin.edu.au