RFC4953 日本語訳
4953 Defending TCP Against Spoofing Attacks. J. Touch. July 2007. (Format: TXT=72756 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Touch Request for Comments: 4953 USC/ISI Category: Informational July 2007
コメントを求めるワーキンググループJ.接触要求をネットワークでつないでください: 4953年のUSC/ISIカテゴリ: 情報の2007年7月
Defending TCP Against Spoofing Attacks
スプーフィング攻撃に対してTCPを防御します。
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 (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
Recent analysis of potential attacks on core Internet infrastructure indicates an increased vulnerability of TCP connections to spurious resets (RSTs), sent with forged IP source addresses (spoofing). TCP has always been susceptible to such RST spoofing attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation of TCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP or between web servers and well-known large-scale caches, increases in the path bandwidth- delay product of a connection have sufficiently increased the receive window space that off-path third parties can brute-force generate a viable RST sequence number. The susceptibility to attack increases with the square of the bandwidth, and thus presents a significant vulnerability for recent high-speed networks. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment. This document focuses on vulnerabilities due to spoofed TCP segments, and includes a discussion of related ICMP spoofing attacks on TCP connections.
コアインターネットインフラストラクチャにおける起こり得るかもしれない攻撃の最近の分析は偽造IPソースアドレス(スプーフィング)と共に送られた偽りのリセット(RSTs)にTCP接続の増強された脆弱性を示します。 TCPはそのようなRSTスプーフィング攻撃とTCP終点とポートナンバーの困惑を通していつも影響されやすいです。(RST一連番号が電流の中で窓を受けることであったのをチェックすることによって、攻撃は間接的に保護されました)。 しばしば組がa接続の遅れ成果が十分増強した経路帯域幅でBGPなどかウェブサーバーとよく知られる大規模なキャッシュの間で増強する予測できるポートの上の組のよく知られる終点、オフ経路第三者缶のブルートフォースが実行可能なRST一連番号に生成する窓のスペースを受けてください。 攻撃する敏感さは、帯域幅の正方形で増加して、その結果、最近の高速ネットワークのために重要な脆弱性を提示します。 このドキュメントは、この脆弱性と輸送レベルで提案されたソリューションについて議論して、既存のネットワークレベルと同様に彼らの固有の挑戦がソリューションと彼らの展開に関する実現の可能性であると扱います。 このドキュメントは、偽造しているTCPセグメントのため脆弱性に焦点を合わせて、TCP接続についての関連するICMPスプーフィング攻撃の議論を含んでいます。
Touch Informational [Page 1] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[1ページ]のRFC4953の防御しているTCPに触れてください。
Table of Contents
目次
1. Introduction ....................................................3
2. Background ......................................................4
2.1. Review of TCP Windows ......................................5
2.2. Recent BGP Attacks Using TCP RSTs ..........................6
2.3. TCP RST Vulnerability ......................................6
2.4. What Changed - the Ever-Opening Advertised Receive Window ..7
3. Proposed Solutions and Mitigations .............................10
3.1. Transport Layer Solutions .................................10
3.1.1. TCP MD5 Authentication .............................11
3.1.2. TCP RST Window Attenuation .........................11
3.1.3. TCP Timestamp Authentication .......................12
3.1.4. Other TCP Cookies ..................................13
3.1.5. Other TCP Considerations ...........................13
3.1.6. Other Transport Protocol Solutions .................14
3.2. Network Layer (IP) Solutions ..............................14
3.2.1. Address Filtering ..................................15
3.2.2. IPsec ..............................................16
4. ICMP ...........................................................17
5. Issues .........................................................18
5.1. Transport Layer (e.g., TCP) ...............................18
5.2. Network Layer (IP) ........................................19
5.3. Application Layer .........................................21
5.4. Link Layer ................................................21
5.5. Issues Discussion .........................................21
6. Security Considerations ........................................22
7. Conclusions ....................................................23
8. Acknowledgments ................................................23
9. Informative References .........................................24
1. 序論…3 2. バックグラウンド…4 2.1. TCP Windowsのレビュー…5 2.2. 最近のBGPはTCP RSTsを使用することで攻撃します…6 2.3. TCP RST脆弱性…6 2.4. 変化したもの--広告に掲載された絶えず始まりは窓を受けます。7 3. ソリューションと緩和を提案します…10 3.1. 層の溶液を輸送してください…10 3.1.1. TCP MD5認証…11 3.1.2. TCP RST窓の減衰…11 3.1.3. TCPタイムスタンプ認証…12 3.1.4. 他のTCPクッキー…13 3.1.5. 他のTCP問題…13 3.1.6. 他のトランスポート・プロトコルソリューション…14 3.2. ネットワーク層(IP)ソリューション…14 3.2.1. フィルタリングを扱ってください…15 3.2.2. IPsec…16 4. ICMP…17 5. 問題…18 5.1. 層(例えば、TCP)を輸送してください…18 5.2. ネットワーク層(IP)…19 5.3. アプリケーション層…21 5.4. 層をリンクしてください…21 5.5. 議論を発行します…21 6. セキュリティ問題…22 7. 結論…23 8. 承認…23 9. 有益な参照…24
Touch Informational [Page 2] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[2ページ]のRFC4953の防御しているTCPに触れてください。
1. Introduction
1. 序論
Analysis of the Internet infrastructure has recently demonstrated a new version of a vulnerability in BGP connections between core routers using an attack based on RST spoofing from off-path attackers [9][10][48]. The attack itself is not new, having been documented nearly six years earlier [20]. Such connections, typically using TCP, can be susceptible to off-path third-party reset (RST) segments with forged source addresses (spoofed), which terminate the TCP connection. BGP routers react to a terminated TCP connection in various ways, which can amplify the impact of an attack, ranging from restarting the connection to deciding that the other router is unreachable and thus flushing the BGP routes [37]. This sort of attack affects other protocols besides BGP, involving any long-lived connection between well-known endpoints. The impact on the Internet infrastructure can be substantial (especially for the BGP case), and warrants immediate attention.
オフ経路から攻撃者[9][10]が[48]であると偽造しながら、インターネット基盤の分析は最近、コアルータの間にRSTに基づく攻撃を使用することでBGP接続における脆弱性の新しいバージョンを示しました。 記録されたおよそ6何年も、より初期の[20]であり攻撃自体は新しくはありません。 TCPを通常使用して、そのような接続は偽造ソースアドレス(だます)でオフ経路第三者リセット(RST)セグメントに影響されやすい場合があります。(ソースアドレスはTCP接続を終えます)。 BGPルータは様々な方法で終えられたTCP接続に反応します、接続を再出発するのからもう片方のルータが手が届かないと決めて、その結果、BGPルート[37]を洗い流すまで及んで。(方法は攻撃の影響を増幅できます)。 よく知られる終点の間のどんな長命の接続にもかかわって、この種類の攻撃はBGP以外に他のプロトコルに影響します。 インターネット基盤の影響は、実質的である場合があり(特にBGPケースのための)、応急手当を保証します。
TCP, like many other protocols, can be susceptible to these off-path third-party spoofing attacks. Such attacks rely on the increase of commodity platforms supporting public access to previously privileged resources, such as system-level (i.e., root) access. Given such access, it is trivial for anyone to generate a packet with any header desired.
他の多くのプロトコルのように、TCPはこれらのオフ経路第三者スプーフィング攻撃に影響されやすい場合があります。 そのような攻撃は以前に特権があるリソースにパブリックアクセスをサポートする商品プラットホームの増加に依存します、システムレベル(すなわち、根づく)アクセサリーなどのように そのようなアクセスを考えて、どんなヘッダーも望まれている状態でだれでもパケットを生成するのは、些細です。
This, coupled with the lack of sufficient address filtering to drop such spoofed traffic, can increase the potential for off-path third- party spoofing attacks [9][10][48]. Proposed solutions include the deployment of existing Internet network and transport security as well as modifications to transport protocols that reduce its vulnerability to generated attacks [13][15][20][36][46].
トラフィックであると偽造されたそのようなものは下げることができるくらいのアドレスフィルタリングの不足に結びつけられたこれが攻撃[9]が[10][48]であると偽造するオフ経路3番目のパーティーの可能性を増強できます。 提案されたソリューションは、発生している攻撃[13][15][20][36][46]に脆弱性を減少させるプロトコルを輸送するために変更と同様に既存のインターネット網と輸送セキュリティの展開を含んでいます。
One way to defeat spoofing is to validate the segments of a connection, either at the transport level or the network level. TCP with MD5 extensions provides this authentication at the transport level, and IPsec provides authentication at the network level [20][24][27]. In both cases, their deployment overhead may be prohibitive, e.g., it may not be feasible for public services, such as web servers, to be configured with the appropriate certificate authorities of large numbers of peers (for IPsec using the Internet Key Exchange Protocol (IKE)), or shared secrets (for IPsec in shared-secret mode, or TCP/MD5), because many clients may need to be configured rapidly without external assistance. Services located on public web servers connecting to large-scale caches or BGP with larger numbers of peers can fall into this category.
スプーフィングを破る1つの方法は接続のセグメントを有効にすることです、輸送レベルかネットワークレベルで。 MD5拡張子があるTCPは輸送レベルでこの認証を提供します、そして、IPsecはネットワークレベル[20][24][27]で認証を提供します。 どちらの場合も、それらの展開オーバーヘッドがひどく高いかもしれない、ウェブサーバーなどの社会奉仕には、例えば、それは多くの同輩の適切な認証局(インターネット・キー・エクスチェンジプロトコル(IKE)を使用するIPsecのための)、または共有秘密キー(共有秘密キーモードによるIPsec、またはTCP/MD5のための)によって構成されるために可能でないかもしれません、多くのクライアントが、対外援助なしで急速に構成される必要があるかもしれないので。 より多くの同輩と共に大規模なキャッシュかBGPに接続しながら公共のウェブサーバーに位置するサービスはこのカテゴリになることができます。
Touch Informational [Page 3] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[3ページ]のRFC4953の防御しているTCPに触れてください。
The remainder of this document outlines the recent attack scenario in detail and describes and compares a variety of solutions, including existing solutions based on TCP/MD5 and IPsec, as well as recently proposed solutions, including modifications to TCP's RST processing [36], modifications to TCP's timestamp processing [34], and modifications to IPsec and TCP/MD5 keying [45]. This document focuses on spoofing of TCP segments, although a discussion of related spoofing of ICMP packets based on spoofed TCP contents is also discussed.
このドキュメントの残りは、さまざまなソリューションを詳細に最近の攻撃シナリオについて概説して、説明して、比較します、TCP/MD5とIPsecに基づく既存のソリューションを含んでいて、最近提案されたソリューションと同様に、TCPのRST処理[36]への変更、TCPのタイムスタンプ処理[34]への変更、および[45]を合わせるIPsecとTCP/MD5への変更を含んでいて。 このドキュメントはTCPセグメントのスプーフィングに集中します、また、偽造しているTCPコンテンツに基づくICMPパケットの関連するスプーフィングの議論について議論しますが。
Note that the description of these attacks is not new; attacks using RSTs on BGP have been known since 1998, and were the reason for the development of TCP/MD5 [20]. The recent attack scenario was first documented by Convery at a NANOG (North American Network Operators' Group) meeting in 2003, but that analysis assumed the entire sequence space (2^32 packets) needed to be covered for an attack to succeed [10]. Watson's more detailed analysis discovered that a single packet anywhere in the current window could succeed at an attack [48]. This document adds the observation that susceptibility to attack is directly proportional to the square of bandwidth, due to the coupling between the linear increase in receive window size and linear increase in rate of a potential attack, as well as comparing the variety of more recent proposals, including modifications to TCP, use of IPsec, and use of TCP/MD5 to resist such attacks.
これらの攻撃の記述が新しくないことに注意してください。 BGPの上の使用RSTsが持っている攻撃は、1998年以来知られていて、TCP/MD5[20]の開発の理由でした。 最近の攻撃シナリオは2003年に最初に、NANOG(北米のNetwork OperatorsのGroup)ミーティングにConveryによって記録されましたが、全体の系列スペースであると思われたその分析(2つの^32パケット)は、攻撃が[10]を引き継ぐようにカバーされる必要がありました。 ワトソンの、より詳細な分析は、現在の窓でどこでも単一のパケットが攻撃[48]で成功できると発見しました。 このドキュメントは攻撃する敏感さがレシーブ・ウィンドウ・サイズの直線的な増加と、より最近の提案のバラエティーを比較することと同様に起こり得るかもしれない攻撃の速度の直線的な増加の間のカップリングによる帯域幅の正方形に正比例しているという観測を加えます、そのような攻撃に抵抗するためにTCPへの変更、IPsecの使用、およびTCP/MD5の使用を含んでいて。
2. Background
2. バックグラウンド
The recent analysis of potential attacks on BGP has again raised the issue of TCP's vulnerability to off-path third-party spoofing attacks [9][10][48]. A variety of such attacks have been known for several years, including sending RSTs, SYNs, and even ACKs in an attempt to affect an existing connection or to load down servers. These attacks often combine external knowledge (e.g., to indicate the IP addresses to attack, the destination port number, and sometimes the Initial Sequence Number (ISN)) with brute-force capabilities enabled by modern computers and network bandwidths (e.g., to scan all source ports or an entire window space). Overall, such attacks are countered by the use of some form of authentication at the network (e.g., IPsec), transport (e.g., SYN cookies, TCP/MD5), or other layers. TCP already includes a weak form of such authentication in its check of segment sequence numbers against the current receiver window. Increases in the bandwidth-delay product for certain long connections have sufficiently weakened this type of weak authentication to make reliance on it inadvisable.
BGPにおける起こり得るかもしれない攻撃の最近の分析は再びオフ経路第三者スプーフィング攻撃[9][10][48]にTCPの脆弱性の問題を提起しました。 さまざまなそのような攻撃は数年間知られています、既存の接続に影響するか、またはサーバをどっさり積む試みでRSTs、SYNs、およびACKsさえ送るのを含んでいて。 これらの攻撃はしばしば外部の知識(例えば攻撃するIPアドレス、目的地ポートナンバー、および時々Initial Sequence Number(ISN)を示す)を現代のコンピュータとネットワーク回線容量(例えばすべてのソースポートか全体の窓のスペースをスキャンする)によって可能にされるブルートフォース能力に結合します。 全体的に見て、何らかの形式の認証の使用でそのような攻撃はネットワーク(例えば、IPsec)、輸送(例えば、SYNクッキー、TCP/MD5)、または他の層で対抗されます。 TCPは既に現在の受信機の窓に対してセグメント一連番号のチェックにおける、そのような認証の弱形を含めます。 確信している長い接続のための帯域幅遅れ製品の増加はこのタイプの弱い認証をそれへの信用を勧められなくするほど弱めました。
Touch Informational [Page 4] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[4ページ]のRFC4953の防御しているTCPに触れてください。
2.1. Review of TCP Windows
2.1. TCP Windowsのレビュー
Before proceeding, it is useful to review the terminology and components of TCP's windowing algorithm. TCP connections have three kinds of windows [1][35]:
進行の前に、TCPのウインドーアルゴリズムの用語と成分を見直すのは役に立ちます。 TCP接続には、3種類の窓[1][35]があります:
o Send window (SND.WND): the latest send window size.
o 窓(SND.WND)を送ってください: 最新のものはウィンドウサイズを送ります。
o Receive window (RCV.WND): the latest advertised receive window
size.
o 窓(RCV.WND)を受けてください: 最新の広告を出しているレシーブ・ウィンドウ・サイズ。
o Congestion window (CWND): the window determined by congestion
feedback that limits how much of RCV.WND can be in-flight in a
round-trip time.
o 混雑ウィンドウ(CWND): 窓は、RCV.WNDのいくらが往復の時間で機内である場合があるかをそれが制限する混雑フィードバックで決定しました。
For TCP connections in most modern implementations, SND.WND and RCV.WND are the size of the corresponding send and receive socket buffers, and are configurable using socket buffer resizing commands.
ほとんどの現代の実装におけるTCP接続に、SND.WNDとRCV.WNDは対応のサイズがソケットバッファを送って、受け取るということであり、コマンドをリサイズするソケットバッファを使用するのにおいて構成可能です。
CWND determines how much data can be in transit in a round-trip time, SND.WND determines how much data the sender is willing to store on its side for possible retransmission due to loss, and RCV.WND determines the ability of the receiver to accommodate that loss and reorder received packets. CWND never grows beyond RCV.WND.
CWNDは、どのくらいのデータがトランジット往復の時間で中であることができるかを決定します、そして、SND.WNDは、損失のため可能な「再-トランスミッション」のために側にどのくらいのデータを保存するかを構わない送付者が、思っている決定します、そして、RCV.WNDは受信機がその損失と追加注文を収容する能力がパケットを受けたことを決定します。 CWNDはRCV.WNDを超えて決して成長しません。
High bandwidth-delay product networks need CWND to be sufficiently large to accommodate as much data as can be in transit in a round trip time; otherwise, their performance will suffer. As a result, it is recommended that users and various automatic programs increase RCV.WND to at least the size of bandwidth*delay (the bandwidth-delay product) [23][38].
高帯域遅れ製品ネットワークは、CWNDが周遊旅行時間、トランジットにはあることができるのと同じくらい多くのデータに対応できるくらい大きい必要があります。 さもなければ、彼らの性能に苦しむでしょう。 その結果、ユーザと様々な自動プログラムが帯域幅*遅れ(帯域幅遅れ製品)[23][38]のサイズにRCV.WNDを増強するのは、お勧めです。
As the bandwidth-delay product of the network increases, however, such increases in the advertised receive window can cause increased susceptibility to spoofing attacks, as the remainder of this document shows. This assumes, however, that the receive window size (e.g., via increased receive socket buffer configuration) is increased with the increased bandwidth-delay product; if not, then connection performance will degrade, but susceptibility to spoofing attacks will increase only linearly (with the rate at which the attacker can send spoofed packets), not as the square of the bandwidth. Note that either increase depends on the receive window itself, and is independent of the congestion state or amount of data transmitted.
しかしながら、ネットワークの帯域幅遅れ製品がそのような増加を増強するので窓が広告を出すところで受信されているとき、スプーフィング攻撃に感受性増大を引き起こす場合があります、このドキュメントの残りが目立っているように。 しかしながら、これは、レシーブ・ウィンドウ・サイズ(例えば、増強にされるを通して、ソケットバッファ構成を受ける)が増強された帯域幅遅れ製品で増強されると仮定します。 そうでなければ、次に、接続性能は下がるでしょうが、スプーフィング攻撃への敏感さは直線的(攻撃者が偽造しているパケットを送ることができるレートで)だけに大きくなるでしょう、帯域幅のいずれの正方形としても、そうしません。 増加がよることに注意そんなにのどちらかになってください、窓自体を受けてください、そして、状態かデータ量が伝えた混雑の独立者は受けます。
Touch Informational [Page 5] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[5ページ]のRFC4953の防御しているTCPに触れてください。
2.2. Recent BGP Attacks Using TCP RSTs
2.2. TCP RSTsを使用する最近のBGP攻撃
BGP represents a particular vulnerability to spoofing attacks because it uses TCP connectivity to infer routability, so losing a TCP connection with a BGP peer can result in the flushing of routes to that peer [37].
routabilityを推論するのにTCPの接続性を使用するので、特定の脆弱性はBGPによってスプーフィング攻撃に表されて、したがって、BGP同輩とのTCP接続を失うと、その同輩[37]へのルートを洗い流すことはもたらされることができます。
Until six years ago, such connections were assumed difficult to attack because they were described by a few comparatively obscure parameters [20]. Most TCP connections are protected by multiple levels of obfuscation except at the endpoints of the connection:
6年前まで、そのような接続は彼らがいくつかの比較的不鮮明なパラメタ[20]によって説明されたので攻撃するのが難しいと思われました。 接続の終点を除いて、ほとんどのTCP接続が複数のレベルの困惑によって保護されます:
o Both endpoint addresses are usually not well-known; although
server addresses are advertised, clients are somewhat anonymous.
o 通常、両方の終点アドレスはよく知られません。 サーバアドレスは広告に掲載されていますが、クライアントはいくらか匿名です。
o Both port numbers are usually not well-known; the server's is
usually advertised (representing the service), but the client's is
typically sufficiently unpredictable to an off-path third-party.
o 通常、両方のポートナンバーはよく知られません。 通常サーバの広告を出しましたが(サービスを表して)、オフ経路第三者にとって、通常、クライアントのものは十分予測できません。
o Valid sequence number space is not well-known.
o 有効な一連番号スペースは周知のことではありません。
o Connections are relatively short-lived and valid sequence space
changes, so any attempt to guess (e.g., by external knowledge or
brute force) the above information is unlikely to be useful.
o コネクションズが比較的短命で有効な系列スペース変化であるので、上記の情報を推測する(例えば、外部の知識か馬鹿力で)どんな試みも役に立ちそうにはありません。
BGP represents an exception to the above criteria (though not the only case). Both endpoints can be well-known, or guessed using hints from part of an AS path. The destination port is typically fixed to indicate the BGP service. The source port used by a BGP router is sometimes fixed and advertised to enable firewall configuration; even when not fixed, there are only approximately 65,000 valid source ports, which thus may be exhaustively attacked. Connections are long- lived, and, as noted before, some BGP implementations interpret successive TCP connection failures as routing failures, discarding the corresponding routing information. In addition, the valid sequence number space once thought to provide some protection has been significantly weakened by increasing advertised receive window sizes.
BGPは上の評価基準(もっとも、唯一のケースでない)への例外を表します。 両方の終点がよく知られる場合がありますか、または推測された使用はAS経路の一部から暗示します。 仕向港は、BGPサービスを示すために通常修理されています。 ファイアウォール構成を可能にするためにBGPルータによって使用されるソースポートの、時々修理して、広告を出します。 修理されていない場合、およそ6万5000の有効なソースポートしかありません。(その結果、ソースポートを徹底的に攻撃してもよいです)。 そして、コネクションズは長い間、以前注意されるように送られます、BGP実装が失敗を発送しながら連続したTCP接続の故障を解釈するいくつか、対応するルーティング情報を捨てて。 さらに、何らかの保護を提供するといったん思われると、有効な一連番号スペースは、広告を出しているレシーブ・ウィンドウ・サイズを増強することによって、かなり弱められました。
2.3. TCP RST Vulnerability
2.3. TCP RST脆弱性
TCP has a known vulnerability to third-party spoofed segments. SYN flooding consumes server resources in half-open connections, affecting the server's ability to open new connections [4][11]. ACK spoofing can cause connections to transmit too much data too quickly, creating network congestion and segment loss, causing connections to slow to a crawl. In the most recent attacks on BGP, RSTs cause connections to be dropped. As noted earlier, some BGP
TCPはセグメントであると偽造された第三者に知られている脆弱性を持っています。 新しい接続[4][11]を開くサーバの能力に影響して、SYN氾濫は半開きな接続におけるサーバリソースを消費します。 接続はACKスプーフィングであまりにすばやくあまりに多くのデータを送ることができます、ネットワークの混雑とセグメントの損失を引き起こして、接続が徐行に遅くなることを引き起こして。 BGPに対する最新の攻撃では、RSTsは接続を下げさせます。 より早いいくらかのBGPに注意します。
Touch Informational [Page 6] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[6ページ]のRFC4953の防御しているTCPに触れてください。
implementations interpret TCP connection termination, or a series of such failures, as a network failure [37]. This causes routers to drop the BGP routing information already exchanged, in addition to inhibiting their ongoing exchanges, thus amplifying the impact of the attack. The result can affect routing paths throughout the Internet.
実装はネットワーク失敗[37]としてTCP接続終了、またはそのような一連の失敗を解釈します。 これで、ルータは既に交換されたBGPルーティング情報を下げます、それらの進行中の交換を抑制することに加えて、その結果、攻撃の影響を増幅します。 結果はインターネット中でルーティング経路に影響できます。
The dangerous effects of RSTs on TCP have been known for many years, even when used by the legitimate endpoints of a connection. TCP RSTs cause the receiver to drop all connection state; because the source is not required to maintain a TIME_WAIT state, such a RST can cause premature reuse of address/port pairs, potentially allowing segments from a previous connection to contaminate the data of a new connection, known as TIME_WAIT assassination [8]. In this case, assassination occurs inadvertently as the result of duplicate segments from a legitimate source, and can be avoided by blocking RST processing while in TIME_WAIT. However, assassination can be useful to deliberately reduce the state held at servers; this requires that the source of the RSTs go into TIME_WAIT state to avoid such hazards, and that RSTs are not blocked in the TIME_WAIT state [12].
TCPへのRSTsの危険な効果は何年間も知られています、接続の正統の終点によって使用されると。 TCP RSTsは受信機にすべての接続状態を下げさせます。 ソースがタイム誌_WAIT状態を維持する必要はないので、そのようなRSTはアドレス/ポート組の時期尚早な再利用を引き起こす場合があります、前の接続からのセグメントがタイム誌_WAIT暗殺[8]として知られている新しい接続に関するデータを汚染するのを潜在的に許容して。 この場合、暗殺は、写しセグメントの結果として正統のソースからうっかり起こって、タイム誌_WAITにある間、RST処理を妨げることによって、避けることができます。 しかしながら、暗殺は故意にサーバで保持された状態を減少させるために役に立つ場合があります。 これは、RSTsの源がそのような危険を避けるためにタイム誌_WAIT状態に入って、RSTsがタイム誌_WAIT状態[12]で妨げられないのを必要とします。
Firewalls and load balancers, so-called 'middleboxes', sometimes emit RSTs on behalf of transited connections to optimize server performance, as noted in RFC 3360 [14]. This is effectively an on- path RST attack in which the RSTs are sent for benign or beneficial intent. There are numerous hazards with such use of RSTs, outlined in that RFC.
ファイアウォールと負荷分散装置(いわゆる'middleboxes')はサーバ性能を最適化するために時々通過している接続を代表してRSTsを放ちます、RFC3360[14]に述べられるように。 事実上、これがそうである、オンである、RSTsが優しいか有益な意図のために送られる経路RSTは攻撃します。 そのRFCに概説されたRSTsのそのような使用がある多数の危険があります。
2.4. What Changed - the Ever-Opening Advertised Receive Window
2.4. 変化したもの--広告に掲載された絶えず始まりは窓を受けます。
RSTs represent a hazard to TCP, especially when completely unvalidated. Fortunately, there are a number of obfuscation mechanisms that make it difficult for off-path third parties to forge (spoof) valid RSTs, as noted earlier. We have already shown it is easy to learn both endpoint addresses and ports for some protocols, notably BGP. The final obfuscation is the segment sequence number.
特に完全に非有効にされると、RSTsは危険をTCPに表します。 幸い、オフ経路第三者が有効なRSTsを鍛造するのを(だまします)難しくする多くの困惑メカニズムがあります、より早く注意されるように。 私たちは両方を学ぶのが簡単であることが既に示された終点アドレスといくつかのプロトコル、著しくBGPのためのポートを持っています。 最終的な困惑はセグメント一連番号です。
TCP segments include a sequence number, which enables out-of-order receiver processing as well as duplicate detection. The sequence number space is also used to manage congestion, and indicates the index of the next byte to be transmitted or received. For RSTs, this is relevant because legitimate RSTs use the next sequence number in the transmitter window, and the receiver checks that incoming RSTs have a sequence number in the expected receive window. Such processing is intended to eliminate duplicate segments (somewhat moot for RSTs, though), and to drop RSTs that were part of previous connections.
TCPセグメントは、一連番号を含んで、検出をコピーします。(一連番号は不適切な受信機処理を可能にします)。 一連番号スペースは、また、混雑を管理するのに使用されて、伝えるか、または受け取るために次のバイトのインデックスを示します。 RSTsがないかどうか、正統のRSTsが送信機の窓で次の一連番号を使用するので、これは関連していて、受信機は、入って来るRSTsが予想の一連番号に窓を受けさせるのをチェックします。 そのような処理は、写しセグメント(もっとも、RSTsにおけるいくらか論争中の)を排除して、前の接続の一部であったRSTsを下げることを意図します。
Touch Informational [Page 7] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[7ページ]のRFC4953の防御しているTCPに触れてください。
TCP uses two window mechanisms, a primary mechanism for reordering and congestion control (which uses a space of 32 bits), and a secondary mechanism that scales this window [23][35]. The valid advertised receive window is a fraction, not to exceed approximately half, of this space, or ~2 billion (2 * 10^9, i.e., 2E9 or 2 U.S. billion). Under typical configurations, the majority of TCP connections open to a very small fraction of this space, e.g., 10,000-60,000(approximately 5-100 segments). This is because the advertised receive window typically matches the receive socket buffer size. It is recommended that this buffer be tuned to match the needs of the connection, either manually or by automatic external means [38].
TCPは2つのウィンドウメカニズム、再命令と輻輳制御(32ビットのスペースを使用する)のための一次機構、およびこの窓[23][35]をスケーリングするセカンダリメカニズムを使用します。 広告に掲載された有効は受信されます。窓は、およそ半分を超えないためにはこのスペース、または~2 billion(すなわち、2*10^9、2E9か2米国10億)の部分です。 典型的な構成の下では、TCP接続の大部分がこのスペース10,000-60,000 例えば、(およそ5-100のセグメント)の非常にわずかな部分まで開きます。 これによる広告を出すことが受信されるので窓が通常合っているということである、ソケットバッファサイズを受けてください。 このバッファが手動か自動外部の手段[38]で接続の必要性を合わせるために調整されるのは、お勧めです。
On a low-loss path, the advertised receive window should be configured to match the path bandwidth-delay product, including buffering delays (assume 1 packet/hop) [38]. Many paths in the Internet have end-to-end bandwidths of under 1 Mbps, latencies under 100 ms, and are under 15 hops, resulting in fairly small advertised receive windows as above (under 35,000 bytes). Under these conditions, and further assuming that the initial sequence number is suitably (pseudo-randomly) chosen, a valid guessed sequence number would have odds of 1 in 57,000 of falling within the advertised receive window. Put differently, a blind (i.e., off-path) attacker would need to send 57,000 RSTs with suitably spaced sequence number guesses within one round-trip time to successfully reset a connection. At 1 Mbps, 57,000 (40 byte) RSTs would take only 20 seconds to transmit, but this presumes that both IP addresses and both ports are known. Absent knowledge of the source port, an off- path spoofer would need to try at least the entire range of 49152- 65535, or 16,384 different ports, resulting in an attack that would take over 91 hours. Because most TCP connections are comparatively short-lived, even this moderate variation in the source port is sufficient for such environments, although further port randomization may be recommended [29].
低い損失経路では、経路帯域幅遅れ製品を合わせるために構成されるべきであり、遅れ(1つのパケット/ホップを仮定する)[38]をバッファリングするのを含んでいて、広告を出すのは窓を受けます。 インターネットの多くの経路が終わりから終わりへの1Mbpsの帯域幅、100msの下の潜在を持って、15未満のホップである、かなり小さいところの広告に掲載された結果になるのは(3万5000バイト未満)のように窓を受けます。 初期シーケンス番号が適当にそうであるとこれらの条件で、さらに仮定する、(疑似である、無作為である、)、選ばれて、広告を出すことの中で低下する1つのコネ57,000の可能性は有効な推測された一連番号で窓を受けるでしょう。 異なって置かれて、盲目(すなわち、オフ経路)の攻撃者は、首尾よく接続をリセットする往復の1回の以内に適当に区切られた一連番号推測と共に5万7000RSTsを送る必要があるでしょう。 1Mbpsでは、5万7000(40バイト)RSTsが伝わるようにほんの20秒取るでしょうが、これは、IPアドレスとポートの両方の両方が知られていると推定します。 ソースポートに関する欠けている知識、オフ経路spooferは、少なくとも49152- 65535の全体の範囲、または1万6384の異なったポートを試す必要があるでしょう、91時間以上かかる攻撃をもたらして。 ほとんどのTCP接続が比較的短命であるので、ソースポートのこの適度の変化さえそのような環境で十分です、さらなるポート無作為化はお勧めの[29]であるかもしれませんが。
Recent use of high bandwidth paths of 10 Gbps and higher results in bandwidth-delay products over 125 MB -- approximately 1/10 of TCP's overall maximum advertised receive window size (i.e., assuming the receive socket buffers are increased as much as possible) excluding scale, assuming the receiver allocates sufficient buffering (as discussed in Section 2). Even under networks that are ten times slower (1 Gbps), the active advertised receive window covers 1/100th of the overall window size. At these speeds, it takes only 10-100 packets, or less than 32 microseconds, to correctly guess a valid sequence number and kill a connection. A table of corresponding exposure to various amounts of RSTs is shown below, for various line rates, assuming the more conventional 100-ms latencies (though even 100 ms is large for BGP cases):
10Gbpsで、より高いことの高帯域経路の最近の使用は125MB以上の帯域幅遅れ製品をもたらします--TCPのおよそ1/10の総合的な最大がレシーブ・ウィンドウ・サイズの広告を出した、(すなわち、仮定、受信、ソケットバッファができるだけ増強される、)、スケールを除いて、受信機を仮定すると、十分なバッファリングは割り当てられます(セクション2で議論するように)。 10倍より遅いネットワーク(1Gbps)の下でさえ、広告に掲載されたアクティブは総合的なウィンドウサイズのウィンドウカバー1/100番目を受けます。 これらの速度では、正しく有効な一連番号を推測して、接続を殺すにはほんの10-100のパケット、または32マイクロセカンド未満かかります。 様々なライン料率のために、より従来の100-ms潜在(BGPケースに、100msさえ大きいのですが)を仮定する下でRSTsの様々な量への対応する暴露のテーブルは見せられます:
Touch Informational [Page 8] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[8ページ]のRFC4953の防御しているTCPに触れてください。
BW BW*delay RSTs needed Time needed
------------------------------------------------------------
10 Gbps 125 MB 35 1 us (microsecond)
1 Gbps 12.5 MB 344 110 us
100 Mbps 1.25 MB 3,436 10 ms (millisecond)
10 Mbps 0.125 MB 34,360 1 second
1 Mbps 0.0125 MB 343,598 2 minutes
100 Kbps 0.00125 MB 3,435,974 3 hours
必要なTimeが必要としたBW BW*遅れRSTs------------------------------------------------------------ 10Gbps125MB35 1、私たち、私たち1.25MB3,436 10のms(ミリセカンド)10Mbps0.125MB34,360 1 2番目の1Mbps0.0125MB343,598 2分100Kbps0.00125MB3,435,974 3時間の(マイクロセカンド)1Gbps12.5のMB344 110 100Mbps
Figure 1: Time needed to kill a connection
図1: 時間は、接続を殺す必要がありました。
This table demonstrates that the effect of bandwidth on the vulnerability is squared; for every increase in bandwidth, there is a linear decrease in the number of sequence number guesses needed, as well as a linear decrease in the time needed to send a set of guesses. Notably, as inter-router link bandwidths approach 1 Mbps, an 'exhaustive' attack becomes practical. Checking that the RST sequence number is somewhere in the advertised receive window, out of the overall maximum receive window (2^32), is an insufficient obfuscation.
このテーブルは、脆弱性への帯域幅の効果が二乗されるのを示します。 帯域幅のあらゆる増加のために、推測が必要であり、時間の直線的な減少が1セットの推測を送るために必要とした一連番号の数の直線的な減少があります。 相互ルータリンク帯域幅が1Mbpsにアプローチするのに応じて、著しく、'徹底的な'攻撃は実用的になります。 RST一連番号が窓(2^32)が広告を出すところでは、総合的な最大からの窓が受信されているところで受信されるということであることをチェックするのは、不十分な困惑です。
Note that this table makes a number of assumptions:
このテーブルが多くの仮定をすることに注意してください:
1. The overall bandwidth-delay product is relatively fixed.
1. 総合的な帯域幅遅れ製品は比較的固定されています。
2. Traffic losses are negligible (insufficient to affect the
congestion window over the duration of most of the connection).
2. トラフィックの損失は取るにたらないです(接続の大部分の持続時間の上で混雑ウィンドウに影響するように不十分な)。
3. The advertised receive window is a large fraction of the overall
maximum receive window size, e.g., because the receive socket
buffers are set to match a large bandwidth-delay product.
3. 広告を出すことは受信されます。合わせてくださいバッファが設定されるソケットを受けてください。窓が総合的な最大のレシーブ・ウィンドウ・サイズの大きい部分である、例えば、大きい帯域幅遅れ製品。
4. The attack bandwidth is similar to the end-to-end path bandwidth.
4. 攻撃帯域幅は終わりから終わりへの経路帯域幅と同様です。
Of these assumptions, the last two are more notable. The issue of receive socket buffers was discussed in Section 2. Figure 1 summarized the time to a successful attack based on large advertised receive windows, but many current commercial routers have limits of 128 KB for large devices, 32 KB for medium, and as little as 4 KB for modest ones. Figure 2 shows the time and bandwidths needed to accomplish an attack on BGP sessions in the time shown for 100-ms latencies; for even short-range network latencies (10 ms), these sessions can be still be attacked over short timescales (minutes to hours).
これらの仮定では、最後の2は、より注目に値します。 ソケットバッファを受け取ってください。問題、セクション2では、議論しました。 大きいことに基づいて広告に掲載されたうまくいっている攻撃に窓が受信されていますが、多くの現在の商業ルータに大きいデバイスのための128KB、媒体のための32KB、および穏やかなもののための最小4KBの限界があるときまとめられた図1。 図2は、時間と帯域幅が、100-ms潜在のために示された時間BGPセッションに対する攻撃を実行する必要だったのを示します。 短距離ネットワーク潜在(10ms)のためにさえ、これらのセッションはそうであることができます、それでも、短いスケール(数分から何時間も)の上で攻撃されてください。
Touch Informational [Page 9] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[9ページ]のRFC4953の防御しているTCPに触れてください。
Receive
BW Buffer Size RSTs needed Time needed
------------------------------------------------------------
10 Mbps 0.128 MB 33,555 1 second
3 Mbps 0.032 MB 134,218 40 seconds
300 Kbps 0.004 MB 1,073,742 1 hour
必要なTimeが必要としたBW Buffer Size RSTsを受けてください。------------------------------------------------------------ 10 300Kbps0.004MB1,073,742 1時間のMbpsの0.032MB134,218 40の3秒のMbps0.128MB33,555 1秒
Figure 2: Time needed to kill a connection with limited buffers
図2: 時間は、限られたバッファとの接続を殺す必要がありました。
The issue of the attack bandwidth is considered reasonable as follows:
攻撃帯域幅の問題は妥当であると以下の通り考えられます:
1. RSTs are substantially easier to send than data; they can be
precomputed and they are smaller than data packets (40 bytes).
1. RSTsはデータより実質的に送りやすいです。 それらを前計算できて、それらはデータ・パケット(40バイト)より小さいです。
2. Although susceptible connections use somewhat less ubiquitous
high-bandwidth paths, the attack may be distributed, at which
point only the ingress link of the attack is the primary
limitation.
2. 影響されやすい接続はいくらか遍在していない高帯域経路を使用しますが、攻撃は広げられるかもしれません。そのポイントだけでは、攻撃のイングレスリンクはプライマリ制限です。
3. For the purposes of the above table, we assume that the ingress at
the attack has the same bandwidth as the path, as an
approximation.
3. 上のテーブルの目的のために、私たちは、攻撃におけるイングレスには経路と同じ帯域幅があると思います、近似として。
The previous sections discussed the nature of the recent attacks on BGP due to the vulnerability of TCP to RST spoofing attacks, due largely to recent increases in the fraction of the TCP advertised receive window space in use for a single, long-lived connection.
前項はTCPの脆弱性のため攻撃を偽造しながら、BGPで最近の攻撃の本質についてRSTと議論して、主に広告に掲載されたTCPの部分の最近の増加への支払われるべきものは単一の、そして、長命の接続に、使用中の窓のスペースを受けます。
3. Proposed Solutions and Mitigations
3. 提案されたソリューションと緩和
TCP currently authenticates received RSTs using the address and port pair numbers, and checks that the sequence number is inside the valid receiver window. The previous section demonstrated how TCP has become more vulnerable to RST spoofing attacks due to the increases in the receive window size. There are a number of current and proposed solutions to this vulnerability, all attempting to provide evidence that a received RST is legitimate.
TCPは、現在アドレスとポート組番号を使用することで容認されたRSTsを認証して、有効な受信機の窓の中に一連番号があるのをチェックします。 前項はTCPがどうレシーブ・ウィンドウ・サイズの増加によるRSTスプーフィング攻撃により被害を受け易くなったかを示しました。 この脆弱性への多くの現在の、そして、提案されたソリューションがあります、容認されたRSTが正統であるという証拠を提供するのをすべて試みて。
3.1. Transport Layer Solutions
3.1. トランスポート層溶液
The transport layer represents the last place that segments can be authenticated before they affect connection management. TCP has a variety of current and proposed mechanisms to increase the authentication of segments, protecting against both off-path and on- path third-party spoofing attacks. Other transport protocols, such as SCTP and DCCP, also have limited antispoofing mechanisms.
接続管理に影響する前にトランスポート層は認証されていた状態でセグメントがあることができる最後の場所を表します。 TCPには、セグメントの認証を増強するさまざまな現在の、そして、提案されたメカニズムがあって、ともに経路でオンに対する保護は経路第三者スプーフィング攻撃です。 また、SCTPやDCCPなどの他のトランスポート・プロトコルは反偽造するメカニズムを制限しました。
Touch Informational [Page 10] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[10ページ]のRFC4953の防御しているTCPに触れてください。
3.1.1. TCP MD5 Authentication
3.1.1. TCP MD5認証
An extension to TCP supporting MD5 authentication was developed in 1998 specifically to authenticate BGP connections (although it can be used for any TCP connection) [20]. The extension relies on a pre- shared secret key to authenticate the entire TCP segment, including the data, TCP header, and TCP pseudo-header (certain fields of the IP header). All segments are protected, including RSTs, to be accepted only when their signature matches. This option, although widely deployed in Internet routers, is considered undeployable for widespread use because the need for pre-shared keys [3][30]. It further is considered computationally expensive for either hosts or routers due to the overhead of MD5 [43][44].
MD5が認証であるとサポートするTCPへの拡大は、1998年に特にBGP接続(どんなTCP接続にもそれを使用できますが)[20]を認証するために発生しました。 拡張子は全体のTCPセグメントを認証するために主要なプレ共有秘密キーを当てにします、データ、TCPヘッダー、およびTCP疑似ヘッダー(IPヘッダーのある一定の分野)を含んでいて。 彼らの署名マッチであるときにだけ、受け入れるためにRSTsを含んでいて、すべてのセグメントが保護されます。 インターネットルータで広く配布されますが、このオプションが普及使用のための非配布可能であると考えられる、あらかじめ共有されたキー[3][30]の必要性。 それはMD5[43][44]のオーバーヘッドのためにホストかルータのどちらかには計算上高価であるとさらに考えられます。
There are also concerns about the use of MD5 due to recent collision- based attacks [22]. Similar concerns exist for SHA-1, and the IETF is currently evaluating how these attacks impact the recommendation for using these hashes, both in TCP/MD5 and in the IPsec suite. For the purposes of this discussion, the particular algorithm used in either protocol suite is not the focus, and there is ongoing work to allow TCP/MD5 to evolve to a more general TCP security option [6][47].
MD5の使用に関する心配も最近の衝突ベースの攻撃[22]のためにあります。 同様の関心はSHA-1のために存在しています、そして、IETFは現在、これらのハッシュ(TCP/MD5とIPsecスイートの両方)を使用するためにこれらの攻撃がどう推薦に影響を与えるかを評価しています。 この議論の目的のために、プロトコル群で使用される特定のアルゴリズムは焦点ではありません、そして、TCP/MD5が、より一般的なTCPセキュリティオプション[6][47]に発展するのを許す進行中の仕事があります。
3.1.2. TCP RST Window Attenuation
3.1.2. TCP RST窓の減衰
A recent proposal extends TCP to further constrain received RST to match the expected next sequence number [36]. This restores TCP's resistance to spurious RSTs, effectively limiting the receive window for RSTs to a single number. As a result, an attacker would need to send 2^32 different packets to brute-force guess the sequence number (worst case, the average would be half that); this makes TCP's vulnerability to attack independent of the size of the receive window (RCV.WND). The extension further modifies the RST receiver to react to incorrectly-numbered RSTs, by sending a zero-length ACK. If the RST source is legitimate, upon receipt of an ACK, the closed source would presumably emit a RST with the sequence number matching the ACK, correctly resetting the intended recipient. This modification changes TCP's control processing, adding to its complexity and thus potentially affecting its correctness (in contrast to adding MD5 signatures, which is orthogonal to TCP control processing altogether). For example, there may be complications between RSTs of different connections between the same pair of endpoints because RSTs flush the TIME-WAIT (as mentioned earlier). Further, this proposal modifies TCP so that, under some circumstances, a RST causes a reply (an ACK), in violation of generally accepted practice, if not gentle recommendation -- although this can be omitted, allowing timeouts to suffice. The advantage to this proposal is that it can be deployed incrementally and has benefit to the endpoint on which it is
最近の提案は、容認されたRSTが次の一連番号[36]に予想に合っているのをさらに抑制するためにTCPを広げています。 これが偽物のRSTs、事実上制限へのTCPの抵抗を復元する、RSTsのために1つの数に窓を受けてください。 その結果、攻撃者は、ブルートフォースへの32の異なったパケットが推測する2^に一連番号を送る必要があるでしょう(最悪の場合、平均はそれの半分でしょう)。 これがサイズの如何にかかわらず攻撃されるTCPの脆弱性になる、窓(RCV.WND)を受けてください。 拡大は、無の長さのACKを送ることによって不当に番号付のRSTsに反応するようにさらにRST受信機を変更します。 RSTソースがACKを受け取り次第正統であるなら、おそらく、閉じているソースは一連番号がACKに合っているRSTを放つでしょう、正しく意図している受取人をリセットして。 この変更はTCPのコントロール処理を変えます、複雑さに加えて、その結果、潜在的に正当性に影響します(MD5署名を加えることと対照して)。それは、全体でTCPコントロール処理と直交しています。 例えば、RSTsがタイム誌-WAIT(先に述べたように)を洗い流すので、同じ組の終点の間の異なった接続のRSTsの間には、複雑さがあるかもしれません。 さらに、この提案がTCPを変更するので、RSTはいくつかの状況で回答(ACK)を引き起こします、タイムアウトが十分であることを許容して、これを省略できるように一般に慣例、または優しい推薦を違反して。 この提案の利点は増加して配布することができて、それがそうである利益を終点に持っているということです。
Touch Informational [Page 11] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[11ページ]のRFC4953の防御しているTCPに触れてください。
deployed. The other advantage to this proposal is that the window attenuation described here makes the vulnerability to spoofed RST packets independent of the size of the receive window.
配布される。 この提案のもう片方の利点がここで説明された窓の減衰がサイズの如何にかかわらず脆弱性を偽造しているRSTパケットにするということである、窓を受けてください。
A variant of this proposal uses a different value to attenuate the window of viable RSTs. It requires RSTs to carry the initial sequence number rather than the next expected sequence number, i.e., the value negotiated on connection establishment [42][49]. This proposal has the advantage of using an explicitly negotiated value, but at the cost of changing the behavior of an unmodified endpoint to a currently valid RST. It would thus be more difficult, without additional mechanism, to deploy incrementally.
この提案の異形は、実行可能なRSTsの窓を減衰させるのに異価を使用します。 それは、RSTsが次の予想された一連番号(すなわち、コネクション確立[42][49]に関して交渉された値)よりむしろ初期シーケンス番号を運ぶのを必要とします。 明らかに交渉された値を使用する利点を持っていますが、この提案は変更されていない終点の振舞いを現在有効なRSTに変える費用で難しいです。その結果、それは、増加して展開するために追加メカニズムなしで、より難しいでしょう。
Another variant of this proposal involves increasing TCP's window space, rather than decreasing the valid range for RSTs, i.e., increasing the sequence space from 32 bits to 64 bits. This has the equivalent effect -- the ratio of the valid sequence numbers for any segment to the overall sequence number space is significantly reduced. The use of the larger space, as with current schemes to establish weak authentication using initial sequence numbers (ISNs), is contingent on using suitably random values for the ISN. Such randomness adds additional complexity to TCP both in specification and implementation, and provides only very weak authentication. Such a modification is not obviously backward compatible, and would be thus difficult to deploy.
この提案の別の異形は、すなわち、RSTsのために系列スペースを32ビットから64ビットまで増強しながら有効枠を減少させるよりむしろTCPの窓のスペースを増強することを伴います。 これには、同等な効果があります--どんなセグメントのための有効な一連番号対総合的な一連番号スペースの比率もかなり低下します。 電流で初期シーケンス番号(ISNs)を使用することで弱い認証を確立するのを計画して、ISNに適当に無作為の値を使用すること次第であるのによる、より大きいスペースの使用。 そのような偶発性は、仕様と実装で追加複雑さをTCPに加えて、非常に弱い認証だけを供給します。 そのような変更が明らかに後方でない、コンパチブル、その結果、配布するのは難しいでしょう。
A converse variant of increasing TCP's window space is to decrease the receive window (RCV.WND) explicitly, which would further reduce the effectiveness of spoofed RSTs with random sequence numbers. This alternative may reduce the throughput of the connection, if the advertised receive window is smaller than the bandwidth-delay product of the connection.
増加するTCPの窓のスペースの逆異形が減少することになっている、明らかに窓(RCV.WND)を受けてください、ランダム・シーケンス番号によると、偽造しているRSTsの有効性をさらに減少させるどれ。 この代替手段が接続に関するスループットを減らすかもしれなくて、広告を出すことが受信されるなら、窓は接続の帯域幅遅れ成果より小さいです。
3.1.3. TCP Timestamp Authentication
3.1.3. TCPタイムスタンプ認証
Another way to authenticate TCP segments is via its timestamp option, using the value as a sort of authentication [34]. This requires that the receiver TCP discard segments whose timestamp is outside the accepted window, which is derived from the timestamps of other packets from the same connection. This technique uses an existing TCP option, but also requires modified TCP control processing (with the same caveats) and may be difficult to deploy incrementally without further modifications. Additionally, the timestamp value may be easier to guess because it can be derived predictably, either assuming it represents actual time at the host, or by probing the host using unrelated benign traffic.
一種の認証[34]として値を使用して、TCPセグメントを認証する別の方法はタイムスタンプゆだねます。 これは、受信機TCPが他のパケットに関するタイムスタンプから同じ接続から得られる受け入れられた窓の外にタイムスタンプがあるセグメントを捨てるのを必要とします。 このテクニックは既存のTCPオプションを使用します、また、変更されたTCPコントロール処理(同じ警告がある)を必要として、さらなる変更なしで増加して配布するのが難しいかもしれないのを除いて。 さらに、タイムスタンプ値は予想どおりにそれを引き出すことができるので推測するのは、より簡単であるかもしれません、ホストにおいて、または、関係ない優しいトラフィックを使用することでホストを調べることで実際の時間を表すと仮定して。
Touch Informational [Page 12] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[12ページ]のRFC4953の防御しているTCPに触れてください。
3.1.4. Other TCP Cookies
3.1.4. 他のTCPクッキー
All of the above techniques are variants of cookies, otherwise meaningless data whose value is used to validate the packet. In the case of MD5 checksums, the cookie is computed based on a shared secret. Note that even a signature can be guessed, and presents a 1 in 2^(signature length) probability of attack. The primary difference is that MD5 signatures are effectively one-time cookies, not predictable based on on-path snooping, because they are dependent on packet data and thus do not repeat. Window attenuation sequence numbers can be guessed by snooping the sequence number of current packets of an existing connection, and timestamps can be guessed even less directly, either by separate benign connections or by assuming they roughly correlate to local time. These variants of cookies are similar in spirit to TCP SYN cookies, again patching a vulnerability to off-path third-party spoofing attacks based on a (fairly weak, excepting MD5) form of authentication. Another form of cookie is the source port itself, which can be randomized but provides only 16 bits of protection (65,000 combinations), which may be exhaustively attacked. This can be combined with destination port randomization as well, but that would require a separate coordination mechanism (so both parties know which ports to use), which is equivalent to (and as infeasible for large-scale deployments as) exchanging a shared secret [39].
上のテクニックのすべてがクッキー、値がパケットを有効にするのに使用されるそうでなければ、無意味なデータの異形です。 MD5チェックサムの場合では、共有秘密キーに基づいてクッキーは計算されます。 署名さえ攻撃の2^(署名の長さ)確率で推測できて、1を提示することに注意してください。 プライマリ違いはMD5署名が事実上1回のクッキーであるということです、経路での詮索に基づいて予測できません、それらがパケットデータに依存していて、その結果、繰り返しません。 既存の接続の現在のパケットの一連番号について詮索することによって、窓の減衰一連番号を推測できます、そして、より直接でない、別々の優しい接続または彼らが現地時間までおよそ関連すると仮定さえすることによって、タイムスタンプを推測できます。 クッキーのこれらの異形は精神においてTCP SYNクッキーと同様です、再び認証の(MD5を除いてかなり弱い)フォームに基づくオフ経路第三者スプーフィング攻撃に脆弱性にパッチして。 (ソースポートをランダマイズできます)。別の形式のクッキーは、ソースポート自体ですが、16ビットの保護(6万5000の組み合わせ)だけを提供します。(それを徹底的に攻撃してもよいです)。 また、仕向港無作為化にこれを結合できますが、それが別々のコーディネートメカニズムを必要として(したがって、双方は、どのポートを使用したらよいかを知っています)、どれに同等物があるか、(大規模な展開に実行不可能である、)、共有秘密キー[39]を交換します。
3.1.5. Other TCP Considerations
3.1.5. 他のTCP問題
The analysis of the potential for RST spoofing above assumes that the advertised receive window is opened to the maximum extent suggested by the bandwidth-delay product of the end-to-end path, and that the window is opened to an appreciable fraction of the overall sequence number space. As noted earlier, for most common cases, connections are too brief or over bandwidths too low for such a large window to be useful. Expanding TCP's sequence number space is a direct way to further avoid such vulnerability, even for long connections over emerging bandwidths. If either manual tuning or automatic tuning of the advertised receive window (via receive buffer tuning) is not provided, this is not an issue (although connection performance will suffer) [38].
上でだますRSTが、広告を出すのが窓を受けると仮定するので、可能性の分析は終わりから端への経路の帯域幅遅れ製品によって示された最大の範囲まで開かれます、そして、窓は総合的な一連番号スペースのかなりの部分に開けられます。 ほとんどのよくある例で、より早く有名であるように、接続は、簡潔過ぎるか、またはそのような大きい窓が役に立つように思えないほど低い帯域幅にわたって有名です。 拡張TCPの一連番号スペースはさらにそのような脆弱性を避けるダイレクト方法です、帯域幅として現れる上の長い接続のためにさえ。 広告を出すことの手動のチューニングか自動同調のどちらかが受信されるなら、窓(受信バッファチューニングを通した)は提供されないで、またこれは問題(接続性能に苦しむでしょうが)[38]ではありません。
It may be sufficient for the endpoint to limit the advertised receive window by deliberately leaving it small. If the receive socket buffer is limited, e.g., to the ubiquitous default of 64 KB, the advertised receive window will not be as vulnerable even for very long connections over very high bandwidths. The vulnerability will grow linearly with the increased network speed, but not as the square. The consequence is lower sustained throughput, where only one window's worth of data per round-trip time (RTT) is exchanged.
それは限界への広告を出すのが故意に窓を受ける終点にそれを小さい状態でおくのに十分であるかもしれません。 制限されたソケットバッファを受け取ってください、そして、例えば、64の遍在しているデフォルトに、KB、広告を出すことは受信されます。窓はまさしくその高帯域の上の非常に長い接続にさえ被害を受け易くならないでしょう。 脆弱性は、増強されたネットワーク速度で直線的になりますが、正方形としてなるというわけではないでしょう。 結果は低い持続しているスループットです。(そこでは、1つの窓だけの往復の時間(RTT)あたりのデータの価値が交換されます)。
Touch Informational [Page 13] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[13ページ]のRFC4953の防御しているTCPに触れてください。
This will keep the connection open longer; for long-lived connections with continuous sourced data, this may continue to present an attack opportunity, albeit a sparse and slow-moving target. For the most recent case where BGP data is being exchanged between Internet routers, the data is bursty and the aggregate traffic may be small (i.e., unlikely to cover a substantial portion of the sequence space, even if long-lived), so smaller advertised receive windows (via small receiver buffers) may, in some cases, sufficiently address the immediate problem. This assumes that the routing tables can be exchanged quickly enough with bandwidth reduced due to the smaller buffers, or perhaps that the advertised receive window is opened only during a large burst exchange (e.g., via some other signal between the two routers, or a time-based signal, though either would be nonstandard).
これは、より長い間、接続を開くように保つでしょう。 連続した出典を明示されたデータとの長命の関係のために、これは、攻撃の機会を提示し続けるかもしれません、aまばら、そして、遅い移動標的ですが。 集合トラフィックが広告を出した状態でインターネットルータの間でBGPデータを交換していて、小さくて(すなわち、系列スペース長命であってもかなりの部分をカバーしそうにない)、データがburstyであるので、より小さいかもしれない最新のケースのために、窓(小さい受信機バッファを通した)を受けてください。いくつかの場合、手近な問題を十分扱ってもよいです。 これが、十分すばやくより小さいバッファのため減少する帯域幅と経路指定テーブルを交換できると仮定するか、または恐らく、広告を出すのが窓を受けるのは大きい炸裂交換だけの間開かれます(どちらかがそうするでしょうが、2つのルータの間のある他の信号、または例えば、時間ベースの信号で、標準的でなくいてください)。
3.1.6. Other Transport Protocol Solutions
3.1.6. 他のトランスポート・プロトコルソリューション
Segment authentication has been addressed at the transport layer in other protocols. Both SCTP and DCCP include cookies for connection establishment and use them to authenticate a variety of other control messages [28][41]. The inclusion of such mechanism at the transport protocol, although emerging as standard practice, complicates the design and implementation of new protocols [32]. As new attacks are discovered (SYN floods, RSTs, etc.), each protocol must be modified individually to compensate. A network solution may be more appropriate and efficient.
セグメント認証はトランスポート層で他のプロトコルで扱われました。 SCTPとDCCPの両方が、コネクション確立のためにクッキーを含んで、他のさまざまなコントロールメッセージ[28][41]を認証するのにそれらを使用します。 標準的技法として現れますが、トランスポート・プロトコルにおけるそのようなメカニズムの包含は新しいプロトコル[32]の設計と実装を複雑にします。 新しい攻撃が発見されるように(SYNフラッド、RSTsなど)、代償するように個別に各プロトコルを変更しなければなりません。 ネットワークソリューションは、より適切であって、効率的であるかもしれません。
It should be noted that RST attacks, which rely on brute-force, are relatively easy for intrusion detection software to detect at the TCP layer. Any connection that receives a large number of invalid -- outside-window -- RSTs might have subsequent RSTs blocked, to defeat such attacks. This would have the side-effect of blocking legitimate RSTs to that connection, which might then interfere with cleaning up the transport state between the endpoint peers. This side-effect, coupled with the increased monitoring load, might render such solutions undesirable in the general case, but they might usefully be applied to special cases, e.g., for BGP for routers.
侵入検出ソフトウェアに、RST攻撃(ブルートフォースを当てにする)はTCP層に検出するのが比較的簡単であることに注意されるべきです。 多くの病人を受けるどんな接続--外の窓--RSTsは、そのような攻撃を破るためにその後のRSTsを妨げさせるかもしれません。 これは終点同輩の間に次に輸送状態をきれいにするのに干渉するかもしれないその接続に正統のRSTsを妨げる副作用を持っているでしょう。 増強されたモニターしている負荷に結びつけられたこの副作用はそのようなソリューションを一般的な場合において望ましくなくするかもしれませんが、それらは有効に特別なケースに適用されるかもしれません、例えば、ルータのためのBGPのために。
3.2. Network Layer (IP) Solutions
3.2. ネットワーク層(IP)ソリューション
There are two primary variants of network layer solutions to spoofing: address filtering and IPsec. Address filtering is an indirect system that relies on other parties to filter packets sent upstream of an attack, but does not necessarily require participation of the packet source. IPsec requires cooperation between the endpoints wanting to avoid attack on their connection, which currently involves preexisting shared knowledge of either a shared key or shared certificate authority.
以下をだますことへのネットワーク層ソリューションの2つのプライマリ異形があります。 フィルタリングとIPsecを扱ってください。 アドレスフィルタリングは、上流へ送られたパケットをフィルターにかけるために相手に頼る攻撃の間接的なシステムですが、必ずパケットソースの参加を必要とするというわけではありません。 IPsecは、現在共有されたキーか共有された認証局のどちらかに関する共有知識を先在させることを伴う彼らの接続に対する攻撃を避けたくしながら、終点の間で協力を必要とします。
Touch Informational [Page 14] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[14ページ]のRFC4953の防御しているTCPに触れてください。
3.2.1. Address Filtering
3.2.1. アドレスフィルタリング
Address filtering is often proposed as an alternative to protocol mechanisms to defeat IP source address spoofing [2][13]. Address filtering restricts traffic from downstream sources across transit networks based on the IP source address. A kind of filtering already occurs at the endpoints of a connection, because attack messages must match the socket pair to succeed; again, note that such attacks require knowing the entire socket pair, and are unlikely except in particular cases. This section discusses filtering based on address only, typically done at the borders of an AS.
アドレスフィルタリングは、プロトコルメカニズムに代わる手段として[2]が[13]であると偽造するIPソースアドレスを破るためにしばしば提案されます。 アドレスフィルタリングはIPソースアドレスに基づく輸送網の向こう側に川下のソースからトラフィックを制限します。 一種のフィルタリングが接続の終点に既に起こります、攻撃メッセージが成功するようにソケット組に合わなければならないので。 もう一度、そのような攻撃が全体のソケット組を知るのが必要であり、特にケースを除いて、ありそうもないことに注意してください。 このセクションは、唯一の、そして、ASの境界で通常されたアドレスに基づいてフィルターにかけると論じます。
It can also restrict core-to-edge paths to reject traffic that should have originated further toward the edge. It cannot restrict traffic from edges lacking filtering through the core to a particular edge. As a result, each border router must perform the appropriate filtering for overall protection to result; failure of any border router to filter defeats the protection of all participants inside the border, and potentially those outside as well. Address filtering at the border can protect those inside the border from some kinds of spoofing, i.e., connections among those inside a border, because only interior addresses should originate inside the border. It cannot, however, protect connections including endpoints outside the border (i.e., those that traverse the AS boundary) except to restrict where the traffic enters from, e.g., if it expected from one AS and not another.
また、それは、さらに縁に向かって起因するべきであったトラフィックを拒絶するためにコアから縁への経路を制限する場合があります。 それはトラフィックを縁によって特定である制限しない場合があります。 その結果、各境界ルータは総合的な保護が結果として生じるように適切なフィルタリングを実行しなければなりません。 フィルターにかけるどんな境界ルータの失敗もまた、境界、および潜在的に外であるそれらの中のすべての関係者の保護を破ります。 境界のアドレスフィルタリングは数種類のスプーフィングから境界の中のそれらを保護できます、すなわち、境界の中のそれらの中の接続、内部のアドレスだけが境界の中で起因するべきであるので。 しかしながら、それは制限するのを除いて、境界(すなわち、AS境界を横断するもの)の外に終点を含むトラフィックが入る接続を保護できません、例えば、1から別のものではなく、ASを予想したなら。
As a result, address filtering is not a local solution that can be deployed to protect communicating pairs, but rather relies on a distributed infrastructure of trusted gateways filtering forged traffic where it enters the network. It is not feasible for local, incremental deployment, but may be applicable to connections among those inside the protected border in some scenarios. Applying filtering can also be useful to reduce the network load of spoofed traffic [31].
その結果、アドレスフィルタリングは、組を伝えながら保護するために配布することができる局所解ではありませんが、むしろネットワークに入るところで偽造トラフィックをフィルターにかける信じられたゲートウェイの分配されたインフラストラクチャを当てにします。 それは、地方の、そして、増加の展開には可能ではありませんが、いくつかのシナリオの保護された境界の中のそれらの中の接続に適切であるかもしれません。 また、フィルタリングを適用するのも、偽造しているトラフィック[31]のネットワーク負荷を減少させるために役に立つ場合があります。
A more recent variant of address filtering checks the IP TTL (Time to Live) field, relying on the TTL set by the other end of the connection [15]. This technique has been used to provide filtering for BGP. It assumes the connection source TTL is set to 255; packets at the receiver are checked for TTL=255, and others are dropped. This restricts traffic to one hop upstream of the receiver (i.e., a BGP router), but those hops could include other user programs at those nodes (e.g., the BGP router's peer) or any traffic those nodes accept via tunnels -- because tunnels need not decrement TTLs, notably for "bump in the wire" (BITW) or BITW-equivalent scenarios [33] (see also Section 5.1 of [15] and [16]). TTL filtering works only where all traffic from the other end of the tunnel is trusted,
IP TTL(Liveへの時間)がさばくチェックをフィルターにかけるアドレスの、より最近の異形、TTLを当てにするのは接続[15]のもう一方の端までにセットしました。 このテクニックは、フィルタリングをBGPに供給するのに使用されました。 それは、接続ソースTTLが255に用意ができていると仮定します。 受信機のパケットはTTL=255がないかどうかチェックされます、そして、他のものは下げられます。 これはトラフィックを受信機(すなわち、BGPルータ)のワンバウンドの上流に制限しますが、トンネルがそれらのノード(例えば、BGPルータの同輩)かそれらのノードがトンネルを通って受け入れるどんなトラフィック、「ワイヤでの隆起」(BITW)かBITW同等なシナリオ[33]のためにTTLsを著しく減少させる必要はないのでそれらのホップは他のユーザ・プログラムを含むことができました。(また、[15]と[16])のセクション5.1を見てください。 もう片方からのすべてのトラフィックが終わるトンネルの作品だけをフィルターにかけるTTLが信じられます。
Touch Informational [Page 15] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[15ページ]のRFC4953の防御しているTCPに触れてください。
i.e., where it does not originate or transit spoofed traffic. The use of TTL rather than link or network security also assumes an untampered point-to-point link, where no other traffic can be spoofed onto a link.
すなわち、どこで起因しないか、そして、トランジットがトラフィックを偽造しました。 また、リンクよりむしろTTLかネットワークセキュリティの使用は「非-いじ」られたポイントツーポイント接続を仮定します。そこでは、他のトラフィックを全くリンクに偽造することができません。
This method of filtering works best where traffic originates one hop away, so that the address filtering is based on the trust of only directly-connected (tunneled or otherwise) nodes. Like conventional address filtering, this reduces spoofing traffic in general, but is not considered a reliable security mechanism because it relies on distributed filtering (e.g., the fact that upstream nodes do not terminate tunnels arbitrarily).
フィルタリングのこのメソッドはトラフィックが起因するところに遠くでワンバウンドでうまくいきます、アドレスフィルタリングが直接接続された(トンネルを堀られたかそうでない)ノードだけの信頼に基づいているように。 従来のアドレスフィルタリングのように、これは、一般に、トラフィックを偽造しながら減少しますが、分配されたフィルタリング(例えば、上流のノードが任意にトンネルを終えないという事実)を当てにするので、信頼できるセキュリティー対策であると考えられません。
3.2.2. IPsec
3.2.2. IPsec
TCP is susceptible to RSTs, but also to other off-path and on-path spoofing attacks, including SYN attacks. Other transport protocols, such as UDP and RTP are equally susceptible. Although emerging transport protocols attempt to defeat such attacks at the transport layer, such attacks take advantage of network layer identity spoofing. The packet is coming from an endpoint that is spoofing another endpoint, either upstream or somewhere else in the Internet. IPsec was designed specifically to establish and enforce authentication of a packet's source and contents in order to most directly and explicitly address this security vulnerability.
SYN攻撃を含んでいて、TCPはRSTsに影響されやすいのですが、他のオフ経路と経路に対するスプーフィング攻撃にも影響されやすいです。 UDPやRTPなどの他のトランスポート・プロトコルは等しく影響されやすいです。 現れているトランスポート・プロトコルは、トランスポート層でそのような攻撃を破るのを試みますが、そのような攻撃はネットワーク層アイデンティティスプーフィングを利用します。 パケットはインターネットの別の終点と、上流か他のどこかでだまされている終点から来る予定です。 IPsecは、特に、最も直接、明らかにこのセキュリティの脆弱性を扱うためにパケットのソースとコンテンツの認証を確立して、実施するように設計されました。
The larger problem with IPsec is that of key distribution and use. IPsec is often cumbersome, and has only recently been supported in many end-system operating systems. More importantly, it relies on preshared keys, signed X.509 certificates, or a trusted third-party (e.g., Kerberos) key infrastructure to establish and exchange keying information (e.g., via IKE). Each of these issues presents challenges when using IPsec to secure traffic to a well-known server, whose clients may not support IPsec or may not have registered with a previously-known certificate authority (CA).
IPsecに関する、より大きい問題は主要な分配と使用のものです。 IPsecはしばしば厄介であり、最近、多くのエンドシステムオペレーティングシステムでサポートされるだけでした。より重要に、それはX.509証明書であると署名される、前共有されたキーか、確立する信じられた第三者(例えば、ケルベロス)の主要なインフラストラクチャと情報(例えば、IKEを通した)を合わせる交換に依存します。 それぞれのこれらの問題は、よく知られるサーバにトラフィックを保証するのにIPsecを使用するとき、挑戦を提示しないか、以前に知られている認証局(カリフォルニア)とともに記名していないかもしれません。サーバのクライアントはIPsecをサポートしないかもしれません。
These keying challenges are being addressed in the IETF in ways that will enable servers secure associations with other parties without advance coordination [45][46]. This can be especially useful for publicly-available servers, or for protecting connections to servers that -- for whatever reason -- have not or will not deploy conventional IPsec certificates (i.e., core Internet BGP routers).
合わせる挑戦がIETFでサーバを可能にする方法で扱われているこれらは進歩コーディネート[45][46]なしで相手との仲間を機密保護します。 これが特に公的に利用可能なサーバの役に立つ場合がありますか、サーバに接続を保護するために、いかなる理由によるそれも配布していないか、または従来のIPsec証明書が(すなわち、コアインターネットBGPルータ)であると配布しないでしょう。
Touch Informational [Page 16] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[16ページ]のRFC4953の防御しているTCPに触れてください。
4. ICMP
4. ICMP
Just as spoofed TCP packets can terminate a connection, so too can spoofed ICMP packets. ICMP can be used to launch a variety of attacks on TCP including connection resets, path-MTU attacks, and can also be used to attack the host with non-TCP 'ping of death' and 'smurf attacks', etc. [40]. ICMP thus represents a substantial threat to TCP, but this is not the focus of this document, although a number of protections are discussed below because some are comparable to TCP anti-spoofing techniques. Note also that ICMP attacks on TCP assume that the socket pair is known by the attacker, which is unlikely except for a subset of services between pairs of widely- known endpoints.
また、ちょうど偽造しているTCPパケットが接続を終えることができるように、偽造しているICMPパケットはそうすることができます。 接続リセットを含んでいて、TCPでさまざまな攻撃に着手するのにICMPを使用できて、経路-MTUは攻撃して、また、非TCPのホストのために'死のピング'と'スマーフ攻撃'などを攻撃するのに使用できます。 [40]. その結果、ICMPはTCPへのかなりの脅威を表しますが、これはこのドキュメントの焦点ではありません、或るものがTCP反スプーフィングのテクニックに匹敵しているので、以下で多くの保護について議論しますが。 また、TCPに対するICMP攻撃が、ソケット組が組の広く知られている終点の間のサービスの部分集合を除いて、ありそうもない攻撃者によって知られていると仮定することに注意してください。
TCP headers can be included inside certain ICMP messages [7]. There have been recent suggestions to validate the sequence number of TCP headers when they occur inside ICMP messages [18]. This sequence checking is similar to checks that would occur for conventional data packets in TCP, but is being proposed in the spirit of the RST window attenuation described in Section 3.1.2.
あるICMPメッセージ[7]でTCPヘッダーを含むことができます。 彼らがICMPメッセージ[18]で起こるとき、TCPヘッダーの一連番号を有効にするために、最近の提案がありました。 この系列の照合は、TCPの従来のデータ・パケットのために起こるチェックと同様ですが、セクション3.1.2で説明されたRST窓の減衰の精神で提案されています。
Some such checks may be reasonable, especially where they parallel the validations already performed by TCP processing, notably where they emulate the semantics of such processing. For example, the TCP checksum should be validated (if the entire TCP segment is contained in the ICMP message) before any fields of the TCP header are examined, to avoid reacting to corrupted packets. Similarly, if the TCP MD5 option is present, its signature should probably be validated before considering the contents of the message. Such validation can ensure that the packet was not corrupted prior to the ICMP generation (checksum), that the packet was one sent by the source (IPsec or TCP/MD5 authenticated), or that the packet was not in the network for an excess of 2*MSL (valid sequence number).
そのようないくつかのチェックが合理的であるかもしれません、特に著しくそれらがそのような処理の意味論を見習うところに処理するTCPによって既に実行された合法化に沿うところで。 例えば、TCPヘッダーのどんな分野も崩壊したパケットに反応するのを避けるために調べられる前にTCPチェックサムは有効にされるべきです(全体のTCPセグメントがICMPメッセージに含まれているなら)。 同様に、TCP MD5オプションが存在しているなら、メッセージのコンテンツを考える前に、署名はたぶん有効にされるべきです。 そのような合法化は、パケットがICMP世代(チェックサム)の前に崩壊しなかったか、パケットがソース(IPsecか認証されたTCP/MD5)によって送られたものであったまたは2*MSL(有効な一連番号)の過剰のためのネットワークにはパケットがなかったのを確実にすることができます。
ICMP presents a particular challenge because some messages can reset a connection more easily -- with less validation -- than even some spoofed TCP segments. One other proposed alternative is to change TCP's reaction to ICMPs after a connection is established; that may leave TCP susceptible during connection establishment and modifies TCP's reaction to certain valid network events [19]. This considers the context-sensitivity of ICMP messages, as does IPsec in some tunneled configurations, but the recommendations are ambiguous regarding such filtering [27].
いくつかのメッセージが、より少ない合法化で、より容易に接続をリセットできるので、ICMPは特定の挑戦を提示します--TCPセグメントであると偽造されたいくつかよりさえ。 他の1つの提案された選択肢は接続が確立された後にTCPの反応をICMPsに変えることです。 それは、コネクション確立の間、影響されやすい状態でTCPを残すかもしれなくて、ある有効なネットワークイベント[19]にTCPの反応を変更します。 これはIPsecのようにいくつかのトンネルを堀られた構成でICMPメッセージの文脈感度を考えますが、推薦は[27]をフィルターにかけるのであるのに関してそのようなあいまいです。
Ultimately, requiring TCP ICMP messages to be 'in window' may be insufficient protection, as this document shows for spoofed data. ICMP packets can be authenticated when originating at known, trusted endpoints, such as endpoints of connections or routers in known
結局、このドキュメントが偽造しているデータのために示すように'窓'にあるTCP ICMPメッセージを必要とするのは、不十分な保護であるかもしれません。 知られるところで接続かルータの終点などの知られていて、信じられた終点で起因するとき、ICMPパケットを認証できます。
Touch Informational [Page 17] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[17ページ]のRFC4953の防御しているTCPに触れてください。
domains with preexisting IPsec associations. Unfortunately, they also can originate at other places in the network. In addition, some networks filter all ICMP packets because validation may not be possible, especially because they can be injected from anywhere in a network, and so cannot be easily and locally address filtered [27]. As a result, they are not addressed separately in the issues or security considerations of this document further.
IPsec協会を先在させるドメイン。 残念ながら、また、彼らは他の場所でネットワークで起因することができます。 さらに、合法化が可能でないかもしれないので、いくつかのネットワークがすべてのICMPパケットをフィルターにかけます、特に、それらがネットワークでどこからでも注入できるので容易に注入されたはずがなくて、アドレスが局所的に[27]をフィルターにかけたので。 その結果、それらは別々にこのドキュメントの問題かセキュリティ問題でさらに扱われません。
5. Issues
5. 問題
There are a number of existing and proposed solutions addressing the vulnerability of transport protocols in general (and TCP in specific) to off-path third-party spoofing attacks. As shown, these operate at the transport or network layer. Transport solutions require separate modification of each transport protocol, addressing network identity spoofing separately in the context of each transport association. Network solutions require distributed coordination (filtering) or can be computationally intensive and require pervasive registration of certificate authorities with every possible endpoint (authentication). This section explains these observations further.
一般に、トランスポート・プロトコル(そして、特定のTCP)の脆弱性をオフ経路第三者スプーフィング攻撃に扱う多くの存在と提案されたソリューションがあります。 示されるように、これらは輸送かネットワーク層で作動します。 輸送対策はそれぞれのトランスポート・プロトコルの別々の変更を必要とします、別々にそれぞれの輸送協会の文脈でネットワークのアイデンティティがスプーフィングであると扱って。 ネットワークソリューションは、分配されたコーディネート(フィルターにかける)を必要とするか、計算上徹底的であり、またはあらゆる可能な終点(認証)がある認証局の普及している登録を必要とすることができます。 このセクションはこれらの観測で、より詳しく説明します。
5.1. Transport Layer (e.g., TCP)
5.1. トランスポート層(例えば、TCP)
Transport solutions rely on shared cookies to authenticate segments, including data, transport header, and even pseudo-header (e.g., fixed portions of the outer IP header in TCP). Because the Internet relies on stateless network protocols, it makes sense to rely on state establishment and maintenance available in some transport layers not only for the connection but for authentication state. Three-way handshakes and heartbeats can be used to negotiate authentication state in conjunction with connection parameters, which can be stored with connection state easily.
輸送対策はセグメントを認証するために共有されたクッキーを当てにします、データ、輸送ヘッダー、および疑似ヘッダー(例えば、TCPの外側のIPヘッダーの固定部分)さえ含んでいて。 インターネットが状態がないネットワーク・プロトコルを当てにするので、それは状態を当てにする意味をいくつかのトランスポート層で接続だけではなく、認証状態に利用可能な設立とメインテナンスにします。 接続パラメタに関連して認証状態を交渉するのに3方向ハンドシェイクと鼓動を使用できます。接続状態と共にパラメタを容易に保存できます。
As noted earlier, transport layer solutions require separate modification of all transport protocols to include authentication. Not all transport protocols support negotiated endpoint state (e.g., UDP), and legacy protocols have been notoriously difficult to safely augment. Not all authentication solutions are created equal, either, and relying on a variety of transport solutions exposes end-systems to increased potential for incorrectly specified or implemented solutions. Transport authentication has often been developed piece- wise, in response to specific attacks, e.g., SYN cookies and RST window attenuation [4][36].
より早く注意されるように、トランスポート層溶液は認証を含むようにすべてのトランスポート・プロトコルの別々の変更を必要とします。 すべてのトランスポート・プロトコルサポートが終点州(例えば、UDP)を交渉したというわけではありません、そして、レガシープロトコルは安全に増大させるのが悪名高く難しいです。 すべての認証対策が等しい状態で作成されるというわけではありません、そして、さまざまな輸送対策を当てにすると、エンドシステムは不当に指定されたか、または実装しているソリューションの増強された可能性にさらされます。 しばしば断片賢明な状態で輸送認証を開発してあります、特定の攻撃、例えば、SYNクッキーとRST窓の減衰[4][36]に対応して。
Transport layer solutions are not only per-protocol, but often per- connection. This has both advantages and drawbacks. One advantage to transport layer solutions is that they can protect the transport protocol when lower layers have failed, e.g., due to bugs in
プロトコルだけではなく、しばしばトランスポート層溶液がそうである、-、接続。 これには、利点と欠点の両方があります。 層の溶液を輸送するそれらが下層が例えば、バグのため失敗したトランスポート・プロトコルを保護できる1つの利点があります。
Touch Informational [Page 18] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[18ページ]のRFC4953の防御しているTCPに触れてください。
implementation. TCP already includes a variety of packet validation mechanisms to protect in these cases, e.g., checking that RSTs are in-window. More strict checks can increase the protections provided, e.g., to protect against misaddressed RSTs that end up in-window (via TCPsecure) or to protect against connection interruption due to RSTs, SYNs, or data injection from misaddressed packets (TCP/MD5) [36].
実装。 TCPはこれらの場合で保護するために既にさまざまなパケット合法化メカニズムを含みます、例えば、チェックして、そのRSTsが窓です。 より厳しいチェックは例えば、misaddressed RSTsに対して窓へのその終わり(TCPsecureを通した)を保護するか、またはmisaddressedパケット(TCP/MD5)[36]からRSTs、SYNs、またはデータ注射による接続中断から守るために提供された保護を増強できます。
Another advantage is that transport layer protections can be more specifically limited to a particular connection. Because each connection negotiates its state separately, that state can be more specifically tied to that connection. This is both an advantage and a drawback. It can make it easier to tie security to an individual connection, although in practice a shared secret or certificate will generally be shared across multiple connections.
別の利点は、より明確にトランスポート層保護を特定の接続に制限できるということです。 各接続が別々に状態を交渉するので、より明確にその状態をその接続に結ぶことができます。 これは利点と欠点の両方です。 それで、個々の接続にセキュリティを結ぶのは、より簡単になる場合があります、共有秘密キーか証明書が実際には複数の接続の向こう側に一般に共有されるでしょうが。
As a drawback, each transport connection needs to negotiate and maintain authentication state separately. Some overhead is not amortized over multiple connections, e.g., overheads in packet exchanges, whereas other overheads are not amortized over different transport protocols, e.g., design and implementation complexity -- both as would be the case in a network layer solution. Because the authentication happens later in packet processing than is required, additional endpoint resources may be needlessly consumed, e.g., in demultiplexing received packets, indexing connection identifiers, and continuing to buffer spoofed packets, etc., only to be dropped later at the transport layer.
欠点として、それぞれの輸送接続は、別々に認証状態を交渉して、維持する必要があります。 ともにネットワーク層ソリューションでそうであるように他のオーバーヘッドは異なったトランスポート・プロトコル、例えば、設計と実装の複雑さについて清算されませんが、何らかのオーバーヘッドは複数の接続、例えば、パケット交換におけるオーバーヘッドについて清算されません。 認証が必要とされるよりパケット処理で遅く起こるので、追加終点リソースは不必要に消費されたかもしれません、例えば、逆多重化では、容認されたパケット、接続識別子に索引をつけて、およびバッファリングする続行はパケットなどを偽造しましたが、後でトランスポート層で下げられました。
5.2. Network Layer (IP)
5.2. ネットワーク層(IP)
A network layer solution avoids the hazards of multiple transport variants, using a single shared endpoint authentication mechanism early in receiver packet processing to discard unauthenticated packets at the network layer instead. This defeats spoofing entirely because spoofing involves masquerading as another endpoint, and network layer security validates the endpoint as the source of the packets it emits. Such a network level solution protects all transport protocols as a result, including both legacy and emerging protocols, and reduces the complexity of these protocols as well. A shared solution also reduces protocol overhead, and decouples the management (and refreshing) of authentication state from that of individual transport connections. Finally, a network layer solution protects not only the transport layer but the network layer as well, e.g., from IGMP, and some kinds of ICMP (Section 4), spoofing attacks.
ネットワーク層ソリューションは複数の輸送異形の危険を避けます、代わりにネットワーク層で非認証されたパケットを捨てるのに早く受信機パケット処理にただ一つの共有された終点認証機構を使用して。 完全にスプーフィングが、別の終点のふりをすることを伴うので、これはスプーフィングを破ります、そして、ネットワーク層セキュリティはそれが放つパケットの源として終点を有効にします。 そのようなネットワークレベルソリューションは、レガシーとプロトコルとして現れる両方を含んでいて、その結果すべてのトランスポート・プロトコルを保護して、また、これらのプロトコルの複雑さを減少させます。 共有されたソリューションは、また、プロトコルオーバーヘッドを下げて、個々の輸送の接続のものから認証状態の管理(そして、リフレッシュ)の衝撃を吸収します。 最終的に、ネットワーク層ソリューションはトランスポート層だけではなく、また、ネットワーク層も保護します、例えば、IGMP、および数種類のICMP(セクション4)から、攻撃を偽造して。
The IETF Proposed Standard protocol for network layer authentication is IPsec [27]. IPsec specifies the overall architecture, including header authentication (AH) [25] and encapsulation (ESP) modes [26].
ネットワーク層認証のためのIETF Proposed StandardプロトコルはIPsec[27]です。 IPsecはヘッダー認証(AH)[25]とカプセル化(超能力)モード[26]を含む総合的なアーキテクチャを指定します。
Touch Informational [Page 19] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[19ページ]のRFC4953の防御しているTCPに触れてください。
AH authenticates both the IP header and IP data, whereas ESP authenticates only the IP data (e.g., transport header and payload). AH is being phased out since ESP is more efficient and the Security Parameters Index (SPI) includes sufficient information to verify the IP header anyway [27]. These two modes describe the security applied to individual packets within the IPsec system; key exchange and management is performed either out-of-band (via pre-shared keys) or by an automated key exchange protocol, e.g., IKE [24].
AHはIPヘッダーとIPデータの両方を認証しますが、超能力はIPデータ(例えば、輸送ヘッダーとペイロード)だけを認証します。 超能力が、より効率的であるので、AHは段階的に廃止されています、そして、Security Parameters Index(SPI)はとにかくIPヘッダーについて確かめるために十分な情報を含んでいます。[27]。 これらの2つのモードがIPsecシステムの中の個々のパケットに適用されたセキュリティについて説明します。 バンドの外(あらかじめ共有されたキーを通して)か自動化された主要な交換プロトコル(例えば、IKE[24])によって主要な交換と管理は実行されます。
IPsec already provides authentication of an IP header and its data contents sufficient to defeat both on-path and off-path third-party spoofing attacks. IKE can configure authentication between two endpoints on a per-endpoint, per-protocol, or per-connection basis, as desired. IKE also can perform automatic periodic re-keying, further defeating crypto-analysis based on snooping (clandestine data collection). The use of IPsec is already commonly strongly recommended for protected infrastructure.
IPsecは既に両方のオン経路とオフ経路第三者スプーフィング攻撃を破ることができるくらいのIPヘッダーとそのデータコンテンツの認証を提供します。 IKEは望まれているように終点、プロトコル、または接続あたり1個のベースの2つの終点の間の認証を構成できます。 (秘密のデータ収集)について詮索することに基づいてさらに暗号解読を破って、IKEも自動周期的な再の合わせることを実行できます。 IPsecの使用は保護されたインフラストラクチャのために既に一般的に強く推薦されます。
Existing IPsec is not appropriate for many deployments. It is computationally intensive both in key management and individual packet authentication [43]. This computational overhead can be prohibitive, and so often requires additional hardware, especially in commercial routers. As importantly, IKE is not anonymous; keys can be exchanged between parties only if they trust each other's X.509 certificates, trust some other third-party to help with key generation (e.g., Kerberos), or pre-share a key. These certificates provide identification (the other party knows who you are) only where the certificates themselves are signed by certificate authorities (CAs) that both parties already trust. To a large extent, the CAs themselves are the pre-shared keys that help IKE establish security association keys, which are then used in the authentication algorithms.
多くの展開には、既存のIPsecは適切ではありません。 それはかぎ管理と個々のパケット認証[43]で計算上徹底的です。 このコンピュータのオーバーヘッドは、禁止である場合があり、特に商業ルータで追加ハードウェアをそうたびたび必要とします。 同じくらい重要に、IKEは匿名ではありません。 彼らが互いのX.509証明書を信じるか、ある他の第三者がキー生成(例えば、ケルベロス)と共に助けると信じるか、またはキーをあらかじめ共有する場合にだけ、パーティーの間でキーを交換できます。 これらの証明書は双方が既に信じる認証局(CAs)によって証明書自体が署名されるところだけに識別(相手は、あなたがだれであるかを知っている)を提供します。 大体において、CAs自身はIKEが次に認証アルゴリズムで使用されるセキュリティ協会キーを設立するのを助けるあらかじめ共有されたキーです。
Alternative mechanisms are under development to address this limitation, to allow publicly-accessible servers to secure connections to clients not known in advance, or to allow unilateral relaxation of identity validation so that the remaining protections of IPsec can be made available [45][46]. In particular, these mechanisms can prevent a client (but without knowing who that client is) from being affected by spoofing from other clients, even when the attackers are on the same communications path.
IPsecの残っている保護が人工の利用可能な[45]にな[46]って、代替のメカニズムは、この制限を扱って、公的にアクセスしやすいサーバがあらかじめ知られなかったクライアントに接続を保証するか、またはアイデンティティ合法化の一方的な緩和を許容するのを許容するために開発中です。 特に、クライアント(しかしそのクライアントがだれであるかを知らない)はこれらのメカニズムで他のクライアントからだますことによって、影響を受けることができません、攻撃者が同じコミュニケーション経路にいるときさえ。
IPsec, although widely available both in commercial routers and commodity end-systems, is not often used except between parties that already have a preexisting relationship (employee/employer, between two ISPs, etc.). Servers to anonymous clients (e.g., customer/ business) or more open services (e.g., BGP, where routers may have large numbers of peers) are unmanageable, due to the breadth and flux
商業ルータと商品エンドシステムで広く利用可能ですが、既に、先在の関係(2つのISPなどの間の従業員/雇い主)を持っているパーティー以外に、IPsecはしばしば使用されるというわけではありません。 匿名のクライアント(例えば、顧客/ビジネス)か、より開いているサービス(例えば、ルータには多くの同輩がいるかもしれないところのBGP)へのサーバは「非-処理しやす」です、幅とフラックスのため
Touch Informational [Page 20] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[20ページ]のRFC4953の防御しているTCPに触れてください。
of CAs. New endpoints cannot establish IPsec associations with such servers unless their own certificate is signed by a CA already trusted by the server. Different servers -- even within the same overall system (e.g., BGP) -- often cannot or will not trust overlapping subsets of CAs in general.
CAsについて。 それら自身の証明書がサーバによって既に信じられたカリフォルニアによって署名されない場合、新しい終点はそのようなサーバとのIPsec協会を設立できません。一般に、同じ総合体系(例えば、BGP)の中の異なったサーバさえ、しばしば信じることができないというわけではありませんし、またCAsの重なっている部分集合を信じるというわけではないでしょう。
5.3. Application Layer
5.3. 応用層
There are a number of application layer authentication mechanisms, often implicit within end-to-end encryption. Application layer security (e.g., TLS, SSH, or MD5 checksums within a BGP stream) provides the ultimate protection of application data from all intermediaries, including network routers as well as exposure at other layers in the end-systems. This is the only way to ultimately protect the application data.
終端間暗号化の中にしばしば内在している多くの応用層認証機構があります。 応用層セキュリティ(BGPストリームの中の例えば、TLS、SSH、またはMD5チェックサム)はすべての仲介者からアプリケーションデータの究極の保護を提供します、エンドシステムの他の層の暴露と同様にネットワークルータを含んでいて。これは結局アプリケーションデータを保護する唯一の方法です。
Application authentication cannot protect either the network or transport protocols from spoofing attacks, however. Spoofed packets interfere with network processing or reset transport connections before the application checks the data. Authentication needs to winnow these packets and drop them before they interfere at these lower layers.
しかしながら、アプリケーション認証はスプーフィング攻撃からネットワークかトランスポート・プロトコルを保護できません。アプリケーションがデータをチェックする前に、偽造しているパケットは、ネットワーク処理を妨げるか、または輸送の接続をリセットします。 認証は、これらの下層で干渉する前に、これらのパケットを選び出して、それらを下げる必要があります。
An alternate application layer solution would involve resilience to reset connections. If the application can recover from such connection interruptions, then such attacks have less impact. Unfortunately, attackers still affect the application, e.g., in the cost of restarting connections, delays until connections are restarted, or increased connection establishment messages on the network. Some applications -- notably BGP -- even interpret TCP connection reliability as an indicator of route path stability, which is why attacks on BGP have such substantial consequences.
代替の応用層溶液は、接続をリセットするために弾力にかかわるでしょう。 アプリケーションがそのような接続中断から回復できるなら、そのような攻撃には、より少ない影響力があります。 残念ながら、攻撃者はまだアプリケーションに影響しています、例えば、接続を再出発する費用では、接続までの遅れがネットワークに関する再開しているか、増強されたコネクション確立メッセージです。 いくつかのアプリケーション(著しくBGP)がルート経路の安定性のインディケータとしてTCP接続の信頼性を解釈さえします(BGPに対する攻撃にはそのようなかなりの結果がある理由です)。
5.4. Link Layer
5.4. リンクレイヤ
Link layer security operates separately on each hop of an Internet. Such security can be critical in protecting link resources, such as bandwidth and link management protocols. Protection at this layer cannot suffice for network or transport layers, because it cannot authenticate the endpoint source of a packet. Link authentication ensures only the source of the current link hop where it is examined.
リンクレイヤセキュリティは別々にインターネットの各ホップを作動させます。 そのようなセキュリティは、帯域幅などのリンクリソースを保護するのにおいて重要であり、管理プロトコルをリンクできます。 この層での保護はネットワークかトランスポート層に十分であることができません、パケットの終点の源を認証できないので。 リンク認証はそれが調べられる現在のリンクホップの源だけを確実にします。
5.5. Issues Discussion
5.5. 議論を発行します。
The issues raised in this section suggest that there are challenges with all solutions to transport protection from spoofing attacks. This raises the potential need for alternate security levels. While it is already widely recognized that security needs to occur
このセクションで提起された問題は、スプーフィング攻撃から保護を輸送するためにすべてのソリューションがある挑戦があるのを示します。 これは代替のセキュリティー・レベルの潜在的必要性を上げます。 セキュリティが、起こる必要であると既に広く認められますが
Touch Informational [Page 21] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[21ページ]のRFC4953の防御しているTCPに触れてください。
simultaneously at many protocol layers, there also may be utility in supporting a variety of strengths at a single layer. For example, IPsec already supports a variety of algorithms (MD5, SHA1, etc., for authentication), but always assumes that:
また、同時に、多くのプロトコル層では、さまざまな強さをサポートするのにおいてユーティリティが単一層にあるかもしれません。 例えば、IPsecは、さまざまなアルゴリズムが(MD5、認証のためのSHA1など)であると既にサポートしますが、いつも以下のことと仮定します。
1. The entire body of the packet is secured.
1. パケットの全身は機密保護されます。
2. Security associations are established only where identity is
authenticated by a known certificate authority or other pre-shared
key.
2. アイデンティティが知られている認証局か他のあらかじめ共有されたキーによって認証されるだけであるところにセキュリティ協会は設立されます。
3. Both on-path and off-path third-party spoofing attacks must be
defeated.
3. 両方のオン経路とオフ経路第三者スプーフィング攻撃を破らなければなりません。
These assumptions are prohibitive, especially in many cases of
spoofing attacks. For spoofing, the primary issue is whether packets
are coming from the same party the server can reach. Only the IP
header is fundamentally in question, so securing the entire packet
(1) is computational overkill. It is sufficient to authenticate the
other party as "a party you have exchanged packets with", rather than
establishing their trusted identity ("Bill" vs. "Bob") as in (2).
Finally, many cookie systems use clear-text (unencrypted), fixed
cookie values, providing reasonable (1 in 2^{cookie-size}) protection
against off-path third-party spoof attacks, but not addressing on-
path attacks at all. Such potential solutions are discussed in the
Better Than Nothing Security (BTNS) documents [5][45][46]. Note also
that NULL Encryption in IPsec applies a variant of this cookie, where
the SPI is the cookie, and no further encryption is applied [17].
これらの仮定は特にスプーフィング攻撃の多くの場合で禁止です。 スプーフィングのために、プライマリ問題はパケットがサーバが届くことができる同じパーティーから来る予定であるかどうかということです。 IPヘッダーだけが基本的にはっきりしていないので、全体のパケットが(1)であると機密保護するのは、コンピュータの過剰殺傷です。 (2)のように彼らの信じられたアイデンティティ(「ボブ」に対する「ビル」)を確立するより「あなたにパケットを交換したパーティー」としてむしろ相手を認証するのは十分です。 最終的に、多くのクッキーシステムが明確なテキスト(非暗号化される)の、そして、固定されたクッキー値を使用して、アドレシングではなく、オフ経路第三者パロディー攻撃に対して進行中の合理的な(2^クッキーサイズにおける1)保護を提供して、経路は全く攻撃されます。 Better Than Nothing Security(BTNS)ドキュメント[5][45][46]でそのような潜在的ソリューションについて議論します。 また、IPsecのNULL Encryptionがこのクッキーの異形を適用することに注意してください。そこでは、SPIがクッキーを適用しましたが、適用されなかったあらゆるさらなる暗号化であることは。[17]。
6. Security Considerations
6. セキュリティ問題
This entire document focuses on increasing the security of transport protocols and their resistance to spoofing attacks. Security is addressed throughout.
この全体のドキュメントは、トランスポート・プロトコルのセキュリティとスプーフィング攻撃への彼らの抵抗を増強するのは焦点を合わせます。 セキュリティはあらゆる点で扱われます。
This document describes a number of techniques for defeating spoofing attacks. Those relying on clear-text cookies, either explicit or implicit (e.g., window sequence attenuation) do not protect from on- path spoofing attacks, since valid values can be learned from prior traffic. Those relying on true authentication algorithms are stronger, protecting even from on-path attacks, because the authentication hash in a single packet approaches the behavior of "one-time" cookies.
このドキュメントはスプーフィング攻撃を破るための多くのテクニックについて説明します。 明白であるか内在(例えば、系列減衰に窓を付ける)であるクッキーが当てにしないクリアテキストを当てにするのが保護するそれら、オンである、経路スプーフィングは攻撃されます、先のトラフィックから有効値について学習できるので。 本当の認証アルゴリズムを当てにするものは、より強いです、経路に対する攻撃からさえ保護して、単一のパケットの認証ハッシュが「1回」のクッキーの動きにアプローチするので。
The security of various levels of the protocol stack is addressed. Spoofing attacks are fundamentally identity masquerading, so we believe the most appropriate solutions defeat these at the network layer, where end-to-end identity lies. Some transport protocols
プロトコル・スタックの様々なレベルのセキュリティは扱われます。 私たちは、スプーフィング攻撃が基本的にアイデンティティ仮装であるので、最も適切なソリューションがネットワーク層でこれらを破ると信じています、終わりから終わりへのアイデンティティがあるところで。 いくつかのトランスポート・プロトコル
Touch Informational [Page 22] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[22ページ]のRFC4953の防御しているTCPに触れてください。
subsume endpoint identity information from the network layer (e.g., TCP pseudo-headers), whereas others establish per-connection identity based on exchanged nonces (e.g., SCTP). It is reasonable, if not recommended, to address security at all layers of the protocol stack.
他のものはネットワーク層(例えば、TCP疑似ヘッダー)交換された一回だけ(例えば、SCTP)に基づく1接続あたりのアイデンティティを確立しますが、終点アイデンティティ情報を包括してください。 それは、全くセキュリティにプロトコル・スタックの層を扱うために妥当であるか、またはお勧めです。
Note that Network Address Translators (NATs) and other middleboxes complicate the design and deployment of techniques to defeat spoofing attacks. Devices such as these, that modify IP and/or TCP headers in-transit, generate traffic equivalent to a spoofing attack, and thus should be inhibited by antispoofing mechanisms. Details of these middlebox-related problems are out of scope for this document, but issues thereof are addressed in RFCs and emerging documents that discuss the interactions between such devices and the Internet architecture, e.g., [21]. Fortunately, many of the most critical TCP-based connections -- in particular, those supporting routing protocols like BGP -- do not traverse such middleboxes, and are not affected by this limitation.
Network Address Translators(NATs)と他のmiddleboxesがスプーフィング攻撃を破るためにテクニックのデザインと展開を複雑にすることに注意してください。 トランジットでIP、そして/または、TCPヘッダーを変更してください、そして、スプーフィング攻撃に同等なトラフィックを生成してください、そして、その結果、メカニズムを反偽造することによって、禁止されるべきです。これらなどのデバイス、このドキュメントのための範囲の外にこれらのmiddlebox関連の問題の詳細がありますが、それの問題がRFCsで扱われて、現れがそれを記録するのがそのようなデバイスとインターネットアーキテクチャ(例えば、[21])との相互作用について議論します。 幸い、ルーティングがプロトコルであるとサポートする人がBGPが特に、好きであるという最も重要なTCPベースの接続の多くが、そのようなmiddleboxesを横断しないで、またこの制限で影響を受けません。
7. Conclusions
7. 結論
This document describes the details of the recent BGP spoofing attacks involving spurious RSTs, which could be used to shutdown TCP connections. It summarizes and discusses a variety of current and proposed solutions at various protocol layers.
このドキュメントは閉鎖TCP接続に使用できた偽物のRSTsにかかわる最近のBGPスプーフィング攻撃の詳細について説明します。 それは、様々なプロトコル層のさまざまな現在の、そして、提案されたソリューションをまとめて、議論します。
8. Acknowledgments
8. 承認
This document was inspired by discussions in the TCPM WG <http://www.ietf.org/html.charters/tcpm-charter.html> about the recent spoofed RST attacks on BGP routers, including R. Stewart's document (whose author list has since evolved) [36][42]. The analysis of the attack issues, alternate solutions, and the anonymous security proposed solutions were the result of discussions on that list as well as with USC/ISI's T. Faber, A. Falk, G. Finn, and Y. Wang. R. Atkinson suggested the UDP variant of TCP/MD5, P. Goyette suggested using the ISN to seed TCP/MD5, and L. Wood suggested using the ISN to validate RSTs. Other improvements are due to the input of various members of the IETF's TCPM WG, notably detailed feedback from F. Gont, P. Savola, and A. Hoenes.
このドキュメントはBGPルータに対する最近の偽造しているRST攻撃に関してTCPM WG<http://www.ietf.org/html.charters/tcpm-charter.html>での議論で奮い立たせられました、R.スチュワートのドキュメント(作者リストは以来、発展している)[36][42]を含んでいて。 攻撃問題の分析、代替策、および匿名のセキュリティ提案された解答はそのリスト、USC/ISIのT.フェーバー、A.フォーク、G.フィンランド人、およびY.ワングとの議論の結果でした。 R。 アトキンソンはTCP/MD5のUDP異形について提案しました、そして、P.ゴエッティは、TCP/MD5に種を蒔くのにISNを使用することを提案しました、そして、L.WoodはRSTsを有効にするのにISNを使用するのを示しました。 他の改良はIETFのTCPM WGの様々なメンバー、F.Gontからの著しく詳細なフィードバック、P.Savola、およびA.Hoenesの入力のためです。
This document was prepared using 2-Word-v2.0.template.dot.
このドキュメントは、2Word v2.0.template.dotを使用することで準備されました。
Touch Informational [Page 23] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[23ページ]のRFC4953の防御しているTCPに触れてください。
9. Informative References
9. 有益な参照
[1] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[1] オールマンとM.とパクソン、V.とW.スティーブンス、「TCP輻輳制御」、RFC2581、1999年4月。
[2] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[2] ベイカー、F.とP.Savola、「Multihomedのためにネットワークをフィルターにかけるイングレス」BCP84、2004年3月のRFC3704。
[3] Bellovin, S. and A. Zinin, "Standards Maturity Variance
Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4
Specification", RFC 4278, January 2006.
[3]Bellovin、S.、およびA.ジニン、「TCP MD5署名オプションに関する規格円熟変化、(RFC2385)とBGP-4仕様、」、RFC4278(2006年1月)
[4] Bernstein, D., "SYN cookies", 1997,
<http://cr.yp.to/syncookies.html>.
[4] バーンスタイン、D.、「SYNクッキー。」1997、<http://cr.yp.to/syncookies.html>。
[5] Better Than Nothing Security [BTNS] WG web pages,
<http://www.postel.org/anonsec>.
[5] より良いThan Nothing Security[BTNS]WGウェブページ、<http://www.postel.org/anonsec>。
[6] Bonica, R., Weis, B., Viswanathan, S., Lange, A., and O.
Wheeler, "Authentication for TCP-based Routing and Management
Protocols", Work in Progress, February 2007.
[6] R.、ウィス、B.、Viswanathan、S.、ラング、A.、およびO.ウィーラー、「TCPベースのルート設定と管理プロトコルのための認証」というBonicaは進行中(2007年2月)で働いています。
[7] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.
[7] ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[8] Braden, R., "TIME-WAIT Assassination Hazards in TCP", RFC 1337,
May 1992.
[8] ブレーデン(R.、「TCPの時間待ち暗殺危険」、RFC1337)は1992がそうするかもしれません。
[9] CERT alert: "Technical Cyber Security Alert TA04-111A:
Vulnerabilities in TCP", April 20, 2004,
<http://www.us-cert.gov/cas/techalerts/TA04-111A.html>.
[9] CERTは以下を警告します。 「技術的なサイバーセキュリティ警告TA04-111A:」 「TCPの脆弱性」、2004年4月20日、<http://www.us-cert.gov/cas/techalerts/TA04-111A. html>。
[10] Convery, S., and M. Franz, "BGP Vulnerability Testing:
Separating Fact from FUD", 2003,
<http://www.nanog.org/mtg-0306/pdf/franz.pdf>.
[10]Convery、S.、およびM.フランツ、「以下をテストするBGP脆弱性」 「FUDと事実を切り離します」、2003、<http://www.nanog.org/mtg-0306/pdf/franz.pdf>。
[11] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations",
Work in Progress, May 2007.
[11] 渦巻と、W.と、「TCP SYNフラッディング攻撃と一般的な緩和」は進歩、2007年5月に働いています。
[12] Faber, T., J. Touch, and W. Yue, "The TIME-WAIT state in TCP
and Its Effect on Busy Servers", Proc. Infocom 1999, pp. 1573-
1583, Mar. 1999.
[12] フェーバー、T.、J.Touch、およびW.Yue、「Busy Serversの上のTCPとIts Effectのタイム誌-WAIT状態」、Proc。 Infocom1999、ページ 1573- 1583と、1999年3月。
[13] 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.
[13] ファーガソン、P.、およびD.Senieは「以下をフィルターにかけるイングレスをネットワークでつなぎます」。 「IP Source Address Spoofingを使うサービス妨害Attacksを破ります」、BCP38、RFC2827、2000年5月。
Touch Informational [Page 24] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[24ページ]のRFC4953の防御しているTCPに触れてください。
[14] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP
60, RFC 3360, August 2002.
[14] フロイド、S.、「有害であると考えられた不適当なTCPリセット」、BCP60、RFC3360、2002年8月。
[15] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL
Security Mechanism (GTSM)", RFC 3682, February 2004.
[15]エラ、V.、Heasley、J.、およびD.マイヤー、「一般化されたTTLセキュリティー対策(GTSM)」、RFC3682 2004年2月。
[16] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism (GTSM)",
Work in Progress, June 2007.
[16] エラ、V.、Heasley、J.、マイヤー、D.、Savola、P.、エド「一般化されたTTLセキュリティー対策(GTSM)」というC.Pignataroは進行中(2007年6月)で働いています。
[17] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its
Use With IPsec", RFC 2410, November 1998.
[17] グレン、R.、S.ケント、および「ヌル暗号化アルゴリズムとIPsecとのその使用」、RFC2410、11月1998日
[18] Gont, F., "ICMP attacks against TCP", Work in Progress, May
2007.
[18]Gont、F.、「TCPに対するICMP攻撃」、Progress、2007年5月のWork。
[19] Gont, F., "TCP's Reaction to Soft Errors", Work in Progress,
June 2007.
[19] F.、「ソフト・エラーへのTCPの反応」というGontは進歩、2007年6月に働いています。
[20] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[20] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、1998年8月。
[21] Holdrege, M. and P. Srisuresh, "Protocol Complications with the
IP Network Address Translator", RFC 3027, January 2001.
[21]HoldregeとM.とP.Srisuresh、「IPネットワークアドレス変換機構とのプロトコル複雑さ」、RFC3027、2001年1月。
[22] Housley, R., Post to IETF Discussion mailing list regarding his
IETF 64 Security Area presentation,
ID=7.0.0.10.2.20051124135914.00f50558@vigilsec.com, Nov. 24,
2005, <http://www1.ietf.org/
mail-archive/ietf/Current/maillist.html>.
[22] Housley、R.、彼のIETF64Security Areaプレゼンテーションに関するIETF Discussionメーリングリストへのポスト、IDが2005年11月24日に 7.0.0.10.2.20051124135914.00f50558@vigilsec.com と等しい、lt;、メールhttp://www1.ietf.org/アーカイブ/ietf/電流/maillist.html>。
[23] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for
High Performance", RFC 1323, May 1992.
[23] ジェーコブソン(V.とブレーデン、R.とD.ボーマン、「高性能のためのTCP拡張子」RFC1323)は1992がそうするかもしれません。
[24] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[24] コーフマン、C.、エド、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、12月2005日
[25] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[25] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月。
[26] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
December 2005.
[26] ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
[27] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[27] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[28] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion
Control Protocol (DCCP)", RFC 4340, March 2006.
[28] コーラー、E.、ハンドレー、M.、およびS.フロイド、「データグラム混雑制御プロトコル(DCCP)」、RFC4340、2006年3月。
Touch Informational [Page 25] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[25ページ]のRFC4953の防御しているTCPに触れてください。
[29] Larsen, M., and F. Gont, "Port Randomization", Work in
Progress, February 2007.
2007年2月のラーセン、M.とF.Gont、「ポート無作為化」が進行中で扱う[29]。
[30] Leech, M., "Key Management Considerations for the TCP MD5
Signature Option", RFC 3562, July 2003.
[30] ヒル、M.、「TCP MD5署名オプションのためのKey Management問題」、RFC3562、2003年7月。
[31] Moore, D., G. Voelker, and S. Savage, "Inferring Internet
Denial-of-Service Activity", Proc. Usenix Security Symposium,
Aug. 2001.
[31] ムーアとD.、G.VoelkerとS.サヴェージ、「インターネットサービス妨害活動を推論します」、Proc。 2001年8月のUsenixセキュリティシンポジウム。
[32] O'Malley, S. and L. Peterson, "TCP Extensions Considered
Harmful", RFC 1263, October 1991.
[32] オマリーとS.とL.ピーターソン、「有害であると考えられたTCP拡張子」、RFC1263、1991年10月。
[33] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
1996.
[33] パーキンス、C.、「IPの中のIPカプセル化」、RFC2003、1996年10月。
[34] Poon, K., "Use of TCP timestamp option to defend against blind
spoofing attack", Work in Progress, October 2004.
[34] ヤラボ、K.、「盲目のスプーフィング攻撃に対して防御するTCPタイムスタンプオプションの使用」、Progress、2004年10月のWork。
[35] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[35] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[36] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", Work in Progress, July
2007.
[36] 「窓での盲目の攻撃にTCPの丈夫さを改良し」て、Ramaiah、A.、スチュワート、R.、およびM.Dalalは進歩、2007年7月に働いています。
[37] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border
Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[37] Rekhter、Y.(エド)、李、T.(エド)、およびS.野兎(エド)、「境界ゲートウェイは4(BGP-4)について議定書の中で述べます」、RFC4271、2006年1月。
[38] Semke, J., J. Mahdavi, and M. Mathis, "Automatic TCP Buffer
Tuning", ACM SIGCOMM '98/ Computer Communication Review, volume
28, number 4, Oct. 1998.
[38]SemkeとJ.、J.MahdaviとM.マシス、「自動TCPバッファチューニング」、ACM SIGCOMM98年/コンピュータCommunication Review、第28巻、No.4、1998年10月。
[39] Shepard, T., "Reassign Port Number option for TCP", Work in
Progress, July 2004.
[39] シェパード、T.、「TCPのためにPort Numberオプションを再選任してください」、Progress、2004年7月のWork。
[40] Shirey, R., "Internet Security Glossary, Version 2", Work in
Progress, November 2006.
[40]Shirey、「インターネットセキュリティ用語集、バージョン2インチは進歩、2006年11月に扱う」R.。
[41] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
Paxson, "Stream Control Transmission Protocol", RFC 2960,
October 2000.
[41] スチュワート、R.、シェ、Q.、K.の、そして、鋭いMorneault、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、および「ストリーム制御伝動プロトコル」、RFC2960(2000年10月)対パクソン
[42] TCPM: IETF TCPM Working Group and mailing list,
<http://www.ietf.org/html.charters/tcpm-charter.html>.
[42]TCPM: IETF TCPM作業部会とメーリングリスト、<http://www.ietf.org/html.charters/tcpm-charter.html>。
[43] Touch, J., "Report on MD5 Performance", RFC 1810, June 1995.
接触、J.が「MD5パフォーマンスに関して報告する」[43]、RFC1810、1995年6月。
Touch Informational [Page 26] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[26ページ]のRFC4953の防御しているTCPに触れてください。
[44] Touch, J., "Performance Analysis of MD5", Proc. Sigcomm 1995,
pp. 77-86, Mar. 1999.
[44] 接触、J.、「MD5"、Procの機能解析。」 Sigcomm1995、ページ 77-86と、1999年3月。
[45] Touch, J., "ANONsec: Anonymous Security to Defend Against
Spoofing Attacks", Work in Progress, May 2004.
[45] J.、触れてください、「ANONsec:」 「スプーフィング攻撃に対して防御する匿名のセキュリティ」は進歩、2004年5月に働いています。
[46] Touch, J., Black, D., and Y. Wang, "Problem and Applicability
Statement for Better Than Nothing Security (BTNS)", Work in
Progress, February 2007.
[46] 接触、J.、黒、D.、およびY.ワング、「ないよりましなセキュリティ(BTNS)のための問題と適用性証明」は進行中(2007年2月)で働いています。
[47] Touch, J. and A. Mankin, "The TCP Simple Authentication
Option", Work in Progress, July 2007.
[47] 「TCP簡易認証オプション」という接触、J.、およびA.マンキンは進歩、2007年7月に働いています。
[48] Watson, P., "Slipping in the Window: TCP Reset attacks",
Presentation at 2004 CanSecWest,
<http://cansecwest.com/csw04archive.html>.
[48] ワトソン、「窓で以下を滑らせる」P. 「TCP Reset攻撃」、2004CanSecWestのPresentation、<http://cansecwest.com/csw04archive.html>。
[49] Wood, L., Post to TCPM mailing list regarding use of ISN in
RSTs, ID=Pine.GSO.4.50.0404232249570.5889-
100000@argos.ee.surrey.ac.uk, Apr. 23, 2004,
<http://www1.ietf.org/mail-archive/web/tcpm/current/
msg00213.html>.
[49] 木、L.、RSTs、IDでのISNの使用に関するTCPMメーリングリストへのポストはPine.GSO.4.50.0404232249570.5889- 100000@argos.ee.surrey.ac.uk 、2004年4月23日、<メールhttp://www1.ietf.org/アーカイブ/ウェブ/tcpm/電流/msg00213.html>と等しいです。
Author's Addresses
作者のアドレス
Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 U.S.A.
ジョーTouch USC/ISI4676海軍本部Wayマリナデルレイ、カリフォルニア90292-6695米国
Phone: +1 (310) 448-9151 Fax: +1 (310) 448-9300 EMail: touch@isi.edu URI: http://www.isi.edu/touch
以下に電話をしてください。 +1 (310) 448-9151Fax: +1 (310) 448-9300 メールしてください: touch@isi.edu ユリ: http://www.isi.edu/touch
Touch Informational [Page 27] RFC 4953 Defending TCP Against Spoofing Attacks July 2007
2007年7月にスプーフィング攻撃に対して情報[27ページ]のRFC4953の防御しているTCPに触れてください。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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機能のための基金は現在、インターネット協会によって提供されます。
Touch Informational [Page 28]
接触情報です。[28ページ]
一覧
スポンサーリンク
