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
Abstract
抽象
This note discusses a feature to support building Greynets for IPv4 and IPv6.
このノートでは、IPv4とIPv6のためGreynetsの構築をサポートするための機能について説明します。
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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).
また、他のものの間で、「ネットワーク望遠鏡」と呼ばれるDarknetsは、実際に使用されていないブロック内のアドレスへのトラフィックを見て（CAIDA、チームCymru、およびミシガン大学を含む）いくつかの組織によって展開されています。そのようなトラフィックは、直接捕捉（これはコレクタにルーティングされる）またはその後方散乱のおかげで（その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.
Darknetsは、当然のことながら、2つの問題があります。知られるようになり、そのアドレス空間として、攻撃者はそれらをプロービングを停止するので、彼らはあまり効果的です。また、これらの接頭辞の管理者は、アクティブなネットワークでそれらを展開する地域インターネットレジストリ（RIR）政策とビジネス要件によって圧迫されています。
[Harrop] defines a 'Greynet' by extension, in these words:
【ハロップは、これらの言葉で、拡張によって「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.
Darknetsはしばしば異常、外部から供給トラフィックを監視することを提案し、未使用のIPアドレスの大規模な、連続ブロックを必要としている - 企業のネットワーク事業者にとって常に実行可能ではありません。私たちは、導入しGreynet評価 - まばらアクティブ（または「点灯」）IPアドレスが点在する「ダークネット」のアドレスが移入されたIPアドレス空間の領域を。大学のキャンパスネットワーク内で収集トラフィックの小さなサンプルに基づいて、我々は比較的まばらなgreynetsは、ネットワークスキャンの検出の有用なレベルを達成できることがわかりました。
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.
言い換えれば、代わりに攻撃者はプローブとその裁判所の発見をすることにしようとする場合がありますプレフィックスを脇に設定するので、ハロップは、サブネット内の個々の（または隣接の小グループ）のアドレスがそれぞれに異なるホスト識別子を使用して、目的のために確保されることを提案しましたアドレスは、それらを検出するためにスキャンのサブネットは、それをより困難にします。コンセプトは、彼らの存在がよりはっきりしていないとして、攻撃者の検索パターンのうちのアドレスまたはプレフィックスをマップするために困難であるという意味で価値があります。ハロップ氏の研究は、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]を有するものを含みます。どちらも、完成した製品の展開とは対照的に、研究実験され、制限があります。
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].
独創的な研究は、ウォーレン・ハロップによって行われ、[ハロップ]に記載されていました。これは、IPv4のみでした。彼の前提は1つが1がそうでなければ使用していなかったことをLAN上の仮想または物理マシンを置き、様々な種類のスキャンを識別するためにそれを使用するというものでした。彼の論文で報告されているように、コンセプトは、高度なインターネットアーキテクチャのためのセンター（CAIA）、スウィンバーン工科大学のプロトタイプの展開に効果的に働いていました。基本的な理由は、指定されたアドレスが表現されるかもしれない潜在的な攻撃者の一部に合理的な期待があったが、この方法で使用されていたアドレスを予測するために、攻撃者を可能にする全くパターンがなかったということでした。 CAIAは、[アーミテージ]を開発し、この前提を中心に構築された2008年のプロトタイプはFreeBSDベースのGreynetシステムをリリースしました。
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.
彼の概念にベーカーの追加は、ルータからそれはオフLANから来た場合、ルータはそのようなスキャンが発生する可能性が高いだろうという考えと、ルータはアドレス解決プロトコル（ARP）またはネイバーを使用しなければならないという事実を開始しましたディスカバリー（ND）を識別するために - または識別するために失敗する - 問題のマシン。実際には、現在のサブネット内でインスタンス化されていない任意のアドレスがGreynetトリガ・アドレスとして働きます。これは明らかに、また、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.
ティムその上にいくつかの研究を行うために私募電子工学・コンピュータ科学科のchownコマンド、サウサンプトン大学、そしてオーウェン・スティーブンスは、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アドレスのスキャンに残る疑問は、攻撃が全く発生する可能性があります。 chownコマンドは、元々アドレススキャンが原因の可能性の膨大な数には不可能だったこと[RFC5157]で主張しました。しかし、2010年9月に報告書は、IPv6アドレスのスキャンのNANOGに行われました。また、フィールドを制限する方法があります。例えば、一つの会社が、マシンまたはネットワークインタフェースカード（NIC）の特定の種類を購入することを観察することができるため、その可能性のEUI-64アドレスは、2 ^ 64よりもずっと小さい範囲に限定されている - より多くのような2 ^ 24アドレス特定のサブネット上の - または1つは、DNSを観察することができ、SMTPエンベロープ、拡張可能なメッセージングおよびプレゼンスプロトコル（XMPP）メッセージ、FTP、HTTPなど、他の方法でIPアドレスを運ぶこと。そのような攻撃はあまり有用履歴情報をレンダリングする、定期的に変化する、プライバシーアドレス[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部門や他のネットワークオペレータは、頻繁にコレクターやセンサーの他の種類を実行します。コレクタは、明示および「トラップ」不正な試みがコンピュータシステムに侵入するために引き付けるために設定されているインターネット上のコンピュータシステムです。このようなシステムは、単に試み（darknets / Greynets）を開始しようとか、データグラムを記録することができる、または、彼らは彼らの活動を研究し、そのメソッド（ハニーポット）を研究するために、潜在的な攻撃におびき寄せ、おとりとして作用することができます。
To accomplish this, we separate nefarious traffic from that which is likely normal and important, studying one and facilitating the other.
これを達成するために、我々は1を勉強し、他の促進、おそらく通常のかつ重要であることから、極悪非道なトラフィックを分離します。
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.
クラスレスドメイン間ルーティング（CIDR）はIPサブネットにO（2 ^ n）のアドレスを割り当て、正確に多くのシステムが存在しないという理由だけであればIPv4のサブネットは通常、それらにいくつかの未割り当て領域を持っています。
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:
ルータは、データグラムが送信される必要に隣接のMAC（Media Access Control）アドレスを決定するために、IPv4のARP [RFC0826]とIPv6近隣探索[RFC4861]を使用します。 ：どちらの仕様は、データグラムがターゲットのプレフィックスを提供していますルータに到着したが、それは意図した送信先のMACアドレスを知らないとき、それは必要があることを意図します
o Enqueue the datagram,
O、データグラムをエンキュー
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とデータグラムを転送します。
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].
【ハロップ]において、Greynetは全て「暗」IPアドレスに対するARP要求に応答するエンドホスト上でインスタンス化されるものとして説明されています。しかし、ルータの動作に小さな変更は、このモデルを拡張することができます。同様にARPリクエストや近隣要請をトリガしたデータグラムをキューイングや削除など、ルータはGreynetの分析機器への独立したリンク上でこのデータグラムのコピーを転送します。この独立したリンクは、UDP、又は他のカプセル化、または実際にそのようなデータグラムを処理することができる任意の場所、異なる物理インタフェース、回路、VLAN、トンネルであってもよいです。受信コレクターの要件に応じて、1つは、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サブネットからの応答を送信するため、それは望ましいことがあります。当然のことながら、このシナリオのコレクタは「点灯の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.
概念の明白な拡張はコレクタに送信するために必要に応じて他のフィルタによって識別されたトラフィックが含まれます。例えば、一方が同じトンネルを介してコレクタにユニキャストRPF（uRPFの）チェック[RFC2827]を失敗トラフィックを転送するようにシステムを構成するかもしれません。
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近隣探索アルゴリズムに適用されます。インターフェース、回路、VLAN、またはトンネルに、構成制御下に、分析システムに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、および他のユーザーによって使用されています。ハロップは彼の研究でそれらを延長しました。概念のこの製剤は、この注意事項は、インターネットトラフィックセンサ上のポール・ヴィクシーとRhetteマーシュとの会話から生まれた2005年に作家の間で議論に由来しました。彼らはまた、それに有益なコメントが寄せられています。アルバート・マンフレディは、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.
ティムのchown [RFC5157]は、少なくともそのRFCを書いている時点で、IPv6ではアドレススキャン攻撃は野生で報告されていない、ということを観察しました。上記セクション1.1で述べたようにしかし、（部分的に）スキャン攻撃は最近、NANOGメーリングリストで報告されました。 Rhetteマーシュは、しかし、このような攻撃の構造を示唆している、とフレッド・ベイカーは、アプリケーション間で交換される情報を扱うに基づくアプローチを提案しています。したがって、我々は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".
ティムのchownとオーウェン・スティーブンスは、提案をテストし、このテキストに組み込まれている便利なコメントが寄せられています。彼の根本的なコメントが、「それは働く」ということがありました。
[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.
[ハロップ]ハロップ、W.およびG.アーミテージ、「Greynets：過疎darknetsの定義と評価」、ローカルコンピュータネットワーク、2005年にIEEE LCN IEEE 30日の会議。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]ポステル、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]プラマー、D.、「イーサネットアドレス解決プロトコル：またはイーサネットハードウェア上で送信するためのイーサネットアドレスを48ビットに、ネットワーク・プロトコル・アドレス変換」、STD 37、RFC 826、1982年11月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン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.デアリング、 "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.、シンプソン、W.、およびH.ソリマン、 "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.クリシュナン、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、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/.
[アーミテージ]アーミテージ、G.、ハロップ、W.、Heyde、A.、パリー、L.、 "Greynets：パッシブ中小ISPや企業ネットワークにおける迷惑ネットワークスキャンの検出"、CAIA、テクノロジー、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. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス攻撃の敗北拒否"、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]ボスキ、E.、トラメル、B.、マーク、L.、およびT. Zseby、RFC 5610、2009年7月 "IPフロー情報のエクスポート（IPFIX）情報要素の型情報のエクスポート"。
Authors' Addresses
著者のアドレス
Fred Baker Cisco Systems Santa Barbara, California 93117 USA
フレッドベイカーシスコシステムズサンタバーバラ、カリフォルニア93117 USA
EMail: fred@cisco.com
メールアドレス：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
メールアドレス：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
高度なインターネットアーキテクチャスウィンバーン工科大学の私書箱218ジョンストリート、ホーソン、ビクトリア、3122オーストラリアのためのグレンヴィルアーミテージセンター
EMail: garmitage@swin.edu.au
メールアドレス：garmitage@swin.edu.au