[要約] 要約： RFC 2267は、IPソースアドレススプーフィングを使用するサービス拒否攻撃に対抗するためのネットワークイングレスフィルタリングの方法を提案しています。目的： 1. サービス拒否攻撃による被害を最小限に抑えるため、IPソースアドレススプーフィングを防止する方法を提供する。 2. ネットワークインフラストラクチャのセキュリティを向上させ、信頼性を確保する。 3. インターネット上のネットワークトラフィックの信頼性と正当性を確保する。
Network Working Group P. Ferguson
Request for Comments: 2267 Cisco Systems, Inc.
Category: Informational D. Senie
BlazeNet, Inc.
January 1998
Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing
ネットワーク入力フィルタリング：IP送信元アドレスのスプーフィングを使用するサービス拒否攻撃を無効にする
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 Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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アドレスを使用するDoS攻撃がインターネットサービスプロバイダー（ISP）集約ポイントの「背後」から伝播されるのを防ぐための、シンプルで効果的かつ簡単な方法について説明します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Restricting forged traffic . . . . . . . . . . . . . . . . 5
4. Further capabilities for networking equipment. . . . . . . 6
5. Liabilities. . . . . . . . . . . . . . . . . . . . . . . . 6
6. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations. . . . . . . . . . . . . . . . . . 7
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]で引用されており、攻撃下にあるシステムの管理者が効果的に防御する方法がなかったため、彼の本「Firewalls and Internet Security」[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フラッディング問題の簡略図を以下に示します。
9.0.0.0/8
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, 9.0.0.0/8.
o 攻撃者は「有効な」プレフィックス9.0.0.0/8内に常駐しています。
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フラッディング）では、偽造されたパケットを使用して、chargen UDPサービスを別のサイトのecho UDPサービスに接続しようとします。システム管理者は、システム診断ポート宛てのUDPパケットが管理ドメインの外部からシステムに到達することを許可しないでください。後者の攻撃（ICMPフラッディング）は、IPサブネットブロードキャストレプリケーションメカニクスの陰湿な機能を使用します。この攻撃は、大規模なマルチアクセスブロードキャストネットワークを提供するルーターを使用して、IPブロードキャストアドレス（10.255.255.255宛てのアドレスなど）をレイヤー2ブロードキャストフレーム（イーサネットの場合、FF：FF：FF：FF：FF： FF）。イーサネットNICハードウェア（具体的にはMAC層ハードウェア）は、通常の動作では選択された数のアドレスのみをリッスンします。通常の操作ですべてのデバイスが共有する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.
この脅威に対応するため、ほとんどのオペレーティングシステムベンダーはソフトウェアを変更して、ターゲットサーバーが非常に高い接続試行率で攻撃に耐えられるようにしています。これは問題を解決するための歓迎すべき必要な部分です。イングレスフィルタリングが普及して完全に効果的になるには時間がかかりますが、オペレーティングシステムの拡張機能をすばやく実装できます。この組み合わせは、送信元アドレスのスプーフィングに対して効果的であることが判明するはずです。ベンダーおよびプラットフォームソフトウェアのアップグレード情報については、[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プロトコル自体の欠点が関係しています。ただし、ダウンストリームネットワークから発信されるトランジットトラフィックを既知の意図的にアドバタイズされたプレフィックスに制限することで、この攻撃シナリオで送信元アドレスのスプーフィングの問題を実質的に排除できます。
11.0.0.0/8
/
router 1
/
/
/ 9.0.0.0/8
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 9.0.0.0/8, 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 9.0.0.0/8 prefix, and prohibits an attacker from using "invalid" source addresses which reside outside of this prefix range.
上記の例では、攻撃者はISP Dによるインターネット接続を提供する9.0.0.0/8内に存在します。攻撃者のネットワークへの接続を提供する「ルーター2」の入力（入力）リンク上の入力トラフィックフィルターは、 9.0.0.0/8プレフィックス内の送信元アドレスから発信されるトラフィックのみを許可し、攻撃者がこのプレフィックス範囲外にある「無効な」送信元アドレスを使用することを禁止するトラフィック。
In other words, the ingress filter on "router 2" above would check:
つまり、上記の「ルーター2」の入力フィルタは次のことをチェックします。
IF packet's source address from within 9.0.0.0/8 THEN forward as appropriate
9.0.0.0/8内からのIFパケットの送信元アドレスTHEN必要に応じて転送
IF packet's source address is anything else THEN deny packet
IFパケットの送信元アドレスがそれ以外の場合はパケットを拒否
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:
将来のプラットフォーム実装では、追加の機能を検討する必要があります。次の1つは注目に値します。
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 リモートアクセスサーバーでの自動フィルタリングの実装。ほとんどの場合、アクセスサーバーにダイヤルするユーザーは、1台の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. The Mobile IP Working Group is addressing this problem by specifying "reverse tunnels" in [7]. This work in progress provides a method for the data transmitted from 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.
[6]で定義されているモバイルIPは、入力トラフィックフィルタリングの影響を特に受けます。指定したとおり、モバイルノードへのトラフィックはトンネリングされますが、モバイルノードからのトラフィックはトンネリングされません。これにより、ステーションが接続されているネットワークと一致しない送信元アドレスを持つモバイルノードからのパケットが発生します。モバイル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 [OpenROUTE Networks, Inc.] for their comments and contributions.
北米ネットワークオペレーターグループ（NANOG）[5]グループ全体として、これらの問題について公然と議論し、可能な解決策を積極的に模索することに対して特別な功績があります。また、コメントと貢献をしてくれたJustin Newton [Priori Networks]とSteve Bielagus [OpenROUTE Networks、Inc.]にも感謝します。
[1] CERT Advisory CA-96.21; TCP SYN Flooding and IP Spoofing Attacks; September 24, 1996.
[1] CERT Advisory 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. Ziegler、「Hacker Tangles Panix Web Site」、Wall Street Journal、1996年9月12日。
[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] "ファイアウォールとインターネットセキュリティ：Wilyハッカーを撃退"; William R. CheswickおよびSteven M. Bellovin、Addison-Wesley Publishing Company、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.、Moskowitz、R.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、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 Mobile IP", Work in Progress.
[7] モンテネグロ、G。、「Reverse Tunneling Mobile IP」、Work in Progress。
[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. 400 Herndon Parkway Herndon, VA USA 20170
Paul Ferguson cisco Systems、Inc. 400 Herndon Parkway Herndon、VA USA 20170
EMail: ferguson@cisco.com
Daniel Senie BlazeNet, Inc. 4 Mechanic Street Natick, MA USA 01760
Daniel Senie BlazeNet、Inc. 4 Mechanic Street Natick、MA USA 01760
EMail: dts@senie.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。