RFC4732 日本語訳
4732 Internet Denial-of-Service Considerations. M. Handley, Ed., E.Rescorla, Ed., IAB. December 2006. (Format: TXT=91844 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Handley, Ed.
Request for Comments: 4732 UCL
Category: Informational E. Rescorla, Ed.
Network Resonance
Internet Architecture Board
IAB
November 2006
ワーキンググループのM.ハンドレー、エドをネットワークでつないでください。コメントのために以下を要求してください。 4732年のUCLカテゴリ: エド情報のE.レスコラ、ネットワーク共鳴インターネット・アーキテクチャ委員会IAB2006年11月
Internet Denial-of-Service Considerations
インターネットサービス妨害問題
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(2006)。
Abstract
要約
This document provides an overview of possible avenues for denial- of-service (DoS) attack on Internet systems. The aim is to encourage protocol designers and network engineers towards designs that are more robust. We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities.
このドキュメントはインターネット・システムに対するサービスの否定(DoS)攻撃に可能な大通りの概要を提供します。目的は、より強健なデザインに向かってプロトコルデザイナーとネットワーク・デザイナーを奨励することです。 私たちは攻撃の有効性を減少させる部分的解決と、何らかの解決法がどううっかり代替の脆弱性を開けるかもしれないかについて議論します。
Handley, et al. Informational [Page 1] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [1ページ]情報のRFC4732DoS問題2006年11月
Table of Contents
目次
1. Introduction ....................................................3
2. An Overview of Denial-of-Service Threats ........................4
2.1. DoS Attacks on End-Systems .................................4
2.1.1. Exploiting Poor Software Quality ....................4
2.1.2. Application Resource Exhaustion .....................5
2.1.3. Operating System Resource Exhaustion ................6
2.1.4. Triggered Lockouts and Quota Exhaustion .............7
2.2. DoS Attacks on Routers .....................................8
2.2.1. Attacks on Routers through Routing Protocols ........8
2.2.2. IP Multicast-based DoS Attacks ......................9
2.2.3. Attacks on Router Forwarding Engines ...............10
2.3. Attacks on Ongoing Communications .........................11
2.4. Attacks Using the Victim's Own Resources ..................12
2.5. DoS Attacks on Local Hosts or Infrastructure ..............12
2.6. DoS Attacks on Sites through DNS ..........................15
2.7. DoS Attacks on Links ......................................16
2.8. DoS Attacks on Firewalls ..................................17
2.9. DoS Attacks on IDS Systems ................................18
2.10. DoS Attacks on or via NTP ................................18
2.11. Physical DoS .............................................18
2.12. Social Engineering DoS ...................................19
2.13. Legal DoS ................................................19
2.14. Spam and Black-Hole Lists ................................19
3. Attack Amplifiers ..............................................20
3.1. Methods of Attack Amplification ...........................20
3.2. Strategies to Mitigate Attack Amplification ...............22
4. DoS Mitigation Strategies ......................................22
4.1. Protocol Design ...........................................23
4.1.1. Don't Hold State for Unverified Hosts ..............23
4.1.2. Make It Hard to Simulate a Legitimate User .........23
4.1.3. Graceful Routing Degradation .......................24
4.1.4. Autoconfiguration and Authentication ...............24
4.2. Network Design and Configuration ..........................25
4.2.1. Redundancy and Distributed Service .................25
4.2.2. Authenticate Routing Adjacencies ...................25
4.2.3. Isolate Router-to-Router Traffic ...................26
4.3. Router Implementation Issues ..............................26
4.3.1. Checking Protocol Syntax and Semantics .............26
4.3.2. Consistency Checks .................................27
4.3.3. Enhance Router Robustness through
Operational Adjustments ............................28
4.3.4. Proper Handling of Router Resource Exhaustion ......28
4.4. End-System Implementation Issues ..........................29
4.4.1. State Lookup Complexity ............................29
4.4.2. Operational Issues .................................30
5. Conclusions ....................................................30
1. 序論…3 2. サービス妨害の脅威の概要…4 2.1. DoSはエンドシステムの上で攻撃します…4 2.1.1. 貧しいソフトウェア品質を利用します…4 2.1.2. アプリケーションリソース疲労困憊…5 2.1.3. オペレーティングシステムリソース疲労困憊…6 2.1.4. ロックアウトと割当て疲労困憊の引き金となります…7 2.2. DoSはルータで攻撃します…8 2.2.1. ルーティング・プロトコルを通したルータに対する攻撃…8 2.2.2. IPのマルチキャストベースのDoSは攻撃します…9 2.2.3. ルータ推進エンジンに対する攻撃…10 2.3. 進行中のコミュニケーションに対する攻撃…11 2.4. 犠牲者の自己のリソースを使用する攻撃…12 2.5. DoSはローカル・ホストかインフラストラクチャで攻撃します…12 2.6. DoSはDNSを通してサイトで攻撃します…15 2.7. DoSはリンクの上に攻撃します…16 2.8. DoSはファイアウォールの上に攻撃します…17 2.9. DoSは免疫不全症候群システムの上で攻撃します…18 2.10. NTPの上、または、NTPを通したDoS Attacks…18 2.11. 物理的なDoS…18 2.12. ソーシャルエンジニアリングDoS…19 2.13. 法的なDoS…19 2.14. スパムとブラックホールリスト…19 3. アンプを攻撃してください…20 3.1. 攻撃増幅のメソッド…20 3.2. 緩和する戦略は増幅を攻撃します…22 4. DoS緩和戦略…22 4.1. デザインについて議定書の中で述べてください…23 4.1.1. Unverifiedホストのための状態を保持しないでください…23 4.1.2. 正統のユーザをシミュレートするのを困難にしてください…23 4.1.3. 優雅なルート設定退行…24 4.1.4. 自動構成と認証…24 4.2. デザインと構成をネットワークでつないでください…25 4.2.1. 冗長と分配されたサービス…25 4.2.2. ルート設定隣接番組を認証してください…25 4.2.3. ルータからルータへのトラフィックを隔離してください…26 4.3. ルータ導入問題…26 4.3.1. プロトコル構文と意味論をチェックします…26 4.3.2. 一貫性はチェックします…27 4.3.3. 操作上の調整でルータ丈夫さを高めてください…28 4.3.4. ルータリソース疲労困憊の適切な取り扱い…28 4.4. 終わりシステムの実現問題…29 4.4.1. ルックアップの複雑さを述べてください…29 4.4.2. 操作上の問題…30 5. 結論…30
Handley, et al. Informational [Page 2] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [2ページ]情報のRFC4732DoS問題2006年11月
6. Security Considerations ........................................31 7. Acknowledgements ...............................................31 8. Normative References ...........................................31 9. Informative References .........................................32 Appendix A. IAB Members at the Time of This Writing ...............36
6. セキュリティ問題…31 7. 承認…31 8. 標準の参照…31 9. 有益な参照…32 この書くこと時点の付録A.IABメンバー…36
1. Introduction
1. 序論
A Denial-of-Service (DoS) attack is an attack in which one or more machines target a victim and attempt to prevent the victim from doing useful work. The victim can be a network server, client or router, a network link or an entire network, an individual Internet user or a company doing business using the Internet, an Internet Service Provider (ISP), country, or any combination of or variant on these. Denial-of-service attacks may involve gaining unauthorized access to network or computing resources, but for the most part in this document we focus on the cases where the denial-of-service attack itself does not involve a compromise of the victim's computing facilities.
サービス妨害(DoS)攻撃は1台以上のマシンが犠牲者を狙って、犠牲者が有益な仕事するのを防ぐのを試みる攻撃です。 犠牲者は、これらのどんなインターネットや、インターネットサービスプロバイダ(ISP)や、国や、組み合わせやまたは異形も使用することでビジネスをするネットワークサーバ、クライアント、ルータ、ネットワークリンク、全体のネットワーク、個々のインターネットユーザまたは会社であるかもしれません。 サービス不能攻撃は、ネットワークでつなぐ不正アクセスかコンピューティング資源を獲得することを伴うかもしれませんが、だいたい本書では私たちはサービス不能攻撃自体が犠牲者のコンピュータ設備の感染にかかわらないケースに焦点を合わせます。
Because of the closed context of the original ARPANET and NSFNet, no consideration was given to denial-of-service attacks in the original Internet Architecture. As a result, almost all Internet services are vulnerable to denial-of-service attacks of sufficient scale. In most cases, sufficient scale can be achieved by compromising enough end- hosts (typically using a virus or worm) or routers, and using those compromised hosts to perpetrate the attack. Such an attack is known as a Distributed Denial-of-Service (DDoS) attack. However, there are also many cases where a single well-connected end-system can perpetrate a successful DoS attack.
オリジナルのアルパネットとNSFNetの閉じている文脈のために、オリジナルのインターネットArchitectureのサービス不能攻撃に対して考慮を全く払いませんでした。 その結果、ほとんどすべてのインターネットのサービスが十分なスケールのサービス不能攻撃に被害を受け易いです。 多くの場合、十分な終わりがホスト(ウイルスかワームを通常使用します)かルータであると感染して、攻撃を犯すためにホストであると感染されるものを使用することによって、十分なスケールを達成できます。 そのような攻撃は分散型サービス妨害(DDoS)攻撃として知られています。 しかしながら、また、多くのケースがただ一つのうまくつながいでいるエンドシステムがうまくいっているDoS攻撃を犯すことができるところにあります。
This document is intended to serve several purposes:
このドキュメントがいくつかの目的に役立つことを意図します:
o To highlight possible avenues for attack, and by so doing encourage
protocol designers and network engineers towards designs that are
more robust.
o 攻撃のために可能な大通りを強調して、そうすることによって奨励するには、より強健なデザインに向かってデザイナーとネットワーク・デザイナーについて議定書の中で述べてください。
o To discuss partial solutions that reduce the effectiveness of
attacks.
o 攻撃の有効性を減少させる部分的解決について議論するために。
o To highlight how some partial solutions can be taken advantage of
by attackers to perpetrate alternative attacks.
o 攻撃者が代替手段を犯すのにどういくつかの部分的解決を利用できるかを強調するのは攻撃されます。
This last point appears to be a recurrent theme in DoS, and highlights the lack of proper architectural solutions. It is our hope that this document will help initiate informed debate about future architectural solutions that might be feasible and cost- effective for deployment.
この最後のポイントは、DoSの繰り返し現れる主題であるように見えて、適切な建築溶液の不足を強調します。 それはこのドキュメントが、将来の建築溶液の可能であるかもしれない知識がある討論と展開に、有効な費用を開始するのを助けるという私たちの望みです。
Handley, et al. Informational [Page 3] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [3ページ]情報のRFC4732DoS問題2006年11月
In addition, it is our hope that this document will spur discussion leading to architectural solutions that reduce the susceptibility of all Internet systems to denial-of-service attacks.
さらに、すべてのインターネット・システムの敏感さをサービス不能攻撃に減少させるのは、このドキュメントが建築溶液に通じる議論に拍車をかけるという私たちの望みです。
We note that in principle it is not possible to distinguish between a sufficiently subtle DoS attack and a flash crowd (where unexpected heavy but non-malicious traffic has the same effect as a DoS attack). Whilst this is true, such malicious attacks are usually more expensive to launch than many of the crude attacks that have been seen to date. Thus, defending against DoS is not about preventing all possible attacks, but rather is largely a question of raising the bar sufficiently high for malicious traffic.
私たちは、原則として、十分微妙なDoS攻撃とフラッシュ群衆(予期していなかった重い、しかし、非悪意があるトラフィックがDoS攻撃と同じ効果を持っているところ)を見分けるのが可能でないことに注意します。 これが本当ですが、通常、悪意ある攻撃は、始めるためにこれまでであるのが見られた露骨な攻撃の多くと同じくらい高価です。 したがって、DoSに対する防御は、すべての可能な攻撃を防ぐことに関してありませんが、むしろ主に十分高く悪意があるトラフィックのために水準を上げる問題です。
However, it is also important to note that not all DoS problems are malicious. Failed links, flash crowds, misconfigured bots, and numerous other causes can result in resource exhaustion problems, and so the overall goal should be to be robust to all forms of overload.
しかしながら、また、すべてのDoS問題がどんな悪意があるというわけではないことに注意するのも重要です。 全体的な目的は失敗したリンク(フラッシュ群衆)がウマバエの幼虫をmisconfiguredして、他の多数の原因がリソース疲労困憊問題をもたらすことができるのですべてのフォームのオーバーロードに強健であることであるべきです。
2. An Overview of Denial-of-Service Threats
2. サービス妨害の脅威の概要
In this section, we will discuss a wide range of possible DoS attacks. This list cannot be exhaustive, but the intent is to provide a good overview of the spectrum of possibilities that need to be defended against.
このセクションで、私たちはさまざまな可能なDoS攻撃について議論するつもりです。 このリストは徹底的であるはずがありませんが、意図は可能性のスペクトルの良い概要に防御されるその必要性を提供することです。
We do not provide descriptions of any attacks that are not already publicly well documented.
私たちは既に公的によく記録されない少しの攻撃の記述も提供しません。
2.1. DoS Attacks on End-Systems
2.1. エンドシステムに対するDoS攻撃
We first discuss attacks on end-systems. An end-system in this context is typically a PC or network server, but it can also include any communication endpoint. For example, a router also is an end- system from the point of view of terminating TCP connections for BGP [10] or ssh [46].
私たちは最初に、エンドシステムに対する攻撃について議論します。エンドシステムは、このような関係においては通常PCかネットワークサーバですが、また、それはどんなコミュニケーション終点も含むことができます。 例えば、ルータもBGP[10]のためのTCP接続かセキュアシェル (SSH)[46]を終える観点からのエンドシステムです。
2.1.1. Exploiting Poor Software Quality
2.1.1. 貧しいソフトウェア品質を利用します。
The simplest DoS attacks on end-systems exploit poor software quality on the end-systems themselves, and cause that software to simply crash. For example, buffer-overflow attacks might be used to compromise the end-system, but even if the buffer-overflow cannot be used to gain access, it will usually be possible to overwrite memory and cause the software to crash. Such vulnerabilities can in principle affect any software that uses data supplied from the network. Thus, not only might a web server be potentially vulnerable, but it might also be possible to crash the back-end software (such as a database) to which a web server provides data.
エンドシステムに対する最も簡単なDoS攻撃で、エンドシステム自体の上の貧しいソフトウェア品質を利用して、そのソフトウェアは単にダウンします。 例えば、バッファオーバーフロー攻撃はエンドシステムに感染するのに使用されるかもしれませんが、アクセスを得るのにバッファオーバーフローを使用できないでも、通常、メモリを上書きして、ソフトウェアがダウンすることを引き起こすのは可能でしょう。 そのような脆弱性は原則としてネットワークから提供されたデータを使用するどんなソフトウェアにも影響できます。 したがって、単にではなくウェブサーバーは潜在的に被害を受け易いかもしれませんが、また、ウェブサーバーがデータを供給するバックエンドソフトウェア(データベースなどの)を墜落させるのも可能であるかもしれません。
Handley, et al. Informational [Page 4] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [4ページ]情報のRFC4732DoS問題2006年11月
Software crashes due to poor coding affect not only application software, but also the operating system kernel itself. A classic example is the so-called "ping of death", which became widely known in 1996 [21]. This exploit caused many popular operating systems to crash when sent a single fragmented ICMP echo request packet whose fragments totaled more than the 65535 bytes allowed in an IPv4 packet.
貧しいコード化によるソフトウェアクラッシュはアプリケーション・ソフトだけではなく、オペレーティングシステムカーネル自体にも影響します。 典型例は1996[21]で広く知れ渡ったいわゆる「死のピング」です。 多くのポピュラーなオペレーティングシステムがシングルを送るとき、ダウンするために引き起こされたこの功績は断片が65535バイトがIPv4パケットに許容した以上を合計したICMPエコー要求パケットを断片化しました。
While DoS attacks such as the ping of death are a significant problem, they are not a significant architectural problem. Once such an attack is discovered, the relevant code can easily be patched, and the problem goes away. We should note though that as more and more software becomes embedded, it is important not to lose the possibility of upgrading the software in such systems.
死のピングなどのDoS攻撃は重大な問題ですが、それらは重要な建築問題ではありません。 そのような攻撃がいったん発見されると、容易に関連コードにパッチすることができます、そして、問題は遠ざかります。 もっとも、私たちは、ますます多くのソフトウェアが埋め込まれるようになるのでそのようなシステムでソフトウェアをアップグレードさせる可能性を失わないのが重要であることに注意するべきです。
2.1.2. Application Resource Exhaustion
2.1.2. アプリケーションリソース疲労困憊
Network applications exist in a context that has finite resources. In processing network traffic, such an application uses these resources to do its intended task. However, an attacker may be able to prevent the application from performing its intended task by causing the application to exhaust the finite supply of a specific resource.
ネットワーク応用は有限な資源を持っている文脈に存在しています。 処理ネットワークトラフィックでは、そのようなアプリケーションが、意図しているタスクを果たすのにこれらのリソースを使用します。 しかしながら、攻撃者は、特定のリソースの有限供給がアプリケーションでくたくたになることを引き起こすことによってアプリケーションが意図しているタスクを実行するのを防ぐことができるかもしれません。
The obvious resources that might be exhausted include:
枯渇するかもしれない明白なリソースは:
o Available memory.
o 利用可能なメモリ。
o The CPU cycles available.
o CPUは利用可能な状態で循環します。
o The disk space available to the application.
o アプリケーションに利用可能な椎間腔。
o The number of processes or threads or both that the application is
permitted to use.
o アプリケーションが使用することが許可されているプロセス、スレッドまたは両方の数。
o The configured maximum number of simultaneous connections the
application is permitted.
o アプリケーションが受入れられる同時接続の構成された最大数。
This list is clearly not exhaustive, but it illustrates a number of points.
このリストは明確に徹底的ではありませんが、それは多くのポイントを例証します。
Some resources are self-renewing: CPU cycles fall in this category -- if the attack ceases, more CPU cycles become available.
いくつかのリソースが自己に更新されています: CPUサイクルはこのカテゴリで下がります--攻撃がやむなら、より多くのCPUサイクルが利用可能になります。
Some resources such as disk space require an explicit action to free up -- if the application cannot do this automatically then the effects of the attack may be persistent after the attack has ceased.
椎間腔などのいくつかのリソースが開ける明白な動作を必要とします--アプリケーションが自動的にこれができないなら、攻撃がやんだ後に攻撃の効果は永続的であるかもしれません。
Handley, et al. Informational [Page 5] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [5ページ]情報のRFC4732DoS問題2006年11月
This problem has been understood for many years, and it is common practice for logs and incoming email to be stored in a separate disk partition (/var on Unix systems) in order to limit the impact of exhaustion.
この問題は何年間も理解されています、そして、ログと入って来るメールが別々のディスクパーティション(Unixシステムの上の/var)で保存されるのは、疲労困憊の影響を制限する一般的な習慣です。
Some resources are constrained by configuration: the maximum number of processes and the maximum number of simultaneous connections are not normally hard limits, but rather are configured limits. The purpose of such limits is clearly to allow the machine to perform other tasks in the event the application misbehaves. However, great care needs to be taken to choose such limits appropriately. For example, if a machine's sole task is to be an FTP server, then setting the maximum number of simultaneous connections to be significantly less than the machine can service makes the attacker's job easier. But setting the limit too high may permit the attacker to cause the machine to crash (due to poor OS design in handling resource exhaustion) or permit livelock (see below), which are generally even less desirable failure modes.
いくつかのリソースが構成によって抑制されます: プロセスの最大数と同時接続の最大数は、通常困難な限界ではありませんが、むしろ構成された限界です。 そのような限界の目的はマシンがイベントにおける他のタスクを実行するのを許容するために、明確に、アプリケーションがふらちな事をするということです。 しかしながら、高度の注意は、適切にそのような限界を選ぶために取られる必要があります。 例えば、マシンの唯一のタスクがFTPサーバであることであるなら、同時接続の最大数にマシンが修理できるよりかなり少ないように設定するのに、攻撃者の仕事は、より簡単になります。 しかし、限界をあまり高く設定するのは、攻撃者が、マシンがlivelockを墜落するか(取り扱いリソース疲労困憊における貧しいOSデザインのため)、または可能にすることを引き起こすことを許可するかもしれません(一般に、それほど望ましくない故障モードですさえ)(以下を見てください)。
2.1.3. Operating System Resource Exhaustion
2.1.3. オペレーティングシステムリソース疲労困憊
Conceptually, OS resource exhaustion and application resource exhaustion are very similar. However, in the case of application resource exhaustion, the operating system may be able to protect other tasks from being affected by the DoS attack. In the case of the operating system itself running out of resources, the problem may be more catastrophic.
概念的に、OSリソース疲労困憊とアプリケーションリソース疲労困憊は非常に同様です。 しかしながら、アプリケーションリソース疲労困憊の場合では、オペレーティングシステムはDoS攻撃で影響を受けるのから他のタスクを保護できるかもしれません。 リソースを使い果たすオペレーティングシステム自体の場合では、問題は、より壊滅的であるかもしれません。
Perhaps the best-known DoS attack on an operating system is the TCP SYN-flood [19], which is essentially a memory-exhaustion attack. The attacker sends a flood of TCP SYN packets to the victim, requesting connection setup, but then does not complete the connection setup. The victim instantiates state to handle the incoming connections. If the attacker can instantiate state faster than the victim times it out, then the victim will run out of memory that it can use to hold TCP state, and so it cannot service legitimate TCP connection setup attempts. This issue was exacerbated in some implementations by the use of a small dedicated storage space for half-open connections, which made the attack easier than it might otherwise have been. In the case of a poorly coded operating system, running out of resources may also cause a system crash.
恐らくオペレーティングシステムに対する最もよく知られているDoS攻撃はTCP SYNフラッド[19]です。(そのSYNフラッドは、本質的にはメモリ疲労困憊攻撃です)。 攻撃者はTCP SYNパケットの洪水を犠牲者に送ります、接続設定を要求して次に、接続設定を終了しないで。 犠牲者は、接続要求を扱うために状態を例示します。 攻撃者が例示できるなら、外に犠牲者回より速くそれを述べてください、そして、次に、犠牲者がそれがTCP状態を保持するのに使用できるメモリを使い果たすので、それは正統のTCP接続設定試みを修理できません。 この問題はいくつかの実装で小さいひたむきな集積スペースの半開きな接続の使用で悪化させられました。そうでなければ、どれが攻撃をそれより簡単にしたかがあったかもしれません。 また、不十分にコード化されたオペレーティングシステムの場合では、リソースを使い果たすと、システムクラッシュは引き起こされるかもしれません。
An alternative TCP DoS attack is the Ack-flood [23], which is essentially a CPU exhaustion attack on the victim. The attacker floods the victim with TCP packets pretending to be from connections that have never been established. A busy server that has a large number of outstanding connections needs to check which connection the packet corresponds to. Some TCP implementations implemented this
代替のTCP DoS攻撃はAck-洪水[23]です。(その[23]は本質的には犠牲者に対するCPU疲労困憊攻撃です)。 TCPパケットが、一度も確立されたことがない接続からあるふりをしている状態で、攻撃者は犠牲者をあふれさせます。 多くの傑出している接続がある忙しいサーバは、パケットがどの接続に相当するかをチェックする必要があります。 これが実装されたいくつかのTCP実装
Handley, et al. Informational [Page 6] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [6ページ]情報のRFC4732DoS問題2006年11月
search rather inefficiently, and so the attacker could use all the victim's CPU resources servicing these packets rather than servicing legitimate requests.
かなり効率悪い、攻撃者が正統の要求を修理するよりむしろこれらのパケットを調整しながらすべての犠牲者のCPUリソースを使用できたには、探してください。
We note that strong authentication mechanisms do not necessarily mitigate against such CPU exhaustion attacks. In fact, poorly designed authentication mechanisms using cryptographic methods can exacerbate the problem. If such an authentication mechanism allows an attacker to present a packet to the victim that requires relatively expensive cryptographic authentication before the packet can be discarded, then this makes the attacker's CPU exhaustion attack easier.
私たちは、強い認証機構が必ずそのようなCPU疲労困憊攻撃を困難にするというわけではないことに注意します。 暗号のメソッドを使用する事実上と、不十分に設計された認証機構は問題を悪化させることができます。 攻撃者がそのような認証機構でパケットを捨てることができる前に比較的高価な暗号の認証を必要とする犠牲者にパケットを提示できるなら、これで、攻撃者のCPU疲労困憊攻撃は、より簡単になります。
CPU exhaustion attacks can be also be exacerbated by poor OS handling of incoming network traffic. In the absence of malicious traffic, an ideal OS should behave as follows:
CPU疲労困憊攻撃はそうであることができます、また、入って来るネットワークトラフィックの不十分なOS取り扱いで、悪化させられてください。 悪意があるトラフィックがないとき、理想的なOSは以下の通り振る舞うべきです:
o As incoming traffic increases, the useful work done by the OS
should increase until some resource (such as the CPU) is saturated.
o 入って来るトラフィックが増加するのに従って、何らかのリソース(CPUなどの)が飽和するまで、OSで行われた実質的な仕事は増加するべきです。
o From this point on, as incoming traffic continues to increase the
useful work done should be constant.
o この地点から先は、入って来るトラフィックが、増加し続けているとき、行われた実質的な仕事は一定であるべきです。
However, this is often not the case. Many systems suffer from livelock [33] where, after saturation, increasing the load causes a decrease in the useful work done. One cause of this is that the system spends an increasing amount of time processing network interrupts for packets that will never be processed, and hence a decreasing amount of time is available for the application for which these packets were intended.
しかしながら、これはしばしばそうであるというわけではありません。 多くのシステムが飽和の後に負荷を増強すると行われた実質的な仕事の減少が引き起こされるところでlivelock[33]が欠点です。 この1つの原因はシステムが決して処理されないパケットのためのネットワーク中断を処理するのに増加する時間を費やすということです、そして、したがって、減少している時間はこれらのパケットが意図したアプリケーションに空いています。
2.1.4. Triggered Lockouts and Quota Exhaustion
2.1.4. 引き起こされたロックアウトと割当て疲労困憊
Many user-authentication mechanisms attempt to protect against password guessing attacks by locking the user out after a small number of failed authentications. If an attacker can guess or discover a user's ID, they may be able to trigger such a mechanism, locking out the legitimate user.
多くのユーザー認証メカニズムが、少ない数の失敗した認証の後にユーザを締め出すことによってパスワード推測攻撃から守るのを試みます。 攻撃者がユーザのIDを推測するか、または発見できるなら、そのようなメカニズムの引き金となることができるかもしれません、正統のユーザを締め出して。
Another way to deny service using protection mechanisms is to cause a quota to be exhausted. This is perhaps most common in the case of small web servers being commercially hosted, where the server has a contract with the hosting company allowing a fixed amount of traffic per day. An attacker may be able to rapidly exhaust this quota, and cause service to be suspended. Similar attacks may be possible against other forms of quota.
保護メカニズムを使用することでサービスを否定する別の方法は割当てが消耗することを引き起こすことです。 商業的にホスティングされる小さいウェブサーバーの場合でこれは恐らく最も一般的です。(そこでは、サーバが1日あたりのトラフィックの定額を許容する接待している会社との契約を持っています)。 攻撃者は、中断するためにこの割当て、および原因サービスを急速に消耗させることができるかもしれません。 同様の攻撃は他のフォームの割当てに対して可能であるかもしれません。
Handley, et al. Informational [Page 7] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [7ページ]情報のRFC4732DoS問題2006年11月
In the absence of such quotas, if the victim is charged for their network traffic, a financial denial-of-service may be possible.
そのような割当てがないとき、犠牲者がそれらのネットワークトラフィックに請求されるなら、財政的なサービスの否定は可能であるかもしれません。
2.2. DoS Attacks on Routers
2.2. ルータに対するDoS攻撃
Many of the denial-of-service attacks that can be launched against end-systems can also be launched against the control processor of an IP router, for example, by flooding the command and control access ports. In the case of a router, these attacks may cause the router to stall, or may cause the router to cease processing routing packets. Even if the router does not stop servicing routing packets, it may become sufficiently slow that routing protocols time out. In any of these circumstances, the consequence of routing failure is not only that the router ceases to forward traffic, but also that it causes routing protocol churn that may have further side effects.
また、例えば、IPルータの制御プロセッサに対して指揮統制アクセスポートをあふれさせることによって、エンドシステムに対して着手できるサービス不能攻撃の多くを始めることができます。 ルータの場合では、これらの攻撃で、ルータが失速することを引き起こすか、またはルータは、ルーティングパケットを処理するのをやめるかもしれません。 ルータが、ルーティングパケットを調整するのを止めないでも、それは十分遅いそんなに掘っているプロトコルタイムアウトになるかもしれません。 これらの事情のいずれではも、単に、ルーティング失敗の結果はルータが、トラフィックを進めるのをやめますが、一層の副作用を持っているかもしれないルーティング・プロトコル攪乳器をまた引き起こすということではありません。
An example of such a side effect is caused by BGP route flap damping [11], which is intended to reduce global routing churn. If an attacker can cause BGP routing churn, route flap damping may then cause the flapping routes to be suppressed [31]. This suppression likely causes the networks served by those routes to become unreachable.
そのような副作用に関する例はグローバルなルーティング攪乳器を減少させることを意図する[11]をじめじめとするBGPルートフラップによって引き起こされます。 攻撃者がBGPを引き起こす場合があるなら、ルーティングは動揺します、次に、ルートフラップ湿気はばたつくルートを抑圧するかもしれません。[31]。 この抑圧によって、それらのルートで役立たれるネットワークはおそらく手が届かなくなります。
A DoS attack on the router control processor might also prevent the router from being managed effectively. This may prevent actions being taken that would mitigate the DoS attack, and it might prevent diagnosis of the cause of the problem.
また、ルータ制御プロセッサに対するDoS攻撃は、ルータが有効に管理されるのを防ぐかもしれません。 これはDoS攻撃を緩和する取られる行動を防ぐかもしれません、そして、それは問題の原因の診断を防ぐかもしれません。
2.2.1. Attacks on Routers through Routing Protocols
2.2.1. ルーティング・プロトコルを通したルータに対する攻撃
In addition to their roles as end-systems, most routers run dynamic routing protocols. The routing protocols themselves can be used to stage a DoS attack on a router or a network of routers. This requires the ability to send traffic from addresses that might plausibly have generated the relevant routing messages, which is somewhat difficult with interior routing protocols but fairly easy with External Border Gateway Protocol (eBGP), for instance.
エンドシステムとしてのそれらの役割に加えて、ほとんどのルータがダイナミックルーティングプロトコルを実行します。 ルータに対するDoS攻撃かルータのネットワークを上演するのにルーティング・プロトコル自体を使用できます。 これはもっともらしく関連ルーティング・メッセージを生成したかもしれないアドレスからトラフィックを送る例えば能力を必要とします。(内部のルーティング・プロトコルによっていくらか難しいのですが、それは、Externalボーダ・ゲイトウェイ・プロトコル(eBGP)でかなり簡単です)。
The simplest attack on a network of routers is to overload the routing table with sufficiently many routes that the router runs out of memory, or the router has insufficient CPU power to process the routes [26]. We note that depending on the distribution and capacities of various routers around the network, such an attack might not overwhelm routers near to the attacking router, but might cause problems to show up elsewhere in the network.
ルータのネットワークに対する最も簡単な攻撃がルータがメモリから動かす十分多くのルートがある経路指定テーブルを積みすぎることであるまたはルータにはルート[26]を処理する不十分なCPUパワーがあります。 私たちは、ネットワークの周りで様々なルータの分配と能力によって、そのような攻撃が攻撃ルータに近いルータを圧倒しませんが、ネットワークにおけるほかの場所から現れるように問題を起こすかもしれないことに注意します。
Some routing protocol implementations allow limits to be configured on the maximum number of routes to be heard from a neighbor [27].
いくつかのルーティング・プロトコル実装が、限界が隣人[27]から聞かれるためにルートの最大数で構成されるのを許容します。
Handley, et al. Informational [Page 8] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [8ページ]情報のRFC4732DoS問題2006年11月
However, limits often make the problem worse rather than better, by making it possible for the attacker to push out legitimate routes with spoofed routes, thus creating an easy form of DoS attack.
しかしながら、限界で、問題はしばしばより良いというよりむしろより悪くなります、攻撃者がルートであると偽造されて、その結果、簡単な形式のDoS攻撃を作成するのに正統のルートを押し出すのを可能にすることによって。
An alternative attack is to overload the routers on the network by creating sufficient routing table churn that routers are unable to process the changes. Many routing protocols allow damping factors to be configured to avoid just such a problem. However, as with table size, such a threshold applied inconsistently may allow the spoofed routes to merge with legitimate routes before the mechanism is applied, causing legitimate routes to be damped.
代替の攻撃はネットワークで変化を処理できない状態でルータがそうである十分な経路指定テーブル攪乳器を作成することによってルータを積みすぎることです。 多くのルーティング・プロトコルが、制動係数がまさしくそのような問題を避けるために構成されるのを許容します。 しかしながら、テーブル・サイズなら、相反して適用されたそのような敷居で、メカニズムが適用されている前に偽造しているルートは正統のルートと合併できるかもしれません、正統のルートがじめじめとすることを引き起こして。
The simplest routing attack on a specific destination is for an attacker to announce a spoofed desirable route to that destination. Such a route might be desirable because it has low metric, or because it is a more specific route than the legitimate route. In any event, if the route is believed, it will cause traffic for the victim to be drawn towards the attacking router, where it will typically be discarded.
特定の目的地に対する最も簡単なルーティング攻撃は攻撃者が偽造している望ましいルートをその目的地に発表することです。 安値をメートル法にするか、またはそれが正統のルートより特定のルートであるので、そのようなルートは望ましいかもしれません。 とにかく、ルートが信じられていると、攻撃ルータに向かって引かれるべき犠牲者のためにトラフィックを引き起こすでしょう、それが通常捨てられるところで。
A more subtle denial-of-service attack might be launched against a network rather than against a destination. Under some circumstances, the propagation of inconsistent routing information can cause traffic to loop. If an attacker can cause this to happen on a busy path, the looping traffic might cause significant congestion, as well as fail to reach the legitimate destination.
より微妙なサービス不能攻撃は目的地に対してというよりむしろネットワークに対して着手されるかもしれません。 いくつかの状況で、トラフィックは矛盾したルーティング情報の伝播で輪にされることができます。 攻撃者が忙しい経路でこれを起こらせることができるなら、ループトラフィックは、重要な混雑を引き起こして、正統の目的地に達しないかもしれません。
In the past, there have been cases where different generations of routers interpreted a routing protocol specification differently. In particular, BGP specifies that in the case of an error, the BGP peering should be dropped. However, if some of the routers in a network treat a particular route as valid and other routers treat the route as invalid, then it may be possible to inject a BGP route at one point in the Internet and cause peerings to be dropped at many other places in the Internet. Unlike many of the examples above, while such an issue might be a serious short-term problem, this is not a fundamental architectural problem. Once the problem is understood, deploying patched routing code can permanently solve the issue.
過去に、ケースがルータの異なった世代がルーティングプロトコル仕様を異なって解釈したところにありました。 特に、BGPは、誤りの場合では、BGPのじっと見ることが下げられるべきであると指定します。 しかしながら、ネットワークにおけるルータのいくつかが有効であるとして特定のルートを扱って、他のルータが病人としてルートを扱うなら、インターネットとインターネットの他の多くの場所で下げられるべき原因peeringsの1ポイントでBGPルートを注入するのは可能であるかもしれません。 上記の例の多くと異なって、そのような問題は重大な短期的な問題であるかもしれませんが、これは基本的な建築問題ではありません。 問題がいったん理解されていると、ルーティングコードであるとパッチされた展開は永久に、問題を解決できます。
2.2.2. IP Multicast-based DoS Attacks
2.2.2. IPのマルチキャストベースのDoS攻撃
There are essentially two forms of IP multicast: traditional Any- Source Multicast (ASM), as specified in RFC 1112 [4] where multiple sources can send to the same multicast group, and Source-Specific Multicast (SSM) where the receiver must specify both the IP source address and the group address. The two forms of multicast provide rather different DoS possibilities.
本質的には、IPマルチキャストの2つのフォームがあります: 伝統的なAnyソースMulticast(ASM)、複数のソースがそうすることができるRFC1112[4]で指定されるように、受信機がIPソースアドレスとグループアドレスの両方を指定しなければならない同じマルチキャストグループ、およびSource特有のMulticast(SSM)に発信してください。 マルチキャストの2つのフォームがかなり異なったDoSの可能性を提供します。
Handley, et al. Informational [Page 9] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [9ページ]情報のRFC4732DoS問題2006年11月
ASM protocols such as PIM-SM [6], MSDP [32], and DVMRP [12] typically cause some routers to instantiate routing state at the time a packet is sent to a multicast group. They do this to ensure that the traffic goes to the group receivers and not to non-receivers. Such protocols are particularly vulnerable to DoS attacks, as an attacker that sends to many multicast groups may cause both multicast routing table explosion (and hence control processor memory exhaustion) and multicast forwarding table exhaustion (and hence forwarding card memory exhaustion or thrashing).
PIM-SM[6]や、MSDP[32]や、DVMRP[12]などのASMプロトコルで、マルチキャストグループにパケットを送るとき、いくつかのルータがルーティング状態を通常例示します。 彼らは、トラフィックが非受信機ではなく、グループ受信機に行くのを保証するためにこれをします。 そのようなプロトコルは特にDoS攻撃に被害を受け易いです、多くのマルチキャストグループに発信する攻撃者がマルチキャスト経路指定テーブル爆発(したがって、プロセッサメモリ疲労困憊を制御する)とマルチキャスト推進テーブル疲労困憊の両方を引き起こすとき(したがって、カードメモリ疲労困憊か打つことを進めて)。
ASM also permits an attacker to send traffic to the same group as legitimate traffic, potentially causing network congestion and denying service to the legitimate group.
また、ASMは、攻撃者が正統のトラフィックと同じグループにトラフィックを送るのを可能にします、潜在的にネットワークの混雑を引き起こして、正統のグループに対するサービスを否定して。
SSM does not permit senders to send to arbitrary groups unless a receiver has requested the traffic. Thus, sender-based attacks on multicast routing state are not possible with SSM. However, as with ASM, a receiver can still join a large number of multicast groups causing routers to hold a large amount of multicast routing state, potentially causing memory exhaustion and hence denial-of-service to legitimate traffic.
受信機がトラフィックを要求していない場合、SSMは、送付者が任意のグループに発信するのを可能にしません。 マルチキャストルーティング状態に対するしたがって、送付者ベースの攻撃はSSMで可能ではありません。 しかしながら、ASMなら、受信機はまだルータに多量のマルチキャストルーティング状態を保持させる多くのマルチキャストグループに加わることができます、潜在的にメモリ疲労困憊としたがって、サービスの否定を正統のトラフィックに引き起こして。
With IPv6, hosts are required to send ICMP Packet Too Big or Parameter Problem messages under certain circumstances, even if the destination address is a multicast address. If the attacker can place himself in the appropriate position in the multicast tree, a packet with an unknown but mandatory Destination Option, for instance, could generate a very large number of responses to the claimed sender.
IPv6と共に、ホストはICMP Packet Too BigかParameter Problemにメッセージをある状況で送らなければなりません、送付先アドレスがマルチキャストアドレスであっても。 攻撃者がマルチキャスト木で適切な位置に自分を任命できるなら、例えば、未知の、しかし、義務的なDestination Optionがあるパケットは要求された送付者への非常に多くの応答を生成するかもしれません。
With IPv4, the same problem exists with multicast ICMP Echo Request packets, but these are somewhat easier to filter.
IPv4と共に、同じ問題はマルチキャストICMP Echo Requestパケットで存在していますが、これらはいくらかフィルターにかけやすいです。
The examples above should not be taken as exhaustive. These are actually specific cases of a general problem that can happen when a multicast/broadcast request solicits a reply from a large number of nodes.
徹底的であるとして上記の例をみなすべきではありません。 これらはマルチキャスト/放送要求が多くのノードから回答に請求するとき起こることができる一般的問題の実際に特定のケースです。
2.2.3. Attacks on Router Forwarding Engines
2.2.3. ルータ推進エンジンに対する攻撃
Router vendors implement many different mechanisms for packet forwarding, but broadly speaking they fall into two categories: ones that use a forwarding cache, and ones that do not. With a forwarding cache, the forwarding engine does not hold the full routing table, but rather holds just the currently active subset of the forwarding table.
ルータベンダーはパケット推進のために多くの異なったメカニズムを実装しますが、2つのカテゴリになります: 推進キャッシュを使用するもの、およびそうしないもの。 推進キャッシュによって、推進エンジンは、完全な経路指定テーブルを持っていませんが、むしろまさしく推進テーブルの現在アクティブな部分集合を保持します。
Handley, et al. Informational [Page 10] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [10ページ]情報のRFC4732DoS問題2006年11月
Many modern routers use a loosely coupled architecture, where one or more control processors handle the routing protocols and communicate over an internal network link to special-purpose forwarding engines, which actually forward the data traffic. In such architectures, it may be possible for an attacker to overwhelm the communications link between the control processor and the forwarding engine. This is possible because the forwarding engines support very high speed links, and the control processor simply cannot handle a similar rate of traffic.
(そこでは、1台以上の制御プロセッサがルーティング・プロトコルを扱います)。多くの現代のルータが、緩く結合したアーキテクチャを使用して、専用推進エンジンへの内部のネットワークリンクの上に交信します。実際に、エンジンはデータ通信量を進めます。 そのようなアーキテクチャでは、攻撃者が制御プロセッサと推進エンジンとのコミュニケーションリンクを圧倒するのは、可能であるかもしれません。 推進エンジンが、非常に高い速度がリンクであるとサポートするので、これは可能です、そして、制御プロセッサはトラフィックの同様のレートを絶対に扱うことができません。
There may be many ways in which an attacker can trigger communication between the forwarding engines and the control processor. The simplest way is for the attacker to simply send to the router's IP address, but this should in principle be relatively easy to prevent using filtering on the forwarding engines. Another way might be to cause the router to forward data packets using the "slow path". This involves sending packets that require special attention from the forwarding router; if the forwarding engine is not smart enough to perform such forwarding, then it will typically pass the packet to the control processor. In a router using a forwarding cache, it may be possible to overload the internal communications by thrashing the forwarding cache. Finally, any form of data-triggered communication between the forwarding engine and the control processor might cause such a problem. Certain multicast routing protocols including PIM-SM contain many such data triggered events that could potentially be problematic.
攻撃者が推進エンジンと制御プロセッサとのコミュニケーションの引き金となることができる多くの方法があるかもしれません。 最も簡単な道が攻撃者が単にルータのIPアドレスに発信することですが、これは推進エンジンの上にフィルタリングを使用するのを防ぐのが原則として比較的簡単であるはずです。 別の方法はルータがデータ・パケットを進めることを「遅い経路」を使用することで引き起こすことであるかもしれません。 これは、推進ルータから特別な注意を必要とするパケットを送ることを伴います。 推進エンジンがそのような推進を実行できるくらいには賢くないなら、それは制御プロセッサにパケットを通常通過するでしょう。 推進キャッシュを使用するルータでは、推進キャッシュを打たせることによって内部のコミュニケーションを積みすぎるのは可能であるかもしれません。 最終的に、推進エンジンと制御プロセッサとのどんなフォームのデータで引き起こされたコミュニケーションもそのような問題を引き起こすかもしれません。 PIM-SMを含むあるマルチキャストルーティング・プロトコルがそのような多くの潜在的に問題が多いかもしれないデータ引き起こされたイベントを含んでいます。
The effects of overloading such internal communications are hard to predict and are very implementation-dependent. One possible effect might be that the forwarding table in the forwarding engine gets out of synchronization with the routing table in the control processor that reflects what the routing protocols believe is happening. This might cause traffic to be dropped or to loop.
そのような内部のコミュニケーションを積みすぎるという効果は、予測しにくくて、実装非常に依存しています。 1つの可能な効果は推進エンジンの推進テーブルが起こっているルーティング・プロトコルが信じていることを反映する制御プロセッサの経路指定テーブルとの同期を出るということであるかもしれません。 これは、トラフィックが下げられるか、または輪にされることを引き起こすかもしれません。
Finally, if an attacker can generate traffic that causes a router to auto-install access control list (ACL) entries, perhaps by triggering a response from an intrusion detection system, then it may be possible to exhaust the ACL resources on the router. This might prevent future attacks from being filtered, or worse, cause ACL processing to be handled by the route processor.
最終的に、攻撃者が自動インストールアクセスコントロールリスト(ACL)エントリーにルータを引き起こすトラフィックを生成することができるなら、その時、恐らく侵入検知システムから応答の引き金となることによって、ルータに関するACLリソースを枯渇させるのは可能であるかもしれません。 これは、ルートプロセッサによって扱われるために今後の攻撃がフィルターにかけることの、または、より悪い原因ACL処理であることを防ぐかもしれません。
2.3. Attacks on Ongoing Communications
2.3. 進行中のコミュニケーションに対する攻撃
Instead of attacking the end-system itself, it is also possible for an attacker to disrupt ongoing communications. If an attacker can observe a TCP connection, then it is relatively easy for them to spoof packets to either reset that connection or to de-synchronize it so that no further progress can be made [29]. Such attacks are not
また、エンドシステム自体を攻撃することの代わりに、攻撃者が通信の進行中のシステムを遮断するのも、可能です。 攻撃者がTCP接続を観察できるなら、彼らがその接続をリセットするか、またはどんなさらなる進歩も人工の[29]であることができないように反-それを連動させるようにパケットを偽造するのは、比較的簡単です。 そのような攻撃はそうではありません。
Handley, et al. Informational [Page 11] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [11ページ]情報のRFC4732DoS問題2006年11月
prevented by transport or application-level security mechanisms such as TLS [5] or ssh, because the authentication takes place after TCP has finished processing the packets.
TLS[5]かセキュアシェル (SSH)などの輸送かアプリケーションレベルセキュリティー対策で、TCPが、パケットを処理し終えた後に認証が行われるので、防がれます。
If an attacker cannot observe a TCP connection, but can infer that such a connection exists, it is theoretically possible to reset or de-synchronize that connection by spoofing packets into the connection. However, this might require an excessively large number of spoofed packets to guess both the port of the active end of the TCP connection (in most cases, the port of the passive end is predictable) and the currently valid TCP sequence numbers. However, as some operating systems have poorly implemented predictable algorithms for selecting either the dynamically selected port or the TCP initial sequence number [41] [20], then such attacks have been found to be feasible [34]. Advice as to how to reduce the vulnerability in the specific case of TCP is available in [37].
攻撃者が、TCP接続を観察できませんが、そのような接続が存在すると推論できるなら、スプーフィングパケットでその接続を接続とリセットするか、または反-同時にさせるのが理論的に可能です。 しかしながら、これは、TCP接続(多くの場合、受け身の終わりのポートは予測できる)のアクティブな終わりのポートと現在有効なTCP一連番号の両方を推測するために過度に多くの偽造しているパケットを必要とするかもしれません。 しかしながら、いくつかのオペレーティングシステムがダイナミックに選択されたポートかTCP初期シーケンス番号[41][20]のどちらかを選択するための予測できるアルゴリズムを不十分に実装したとき、そして、そのような攻撃は可能な[34]であることがわかりました。 TCPの特定の場合における脆弱性をどう減少させるかに関するアドバイスは[37]で利用可能です。
An attacker might be able to significantly reduce the throughput of a connection by sending spoofed ICMP source quench packets, although most modern operating systems should ignore such packets. However, care should be taken in the design of future transport and signaling protocols to avoid the introduction of similar mechanisms that could be exploited.
攻撃者はICMPソース焼き入れパケットであると偽造された発信するのによる接続に関するスループットをかなり減らすことができるかもしれません、ほとんどの近代的なオペレーティングシステムがそのようなパケットを無視するべきですが。 しかしながら、注意は、今後の輸送のデザインで取られて、利用できた同様のメカニズムの導入を避けるようにプロトコルに示すべきです。
2.4. Attacks Using the Victim's Own Resources
2.4. 犠牲者の自己のリソースを使用する攻撃
Instead of directly overloading the victim, it may be possible to cause the victim or a machine on the same subnet as the victim to overload itself.
直接犠牲者を積みすぎることの代わりに、犠牲者と同じサブネットの犠牲者かマシンがそれ自体を積みすぎることを引き起こすのは可能であるかもしれません。
An example of such an attack is documented in [18], where the attacker spoofs the source address on a packet sent to the victim's UDP echo port. The source address is that of another machine that is running a UDP chargen server (a chargen server sends a character pattern back to the originating source). The result is that the two machines bounce packets back and forth as fast as they can, overloading either the network between them or one of the end-systems itself.
そのような攻撃に関する例は[18]に記録されます。そこでは、攻撃者が犠牲者のUDPエコーポートに送られたパケットに関するソースアドレスを偽造します。 ソースアドレスはUDP chargenサーバを実行している別のマシンのもの(chargenサーバはキャラクタパターンを起因しているソースに送り返す)です。 結果は2台のマシンが前後までパケットをできるだけ速く弾ませるということです、それらかエンドシステムの1つの間のネットワーク自体を積みすぎて。
2.5. DoS Attacks on Local Hosts or Infrastructure
2.5. ローカル・ホストかインフラストラクチャに対するDoS攻撃
There are a number of attacks that might only be performed by a local attacker.
地元の攻撃者によって実行されるだけであるかもしれない多くの攻撃があります。
An attacker with access to a subnet may be able to prevent other local hosts from accessing the network at all by simply exhausting the address pool allocated by a Dynamic Host Configuration Protocol (DHCP) server. This requires being able to spoof the MAC address of
サブネットへのアクセスの攻撃者は、Dynamic Host Configuration Protocol(DHCP)サーバによって割り当てられたアドレスプールを単に消耗させることによって他のローカル・ホストが全くネットワークにアクセスするのを防ぐことができるかもしれません。これは、MACがアドレスであると偽造することができるのを必要とします。
Handley, et al. Informational [Page 12] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [12ページ]情報のRFC4732DoS問題2006年11月
an ethernet or wireless card, but this is quite feasible with certain hardware and operating systems.
イーサネットかしかし、ワイヤレス・カード、これが、あるハードウェアとオペレーティングシステムでかなり可能です。
An alternative DHCP-based attack is simply to respond faster than the legitimate DHCP server, and to give out an address that is not useful to the victim.
代替のDHCPベースの攻撃は、単に正統のDHCPサーバより速く応じて、犠牲者の役に立たないアドレスを配ることです。
These sorts of bootstrapping attacks tend to be difficult to avoid because most of the time trust relationships are established after IP communication has already been established.
これらの種類のブートストラップ法攻撃は、信頼関係がたいてい確立されるので、IPコミュニケーションが既に確立された後に、避けるのが難しい傾向があります。
Similar attacks are possible through ARP spoofing [16]; an attacker can respond to ARP requests before the victim and prevent traffic from reaching the victim. Some brands of ethernet switch allow an even simpler attack: simply send from the victim's MAC address, and the switch will redirect traffic destined for the victim to the attacker's port. This attack might also potentially be used to block traffic from the victim by engaging screening or flap-dampening algorithms in the switch, depending on the switch design.
同様の攻撃は[16]を偽造しながら、ARPを通して可能です。 攻撃者は、犠牲者の前でARP要求に応じて、トラフィックが犠牲者に届くのを防ぐことができます。 イーサネットスイッチのいくつかのブランドがさらに簡単な攻撃を許します: 犠牲者のMACアドレスから単に発信してください。そうすれば、スイッチは犠牲者のために攻撃者のポートに運命づけられたトラフィックを向け直すでしょう。 また、この攻撃は犠牲者から選別かフラップを弱まらせているアルゴリズムにスイッチに従事していることによって交通の妨害になるのに潜在的に使用されるかもしれません、スイッチデザインによって。
It may be possible to cause broadcast storms [16] on a local LAN by sending a stream of unicast IP packets to the broadcast MAC address. Some hosts on the LAN may then attempt to forward the packets to the correct MAC address, greatly amplifying the traffic on the LAN.
地方のLANでユニキャストIPパケットの流れを放送MACアドレスに送ることによってブロードキャスト・ストーム[16]を引き起こすのは可能であるかもしれません。 次に、LANの何人かのホストが、正しいMACアドレスにパケットを送るのを試みるかもしれません、LANでトラフィックを大いに増幅して。
802.11 wireless networks provide many opportunities to deny service to other users. In some cases, the lack of defenses against DoS was a deliberate choice--because 802.11 operates on unlicensed spectrum it was assumed that there would be sources of interference and that producing intentional radio-level jamming would be trivial. Thus, the amount of DoS protection possible at higher levels was minimal.
802.11 ワイヤレスのネットワークは他のユーザに対するサービスを否定する多くの機会を提供します。 いくつかの場合、DoSに対するディフェンスの不足は慎重な選択でした--802.11が無免許のスペクトルを作動させるので、干渉の源があって、意図的なラジオレベルジャムを生産するのが些細であると思われました。 したがって、より高いレベルで可能なDoS保護の量は最小限でした。
Nevertheless, some of the weaknesses of the protocols against more sophisticated attacks are worth noting. The most prominent of these is that association is unprotected, thus allowing rogue access points (APs) to solicit notifications that would otherwise have gone to legitimate APs.
それにもかかわらず、より洗練された攻撃に対するプロトコルの弱点のいくつかは注意する価値があります。 これらで最も際立つのは、協会が保護がないということです、その結果、凶暴なアクセスポイント(APs)がそうでなければ正統のAPsに行った通知に請求するのを許容します。
The SSID field provides effectively no defense against this kind of attack. Unless encryption is enabled, it is trivial to announce the presence of a base station (or even of an ad-hoc mode host) with the same network name (SSID) as the legitimate basestation. Even adding authentication and encryption a la 802.1X and 802.11i may not help much in this respect. The SSID space is unmanaged, so everyone is free to put anything they want in the SSID field. Most host stacks don't deal gracefully with this. Moreover, SSIDs are very often set to the manufacturer's default, making them highly predictable.
SSID分野は有効にこの種類の攻撃に対してディフェンスを全く提供しません。 暗号化が可能にされない場合、正統のbasestationと同じネットワーク名(SSID)で基地局(またはアドホック・モードホストについてさえ)の存在を示すのは些細です。 この点で多くの助けではなく、la802.1Xと802.11iがそうする認証と暗号化を加えさえします。 SSIDスペースが非管理されるので、皆は自由に彼らが欲しいものをSSID分野に置くことができます。 ほとんどのホストスタックは優雅にこれに対処しません。 そのうえ、彼らを非常に予測できるようにして、SSIDsは頻繁にメーカーのデフォルトに用意ができています。
Handley, et al. Informational [Page 13] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [13ページ]情報のRFC4732DoS問題2006年11月
Some 802.11 basestations have limited memory for the number of associations they can support. If this is exceeded, they may drop all associations. In an attempt to forestall this problem, some APs advertise their load so as to enable stations to choose APs that are less loaded. However, crude implementations of these algorithms can result in instability.
およそ802.11basestationsがそれらがサポートすることができる協会の数のためのメモリを制限しました。 これが超えられているなら、彼らはすべての協会を下げるかもしれません。 この問題を出し抜く試みでは、いくつかのAPsが、ステーションがそれほど積み込まれないAPsを選ぶのを可能にするために彼らの負荷の広告を出します。 しかしながら、これらのアルゴリズムの粗雑な実装は不安定性をもたらすことができます。
Finally, as the authentication in 802.11 takes place at a comparatively high level in the stack, it is possible to simply deauthenticate or disassociate the victim from the basestation, even if Wired Equivalent Privacy (WEP) is in use [30]. Bellardo and Savage [15] describe some simple remedies that reduce the effectiveness of such attacks. While IEEE 802.11w will protect Deauthenticate or Disassociate frames, this attack is still possible via forging of Association frames.
最終的に、802.11における認証がスタックの比較的高いレベルで行われるとき、それが単にdeauthenticateに可能であるか、またはbasestationから犠牲者を分離してください、WEP(WEP)が使用[30]であっても。 Bellardoとサヴェージ[15]はそのような攻撃の有効性を減少させるいくつかの簡単な療法を説明します。 IEEE 802.11wはDeauthenticateかDisassociateフレームを保護するでしょうが、この攻撃はAssociationフレームの鍛造物でまだ可能です。
What all these attacks have in common is that they exploit vulnerabilities in the link auto-configuration mechanisms. In a wireless network, it is necessary for a station to detect the presence of APs in order to choose which one to connect to. In 802.11, this is handled via the Beacon and Probe Request/Response mechanisms.
これらのすべての攻撃が共通であることはリンク自動構成メカニズムの脆弱性を利用するということです。ワイヤレス・ネットワークでは、ステーションがAPsの存在を検出するのが、どれに接続するかを選ぶのに必要です。 802.11では、これはBeaconとProbe Request/反応機構で扱われます。
Beacons cannot easily be encrypted, because the station needs to utilize them prior to authentication in order to discover which APs it may wish to communicate with. Since authentication can only occur after interpreting the Beacon, an encrypted Beacon would present a chicken-egg problem: you can't obtain a key to decrypt the Beacon until completing authentication, and you may not be able to figure out which AP to authenticate with prior to decrypting the Beacon. Note that in principle you could encrypt Beacons with a shared (per-AP) key but this would require each station to trial-decrypt beacons until it finds one that matches up to whatever shared authentication secret it had. This is not particularly convenient.
容易に標識を暗号化できません、ステーションが、認証の前にそれがどのAPsとコミュニケートしたがっているかもしれないかを発見するのにそれらを利用する必要があるので。 Beaconを解釈した後に認証が起こることができるだけであるので、暗号化されたBeaconは鶏の卵問題を提示するでしょう: あなたは認証を終了するまでBeaconを解読するためにキーを入手できません、そして、解読する前にBeaconと共にどのAPを認証したらよいかを理解できないかもしれません。 原則として、共有された(1APあたりの)キーでBeaconsを暗号化できましたが、それにはどういった共有された認証秘密があるかまで合っているものを見つけるまでこれが、各ステーションが標識をトライアルで解読するのを必要とすることに注意してください。 これは特に便利ではありません。
As a result, discussions of Beacon frame security have largely focused on authentication of Beacon frames, not encryption. Even here, solutions are difficult. While it may be possible for a station to validate a Beacon *after* authentication (either by checking a Message Integrity Check (MIC) computed with the group key provided by the AP or verifying the Beacon parameters during the 4-way handshake), doing so *before* authentication may require synchronization of keys between APs within an SSID.
その結果、Beaconフレームセキュリティの議論は暗号化ではなく、Beaconフレームの認証に主に焦点を合わせました。 ここでさえ、ソリューションは難しいです。 ステーションが*認証(どちらかグループキーがAPによって提供されている状態で計算されるか、または4ウェイ握手の間、Beaconパラメタについて確かめながらMessage Integrity Check(MIC)をチェックするのによる)の後にBeacon*を有効にするのが、可能であるかもしれない間、*認証の前にそう*をするのはSSIDの中のAPsの間のキーの同期を必要とするかもしれません。
Handley, et al. Informational [Page 14] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [14ページ]情報のRFC4732DoS問題2006年11月
2.6. DoS Attacks on Sites through DNS
2.6. DNSを通したサイトに対するDoS攻撃
In today's Internet, DNS is of sufficient importance that if access to a site's DNS servers is denied, the site is effectively unreachable, even if there is no actual communication problem with the site itself.
今日のインターネットでは、DNSは十分重要であり、サイトのDNSサーバへのアクセスであるなら否定される事実上、サイトは手が届きません、サイト自体に関するどんな実際の意思疎通の問題もなくても。
Many of the attacks on end-systems described above can be perpetrated on DNS servers. As servers go, DNS servers are not particularly vulnerable to DoS. So long as a DNS server has sufficient memory, a modern host can usually respond very rapidly to DNS requests for which it is authoritative. This was demonstrated in October 2002 when the root nameservers were subjected to a very large DoS attack [38]. A number of the root nameservers have since been replicated using anycast [1] to further improve their resistance to DoS. However, it is important for authoritative servers to have relaying disabled, or it is possible for an attacker to force the DNS servers to hold state [40].
DNSサーバで上で説明されたエンドシステムに対する攻撃の多くを犯すことができます。 サーバが動くとき、DNSサーバは特にDoSに被害を受け易くはありません。 DNSサーバに十分な記憶力がある限り、通常、現代のホストは非常に急速にそれが正式であるDNS要求に応じることができます。 これは根のネームサーバが非常に大きいDoS攻撃[38]にかけられた2002年10月に示されました。 以来、さらにDoSへの彼らの抵抗を改良するのにanycast[1]を使用することで多くの根のネームサーバを模写してあります。 しかしながら、正式のサーバが持つように、それが身体障害者をリレーしながら、重要であるか、または攻撃者がDNSサーバに状態[40]を強制的に支えさせるのは、可能です。
Many of the routing attacks can also be used against DNS servers by targeting the routing for the server. If the DNS server is co- located with the site for which is authoritative, then the fact that the DNS server is also unavailable is of secondary importance. However, if all the DNS servers are made unavailable, this may cause email to that site to bounce rather than being stored while the mail servers are unreachable, so distribution of DNS server locations is important.
また、DNSサーバに対してサーバのためにルーティングを狙うことによって、ルーティング攻撃の多くを使用できます。DNSサーバがどれがあるかに、正式のサイトで共同見つけられているなら、また、DNSサーバも入手できないという事実はセカンダリに重要です。 しかしながら、すべてのDNSサーバを入手できなくするなら、そのサイトへのメールがメールサーバが手が届かない間、保存されるよりこれでむしろ弾むかもしれないので、DNSサーバ位置の分配は重要です。
Causing network congestion on links to and from a DNS server can have similar effects to end-system attacks or routing attacks, causing DNS to fail to obtain an answer, and effectively denying access to the site being served.
リンクでサーバとDNSサーバからネットワークの混雑を引き起こすと、エンドシステム攻撃かルーティング攻撃に同様の影響を与えることができます、DNSが答えを得ないことを引き起こして、事実上、役立たれているサイトへのアクセスを拒絶して。
We note that if an attacker can deny external access to all the DNS servers for a site, this will not only cause email to that site to be dropped, but it will also cause email from that site to be dropped. This is because recent versions of mail transfer agents such as sendmail will drop email if the mail originates from a domain that does not exist. This is a classic example of unexpected consequences. Sendmail performs this check as an anti-spam measure, and spam itself can be viewed as a form of DoS attack. Thus, defending against one DoS attack opens up the vulnerability that allows another DoS attack. If a receiving implementation is using a black-hole list (see Section 2.14) served by DNS, an attacker can also mount a DoS attack by attacking the black-hole server.
私たちは、攻撃者がすべてのDNSサーバへの外部のアクセスをサイトに拒絶できると、これでそのサイトへのメールを下げるだけではありませんが、また、それでそのサイトからのメールを下げることに注意します。 これはメールが存在しないドメインから発するとsendmailなどのメール転送エージェントの最近のバージョンがメールを下げるからです。 これは予期していなかった結果に関する典型例です。 センドメールは反スパム測定としてこのチェックを実行します、そして、DoS攻撃のフォームとしてスパム自体は見なすことができます。 したがって、1つのDoS攻撃に対する防御は別のDoS攻撃を許す脆弱性を開けます。 また、受信実装がDNSによって役立たれたブラックホールリスト(セクション2.14を見る)を使用しているなら、攻撃者は、ブラックホールサーバを攻撃することによって、DoS攻撃を仕掛けることができます。
Handley, et al. Informational [Page 15] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [15ページ]情報のRFC4732DoS問題2006年11月
Finally, a data corruption attack is possible if a site's nameserver is permitted to relay requests from untrusted third parties [40]. The attacker issues a query for the data he wishes to corrupt, and the victim's nameserver relays the request to the authoritative nameserver. The request contains a 16-bit ID that is used to match up the response with the request. If the attacker spoofs sufficient response packets from the authoritative nameserver just before the official response arrives, each containing a forged response and a different DNS ID, then there is a reasonable chance that one of the forged responses will have the correct DNS ID. The incorrect data will then be believed and cached by the victim's nameserver, so giving the incorrect response to future queries. The probability of the attack can further be increased if the attacker issues many different requests for the same data with different DNS IDs, because many nameserver implementations will issue relayed requests with different DNS IDs, and so the response only has to match any one of these request IDs [17] [36].
最終的に、サイトのネームサーバが信頼されていない第三者[40]からの要求をリレーすることが許可されるなら、データの汚染攻撃は可能です。 攻撃者は彼が崩壊させたがっているデータのための質問を発行します、そして、犠牲者のネームサーバは正式のネームサーバに要求をリレーします。要求は要求による応答を合わせるのに使用される16ビットのIDを含んでいます。 攻撃者が、ちょうど以前正式のネームサーバから十分な応答がパケットであると偽造するなら、公式の応答は到着して、それぞれ偽造応答と異なったDNS IDを含んでいて、次に、偽造応答の1つには正しいDNS IDがあるという妥当な見込みがあります。 次に、間違ったデータは、犠牲者のネームサーバによって信じられていて、キャッシュされるでしょう、したがって、今後の質問への不正確な応答を与えて。 多くのネームサーバ実装が異なったDNS IDとのリレーされた要求を出すので攻撃者が異なったDNS IDで同じデータに関する多くの異なった要求を出すならさらに攻撃の確率を増強できるので、応答だけがこれらの要求ID[17][36]のいずれにも合わなければなりません。
The use of anycast for DNS services makes it even more vulnerable to spoofing attacks. An attacker who can convince the ISP to accept an anycast route to his fake DNS server can arrange to receive requests and generate fake responses. Anycast DNS also makes DoS attacks on DNS easier. The idea is to disable one of the DNS servers while maintaining the BGP route to that server. This creates failures for any client that is routed to the (now defunct) server.
anycastのDNSサービスの使用で、それはスプーフィング攻撃にさらに被害を受け易くなります。 彼のにせのDNSサーバにanycastルートを受け入れるようにISPに納得させることができる攻撃者は要求を受け取って、にせの応答を生成するように手配できます。 また、Anycast DNSで、DNSに対するDoS攻撃は、より簡単になります。 考えはそのサーバにBGPルートを維持している間、DNSサーバの1つを無効にすることです。これは(現在、死ぬ)のサーバに発送されるどんなクライアントのためにも失敗を作成します。
2.7. DoS Attacks on Links
2.7. リンクに対するDoS攻撃
The simplest DoS attack is to simply send enough non-congestion- controlled traffic such that a link becomes excessively congested, and legitimate traffic suffers unacceptably high packet loss.
リンクは過度に混雑するようになります、そして、最も簡単なDoS攻撃が単に十分発信することである、非、-、混雑していて交通整理したので、正統のトラフィックは容認できないほど高いパケット損失を受けます。
Under some circumstances, the effect of such a link DoS can be much more extensive. We have already discussed the effects of denying access to a DNS server. Congesting a link might also cause a routing protocol to drop an adjacency if sufficient routing packets are lost, potentially greatly amplifying the effects of the attack. Good router implementations will prioritize the transmission of routing packets, but this is not a total panacea. If routers are peered across a shared medium such as ethernet, it may be possible to congest the medium sufficiently that routing packets are still lost.
いくつかの状況で、そのようなリンクDoSの効果ははるかに大規模である場合があります。 私たちは既にDNSサーバへのアクセスを拒絶するという効果について検討しました。また、リンクを充血させるのに、十分なルーティングパケットが無くなるなら、ルーティング・プロトコルは隣接番組を下げるかもしれません、潜在的に攻撃の効果を大いに増幅して。 良いルータ実装はルーティングパケットのトランスミッションを最優先させるでしょうが、これは総万能薬ではありません。 ルータがイーサネットなどの共有された媒体の向こう側にじっと見ます、媒体をまだルーティングパケットを失うことができるくらい充血させるのが可能であるかもしれないということであるなら。
Even if a link DoS does not cause routing packets to be lost, it may prevent remote access to a router using ssh or Simple Network Management Protocol (SNMP) [48]. This might make the router unmanageable, or prevent the attack from being correctly diagnosed.
リンクDoSがルーティングパケットは失われないでもさえ、それが、セキュアシェル (SSH)かSimple Network Managementプロトコル(SNMP)[48]を使用することでルータに遠隔アクセスを防ぐかもしれません。 ルータが、攻撃が正しく診断されるのを「非-処理しやす」するか、または防ぐのをこれは、させるかもしれません。
Handley, et al. Informational [Page 16] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [16ページ]情報のRFC4732DoS問題2006年11月
The prioritization of routing packets can itself cause a DoS problem. If the attacker can cause a large amount of routing flux, it may be possible for a router to send routing packets at a high enough rate that normal traffic is effectively excluded. However, this is unlikely except on low-bandwidth links.
ルーティングパケットの優先順位づけは原因a DoS問題自体をそうすることができます。 攻撃者が多量のルーティングフラックスを引き起こす場合があるなら、ルータが十分高いレートでルーティングパケットを送るのにおいて事実上、正常なトラフィックが除かれるのは、可能であるかもしれません。 しかしながら、低バンド幅リンクを除いて、これはありそうもないです。
Finally, it may be possible for an attacker to deny access to a link by causing the router to generate sufficient monitoring or report traffic that the link is filled. SNMP traps are one possible vector for such an attack, as they are not normally congestion controlled.
最終的に、ルータが十分なモニターかレポートトラフィックを生成することを引き起こすことによって攻撃者がリンクへのアクセスを拒絶するのにおいてリンクがいっぱいにされるのは、可能であるかもしれません。 それらが通常制御された混雑でないので、SNMP罠はそのような攻撃のための1つの可能なベクトルです。
Attackers with physical access to multiple access links can easily bring down the link. This is particularly easy to mount and difficult to counter with wireless networks.
複数のアクセスリンクへの物理的なアクセスの攻撃者は容易にリンクを降ろすことができます。 これは、特に上がりやすくてワイヤレス・ネットワークに対抗するのは難しいです。
2.8. DoS Attacks on Firewalls
2.8. ファイアウォールに対するDoS攻撃
Firewalls are intended to defend the systems behind them against attack. In that they restrict the traffic that can reach those systems, they may also aid in defending against denial-of-service attacks. However, under some circumstances the firewall itself may also be used as a weapon in a DoS attack.
ファイアウォールがそれらの後ろで攻撃に対してシステムを防御することを意図します。 彼らがそれらのシステムに達することができるトラフィックを制限するので、また、それらはサービス不能攻撃に対して防御する際に支援するかもしれません。 しかしながら、いくつかの状況で、また、ファイアウォール自体は兵器としてDoS攻撃に使用されるかもしれません。
There are many different types of firewall, but generally speaking they fall into stateful and stateless classes. The state here refers to whether the firewall holds state for the active flows traversing the firewall. Stateless firewalls generally can only be attacked by attempting to exhaust the processing resources of the firewall. Stateful firewalls can be attacked by sending traffic that causes the firewall to hold excessive state or state that has pathological structure.
ファイアウォールの多くの異なったタイプがありますが、概して彼らはstatefulであって状態がないクラスになります。 ここの州は、ファイアウォールを横断しながら、アクティブな流れについてファイアウォールが状態を保持するかどうか示します。 一般に、ファイアウォールに関する処理リソースを枯渇させるのを試みることによって、状態がないファイアウォールを攻撃できるだけです。 ファイアウォールが病理学的な構造を持っている過度の州か州を保持するトラフィックを送ることによって、Statefulファイアウォールを攻撃できます。
In the case of excessive state, the firewall simply runs out of memory, and can no longer instantiate the state required to pass legitimate flows. Most firewalls will then fail disconnected, causing denial-of-service to the systems behind the firewall.
過度の状態の場合では、ファイアウォールは、単にメモリを使い果たして、もう正統の流れを通過しなければならなかった状態を例示できません。 そして、ファイアウォールの後ろのシステムにサービスの否定を引き起こすと、ほとんどのファイアウォールが切断された状態で失敗するでしょう。
In the case of pathological structure, the attacker sends traffic that causes the firewall's data structures to exhibit worst-case behaviour. An example of this would be when the firewall uses hash tables to look up forwarding state, and the attacker can predict the hash function used. The attacker may then be able to cause a large amount of flow state to hash to the same bucket, which causes the firewall's lookup performance to change from O(1) to O(n), where n is the number of flows the attacker can instantiate [28]. Thus, the attacker can cause forwarding performance to degrade to the point where service is effectively denied to the legitimate traffic traversing the firewall.
病理学的な構造の場合では、攻撃者はファイアウォールのデータ構造が最悪の場合のふるまいを示すトラフィックを送ります。 この例はファイアウォールが見上げるのに状態を進めながらハッシュ表を使用して、攻撃者が、ハッシュ関数が使用したと予測できる時でしょう。 そしてときに攻撃者は多量の流れ状態がO(1)からO(n)に変化するファイアウォールのルックアップ性能を引き起こすのと同じバケツに論じ尽くすことを引き起こすことができます、攻撃者がnが流れの数であるところに[28]を例示できるということであるかもしれません。 したがって、攻撃者は事実上、サービスがファイアウォールを横断する正統のトラフィックに対して否定されるポイントへ退行する推進性能を引き起こす場合があります。
Handley, et al. Informational [Page 17] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [17ページ]情報のRFC4732DoS問題2006年11月
2.9. DoS Attacks on IDS Systems
2.9. 免疫不全症候群システムに対するDoS攻撃
Intrusion detection systems (IDSs) suffer from similar problems to firewalls. It may be possible for an attacker to cause the IDS to exhaust its available processing power, to run out of memory, or to instantiate state with pathological structure. Unlike a firewall, an IDS will normally fail open, which will not deny service to the systems protected by the IDS. However, it may mean that subsequent attacks that the IDS would have detected will be missed.
侵入検知システム(IDSs)に同様の問題からファイアウォールまで苦しみます。 攻撃者が、IDSが利用可能な処理能力を消耗させるか、メモリを使い果たすか、または病理学的な構造がある状態を例示することを引き起こすのは、可能であるかもしれません。 ファイアウォールと異なって、通常、IDSは戸外に失敗するでしょう。(それは、システムに対するサービスがIDSによって保護されたことを否定しないでしょう)。 しかしながら、それは、IDSが検出したその後の攻撃が逃されることを意味するかもしれません。
Some IDSs are reactive; that is, on detection of a hostile event they react to block subsequent traffic from the hostile system, or to terminate an ongoing connection from that system. It may be possible for an attacker to spoof packets from a legitimate system, and hence cause the IDS to believe that system is hostile. The IDS will then cause traffic from the legitimate system to be blocked, hence denying service to it. The effect can be particularly bad if the legitimate system is a router, DNS server, or other system whose performance is essential for the operation of a large number of other systems.
いくつかのIDSsが反応しています。 すなわち、敵対的なイベントの検出のときに、彼らは、敵軍のシステムからその後のトラフィックを妨げるか、またはそのシステムからの進行中の接続を終えるために反応します。 攻撃者がそのシステムを信じるために正統のシステム、およびしたがって、原因からのパケットにIDSを偽造するのが、敵対的であることは、可能であるかもしれません。 そして、したがって、それに対するサービスを否定して、IDSは正統のシステムからのトラフィックを妨げさせるでしょう。 効果は正統のシステムが他の多くのシステムの操作に、性能が不可欠であるルータ、DNSサーバ、または他のシステムであるなら特に悪い場合があります。
2.10. DoS Attacks on or via NTP
2.10. NTPの上、または、NTPを通したDoS Attacks
Network time servers are generally not considered security-critical services, but under some circumstances NTP servers might be used to perpetrate a DoS attack.
ネットワーク時間サーバは、セキュリティ重要なサービスであることは一般に考えられませんが、DoS攻撃を犯すのにいくつかの事情NTPサーバの下に使用されるかもしれません。
The most obvious such attack is to DoS the NTP servers themselves. Many end-systems have rather poor clock accuracy and so, without access to network time, their clock will naturally drift. This can cause problems with distributed systems that rely on good clocks. For example, one commonly used revision control system can fail if it perceives the modification timestamp to be in the future.
そのような最も明白な攻撃はDoSへのNTPサーバ自体です。 多くのエンドシステムにはかなり低い時計精度があるので、ネットワーク時間へのアクセスがなければ、それらの時計は自然に漂流するでしょう。 これは良い時計を当てにする分散システムで問題を起こすことができます。 例えば、未来に、変更タイムスタンプがあると知覚するなら、1台の一般的に使用された改訂管理システムが失敗できます。
If the NTP servers relied on by a host can be subverted, either through compromising or impersonating them, then the attacker may be able to control the host's system clock. This can cause many unexpected consequences, including the premature expiry of dated resources such as encryption or authentication keys. This in turn can prevent access to other more critical services.
それらを感染するか、またはまねることでホストによって当てにされたNTPサーバを打倒できるなら、攻撃者はホストのシステムクロックを制御できるかもしれません。 これは暗号化か認証キーなどの時代遅れのリソースの時期尚早な満期を含む多くの予期していなかった結果を引き起こす場合があります。 これは順番に他の、より重要なサービスへのアクセスを防ぐことができます。
2.11. Physical DoS
2.11. 物理的なDoS
The discussion thus far has centered on denial-of-service attacks perpetrated using the network. However, computer systems are only as resilient as the weakest link. It may be easier to deny service by causing a power failure, by cutting network cables, or by simply switching a system off, and so physical security is at least as important as network security. Physical attacks can also serve as
議論はこれまでのところ、ネットワークを使用することで犯されたサービス不能攻撃に集中しました。 しかしながら、コンピュータ・システムは単に最も弱いリンクと同じくらい弾力があります。 停電を引き起こすか、ネットワークケーブルを切るか、または単にシステムを消すことによってサービスを否定するのがネットワークセキュリティより簡単であるかもしれなく、とても物理的なセキュリティは少なくとも同じくらい重要です。 また攻撃が機能できる身体検査
Handley, et al. Informational [Page 18] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [18ページ]情報のRFC4732DoS問題2006年11月
entry points for non-physical DoS, for instance, by reducing the resources available to deal with overcapacity.
例えば、エントリーは、非物理的なDoSのために満席に対処するために利用可能なリソースを減らすことによって、指します。
2.12. Social Engineering DoS
2.12. ソーシャルエンジニアリングDoS
The weakest link may also be human. In defending against DoS, the possibility of denial-of-service through social engineering should not be neglected, such as convincing an employee to make a configuration change that prevents normal operation.
また、最も弱いリンクも人間であるかもしれません。 DoSに対して防御する際に、ソーシャルエンジニアリングを通したサービスの否定の可能性を無視するべきではありません、通常の操作を防ぐ構成変更を作るように従業員を説得するのなどように。
2.13. Legal DoS
2.13. 法的なDoS
Computer systems cannot be considered in isolation from the social and legal systems in which they operate. This document focuses primarily on the technical issues, but we note that "cease and desist" letters, government censorship, and other legal mechanisms also touch on denial-of-service issues.
分離してそれらが作動する社会的で法的なシステムからコンピュータ・システムを考えることができません。 このドキュメントは主として専門的な問題に焦点を合わせますが、私たちは、そのサービスの手紙、政府検閲、および他の法的なメカニズムも触れる「やんでください、そして、やめてください」否定が発行することに注意します。
2.14. Spam and Black-Hole Lists
2.14. スパムとブラックホールリスト
Unsolicited commercial email, also known as "spam", can effectively cause denial-of-service to email systems. While the intent is not denial-of-service, the large amount of unwanted mail can waste the recipient's time or cause legitimate email to fail to be noticed amongst all the background noise. If spam filtering software is used, some level of false positives is to be expected, and so these messages are effectively denied service.
事実上、サービスの否定はまた、「スパム」として知られているお節介なコマーシャルメールでシステムをメールできます。意図はサービスの否定ではありませんが、多量の求められていないメールで、受取人の時間を浪費できないか、正統のメールはすべてのバックグラウンドノイズの中で気付くことができません。 ソフトウェアをフィルターにかけるスパムが使用されているなら、何らかのレベルの無病誤診が予想されることであるので、事実上、サービスはこれらのメッセージに対して否定されます。
One mechanism to reduce spam is the use of black-hole lists. The IP addresses of dial-up ISPs or mail servers used to originate or relay spam are added to black-hole lists. The recipients of mail choose to consult these lists and reject spam if it originates or is relayed by systems on the list. One significant problem with such lists is that it may be possible for an attacker to cause a victim to be black- hole-listed, even if the victim was not responsible for relaying spam. Thus, the black-hole list itself can be a mechanism for effecting a DoS attack. Note that every black-hole list has its own policy regarding additions, and some are less susceptible to this DoS attack than others. Consumers of black-hole list technology are advised to investigate these policies before they subscribe. Similar considerations apply to feeds of bad BGP bad route advertisements.
One mechanism to reduce spam is the use of black-hole lists. The IP addresses of dial-up ISPs or mail servers used to originate or relay spam are added to black-hole lists. The recipients of mail choose to consult these lists and reject spam if it originates or is relayed by systems on the list. One significant problem with such lists is that it may be possible for an attacker to cause a victim to be black- hole-listed, even if the victim was not responsible for relaying spam. Thus, the black-hole list itself can be a mechanism for effecting a DoS attack. Note that every black-hole list has its own policy regarding additions, and some are less susceptible to this DoS attack than others. Consumers of black-hole list technology are advised to investigate these policies before they subscribe. Similar considerations apply to feeds of bad BGP bad route advertisements.
Handley, et al. Informational [Page 19] RFC 4732 DoS Considerations November 2006
Handley, et al. Informational [Page 19] RFC 4732 DoS Considerations November 2006
3. Attack Amplifiers
3. Attack Amplifiers
Many of the attacks described above rely on sending sufficient traffic to overwhelm the victim. Such attacks are made much easier by the existence of "attack amplifiers", where an attacker can send traffic from the spoofed source address of the victim and cause larger responses to be returned to the victim. A detailed discussion of such reflection attacks can be found in [35].
Many of the attacks described above rely on sending sufficient traffic to overwhelm the victim. Such attacks are made much easier by the existence of "attack amplifiers", where an attacker can send traffic from the spoofed source address of the victim and cause larger responses to be returned to the victim. A detailed discussion of such reflection attacks can be found in [35].
3.1. Methods of Attack Amplification
3.1. Methods of Attack Amplification
The simplest such attack was the "smurf" attack [22], where an ICMP echo request packet with the spoofed source address of the victim is sent to the subnet-broadcast address of a network to be used as an amplifier. Every system on that subnet then responds with an ICMP echo response that returns to the victim. Smurf attacks are no longer such a serious problem, as these days routers usually drop such packets and end-systems do not respond to them.
The simplest such attack was the "smurf" attack [22], where an ICMP echo request packet with the spoofed source address of the victim is sent to the subnet-broadcast address of a network to be used as an amplifier. Every system on that subnet then responds with an ICMP echo response that returns to the victim. Smurf attacks are no longer such a serious problem, as these days routers usually drop such packets and end-systems do not respond to them.
An alternative form of attack amplifier is typified by a DNS reflection attack. An attacker sends a DNS request to a DNS server requesting resolution of a domain name. Again the source address of the request is the spoofed address of the victim. The request is carefully chosen so that the size of the response is significantly greater than the size of the request, thereby providing the amplification. As an aside, it is interesting to note that the largest DNS responses tend to be those incorporating DNSsec authentication information. This attack amplifier can only be used by an attacker with the ability to spoof the source address of the victim. However, we note that if the victim's DNS server is configured to relay requests from external clients, it may be possible to cause it to congest its own incoming network link.
An alternative form of attack amplifier is typified by a DNS reflection attack. An attacker sends a DNS request to a DNS server requesting resolution of a domain name. Again the source address of the request is the spoofed address of the victim. The request is carefully chosen so that the size of the response is significantly greater than the size of the request, thereby providing the amplification. As an aside, it is interesting to note that the largest DNS responses tend to be those incorporating DNSsec authentication information. This attack amplifier can only be used by an attacker with the ability to spoof the source address of the victim. However, we note that if the victim's DNS server is configured to relay requests from external clients, it may be possible to cause it to congest its own incoming network link.
Another variant of attack amplifier involves amplification through retransmission. This is typified by a TCP amplification attack known as "bang.c". The attacker sends a spoofed TCP SYN with the source address of the victim to an arbitrary TCP server. The server will respond with a SYN|ACK that is sent to the victim, and when no final ACK is received to complete the handshake, the SYN|ACK will be retransmitted a number of times. Typically, this attack uses a very large list of arbitrarily chosen servers as reflectors. For the attack to be successful, the reflector must not receive a RST from the victim in response to the SYN|ACK. However, if the attack traffic sufficiently overwhelms the server or access link to the server, then packet loss will ensure that many reflectors do not receive a RST in response to their SYN|ACK, and so continue to retransmit. The attack can be exacerbated by firewalls that silently drop the incoming SYN|ACK without sending a RST.
Another variant of attack amplifier involves amplification through retransmission. This is typified by a TCP amplification attack known as "bang.c". The attacker sends a spoofed TCP SYN with the source address of the victim to an arbitrary TCP server. The server will respond with a SYN|ACK that is sent to the victim, and when no final ACK is received to complete the handshake, the SYN|ACK will be retransmitted a number of times. Typically, this attack uses a very large list of arbitrarily chosen servers as reflectors. For the attack to be successful, the reflector must not receive a RST from the victim in response to the SYN|ACK. However, if the attack traffic sufficiently overwhelms the server or access link to the server, then packet loss will ensure that many reflectors do not receive a RST in response to their SYN|ACK, and so continue to retransmit. The attack can be exacerbated by firewalls that silently drop the incoming SYN|ACK without sending a RST.
Handley, et al. Informational [Page 20] RFC 4732 DoS Considerations November 2006
Handley, et al. Informational [Page 20] RFC 4732 DoS Considerations November 2006
Care must also be taken with services that relay requests. If an attacker can send a request to a proxy, and that proxy now attempts to connect to a victim whose address is chosen by the attacker, then, if the proxy repeatedly resends the request when receiving no answer, this can also serve as an attack amplifier.
Care must also be taken with services that relay requests. If an attacker can send a request to a proxy, and that proxy now attempts to connect to a victim whose address is chosen by the attacker, then, if the proxy repeatedly resends the request when receiving no answer, this can also serve as an attack amplifier.
Another variant of amplification occurs in protocols that include, within the protocol payload, an IP address or name of host to which subsequent messages should be sent. An example of such a protocol is the Session Initiation Protocol (SIP) [50], which carries a payload defined by the Session Description Protocol (SDP) [51]. The SDP payload of the SIP message conveys the IP address and port to which media packets, typically encoded using the Real Time Transport Protocol (RTP) [52], are sent.
Another variant of amplification occurs in protocols that include, within the protocol payload, an IP address or name of host to which subsequent messages should be sent. An example of such a protocol is the Session Initiation Protocol (SIP) [50], which carries a payload defined by the Session Description Protocol (SDP) [51]. The SDP payload of the SIP message conveys the IP address and port to which media packets, typically encoded using the Real Time Transport Protocol (RTP) [52], are sent.
To launch this attack, an attacker sends a protocol message, and sets the IP address within the payload to point to the attack target. The recipient of the message will generate subsequent traffic to that IP address. Depending on the protocol, this attack can provide substantial amplification properties. In the specific case of SIP, if a caller makes calls to high-bandwidth media sources (such as a video server or streaming audio server), a single SIP INVITE packet, typically a few hundred bytes, can result in a nearly continuous stream of media packets at rates anywhere from a few kbits per second up to megabits per second. This particular attack is called the "voice hammer".
To launch this attack, an attacker sends a protocol message, and sets the IP address within the payload to point to the attack target. The recipient of the message will generate subsequent traffic to that IP address. Depending on the protocol, this attack can provide substantial amplification properties. In the specific case of SIP, if a caller makes calls to high-bandwidth media sources (such as a video server or streaming audio server), a single SIP INVITE packet, typically a few hundred bytes, can result in a nearly continuous stream of media packets at rates anywhere from a few kbits per second up to megabits per second. This particular attack is called the "voice hammer".
Unlike the other techniques described above, this technique does not require the attacker to modify packets or even spoof their source IP address. This makes it easier to launch.
Unlike the other techniques described above, this technique does not require the attacker to modify packets or even spoof their source IP address. This makes it easier to launch.
This attack is prevented through careful protocol design. Protocols should, whenever possible, avoid including IP addresses or hostnames within protocol payloads as addresses to which subsequent messaging should be sent. Rather, when possible, messages should be sent to the source IP from which the protocol packet came. If such a design is not possible, the protocol should include a handshake whereby it can be positively determined that the protocol entity at that IP address or hostname does, in fact, wish to receive that subsequent messaging. That handshake itself needs to be lightweight (to avoid being the source of another DoS attack), and secured against the spoofing of the handshake response.
This attack is prevented through careful protocol design. Protocols should, whenever possible, avoid including IP addresses or hostnames within protocol payloads as addresses to which subsequent messaging should be sent. Rather, when possible, messages should be sent to the source IP from which the protocol packet came. If such a design is not possible, the protocol should include a handshake whereby it can be positively determined that the protocol entity at that IP address or hostname does, in fact, wish to receive that subsequent messaging. That handshake itself needs to be lightweight (to avoid being the source of another DoS attack), and secured against the spoofing of the handshake response.
Finally, a somewhat similar attack is possible with some protocols where one message leads to another message that is not sent as a reply to the source address of the first message. This can be an
Finally, a somewhat similar attack is possible with some protocols where one message leads to another message that is not sent as a reply to the source address of the first message. This can be an
Handley, et al. Informational [Page 21] RFC 4732 DoS Considerations November 2006
Handley, et al. Informational [Page 21] RFC 4732 DoS Considerations November 2006
issue with protocols to enable mobility, for example, and might permit an attacker to avoid ingress filtering. Such protocols are notoriously difficult to get right.
issue with protocols to enable mobility, for example, and might permit an attacker to avoid ingress filtering. Such protocols are notoriously difficult to get right.
3.2. Strategies to Mitigate Attack Amplification
3.2. Strategies to Mitigate Attack Amplification
In general, the architectural lessons to be learnt are simple:
In general, the architectural lessons to be learnt are simple:
o As far as possible, perform ingress filtering [7] [39] to prevent
source address spoofing.
o As far as possible, perform ingress filtering [7] [39] to prevent source address spoofing.
o Avoid designing protocols or mechanisms that can return
significantly larger responses than the size of the request,
unless a handshake is performed to validate the client's source
address. Such a handshake needs to incorporate an unpredictable
nonce that is secure enough to mitigate the amplification effects
of the protocol.
o Avoid designing protocols or mechanisms that can return significantly larger responses than the size of the request, unless a handshake is performed to validate the client's source address. Such a handshake needs to incorporate an unpredictable nonce that is secure enough to mitigate the amplification effects of the protocol.
o All retransmission during initial connection setup should be
performed by the client.
o All retransmission during initial connection setup should be performed by the client.
o Proxies should not arbitrarily relay requests to destinations
chosen by a client.
o Proxies should not arbitrarily relay requests to destinations chosen by a client.
o Avoid signaling third-party connections. Any unavoidable third-
party connections set up by a signaling protocol should
incorporate lightweight validation before sending significant
data.
o Avoid signaling third-party connections. Any unavoidable third- party connections set up by a signaling protocol should incorporate lightweight validation before sending significant data.
4. DoS Mitigation Strategies
4. DoS Mitigation Strategies
A general problem with DoS defense is that it is not in principle possible to distinguish between a flash crowd and a DoS attack. Indeed, having your site taken down by a flash crowd is probably a more common experience than having it DoS-ed -- so common it has acquired its own names: being Slashdotted or Farked, after the web sites that are common sources of flash crowds. Thus, the first line of defense against DoS attacks must be to provision your service so that it can handle a foreseeable legitimate peak load. Underprovisioned sites are the easiest to take down.
A general problem with DoS defense is that it is not in principle possible to distinguish between a flash crowd and a DoS attack. Indeed, having your site taken down by a flash crowd is probably a more common experience than having it DoS-ed -- so common it has acquired its own names: being Slashdotted or Farked, after the web sites that are common sources of flash crowds. Thus, the first line of defense against DoS attacks must be to provision your service so that it can handle a foreseeable legitimate peak load. Underprovisioned sites are the easiest to take down.
Specific strategies for DoS defense fall into two broad categories:
Specific strategies for DoS defense fall into two broad categories:
1. Avoiding allowing attacks that are better than generic resource
consumption.
1. Avoiding allowing attacks that are better than generic resource consumption.
2. Minimizing the extent to which generic resource consumption
attacks crowd out legitimate users.
2. Minimizing the extent to which generic resource consumption attacks crowd out legitimate users.
Handley, et al. Informational [Page 22] RFC 4732 DoS Considerations November 2006
Handley, et al. Informational [Page 22] RFC 4732 DoS Considerations November 2006
In the remainder of this section, we consider specific applications of these two approaches at a variety of levels of network system architecture.
In the remainder of this section, we consider specific applications of these two approaches at a variety of levels of network system architecture.
4.1. Protocol Design
4.1. Protocol Design
4.1.1. Don't Hold State for Unverified Hosts
4.1.1. Don't Hold State for Unverified Hosts
From an end-system server point of view, one simple aim is to avoid instantiating state without having completed a handshake with the client to validate their address, and as far as possible to push work and stateholding to client. There are a number of techniques that might be used to do this, including SYN cookies [2] [14]. All client-server protocols should probably be designed to allow such techniques to be used, but the enabling of the mechanism should normally be at the server's discretion to avoid unnecessary work under normal circumstances.
From an end-system server point of view, one simple aim is to avoid instantiating state without having completed a handshake with the client to validate their address, and as far as possible to push work and stateholding to client. There are a number of techniques that might be used to do this, including SYN cookies [2] [14]. All client-server protocols should probably be designed to allow such techniques to be used, but the enabling of the mechanism should normally be at the server's discretion to avoid unnecessary work under normal circumstances.
4.1.2. Make It Hard to Simulate a Legitimate User
4.1.2. Make It Hard to Simulate a Legitimate User
Other than having massive overcapacity, the only real defense against resource consumption attacks is to preferentially discriminate against attackers. The general idea is to find something that legitimate users can do but attackers can't. The most commonly proposed approaches include:
Other than having massive overcapacity, the only real defense against resource consumption attacks is to preferentially discriminate against attackers. The general idea is to find something that legitimate users can do but attackers can't. The most commonly proposed approaches include:
1. Puzzles: force the attacker to do some computation that would not
be onerous for a single user but is too expensive to do en masse
[14].
1. Puzzles: force the attacker to do some computation that would not be onerous for a single user but is too expensive to do en masse [14].
2. Reverse Turing tests: specialized puzzles that are hard for
machines to do but easy for humans, thus making automated attacks
hard [13].
2. Reverse Turing tests: specialized puzzles that are hard for machines to do but easy for humans, thus making automated attacks hard [13].
3. Reachability testing: force the proposed client to demonstrate
that it can receive traffic at a given IP address. This makes it
easier to trace attackers.
3. Reachability testing: force the proposed client to demonstrate that it can receive traffic at a given IP address. This makes it easier to trace attackers.
All of these techniques have substantial limitations. Puzzles tend
to discriminate against legitimate users with slow computers. In
addition, the wide availability of remotely controlled compromised
machines ("bots") means that attackers have ample computing power at
their disposal. There has been substantial work in attacking reverse
Turing tests automatically, thus making them of limited
applicability. Finally, reachability testing is substantially
weakened by bots because the attacker does not need to hide his
source address.
All of these techniques have substantial limitations. Puzzles tend to discriminate against legitimate users with slow computers. In addition, the wide availability of remotely controlled compromised machines ("bots") means that attackers have ample computing power at their disposal. There has been substantial work in attacking reverse Turing tests automatically, thus making them of limited applicability. Finally, reachability testing is substantially weakened by bots because the attacker does not need to hide his source address.
Handley, et al. Informational [Page 23] RFC 4732 DoS Considerations November 2006
Handley, et al. Informational [Page 23] RFC 4732 DoS Considerations November 2006
4.1.3. Graceful Routing Degradation
4.1.3. Graceful Routing Degradation
A goal with routing protocols is that of graceful degradation in overload, and automatic recovery after the source of the overload has been remedied. Some routing protocols satisfy this goal more than others. Although RIP [53] doesn't scale well, if a router runs out of memory when receiving a RIP route, it can just drop the route and send an infinite metric to its peers. The route will later be refreshed, and if the original source of the problem has been resolved, the router will now be able to process it correctly.
A goal with routing protocols is that of graceful degradation in overload, and automatic recovery after the source of the overload has been remedied. Some routing protocols satisfy this goal more than others. Although RIP [53] doesn't scale well, if a router runs out of memory when receiving a RIP route, it can just drop the route and send an infinite metric to its peers. The route will later be refreshed, and if the original source of the problem has been resolved, the router will now be able to process it correctly.
On the other hand, BGP is stateful in the sense that a peer assumes you have processed or chosen to filter any route that it sent you. There is no mechanism to refresh state in the base BGP spec, and even the later route refresh option [3] is hard to use in the presence of overload. A BGP router that cannot store a route it received has two choices: completely restart BGP or shut down one or more peerings [26]. This means that the effects of a BGP overload are rather more severe than they need to be, and so amplifies the effect of any attack.
On the other hand, BGP is stateful in the sense that a peer assumes you have processed or chosen to filter any route that it sent you. There is no mechanism to refresh state in the base BGP spec, and even the later route refresh option [3] is hard to use in the presence of overload. A BGP router that cannot store a route it received has two choices: completely restart BGP or shut down one or more peerings [26]. This means that the effects of a BGP overload are rather more severe than they need to be, and so amplifies the effect of any attack.
In general, few routing protocol designs actively consider the possible behaviour of routers under overload conditions; this should be an explicit part of future routing protocol designs. Although precise details should clearly be left to implementors, the protocol design needs to give them the capability to do their job properly.
In general, few routing protocol designs actively consider the possible behaviour of routers under overload conditions; this should be an explicit part of future routing protocol designs. Although precise details should clearly be left to implementors, the protocol design needs to give them the capability to do their job properly.
4.1.4. Autoconfiguration and Authentication
4.1.4. Autoconfiguration and Authentication
Autoconfiguration mechanisms greatly ease deployment, and are increasingly necessary as the number of networked devices grows beyond what can be managed manually. However, it should be recognised that unauthenticated autoconfiguration opens up many avenues for attack. There is a clear tension between ease of configuration and security of configuration, especially because there are environments in which it is desirable for units to operate with effectively no authentication (e.g., airport hotspots). Future autoconfiguration protocols should consider the need to allow different end-systems to operate at different points in this spectrum within the same autoconfiguration framework. However, this also implies that the network elements should avoid acting for unauthenticated hosts, instead just letting them access the network more or less directly.
Autoconfiguration mechanisms greatly ease deployment, and are increasingly necessary as the number of networked devices grows beyond what can be managed manually. However, it should be recognised that unauthenticated autoconfiguration opens up many avenues for attack. There is a clear tension between ease of configuration and security of configuration, especially because there are environments in which it is desirable for units to operate with effectively no authentication (e.g., airport hotspots). Future autoconfiguration protocols should consider the need to allow different end-systems to operate at different points in this spectrum within the same autoconfiguration framework. However, this also implies that the network elements should avoid acting for unauthenticated hosts, instead just letting them access the network more or less directly.
Handley, et al. Informational [Page 24] RFC 4732 DoS Considerations November 2006
Handley, et al. Informational [Page 24] RFC 4732 DoS Considerations November 2006
4.2. Network Design and Configuration
4.2. Network Design and Configuration
In general, networks should be provisioned with private, out-of-band access to console or control ports so that such control facilities will be available in the face of a DoS attack launched against either the control or data plane of the (in-band) network. Typically, such out-of-band networks are provisioned on a separate infrastructure for exactly this purpose. Out-of-band access is a crucial capability for DoS mitigation, since many of the typical redundancy and capacity management techniques (such as prioritizing routing or network management traffic) fail during such attacks. In addition, many redundancy protocols such as VRRP [47] can fail during such attacks as they may be unable to keep adjacencies alive.
In general, networks should be provisioned with private, out-of-band access to console or control ports so that such control facilities will be available in the face of a DoS attack launched against either the control or data plane of the (in-band) network. Typically, such out-of-band networks are provisioned on a separate infrastructure for exactly this purpose. Out-of-band access is a crucial capability for DoS mitigation, since many of the typical redundancy and capacity management techniques (such as prioritizing routing or network management traffic) fail during such attacks. In addition, many redundancy protocols such as VRRP [47] can fail during such attacks as they may be unable to keep adjacencies alive.
There are several default configuration settings that can also be exploited to generate several of the attacks outlined in this document. For example, some vendors may have features such as IP redirect, directed broadcast, and proxy ARP enabled by default. Similar defaults, such as publicly readable SNMP [48] communities (e.g., "public") can be used to reveal otherwise confidential information to a prospective attacker. Finally, other unauthenticated configuration management protocols such as TFTP [49] should be avoided if possible; at the very least access to TFTP configuration archives should be protected and TFTP should be filtered at administrative boundaries. Finally, since many of the password encryption techniques used by router vendors are reversible, keeping such passwords on a configuration archive (as part of a configuration file), even in the encrypted form written by the router, can lead to unauthorized access if the archive is compromised.
There are several default configuration settings that can also be exploited to generate several of the attacks outlined in this document. For example, some vendors may have features such as IP redirect, directed broadcast, and proxy ARP enabled by default. Similar defaults, such as publicly readable SNMP [48] communities (e.g., "public") can be used to reveal otherwise confidential information to a prospective attacker. Finally, other unauthenticated configuration management protocols such as TFTP [49] should be avoided if possible; at the very least access to TFTP configuration archives should be protected and TFTP should be filtered at administrative boundaries. Finally, since many of the password encryption techniques used by router vendors are reversible, keeping such passwords on a configuration archive (as part of a configuration file), even in the encrypted form written by the router, can lead to unauthorized access if the archive is compromised.
4.2.1. Redundancy and Distributed Service
4.2.1. Redundancy and Distributed Service
A basic principle of designing systems to handle failure is to have redundant servers that can take over when one fails. This is equally true in the case of DoS attacks, which often focus on a given server and/or link. If service delivery points can be distributed across the network, then it becomes much harder to attack the entire service. In particular, this makes attacks on a single network link more difficult.
A basic principle of designing systems to handle failure is to have redundant servers that can take over when one fails. This is equally true in the case of DoS attacks, which often focus on a given server and/or link. If service delivery points can be distributed across the network, then it becomes much harder to attack the entire service. In particular, this makes attacks on a single network link more difficult.
4.2.2. Authenticate Routing Adjacencies
4.2.2. Authenticate Routing Adjacencies
In general, cryptographic authentication mechanisms are too costly to form the main part in DoS prevention. However, routing adjacencies are too important to risk an attacker being able to inject bad routing information, which can affect more than the router in question. Additional non-cryptographic mechanisms should then be
In general, cryptographic authentication mechanisms are too costly to form the main part in DoS prevention. However, routing adjacencies are too important to risk an attacker being able to inject bad routing information, which can affect more than the router in question. Additional non-cryptographic mechanisms should then be
Handley, et al. Informational [Page 25] RFC 4732 DoS Considerations November 2006
Handley, et al. Informational [Page 25] RFC 4732 DoS Considerations November 2006
used to avoid arbitrary end-systems being able to cause the router to spend CPU cycles on validating authentication data.
used to avoid arbitrary end-systems being able to cause the router to spend CPU cycles on validating authentication data.
For BGP, at the very least, this implies the use of TCP MD5 [9] or IPsec authentication, combined with the GTSM [8] to prevent eBGP association with non-immediate neighbors. In the future, this will likely imply better authentication of the routing information itself.
For BGP, at the very least, this implies the use of TCP MD5 [9] or IPsec authentication, combined with the GTSM [8] to prevent eBGP association with non-immediate neighbors. In the future, this will likely imply better authentication of the routing information itself.
4.2.3. Isolate Router-to-Router Traffic
4.2.3. Isolate Router-to-Router Traffic
As far as is feasible, router-to-router traffic should be isolated from data traffic. How this should be implemented depends on the precise technologies available, both in the router and at the link layer. The goal should be that failure of the link for data traffic should also cause failure for the routing traffic, but that an attacker cannot directly send packets to the control processor of the routers.
As far as is feasible, router-to-router traffic should be isolated from data traffic. How this should be implemented depends on the precise technologies available, both in the router and at the link layer. The goal should be that failure of the link for data traffic should also cause failure for the routing traffic, but that an attacker cannot directly send packets to the control processor of the routers.
A downside of this is that some diagnostic techniques (such as pinging consecutive routers to find the source of a delay) may no longer be possible. Ideally, alternative mechanisms (which do not open up additional avenues for DoS) should be designed to replace such lost techniques.
A downside of this is that some diagnostic techniques (such as pinging consecutive routers to find the source of a delay) may no longer be possible. Ideally, alternative mechanisms (which do not open up additional avenues for DoS) should be designed to replace such lost techniques.
4.3. Router Implementation Issues
4.3. Router Implementation Issues
Because a router can be considered as an end-system, it can potentially benefit from all the prevention mechanisms prescribed for end-system implementation. However, one basic distinction between a router and a host is that the former implements routing protocols and forwards data, which in turn lead to additional router-specific implementation considerations. The issues described below are meant to be illustrative and not exhaustive.
Because a router can be considered as an end-system, it can potentially benefit from all the prevention mechanisms prescribed for end-system implementation. However, one basic distinction between a router and a host is that the former implements routing protocols and forwards data, which in turn lead to additional router-specific implementation considerations. The issues described below are meant to be illustrative and not exhaustive.
4.3.1. Checking Protocol Syntax and Semantics
4.3.1. Checking Protocol Syntax and Semantics
Protocol syntax defines the formation of the protocol messages and the rules of exchanges. The questions addressed by protocol syntax checking includes, but is not limited to, the following:
Protocol syntax defines the formation of the protocol messages and the rules of exchanges. The questions addressed by protocol syntax checking includes, but is not limited to, the following:
1. Who sent the message?
1. Who sent the message?
2. Does the content conform to the protocol format?
2. Does the content conform to the protocol format?
3. Was the message sent with correct timing?
3. Was the message sent with correct timing?
Handley, et al. Informational [Page 26] RFC 4732 DoS Considerations November 2006
Handley, et al. Informational [Page 26] RFC 4732 DoS Considerations November 2006
The first step in protocol syntax verification is to ensure that an incoming message was sent by a legitimate party. There are multiple ways to perform this check. One can verify the source IP address and even the MAC address of the message. Utilizing the fact that eBGP peers are normally directly connected, one can also check the TTL value in a packet and discard any BGP updates packet whose TTL is less than some maximum value (typically, max TTL - 1) [8]. Cryptographic authentication should also be used whenever available to verify that an incoming message is indeed from an expected sender. For BGP, at the very least, this implies the use of TCP MD5 [9] or IPsec authentication.
The first step in protocol syntax verification is to ensure that an incoming message was sent by a legitimate party. There are multiple ways to perform this check. One can verify the source IP address and even the MAC address of the message. Utilizing the fact that eBGP peers are normally directly connected, one can also check the TTL value in a packet and discard any BGP updates packet whose TTL is less than some maximum value (typically, max TTL - 1) [8]. Cryptographic authentication should also be used whenever available to verify that an incoming message is indeed from an expected sender. For BGP, at the very least, this implies the use of TCP MD5 [9] or IPsec authentication.
In addition to the sender verification, it is also important to check the syntax of a received routing message, as opposed to assuming that all messages came in a correct format. It happened in the past that routers crashed upon receiving ill-formed routing messages. Such faults will be prevented by performing rigorous syntax checking.
In addition to the sender verification, it is also important to check the syntax of a received routing message, as opposed to assuming that all messages came in a correct format. It happened in the past that routers crashed upon receiving ill-formed routing messages. Such faults will be prevented by performing rigorous syntax checking.
4.3.2. Consistency Checks
4.3.2. Consistency Checks
Protocol semantics define the meaning of the message content, the interpretation of the values, and the actions to be taken according to the content. Here is a simple example of using semantic checking. When a link failure causes a router in Autonomous System (AS) A to send a peer router B a withdrawal message for prefix P, B should make sure that any alternative path it finds to reach P does not go through A. This simple check is shown to significantly improve BGP convergence time in many cases [42].
Protocol semantics define the meaning of the message content, the interpretation of the values, and the actions to be taken according to the content. Here is a simple example of using semantic checking. When a link failure causes a router in Autonomous System (AS) A to send a peer router B a withdrawal message for prefix P, B should make sure that any alternative path it finds to reach P does not go through A. This simple check is shown to significantly improve BGP convergence time in many cases [42].
Another example of using semantic checking against false routing injection is described in [44]. The basic idea is to attach to the route announcement for prefix P a list of the valid origin ASes. Due to the rich connectivity in today's Internet topology, a remote AS will receive routing updates from multiple different paths and can check to see whether each update carries the identical origin AS list. Although a false origin may announce reachability to P, or alter the origin AS list, it would be difficult, if not impossible, to block the correct updates from propagating out, and thus remote ASes can detect the existence of false updates by observing the inconsistency of the received origin AS lists for P. Research studies show that the "allowed origin list" test can effectively detect the majority of falsely originated updates.
Another example of using semantic checking against false routing injection is described in [44]. The basic idea is to attach to the route announcement for prefix P a list of the valid origin ASes. Due to the rich connectivity in today's Internet topology, a remote AS will receive routing updates from multiple different paths and can check to see whether each update carries the identical origin AS list. Although a false origin may announce reachability to P, or alter the origin AS list, it would be difficult, if not impossible, to block the correct updates from propagating out, and thus remote ASes can detect the existence of false updates by observing the inconsistency of the received origin AS lists for P. Research studies show that the "allowed origin list" test can effectively detect the majority of falsely originated updates.
Generally speaking, verifying the validity of BGP routes can be challenging because BGP is policy driven and policies of individual ISPs are not known in most cases. But assuming that policies do not change in short time scale, in principle one could verify new updates against observed routes from the recent past, which reflect the
Generally speaking, verifying the validity of BGP routes can be challenging because BGP is policy driven and policies of individual ISPs are not known in most cases. But assuming that policies do not change in short time scale, in principle one could verify new updates against observed routes from the recent past, which reflect the
Handley, et al. Informational [Page 27] RFC 4732 DoS Considerations November 2006
Handley, et al. Informational [Page 27] RFC 4732 DoS Considerations November 2006
routing policies in place. Research work is needed to explore this direction.
routing policies in place. Research work is needed to explore this direction.
Note that while the above steps are all fairly simple and don't really "bulletproof" the protocol, each adds some degree of protection. As such, the combination of the above techniques can result in an effective reduction in the probability of undetected faults.
Note that while the above steps are all fairly simple and don't really "bulletproof" the protocol, each adds some degree of protection. As such, the combination of the above techniques can result in an effective reduction in the probability of undetected faults.
4.3.3. Enhance Router Robustness through Operational Adjustments
4.3.3. Enhance Router Robustness through Operational Adjustments
There exist a number of configuration tunings that can enhance robustness of BGP operations. One example is to let BGP peers coordinate the setting of a limit on the number of prefixes that one BGP speaker will send to its peer [43]. Although such a check does not validate the prefix owned by each peer, it can prevent false announcements of large numbers of invalid routes. Had all BGP routers been configured with this simple checking earlier, several large-scale routing outages in the past could have been prevented. Note, however, that care must be taken with hard limits of this type because they can be used to mount a DoS because implementations often discard excess routes indiscriminately, thus potentially causing black-holing of correct routes.
There exist a number of configuration tunings that can enhance robustness of BGP operations. One example is to let BGP peers coordinate the setting of a limit on the number of prefixes that one BGP speaker will send to its peer [43]. Although such a check does not validate the prefix owned by each peer, it can prevent false announcements of large numbers of invalid routes. Had all BGP routers been configured with this simple checking earlier, several large-scale routing outages in the past could have been prevented. Note, however, that care must be taken with hard limits of this type because they can be used to mount a DoS because implementations often discard excess routes indiscriminately, thus potentially causing black-holing of correct routes.
Another example of useful configuration tuning is to adjust the BGP's KeepAlive and Hold Timer values to minimize BGP peering session resets. Previous measurements show that heavy traffic load, such as those caused by worms, can cause BGP KeepAlive messages to be delayed or dropped, which in turn cause BGP peering session breakdown. Such load-induced session breaks and re-establishments can lead to an excessive amount of BGP updates during the periods when stable routing is needed most.
Another example of useful configuration tuning is to adjust the BGP's KeepAlive and Hold Timer values to minimize BGP peering session resets. Previous measurements show that heavy traffic load, such as those caused by worms, can cause BGP KeepAlive messages to be delayed or dropped, which in turn cause BGP peering session breakdown. Such load-induced session breaks and re-establishments can lead to an excessive amount of BGP updates during the periods when stable routing is needed most.
4.3.4. Proper Handling of Router Resource Exhaustion
4.3.4. Proper Handling of Router Resource Exhaustion
In addition to the resource exhaustion problems that are generally apply to all end-systems, as described in Section 2, router implementations must also take special care in handling resource exhaustions when they occur in order to keep the router operating despite the problem. For example, under normal operations a router does not require a large cache to hold outstanding ARP requests because the replies are normally received within a few milliseconds. However, certain conditions can lead to ARP cache exhaustion, for example, during a virus attack where many packets are sent to non- existing IP addresses, thus there are no ARP replies to the requests for those addresses. Such phenomena have happened in the past and led to routers failing to forward packets.
In addition to the resource exhaustion problems that are generally apply to all end-systems, as described in Section 2, router implementations must also take special care in handling resource exhaustions when they occur in order to keep the router operating despite the problem. For example, under normal operations a router does not require a large cache to hold outstanding ARP requests because the replies are normally received within a few milliseconds. However, certain conditions can lead to ARP cache exhaustion, for example, during a virus attack where many packets are sent to non- existing IP addresses, thus there are no ARP replies to the requests for those addresses. Such phenomena have happened in the past and led to routers failing to forward packets.
Handley, et al. Informational [Page 28] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [28ページ]情報のRFC4732DoS問題2006年11月
Another example is queue management. Many high-end routers are designed so that most packets can be handled purely in specialized processors (Application-Specific Integrated Circuit (ASICs), Field Programmable Gate-Arrays (FPGAs), etc.). However, exceptional packets must be routed to a supporting general purpose CPU for handling. On some such systems, it may be possible mount a low- effort DoS attack by saturating the queues between the specialized hardware and the supporting processor.
別の例は待ち行列管理です。 多くのハイエンドルータが、専門化しているプロセッサ(アプリケーション特有のIntegrated Circuit(ASICs)、Field Programmable Gate-配列(FPGAs)など)で純粋にほとんどのパケットを扱うことができるように設計されています。 しかしながら、取り扱いのためのサポートの汎用のCPUに例外的なパケットを発送しなければなりません。 そのようないくつかのシステムの上では、それは低い取り組みDoSが専門化しているハードウェアとサポートプロセッサの間の待ち行列を飽和状態にすることによって攻撃する可能なマウントであるかもしれません。
So the attack vector on routers/network devices is a low packets- per-second (PPS) queue saturation attack on the ASIC's raw queue structure. The countermeasure here is to have multiple such queues designed in such a way that it's difficult for an attacker to arrange to fill multiple queues [45].
それで、ルータ/ネットワークデバイスの攻撃ベクトルはASICの生の待ち行列構造におけるパケット2(PPS)番目の低い待ち行列集中攻撃です。 ここの対策は待ち行列が攻撃者が、複数の待ち行列[45]をいっぱいにするように手配するのが、難しいような方法で設計した複数のそのようなものを持つことです。
4.4. End-System Implementation Issues
4.4. 終わりシステムの実現問題
4.4.1. State Lookup Complexity
4.4.1. 州のルックアップの複雑さ
Any system that instantiates per-connection state should take great care to implement state-lookup mechanisms in such a way that performance cannot be controlled by the attacker. One way to achieve this is to use hash tables where the hash mechanism is keyed in such a way that the attacker cannot instantiate a large number of flows in the same hash bucket.
1接続あたりの状態を例示するどんなシステムも、攻撃者が性能を制御できないような方法で州ルックアップメカニズムを実装するために高度の注意を取るはずです。 これを達成する1つの方法はハッシュメカニズムが攻撃者が同じハッシュバケツにおける多くの流れを例示できないような方法で合わせられるハッシュ表を使用することです。
4.4.1.1. Avoid Livelock
4.4.1.1. Livelockを避けてください。
Most operating systems use network interrupts to receive data from the network, which is a good solution if the host spends only a small amount of its time handling network traffic. However, this leaves the host open to livelock [33], where under heavy load the OS spends all its time handling interrupts and no time doing the work needed to handle the traffic at the application level. Server operating systems should consider using network polling at times of heavy load, rather than being interrupt-driven, and should be carefully architected so that as far as reasonably possible, traffic received by the OS is processed to completion or very cheaply discarded.
ほとんどのオペレーティングシステムが、ネットワークからデータを受け取るのにネットワーク中断を使用します。(ホストが少量の時間取り扱いネットワークトラフィックだけを費やすなら、ネットワークは良いソリューションです)。 しかしながら、これはlivelock[33]へホストを開いた状態でおきます、そして、仕事をするどんな時間もアプリケーションレベルでトラフィックを扱う必要がありませんでした。(そこでは、重量物の下で、OSがすべての時間取り扱い中断を費やします)。 サーバオペレーティングシステムが、時にはネットワーク世論調査を使用して、悪党では、合理的にできるだけ遠くなるように中断駆動であり、慎重にarchitectedされるべきであるよりむしろロードするように考えるべきであり、OSで受け取られたトラフィックは、完成に処理されるか、または非常に安く捨てられます。
4.4.1.2. Use Unpredictable Values for Session IDs
4.4.1.2. セッションIDに予測できない値を使用してください。
Most recent TCP implementations use fairly good random mechanisms for allocating the TCP initial sequence numbers. In general, any dynamically allocated value used purely to identify a communication session should be allocated using an unpredictable mechanism, as this increases the search space for an attacker that wishes to disrupt ongoing communications. Thus, the dynamically allocated port of the active end of a TCP connection might also be randomly allocated.
最新のTCP実装は、TCP初期シーケンス番号を割り当てるのに良いランダム機構を公正に使用します。 一般に、予測できないメカニズムを使用することでコミュニケーションセッションを特定するのに純粋に使用されるどんなダイナミックに割り当てられた値も割り当てるべきです、これが通信の進行中のシステムを遮断したがっている攻撃者のために検索スペースを増強するのに従って。 したがって、また、手当たりしだいにTCP接続のアクティブな終わりのダイナミックに割り当てられたポートを割り当てるかもしれません。
Handley, et al. Informational [Page 29] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [29ページ]情報のRFC4732DoS問題2006年11月
With DNS, the ID that is used to match responses with requests should also be randomly generated. However, as the ID field is only 16 bits, the protection is rather limited.
また、DNSと共に、要求に応答に合うのに使用されるIDは手当たりしだいに生成されるべきです。 しかしながら、ID分野が16ビットにすぎないので、保護はかなり限られています。
4.4.2. Operational Issues
4.4.2. 操作上の問題
4.4.2.1. Eliminate Bad Traffic Early
4.4.2.1. 早く悪いトラフィックを排除してください。
Many DoS attacks are generic bandwidth consumption attacks that operate by clogging the link that connects the victim server to the Internet. Filtering these attacks at the server does no good because the traffic has already traversed the link that is the scarce resource. Such flows need to be filtered at some point closer to the attacker. Where possible, operators should filter out obviously bad traffic. In particular, they should perform ingress filtering [7].
多くのDoS攻撃は犠牲者サーバをインターネットに関連づけるリンクを妨げることによって作動するジェネリック帯域幅消費攻撃です。 トラフィックが既に不十分なリソースであるリンクを横断したので、サーバでこれらの攻撃をフィルターにかけるのに役に立ちません。 そのような流れは、攻撃者の何らかのポイントより近くでフィルターにかけられる必要があります。 可能であるところでは、オペレータが明らかに悪いトラフィックを無視するべきです。 特に、彼らは[7]をフィルターにかけるイングレスを実行するべきです。
4.4.2.2. Establish a Monitoring Framework
4.4.2.2. モニターしているフレームワークを確立してください。
Network operators are strongly encouraged to establish a monitoring framework to detect and log abnormal network activity. One cannot defend against an attack that one doesn't detect or understand. Such monitoring tools can be used to set a baseline of "normal" traffic, and can be used to detect aberrant flows and determine the type and source of the aberrant flows. This is extremely helpful when responding to distributed DoS attacks or a flash crowd, and should be in place prior to the event.
ネットワーク・オペレータが異常なネットワーク活動を検出して、登録するためにモニターしているフレームワークを確立するよう強く奨励されます。 1つはものが検出もしませんし、理解もしていない攻撃に対して防御されることができません。 そのようなモニターしているツールを「正常な」トラフィックの基線を設定するのに使用できて、常軌をはずしている流れを検出して、常軌をはずしている流れのタイプと源を決定するのに使用できます。 これは、分配されたDoS攻撃かフラッシュ群衆に応じるとき、非常に役立って、イベントの前に適所にあるべきです。
5. Conclusions
5. 結論
In this document, we have highlighted possible avenues for DoS attacks on networks and networked systems, with the aim of encouraging protocol designers and network engineers towards designs that are more robust. We have discussed partial solutions that reduce the effectiveness of attacks, and highlighted how some partial solutions can be taken advantage of by attackers to perpetrate alternative attacks.
本書では、私たちは、ネットワークに対するDoS攻撃のために可能な大通りを強調して、システムをネットワークでつなぎました、より強健なデザインに向かってプロトコルデザイナーとネットワーク・デザイナーを奨励する目的で。 私たちは、攻撃の有効性を減少させる部分的解決について議論して、攻撃者が代替の攻撃を犯すのにどういくつかの部分的解決を利用できるかを強調しました。
Our focus has primarily been on protocol and network architecture issues, but there are many things that network and service operators can do to lessen the threat. Further advice and information for network operators can be found in [24] [39] [25].
プロトコルとネットワークアーキテクチャ問題には私たちの焦点が主としてありましたが、ネットワークとサービスオペレータが脅威を少なくするためにできる多くのことがあります。 [24] [39][25]でネットワーク・オペレータへのさらなるアドバイスと情報を見つけることができます。
It is our hope that this document will spur discussion leading to architectural solutions that reduce the succeptibility of all Internet systems to denial-of-service attacks.
すべてのインターネット・システムのsucceptibilityをサービス不能攻撃に減少させるのは、このドキュメントが建築溶液に通じる議論に拍車をかけるという私たちの望みです。
Handley, et al. Informational [Page 30] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [30ページ]情報のRFC4732DoS問題2006年11月
6. Security Considerations
6. セキュリティ問題
This entire document is about security.
この全体のドキュメントはセキュリティに関するものです。
7. Acknowledgements
7. 承認
We are very grateful to Vern Paxson, Paul Vixie, Rob Thomas, Dug Song, George Jones, Jari Arkko, Geoff Huston, and Barry Greene for their constructive comments on earlier versions of this document.
私たちはバーン・パクソン、ポールVixie、ロブ・トーマス、Dug Song、ジョージ・ジョーンズ、ヤリArkko、ジェフ・ヒューストン、およびバリー・グリーンにこのドキュメントの以前のバージョンの彼らの建設的なコメントに非常に感謝しています。
8. Normative References
8. 引用規格
[1] J. Abley, "Hierarchical Anycast for Global Service
Distribution", http://www.isc.org/index.pl?/pubs/tn/
index.pl?tn=isc-tn-2003-1.txt.
[1] J.Abley、「グローバルなサービス分配のための階層的なAnycast」 http://www.isc.org/index.pl?/pubs/tn/ index.pl?tn=isc-tn-2003-1.txt。
[2] D.J. Bernstein, "SYN Cookies", http://cr.yp.to/syncookies.html.
[2] D.J.バーンスタイン、「SYNクッキー」、 http://cr.yp.to/syncookies.html 。
[3] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
September 2000.
[3] チェン、E.、「ルートは2000年9月にBGP-4インチ、RFC2918のために能力をリフレッシュします」。
[4] Deering, S., "Host extensions for IP multicasting", STD 5, RFC
1112, August 1989.
[4] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[5] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[5] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[6] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", RFC 4601, August 2006.
[6] フェナー、B.、ハンドレー、M.、ホルブルック、H.、およびI.Kouvelas、「プロトコルの独立しているマルチキャスト--まばらなモード(PIM-Sm):、」 「プロトコル仕様(改訂される)」、RFC4601、2006年8月。
[7] 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.
[7] ファーガソン、P.、およびD.Senieは「以下をフィルターにかけるイングレスをネットワークでつなぎます」。 「IP Source Address Spoofingを使うサービス妨害Attacksを破ります」、BCP38、RFC2827、2000年5月。
[8] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL
Security Mechanism (GTSM)", RFC 3682, February 2004.
[8]エラ、V.、Heasley、J.、およびD.マイヤー、「一般化されたTTLセキュリティー対策(GTSM)」、RFC3682 2004年2月。
[9] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[9] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、1998年8月。
[10] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4
(BGP-4)", RFC 4271, January 2006.
[10]Rekhter、Y.、李、T.、およびS.野兎、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC4271 2006年1月。
[11] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap
Damping", RFC 2439, November 1998.
[11]VillamizarとC.とチャンドラ、R.とR.Govindan、「BGPルートフラップ湿気」、RFC2439、1998年11月。
Handley, et al. Informational [Page 31] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [31ページ]情報のRFC4732DoS問題2006年11月
[12] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector
Multicast Routing Protocol", RFC 1075, November 1988.
[12]WaitzmanとD.とヤマウズラ、C.とS.デアリング、「ディスタンス・ベクタ・マルチキャスト・ルーティング・プロトコル」、RFC1075、1988年11月。
[13] L. von Ahn, M. Blum, N. Hopper, and J. Langford. CAPTCHA: Using
hard AI problems for security. In Proceedings of Eurocrypt,
2003.
[13] L.フォン・アン、M.ブルーム、N.Hopper、およびJ.ラングフォード。 CAPTCHA: セキュリティに困難なAI問題を使用します。 Eurocrypt、2003年の議事で。
9. Informative References
9. 有益な参照
[14] T. Aura, P. Nikander, J. Leiwo, "DOS-resistant authentication
with client puzzles", In B. Christianson, B. Crispo, and M. Roe,
editors, Proceedings of the 8th International Workshop on
Security Protocols, Lecture Notes in Computer Science,
Cambridge, UK, April 2000.
[14] コンピュータScience、ケンブリッジイギリス(2000年4月)のT.香気とP.NikanderとJ.Leiwoと「クライアントパズルがある耐DOSの認証」とIn B.Christianson、B.CrispoとM.Roe、エディタ(Securityプロトコルの第8国際WorkshopのProceedings)Lecture Notes。
[15] J. Bellardo, S. Savage, "802.11 Denial-of-Service Attacks: Real
Vulnerabilities and Practical Solutions", Proceedings of the
USENIX Security Symposium, Washington D.C., August 2003.
[15] J.Bellardo、S.サヴェージ、「802.11のサービス不能攻撃:」 「本当の脆弱性の、そして、実用的なソリューション」、USENIXセキュリティシンポジウム、ワシントンDC、2003年8月の議事。
[16] S.M. Bellovin, "Security Problems in the TCP/IP Protocol Suite",
Computer Communication Review, Vol. 19, No. 2, pp. 32-48, April
1989.
[16] S.M.Bellovin、「TCP/IPプロトコル群の警備上の問題」、コンピュータCommunication Review、Vol.19、No.2、ページ 32-48と、1989年4月。
[17] CCAIS/RNP Alertas do Cais ALR-19112002a, "Vulnerability in the
sending requests control of Bind versions 4 and 8 allows DNS
spoofing",
http://www.rnp.br/cais/alertas/2002/cais-ALR-19112002a.html.
[17] CCAIS/RNP AlertasはCais ALR-19112002aをします、と「Bindバージョン4と8の送付要求コントロールにおける脆弱性はDNSスプーフィングを許容します」、 http://www.rnp.br/cais/alertas/2002/cais-ALR-19112002a.html 。
[18] CERT Advisory CA-1996-01, "UDP Port Denial-of-Service Attack",
Feb 1996.
[18]CERT勧告、カリフォルニア-1996-01、「UDPポートサービス不能攻撃」、2月1996
[19] CERT Advisory CA-1996-21, "TCP SYN Flooding and IP Spoofing
Attacks", Sept 1996.
[19]CERT勧告、カリフォルニア-1996-21 「TCP SYN氾濫とIPスプーフィング攻撃」、9月1996日
[20] CERT Advisory CA-2001-09, "Statistical Weaknesses in TCP/IP
Initial Sequence Numbers", May 2001.
[20] 「TCP/IP初期シーケンス番号における統計的な弱点」というカリフォルニア-2001-09が2001にそうするかもしれないCERT勧告
[21] CERT Advisory CA-1996-26, "Denial-of-Service Attack via ping",
Dec 1996.
[21] CERT勧告カリフォルニア-1996-26、「ピングを通したサービス妨害Attack」1996年12月。
[22] CERT Advisory CA-1998-01, "Smurf IP Denial-of-Service Attacks",
http://www.cert.org/advisories/CA-1998-01.html, Jan 1998.
[22]CERT勧告、カリフォルニア-1998-01、「Smurf IPサービス不能攻撃」 http://www.cert.org/advisories/CA-1998-01.html 、1月1998日
[23] CERT Incident Note IN-2000-05, "'mstream' Distributed Denial of
Service Tool", May 2000.
[23] 2000-05のCERTインシデント「'mstream'分散型サービス妨害ツール」は2000がそうするかもしれません。
[24] CERT/CC - "Managing the Threat of Denial of Service Attacks",
http://www.cert.org/archive/pdf/Managing_DoS.pdf.
[24]CERT/CC--「サービス不能攻撃の脅威を管理します」、 http://www.cert.org/archive/pdf/Managing_DoS.pdf 。
Handley, et al. Informational [Page 32] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [32ページ]情報のRFC4732DoS問題2006年11月
[25] CERT/CC - "Trends in Denial of Service Attack Technology",
http://www.cert.org/archive/pdf/DoS_trends.pdf.
[25]CERT/CC--「サービス不能攻撃技術における傾向」、 http://www.cert.org/archive/pdf/DoS_trends.pdf 。
[26] D.F. Chang, R. Govindan, J. Heidemann, "An Empirical Study of
Router Response to Large Routing Table Load", Proceedings of the
2nd Internet Measurement Workshop (IMW 2002), 2002.
[26] D.F.チャン、R.Govindan、J.Heidemann、「大きい経路指定テーブル荷重へのルータ応答の実証的研究」、第2インターネット測定ワークショップ(IMW2002)、2002年の議事。
[27] Cisco Systems, "Configuring the BGP Maximum-Prefix Feature",
Cisco Document ID: 25160,
http://www.cisco.com/warp/public/459/bgp-maximum-prefix.html.
[27] 「BGP最大の接頭語機能を構成します」、コクチマスDocumentシスコシステムズ(ID): 25160 http://www.cisco.com/warp/public/459/bgp-maximum-prefix.html 。
[28] Scott A Crosby and Dan S Wallach, "Denial of Service via
Algorithmic Complexity Attacks", Proceedings of the USENIX
Security Symposium, Washington D.C., August 2003.
[28] スコット・Aクロズビーとダン・Sウォーラック、「Algorithmic Complexity Attacksを通したサービス妨害」、USENIX Security Symposium、ワシントンDC(2003年8月)のProceedings。
[29] Laurent Joncheray, "Simple Active Attack Against TCP", 5th
USENIX Security Symposium, 1995.
[29]ローランJoncheray、「TCPに対する簡単な活発な攻撃」、第5USENIXセキュリティシンポジウム、1995。
[30] M. Lough, "A Taxonomy of Computer Attacks with Applications to
Wireless", PhD thesis, Virginia Polytechnic Institute, April
2001.
[30] M.湖、「ワイヤレスへのアプリケーションとのコンピュータ攻撃の分類学」、博士論文、バージニア州工芸協会、2001年4月。
[31] Z. Mao, R. Govindan, G. Varghese, R. Katz, "Route Flap Dampening
Exacerbates Internet Routing Convergence", Proceedings of ACM
SIGCOMM, 2002.
[31] Z.マオ、R.Govindan、G.Varghese、R.キャッツ、「ルートフラップの湿りはインターネットルート設定集合を悪化させる」ACM SIGCOMM、2002年の議事。
[32] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery
Protocol (MSDP)", RFC 3618, October 2003.
[32] フェナー、B.、エド、D.マイヤー、エド、「マルチキャストソース発見プロトコル(MSDP)」、RFC3618、10月2003日
[33] J. Mogul, KK. Ramakrishnan, "Eliminating Receive Livelock in an
Interrupt-driven Kernel", ACM Transactions on Computer Systems,
Vol 15, Number 3, pp. 217-252, 1997.
[33] J.ムガール人、KK。 Ramakrishnan、「排泄して、中断やる気満々のカーネルでLivelockを受けてください」、コンピュータシステムズのACM Transactions、Vol15、Number3、ページ 217-252, 1997.
[34] Watson, P., "Slipping in the Window: TCP Reset attacks",
Presentation at 2004 CanSecWest,
http://www.cansecwest.com/archives.html.
[34] ワトソン、「窓で以下を滑らせる」P. 「TCP Reset攻撃」、2004CanSecWest、 http://www.cansecwest.com/archives.html のPresentation。
[35] V. Paxson, "An Analysis of Using Reflectors for Distributed
Denial-of-Service Attacks", Computer Communication Review 31(3),
July 2001.
[35] V.パクソン、「分散型サービス妨害攻撃のための使用反射鏡の分析」、コンピュータコミュニケーションレビュー31(3)、2001年7月。
[36] Joe Stewart, "DNS Cache Poisoning - The Next Generation", Jan 27
2003, http://www.lurhq.com/dnscache.pdf.
[36] ジョー・スチュワート、「DNSは中毒をキャッシュします--次世代」、2003年1月27日、 http://www.lurhq.com/dnscache.pdf 。
[37] Stewart, R., Ed., and M. Dalal, Ed., "Improving TCP's Robustness
to Blind In-Window Attacks", Work in Progress, June 2006.
[37] スチュワート、R.、エド、エドM.Dalal、処理中の作業、「窓での盲目の攻撃にTCPの丈夫さを改良すること」での6月2006日
Handley, et al. Informational [Page 33] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [33ページ]情報のRFC4732DoS問題2006年11月
[38] P. Vixie, G. Sneeringer, M. Schleifer, "Events of 21-Oct-2002",
http://f.root-servers.org/october21.txt.
[38] P.Vixie、G.Sneeringer、M.Schleifer、「2002年10月21日のイベント」、 http://f.root-servers.org/october21.txt 。
[39] P. Vixie, "Securing the Edge",
http://www.icann.org/committees/security/sac004.txt.
[39]P.Vixie、「縁を保証します」、 http://www.icann.org/committees/security/sac004.txt 。
[40] D. Wessels, "Running An Authoritative-Only BIND Nameserver",
http://www.isc.org/index.pl?/pubs/tn/
index.pl?tn=isc-tn-2002-2.txt.
[40] D.ウェセルズ、「正式に唯一のひもを実行する、ネームサーバ、」、 http://www.isc.org/index.pl?/pubs/tn/ index.pl?tn=isc-tn-2002-2.txt。
[41] M. Zalewski, "Strange Attractors and TCP/IP Sequence Number
Analysis",
http://www.bindview.com/Services/Razor/Papers/2001/tcpseq.cfm.
[41]M.Zalewskiと、「奇妙なアトラクタとTCP/IP一連番号分析」、 http://www.bindview.com/Services/Razor/Papers/2001/tcpseq.cfm 。
[42] D. Pei, X. Zhao, L. Wang, D. Massey, A. Mankin, F. S. Wu, and L.
Zhang. Improving BGP Conver-gence Through Assertions Approach.
In Proc. of IEEE INFOCOM, June 2002.
[42] D.ペイ、X.チャオ、L.ワング、D.マッシー、A.マンキン、F.S.ウー、およびL.チャン。 主張アプローチでBGP集合を改良します。 中、Proc IEEE INFOCOM、2002年6月について。
[43] Chavali, S., Radoaca, V., Miri, M., Fang, L., and S. Hares,
"Peer Prefix Limits Exchange in BGP", Work in Progress, April
2004.
[43] Chavali、S.、Radoaca、V.、ミリ、M.、牙、L.、およびS.野兎、「限界がBGPで交換する同輩接頭語」は進行中(2004年4月)で働いています。
[44] X. Zhao, D. Massey, A. Mankin, S.F. Wu, D. Pei, L. Wang, L.
Zhang, "BGP Multiple Origin AS (MOAS) Conflicts",
http://nanog.org/mtg-0110/lixia.html, 2001.
[44] X.チャオ、D.マッシー、A.マンキン、S.F.ウー、D.ペイ、L.ワング、L.チャン、「(モア)としてのBGP複数の発生源が闘争する」 http://nanog.org/mtg-0110/lixia.html 、2001。
[45] Cisco Systems, "Building Security Into the Hardware",
ftp://ftp-eng.cisco.com/cons/isp/security/CPN-Summit-2004/
Paris-Sept-04/SE14-BUILDING-SECURITY-INTO-THE-HARDWARE-
c1_8_30_04.pdf, 2004.
[45]シスコシステムズ、「ハードウェアへのビルの防犯」、 ftp://ftp-eng.cisco.com/cons/isp/security/CPN-Summit-2004/ パリ9月-04/SE14ビル-SECURITY-INTO、-、-、HARDWARE- c1_8_30_04.pdf、2004
[46] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol
Architecture", RFC 4251, January 2006.
[46]YlonenとT.とC.Lonvick、「セキュア・シェル(セキュアシェル (SSH))プロトコルアーキテクチャ」、RFC4251、2006年1月。
[47] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", RFC
3768, April 2004.
[47]Hinden、2004年4月のR.、「仮想のルータ冗長プロトコル(VRRP)」RFC3768。
[48] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for
Describing Simple Network Management Protocol (SNMP) Management
Frameworks", STD 62, RFC 3411, December 2002.
[48] ハリントン、D.、Presuhn、R.、およびB.Wijnen、「簡単なネットワーク管理プロトコル(SNMP)管理フレームワークについて説明するためのアーキテクチャ」、STD62、RFC3411(2002年12月)。
[49] Malkin, G. and A. Harkin, "TFTP Timeout Interval and Transfer
Size Options", RFC 2349, May 1998.
[49] マルキン、G.、A.ハーキン、および「TFTPタイムアウト間隔と転送サイズオプション」(RFC2349)は1998がそうするかもしれません。
[50] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[50] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
Handley, et al. Informational [Page 34] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [34ページ]情報のRFC4732DoS問題2006年11月
[51] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[51] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
[52] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[52]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[53] Hedrick, C., "Routing Information Protocol", RFC 1058, June
1988.
[53] ヘドリック、C.、「ルーティング情報プロトコル」、RFC1058、1988年6月。
Handley, et al. Informational [Page 35] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [35ページ]情報のRFC4732DoS問題2006年11月
Appendix A. IAB Members at the Time of This Writing
この書くこと時点の付録A.IABメンバー
o Bernard Aboba
o バーナードAboba
o Loa Andersson
o Loaアンデション
o Brian Carpenter
o ブライアン大工
o Leslie Daigle
o レスリーDaigle
o Elwyn Davies
o Elwynデイヴィース
o Kevin Fall
o ケビンFall
o Olaf Kolkman
o オラフKolkman
o Kurtis Lindvist
o カーティスLindvist
o David Meyer
o デヴィッド・マイヤー
o David Oran
o デヴィッド・オラン
o Eric Rescorla
o エリック・レスコラ
o Dave Thaler
o デーヴThaler
o Lixia Zhang
o Lixiaチャン
Handley, et al. Informational [Page 36] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [36ページ]情報のRFC4732DoS問題2006年11月
Authors' Addresses
作者のアドレス
Mark J. Handley, Ed. UCL Gower Street London WC1E 6BT UK
マーク・J.ハンドレー、エドUCLガウアー・ストリートロンドンWC1E 6BTイギリス
EMail: M.Handley@cs.ucl.ac.uk
メール: M.Handley@cs.ucl.ac.uk
Eric Rescorla, Ed. Network Resonance 2483 E. Bayshore #212 Palo Alto 94303 USA
エドエリック・ネットワーク共鳴2483E.Bayshore#212パロアルト94303レスコラ(米国)
EMail: ekr@networkresonance.com
メール: ekr@networkresonance.com
Internet Architecture Board IAB
インターネット・アーキテクチャ委員会IAB
EMail: iab@ietf.org
メール: iab@ietf.org
Handley, et al. Informational [Page 37] RFC 4732 DoS Considerations November 2006
ハンドレー、他 [37ページ]情報のRFC4732DoS問題2006年11月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、IETF信頼、「そのままで」という基礎と貢献者の上で提供していて、そして、インターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Handley, et al. Informational [Page 38]
ハンドレー、他 情報[38ページ]
一覧
スポンサーリンク
