Network Working Group P. Ferguson
Request for Comments: 2827 Cisco Systems, Inc.
Obsoletes: 2267 D. Senie
BCP: 38 Amaranth Networks Inc.
Category: Best Current Practice May 2000
Network Ingress Filtering:
Defeating Denial of Service Attacks which employ
IP Source Address Spoofing
Status of this Memo
このメモの位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
Recent occurrences of various Denial of Service (DoS) attacks which have employed forged source addresses have proven to be a troublesome issue for Internet Service Providers and the Internet community overall. This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point.
偽造送信元アドレスを使用してきたさまざまなサービス拒否（DoS）攻撃の最近の出現は、インターネットサービスプロバイダおよび全体的なインターネットコミュニティのための厄介な問題であることが判明しています。本論文では、IPは、インターネットサービスプロバイダ（ISP）集約ポイント「背後」から伝播されるようにアドレスを偽造使用DoS攻撃を禁止する入力トラフィックのフィルタリングを使用するための、簡単で効果的、かつ簡単な方法を説明します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Restricting forged traffic . . . . . . . . . . . . . . . . 5
4. Further capabilities for networking equipment. . . . . . . 6
5. Liabilities. . . . . . . . . . . . . . . . . . . . . . . . 6
6. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations. . . . . . . . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . 8
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 9
11. Full Copyright Statement . . . . . . . . . . . . . . . . . 10
A resurgence of Denial of Service Attacks [1] aimed at various targets in the Internet have produced new challenges within the Internet Service Provider (ISP) and network security communities to find new and innovative methods to mitigate these types of attacks. The difficulties in reaching this goal are numerous; some simple tools already exist to limit the effectiveness and scope of these attacks, but they have not been widely implemented.
[1]インターネットで様々なターゲットに向けたサービス拒否攻撃の復活は、この種の攻撃を軽減するための新しい革新的な方法を見つけるために、新しいインターネットサービスプロバイダ（ISP）内の課題とネットワークセキュリティコミュニティを生産しています。この目標を達成するのが困難は数多くあります。いくつかの簡単なツールは、すでにこれらの攻撃の有効性と範囲を制限するために存在するが、それらは広く実装されていません。
This method of attack has been known for some time. Defending against it, however, has been an ongoing concern. Bill Cheswick is quoted in [2] as saying that he pulled a chapter from his book, "Firewalls and Internet Security" [3], at the last minute because there was no way for an administrator of the system under attack to effectively defend the system. By mentioning the method, he was concerned about encouraging it's use.
攻撃のこの方法は、いくつかの時間のために知られています。それに対して守る、しかし、継続的な関心事となっています。ビル・チェスウィックは、彼が彼の本からの章を引っ張ったと言って、「ファイアウォールとインターネットセキュリティ」と[2]に引用されている[3]、最後の最後で効果的に守るために攻撃を受けてシステムの管理者のための方法がなかったので、システム。方法に言及することで、彼はそれの使用を奨励することを懸念しました。
While the filtering method discussed in this document does absolutely nothing to protect against flooding attacks which originate from valid prefixes (IP addresses), it will prohibit an attacker within the originating network from launching an attack of this nature using forged source addresses that do not conform to ingress filtering rules. All providers of Internet connectivity are urged to implement filtering described in this document to prohibit attackers from using forged source addresses which do not reside within a range of legitimately advertised prefixes. In other words, if an ISP is aggregating routing announcements for multiple downstream networks, strict traffic filtering should be used to prohibit traffic which claims to have originated from outside of these aggregated announcements.
この文書で説明するフィルタリング方法が有効なプレフィックス（IPアドレス）から発信フラッディング攻撃から保護するために絶対に何もしませんが、それは準拠していない偽造送信元アドレスを使用してこの種の攻撃を開始からの発信ネットワーク内で攻撃を禁止しますイングレスフィルタリングルールへ。インターネット接続のすべてのプロバイダは、合法的にアドバタイズされたプレフィクスの範囲内に存在していない偽造送信元アドレスを使用してからの攻撃を禁止するために、この文書で説明したフィルタリングを実装するために促しています。 ISPは、複数のダウンストリームネットワークのルーティングアナウンスを凝集さ言い換えれば、厳密なトラフィックフィルタリングは、これらの凝集アナウンスの外部から発信されたと主張するトラフィックを禁止するために使用されるべきです。
An additional benefit of implementing this type of filtering is that it enables the originator to be easily traced to it's true source, since the attacker would have to use a valid, and legitimately reachable, source address.
この種のフィルタリングを実装するための追加的な利点は、それが本当の原因だと、攻撃者が有効、かつ合法的に到達可能な、送信元アドレスを使用しなければならないので、発信者が簡単に、トレースすることを可能にするということです。
A simplified diagram of the TCP SYN flooding problem is depicted below:
TCP SYNフラッディング問題の簡略図を下に描かれています。
204.69.207.0/24
host <----- router <--- Internet <----- router <-- attacker
TCP/SYN
<---------------------------------------------
Source: 192.168.0.4/32
SYN/ACK
no route
TCP/SYN
<---------------------------------------------
Source: 10.0.0.13/32
SYN/ACK
no route
TCP/SYN
<---------------------------------------------
Source: 172.16.0.2/32
SYN/ACK
no route
[etc.]
[等。]
Assume:
想定します。
o The "host" is the targeted machine.
O「ホスト」は対象マシンです。
o The attacker resides within the "valid" prefix, 204.69.207.0/24.
O攻撃者が204.69.207.0/24、「有効」プレフィックス内に存在します。
o The attacker launches the attack using randomly changing source addresses; in this example, the source addresses are depicted as from within [4], which are not generally present in the global Internet routing tables, and therefore, unreachable. However, any unreachable prefix could be used to perpetrate this attack method.
O攻撃者がランダムに変化する送信元アドレスを使用して攻撃を開始します。この例では、送信元アドレスは、[4]、一般グローバルインターネットルーティングテーブル内に存在し、したがって、到達不能されていない内からとして示されています。しかし、いずれの到達不能の接頭辞は、この攻撃方法を犯すために使用することができます。
Also worthy of mention is a case wherein the source address is forged to appear to have originated from within another legitimate network which appears in the global routing table(s). For example, an attacker using a valid network address could wreak havoc by making the attack appear to come from an organization which did not, in fact, originate the attack and was completely innocent. In such cases, the administrator of a system under attack may be inclined to filter all traffic coming from the apparent attack source. Adding such a filter would then result in a denial of service to legitimate, non-hostile end-systems. In this case, the administrator of the system under attack unwittingly becomes an accomplice of the attacker.
また、言及の価値は、送信元アドレスがグローバルルーティングテーブル（単数または複数）に表示される別の正当なネットワーク内から発信されているように見えるように鍛造される場合です。例えば、攻撃を行うことで大混乱をもたらす可能性があり、有効なネットワーク・アドレスを使用して、攻撃者は、実際には、攻撃を発信し、完全に無実していなかった組織から来たように見えます。このような場合には、攻撃対象のシステムの管理者は、見かけの攻撃元からのすべてのトラフィックをフィルタリングするように傾斜していてもよいです。このようなフィルタを追加すると、その後、正当な、非敵対的エンドシステムに対するサービスの拒否をもたらすであろう。この場合、攻撃対象のシステムの管理者は、無意識のうちに攻撃者の共犯となります。
Further complicating matters, TCP SYN flood attacks will result in SYN-ACK packets being sent to one or many hosts which have no involvement in the attack, but which become secondary victims. This allows the attacker to abuse two or more systems at once.
さらに問題を複雑にする、TCP SYNフラッド攻撃は、SYN-ACKパケットが攻撃には関与していないが、第二の犠牲者になる1つのまたは複数のホストに送信されているになります。これにより、攻撃者は一度に2つの以上のシステムを悪用することができます。
Similar attacks have been attempted using UDP and ICMP flooding. The former attack (UDP flooding) uses forged packets to try and connect the chargen UDP service to the echo UDP service at another site. Systems administrators should NEVER allow UDP packets destined for system diagnostic ports from outside of their administrative domain to reach their systems. The latter attack (ICMP flooding), uses an insidious feature in IP subnet broadcast replication mechanics. This attack relies on a router serving a large multi-access broadcast network to frame an IP broadcast address (such as one destined for 10.255.255.255) into a Layer 2 broadcast frame (for ethernet, FF:FF:FF:FF:FF:FF). Ethernet NIC hardware (MAC-layer hardware, specifically) will only listen to a select number of addresses in normal operation. The one MAC address that all devices share in common in normal operation is the media broadcast, or FF:FF:FF:FF:FF:FF. In this case, a device will take the packet and send an interrupt for processing. Thus, a flood of these broadcast frames will consume all available resources on an end-system [9]. It is perhaps prudent that system administrators should consider ensuring that their border routers do not allow directed broadcast packets to be forwarded through their routers as a default.
同様の攻撃は、UDPやICMPフラッディングを使用して試みられています。かつての攻撃（UDPフラッド）は、別のサイトでのエコーUDPサービスへのchargenのUDPサービスを試してみて、接続するために偽造パケットを使用しています。システム管理者は、管理ドメインの外からシステム診断ポートに宛てUDPパケットがシステムに到達できるようにするべきではありません。後者の攻撃（ICMPフラッディング）は、IPサブネットブロードキャスト複製力学の陰湿な機能を使用しています。この攻撃は、（レイヤ2ブロードキャストフレームに（ものなどが10.255.255.255宛ての）IPブロードキャストアドレスをフレームに大規模なマルチアクセスブロードキャストネットワークを提供するルータに依存しているイーサネットのため、FF：FF：FF：FF：FF： FF）。 （具体的にはMACレイヤハードウェア、）イーサネットNICのハードウェアは、通常動作時のアドレスの選択数を聞くであろう。 1つのMAC通常の操作では一般的にあるすべてのデバイスのシェアがメディア放送でアドレス、またはFF：FF：FF：FF：FF：FF。この場合、デバイスはパケットを取得し、処理のための割り込みを送信します。したがって、これらのブロードキャストフレームの洪水は、エンドシステムで使用可能なすべてのリソースを消費します[9]。システム管理者は境界ルータがダイレクトブロードキャストパケットはデフォルトとしてのルータを介して転送することはできませんことを確実にすることを検討すべきであることをおそらく賢明です。
When an TCP SYN attack is launched using unreachable source address, the target host attempts to reserve resources waiting for a response. The attacker repeatedly changes the bogus source address on each new packet sent, thus exhausting additional host resources.
TCP SYN攻撃が到達不能の送信元アドレスを使用して起動すると、ターゲットホストが応答を待っているリソースを予約しようとします。攻撃者は繰り返しので、追加のホストのリソースを消耗、送られたそれぞれの新しいパケットに偽の送信元アドレスを変更します。
Alternatively, if the attacker uses someone else's valid host address as the source address, the system under attack will send a large number of SYN/ACK packets to what it believes is the originator of the connection establishment sequence. In this fashion, the attacker does damage to two systems: the destination target system, as well as the system which is actually using the spoofed address in the global routing system.
攻撃者が送信元アドレスとして誰か他の人の有効なホストアドレスを使用している場合あるいは、攻撃対象のシステムは、コネクション確立シーケンスの創始者であると信じているものにSYN / ACKパケットを大量に送信されます。先のターゲットシステム、ならびに実際のグローバルルーティングシステムでスプーフィングされたアドレスを使用しているシステム：この方法では、攻撃者は、2つのシステムにダメージを与えます。
The result of both attack methods is extremely degraded performance, or worse, a system crash.
両方の攻撃方法の結果は、非常に性能の低下、または悪化し、システムのクラッシュです。
In response to this threat, most operating system vendors have modified their software to allow the targeted servers to sustain attacks with very high connection attempt rates. This is a welcome and necessary part of the solution to the problem. Ingress filtering will take time to be implemented pervasively and be fully effective, but the extensions to the operating systems can be implemented quickly. This combination should prove effective against source address spoofing. See [1] for vendor and platform software upgrade information.
この脅威に対応して、ほとんどのオペレーティングシステムのベンダーは、対象のサーバーが非常に高い接続試行率と攻撃を維持できるようにするために彼らのソフトウェアを変更しました。これは、問題の解決策の歓迎し、必要な部分です。イングレスフィルタリングはpervasively実装するには時間がかかるし、完全に効果的であるが、オペレーティング・システムへの拡張を迅速に実装することができます。この組み合わせは、送信元アドレススプーフィングに対する効果を証明する必要があります。 [1]ベンダーやプラットフォームソフトウェアのアップグレード情報を参照してください。
The problems encountered with this type of attack are numerous, and involve shortcomings in host software implementations, routing methodologies, and the TCP/IP protocols themselves. However, by restricting transit traffic which originates from a downstream network to known, and intentionally advertised, prefix(es), the problem of source address spoofing can be virtually eliminated in this attack scenario.
この種の攻撃に直面した問題は数多くある、とホストソフトウェアの実装、ルーティング方法、およびTCP / IPプロトコルそのものに欠点を伴います。しかしながら、既知の下流のネットワークから発信され、意図的にアドバタイズ通過トラフィックを制限することによって、接頭語（ES）、ソースアドレススプーフィングの問題は、事実上、この攻撃のシナリオで除去することができます。
11.0.0.0/8
/
router 1
/
/
/ 204.69.207.0/24
ISP <----- ISP <---- ISP <--- ISP <-- router <-- attacker
A B C D 2
/
/
/
router 3
/
12.0.0.0/8
In the example above, the attacker resides within 204.69.207.0/24, which is provided Internet connectivity by ISP D. An input traffic filter on the ingress (input) link of "router 2", which provides connectivity to the attacker's network, restricts traffic to allow only traffic originating from source addresses within the 204.69.207.0/24 prefix, and prohibits an attacker from using "invalid" source addresses which reside outside of this prefix range.
上記の例では、攻撃者は、入力上のISP D.アン入力トラフィックフィルタ攻撃者のネットワークへの接続を提供する「ルータ2」の（入力）リンクによってインターネット接続が提供され、204.69.207.0/24内に存在する制限しトラフィックは204.69.207.0/24プレフィックス内のソースアドレスから発信トラフィックのみを許可し、このプレフィックス範囲の外にある「無効」送信元アドレスを使用して攻撃者を禁止します。
In other words, the ingress filter on "router 2" above would check:
言い換えれば、「ルータ2」上の入力フィルタは、上記のチェックになります。
IF packet's source address from within 204.69.207.0/24 THEN forward as appropriate
IF THEN前方適切な204.69.207.0/24の中からパケットの送信元アドレス
IF packet's source address is anything else THEN deny packet
パケットの送信元アドレスは、他の何かである場合、パケットを拒否
Network administrators should log information on packets which are dropped. This then provides a basis for monitoring any suspicious activity.
ネットワーク管理者は、廃棄されたパケットに関する情報をログに記録する必要があります。これは、その後、任意の不審な行動を監視するための基礎を提供します。
Additional functions should be considered for future platform implementations. The following one is worth noting:
その他の機能は、将来のプラットフォーム実装を検討すべきです。以下の一つは注目に値します。
o Implementation of automatic filtering on remote access servers. In most cases, a user dialing into an access server is an individual user on a single PC. The ONLY valid source IP address for packets originating from that PC is the one assigned by the ISP (whether statically or dynamically assigned). The remote access server could check every packet on ingress to ensure the user is not spoofing the source address on the packets which he is originating. Obviously, provisions also need to be made for cases where the customer legitimately is attaching a net or subnet via a remote router, but this could certainly be implemented as an optional parameter. We have received reports that some vendors and some ISPs are already starting to implement this capability.
リモートアクセスサーバー上の自動フィルタリングのOの実装。ほとんどの場合、アクセスサーバにダイヤルインユーザーは、単一のPC上の個々のユーザーです。そのPCから発信するパケットに対してのみ有効な送信元IPアドレスは、（静的または動的に割り当てられたかどうか）ISPによって割り当てられたものです。リモートアクセスサーバーは、ユーザーは自分が発信されるパケットの送信元アドレスを偽装されていないことを確認するために、入口上のすべてのパケットをチェックすることができます。明らかに、規定はまた、顧客が合法的にリモートルータを経由してネットまたはサブネットを取り付けるれる場合のためになされる必要があるが、これは確かにオプションのパラメータとして実装することができます。我々はいくつかのベンダーといくつかのISPは既にこの機能を実装し始めているという報告を受けています。
We considered suggesting routers also validate the source IP address of the sender as suggested in [8], but that methodology will not operate well in the real networks out there today. The method suggested is to look up source addresses to see that the return path to that address would flow out the same interface as the packet arrived upon. With the number of asymmetric routes in the Internet, this would clearly be problematic.
私たちは、[8]で提案されているように、ルータはまた、送信者の送信元IPアドレスを検証し、それの方法論は、今日そこから実際のネットワークではうまく動作しません示唆考えました。提案された方法では、パケットが到着した時のように、そのアドレスへのリターンパスが同じインターフェイスを流れ出るであろうと確認するために、送信元アドレスを調べることです。インターネットにおける非対称ルートの数と、これは明らかに問題となります。
Filtering of this nature has the potential to break some types of "special" services. It is in the best interest of the ISP offering these types of special services, however, to consider alternate methods of implementing these services to avoid being affected by ingress traffic filtering.
この種のフィルタリングは、「特別な」サービスのいくつかのタイプを打破する可能性を秘めています。しかし、入力トラフィックのフィルタリングの影響を受けないように、これらのサービスを実装するための別の方法を検討するために、特別なサービスのこれらのタイプを提供するISPの最善の利益です。
Mobile IP, as defined in [6], is specifically affected by ingress traffic filtering. As specified, traffic to the mobile node is tunneled, but traffic from the mobile node is not tunneled. This results in packets from the mobile node(s) which have source addresses that do not match with the network where the station is attached. To accommodate Ingress Filtering and other concerns, the Mobile IP Working Group developed a methodology for "reverse tunnels", specified in [7]. This provides a method for the data transmitted by the mobile node to be tunneled to the home agent before transmission to the Internet. There are additional benefits to the reverse tunneling scheme, including better handling of multicast traffic. Those implementing mobile IP systems are encouraged to implement this method of reverse tunneling.
モバイルIPは、で定義されるように[6]、具体的には入力トラフィックフィルタリングによって影響されます。指定されているように、モバイルノードへのトラフィックがトンネリングされますが、モバイルノードからのトラフィックがトンネリングされていません。これは、ステーションが接続されているネットワークと一致しない送信元アドレスを有するモバイルノード（S）からのパケットになります。入力フィルタリングおよびその他の懸念に対応するために、モバイルIPワーキンググループは、[7]で指定された「逆トンネル」、のための方法論を開発しました。これは、モバイルノードによって送信されたデータは、インターネットへの送信前に、ホームエージェントにトンネリングさせるための方法を提供します。マルチキャストトラフィックのより良いハンドリングを含むリバーストンネリング方式への付加的な利点があります。モバイルIPシステムを実装するものがリバーストンネリングのこのメソッドを実装することをお勧めします。
As mentioned previously, while ingress traffic filtering drastically reduces the success of source address spoofing, it does not preclude an attacker using a forged source address of another host within the permitted prefix filter range. It does, however, ensure that when an attack of this nature does indeed occur, a network administrator can be sure that the attack is actually originating from within the known prefixes that are being advertised. This simplifies tracking down the culprit, and at worst, the administrator can block a range of source addresses until the problem is resolved.
前述のように入力トラフィックフィルタリングが大幅ソースアドレススプーフィングの成功を低減しながら、それが許可プレフィックスフィルタ範囲内の他のホストの偽造ソースアドレスを使用して攻撃を排除するものではありません。しかし、この種の攻撃が実際に発生したときに、ネットワーク管理者は、攻撃が実際に宣伝されている知られている接頭辞内から発信されたことを確認することができていることを確認しません。これは、犯人を追跡簡素化し、問題が解決されるまでは最悪で、管理者は、送信元アドレスの範囲をブロックすることができます。
If ingress filtering is used in an environment where DHCP or BOOTP is used, the network administrator would be well advised to ensure that packets with a source address of 0.0.0.0 and a destination of 255.255.255.255 are allowed to reach the relay agent in routers when appropriate. The scope of directed broadcast replication should be controlled, however, and not arbitrarily forwarded.
イングレスフィルタリングがDHCPまたはBOOTPを使用している環境で使用されている場合は、ネットワーク管理者はよく0.0.0.0の送信元アドレスと255.255.255.255の宛先を持つパケットは、ルータでのリレーエージェントに到達するために許可されていることを確認することをお勧めされるだろう適切な場合。ダイレクトブロードキャスト複製の範囲は、しかし、制御、および任意に転送されませんする必要があります。
Ingress traffic filtering at the periphery of Internet connected networks will reduce the effectiveness of source address spoofing denial of service attacks. Network service providers and administrators have already begun implementing this type of filtering on periphery routers, and it is recommended that all service providers do so as soon as possible. In addition to aiding the Internet community as a whole to defeat this attack method, it can also assist service providers in locating the source of the attack if service providers can categorically demonstrate that their network already has ingress filtering in place on customer links.
インターネット接続されたネットワークの周囲の入力トラフィックのフィルタリングは、サービス拒否攻撃を偽装元アドレスの有効性が低下します。ネットワークサービスプロバイダと管理者は、すでに周辺ルータでこの種のフィルタリングを実装し始めている、そしてすべてのサービスプロバイダーが、できるだけ早くそれを行うことをお勧めします。この攻撃方法を倒すために、全体としてのインターネットコミュニティを支援することに加えて、それはまた、サービスプロバイダは断固としてそのネットワークはすでに顧客のリンク上の場所で入力フィルタリングを持っていることを証明することができれば、攻撃の発生源を特定するには、サービスプロバイダーを支援することができます。
Corporate network administrators should implement filtering to ensure their corporate networks are not the source of such problems. Indeed, filtering could be used within an organization to ensure users do not cause problems by improperly attaching systems to the wrong networks.
企業のネットワーク管理者は、企業ネットワークは、このような問題の原因ではないことを確認するためのフィルタリングを実装する必要があります。確かに、フィルタリングは、ユーザーが不適切に間違ったネットワークにシステムを取り付けることによって、問題を引き起こさないことを確認するために、組織内で使用することができます。
The filtering could also, in practice, block a disgruntled employee from anonymous attacks.
フィルタリングはまた、実際には、匿名の攻撃から不満を持つ従業員をブロックすることができます。
It is the responsibility of all network administrators to ensure they do not become the unwitting source of an attack of this nature.
彼らがこの種の攻撃の無意識の源となっていないことを確認するために、すべてのネットワーク管理者の責任です。
The primary intent of this document is to inherently increase security practices and awareness for the Internet community as a whole; as more Internet Providers and corporate network administrators implement ingress filtering, the opportunity for an attacker to use forged source addresses as an attack methodology will significantly lessen. Tracking the source of an attack is simplified when the source is more likely to be "valid". By reducing the number and frequency of attacks in the Internet as a whole, there will be more resources for tracking the attacks which ultimately do occur.
このドキュメントの主な目的は、本質的に、インターネットコミュニティ全体のセキュリティ実践と意識を高めることです。より多くのインターネットプロバイダーや企業のネットワーク管理者が入力フィルタリングを実装して、攻撃の方法論として偽造送信元アドレスを使用するには、攻撃者のための機会が大幅に軽減されます。ソースが「有効」である可能性が高いとき、攻撃の発信元を追跡することは単純化されています。全体として、インターネットにおける攻撃の数や頻度を減らすことにより、最終的に発生した攻撃を追跡するため、より多くのリソースがあるでしょう。
The North American Network Operators Group (NANOG) [5] group as a whole deserves special credit for openly discussing these issues and actively seeking possible solutions. Also, thanks to Justin Newton [Priori Networks] and Steve Bielagus [IronBridge Networks]. for their comments and contributions.
北アメリカネットワークオペレータグループ（NANOG）[5]グループ全体としては、公然と、これらの問題を議論し、積極的に可能な解決策を模索するための特別な信用に値します。また、ジャスティン・ニュートン[プリオリネットワーク]とスティーブBielagus [アイアンブリッジネットワーク]のおかげ。彼らのコメントと貢献のために。
[1] CERT Advisory CA-96.21; TCP SYN Flooding and IP Spoofing Attacks; September 24, 1996.
[1] CERTアドバイザリCA-96.21。 TCP SYNフラッドとIPスプーフィング攻撃。 1996年9月24日。
[2] B. Ziegler, "Hacker Tangles Panix Web Site", Wall Street Journal, 12 September 1996.
[2] B.ツィーグラーは、ウォールストリートジャーナル、1996年9月12日 "ハッカーはPanixのWebサイトをもつれ"。
[3] "Firewalls and Internet Security: Repelling the Wily Hacker"; William R. Cheswick and Steven M. Bellovin, Addison-Wesley Publishing Company, 1994; ISBN 0-201-63357-4.
[3]「ファイアウォールとインターネットセキュリティ：ワイリーハッカーを撃退」。ウィリアム・R.チェスウィックとスティーブン・M・ベロビン、アディソン・ウェズリー出版社、1994; ISBN 0-201-63357-4。
[4] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996.
[4] Rekhter、Y.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、RFC 1918、1996年2月デ。
[5] The North American Network Operators Group; http://www.nanog.org.
[5]北アメリカネットワークオペレータグループ。 http://www.nanog.org。
[6] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[6]パーキンス、C.、 "IPモビリティサポート"、RFC 2002、1996年10月。
[7] Montenegro, G., "Reverse Tunneling for Mobile IP", RFC 2344, May 1998.
[7]モンテネグロ、G.、 "モバイルIPのためのリバーストンネリング"、RFC 2344、1998年5月を。
[8] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[8]ベイカー、F.、 "IPバージョン4つのルータのための要件"、RFC 1812、1995年6月。
[9] Thanks to: Craig Huegen; See: http://www.quadrunner.com/~chuegen/smurf.txt.
[9]のおかげで：クレイグHuegen。参照：http://www.quadrunner.com/~chuegen/smurf.txtを。
Paul Ferguson Cisco Systems, Inc. 13625 Dulles Technology Dr. Herndon, Virginia 20170 USA
ポール・ファーガソンシスコシステムズ、株式会社13625ダレステクノロジー博士ハーンドン、バージニア州20170 USA
EMail: ferguson@cisco.com
メールアドレス：ferguson@cisco.com
Daniel Senie Amaranth Networks Inc. 324 Still River Road Bolton, MA 01740 USA
ダニエルSenieアマランスネットワークス株式会社324それでもリバーロードボルトン、MA 01740 USA
EMail: dts@senie.com
メールアドレス：dts@senie.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。