Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 6274 UK CPNI
Category: Informational July 2011
ISSN: 2070-1721
Security Assessment of the Internet Protocol Version 4
Abstract
抽象
This document contains a security assessment of the IETF specifications of the Internet Protocol version 4 and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI).
この文書は、インターネットプロトコルバージョン4の、人気のIPv4の実装で使用されているメカニズムとポリシーの数のIETF仕様のセキュリティ評価が含まれています。それは、国家インフラの保護のための英国のセンター（CPNI）で行われたプロジェクトの成果に基づいています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6274.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6274で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Preface .........................................................4
1.1. Introduction ...............................................4
1.2. Scope of This Document .....................................6
1.3. Organization of This Document ..............................7
2. The Internet Protocol ...........................................7
3. Internet Protocol Header Fields .................................8
3.1. Version ....................................................9
3.2. IHL (Internet Header Length) ..............................10
3.3. Type of Service (TOS) .....................................10
3.3.1. Original Interpretation ............................10
3.3.2. Standard Interpretation ............................12
3.3.2.1. Differentiated Services Field .............12
3.3.2.2. Explicit Congestion Notification (ECN) ....13
3.4. Total Length ..............................................14
3.5. Identification (ID) .......................................15
3.5.1. Some Workarounds Implemented by the Industry .......16
3.5.2. Possible Security Improvements .....................17
3.5.2.1. Connection-Oriented Transport Protocols ...17
3.5.2.2. Connectionless Transport Protocols ........18
3.6. Flags .....................................................19
3.7. Fragment Offset ...........................................21
3.8. Time to Live (TTL) ........................................22
3.8.1. Fingerprinting the Operating System in Use
by the Source Host .................................24
3.8.2. Fingerprinting the Physical Device from
which the Packets Originate ........................24
3.8.3. Mapping the Network Topology .......................24
3.8.4. Locating the Source Host in the Network Topology ...25
3.8.5. Evading Network Intrusion Detection Systems ........26
3.8.6. Improving the Security of Applications That
Make Use of the Internet Protocol (IP) .............27
3.8.7. Limiting Spread ....................................28
3.9. Protocol ..................................................28
3.10. Header Checksum ..........................................28
3.11. Source Address ...........................................29
3.12. Destination Address ......................................30
3.13. Options ..................................................30
3.13.1. General Issues with IP Options ....................31
3.13.1.1. Processing Requirements ..................31
3.13.1.2. Processing of the Options by the
Upper-Layer Protocol .....................32
3.13.1.3. General Sanity Checks on IP Options ......32
3.13.2. Issues with Specific Options ......................34
3.13.2.1. End of Option List (Type=0) ..............34
3.13.2.2. No Operation (Type=1) ....................34
3.13.2.3. Loose Source and Record Route
(LSRR) (Type=131) ........................34
3.13.2.4. Strict Source and Record Route
(SSRR) (Type=137) ........................37
3.13.2.5. Record Route (Type=7) ....................39
3.13.2.6. Stream Identifier (Type=136) .............40
3.13.2.7. Internet Timestamp (Type=68) .............40
3.13.2.8. Router Alert (Type=148) ..................43
3.13.2.9. Probe MTU (Type=11) (Obsolete) ...........44
3.13.2.10. Reply MTU (Type=12) (Obsolete) ..........44
3.13.2.11. Traceroute (Type=82) ....................44
3.13.2.12. Department of Defense (DoD)
Basic Security Option (Type=130) ........45
3.13.2.13. DoD Extended Security Option
(Type=133) ..............................46
3.13.2.14. Commercial IP Security Option
(CIPSO) (Type=134) ......................47
3.13.2.15. Sender Directed
Multi-Destination Delivery (Type=149) ...47
4. Internet Protocol Mechanisms ...................................48
4.1. Fragment Reassembly .......................................48
4.1.1. Security Implications of Fragment Reassembly .......49
4.1.1.1. Problems Related to Memory Allocation .....49
4.1.1.2. Problems That Arise from the
Length of the IP Identification Field .....51
4.1.1.3. Problems That Arise from the
Complexity of the Reassembly Algorithm ....52
4.1.1.4. Problems That Arise from the
Ambiguity of the Reassembly Process .......52
4.1.1.5. Problems That Arise from the Size
of the IP Fragments .......................53
4.1.2. Possible Security Improvements .....................53
4.1.2.1. Memory Allocation for Fragment
Reassembly ................................53
4.1.2.2. Flushing the Fragment Buffer ..............54
4.1.2.3. A More Selective Fragment Buffer
Flushing Strategy .........................55
4.1.2.4. Reducing the Fragment Timeout .............57
4.1.2.5. Countermeasure for Some NIDS
Evasion Techniques ........................58
4.1.2.6. Countermeasure for Firewall-Rules
Bypassing .................................58
4.2. Forwarding ................................................58
4.2.1. Precedence-Ordered Queue Service ...................58
4.2.2. Weak Type of Service ...............................59
4.2.3. Impact of Address Resolution on Buffer Management ..60
4.2.4. Dropping Packets ...................................61
4.3. Addressing ................................................61
4.3.1. Unreachable Addresses ..............................61
4.3.2. Private Address Space ..............................61
4.3.3. Former Class D Addresses (224/4 Address Block) .....62
4.3.4. Former Class E Addresses (240/4 Address Block) .....62
4.3.5. Broadcast/Multicast Addresses and
Connection-Oriented Protocols ......................62
4.3.6. Broadcast and Network Addresses ....................63
4.3.7. Special Internet Addresses .........................63
5. Security Considerations ........................................65
6. Acknowledgements ...............................................65
7. References .....................................................66
7.1. Normative References ......................................66
7.2. Informative References ....................................68
The TCP/IP protocols were conceived in an environment that was quite different from the hostile environment in which they currently operate. However, the effectiveness of the protocols led to their early adoption in production environments, to the point that, to some extent, the current world's economy depends on them.
TCP / IPプロトコルは、彼らが現在営業している敵対的な環境とは全く異なっていた環境の中で考案されました。しかし、プロトコルの有効性はある程度、現在の世界経済は、それらに依存して、ポイントに、本番環境での早期採択につながりました。
While many textbooks and articles have created the myth that the Internet protocols were designed for warfare environments, the top level goal for the Defense Advanced Research Projects Agency (DARPA) Internet Program was the sharing of large service machines on the ARPANET [Clark1988]. As a result, many protocol specifications focus only on the operational aspects of the protocols they specify and overlook their security implications.
多くの教科書や論文は、インターネット・プロトコルは、戦争の環境向けに設計された神話を作成しているが、米国防総省の国防高等研究計画庁（DARPA）のインターネットプログラムのトップレベルの目標は、[Clark1988] ARPANET上の大きなサービス・マシンの共有でした。その結果、多くのプロトコル仕様は、彼らがセキュリティへの影響を指定し、見落とすプロトコルの運用面にのみ焦点を当てます。
While the Internet technology evolved since its inception, the Internet's building blocks are basically the same core protocols adopted by the ARPANET more than two decades ago. During the last twenty years, many vulnerabilities have been identified in the TCP/IP stacks of a number of systems. Some of them were based on flaws in some protocol implementations, affecting only a reduced number of systems, while others were based on flaws in the protocols themselves, affecting virtually every existing implementation [Bellovin1989]. Even in the last couple of years, researchers were still working on security problems in the core protocols [RFC5927] [Watson2004] [NISCC2004] [NISCC2005].
インターネット技術は、創業以来、進化している間、インターネットのビルディングブロックは、基本的には、二十年以上前にARPANETで採択された同じコアプロトコルです。過去20年の間、多くの脆弱性は、システムの数のTCP / IPスタックで同定されています。そのうちのいくつかは他は、ほぼすべての既存の実装[Bellovin1989]に影響を与え、プロトコルそのものの欠陥に基づいていた一方で、システムの唯一の減少数に影響を与え、いくつかのプロトコル実装の欠陥に基づいていました。でも、ここ数年で、研究者たちは、まだコアプロトコル[RFC5927] [Watson2004] [NISCC2004] [NISCC2005]におけるセキュリティ上の問題に取り組んでいました。
The discovery of vulnerabilities in the TCP/IP protocols led to reports being published by a number of CSIRTs (Computer Security Incident Response Teams) and vendors, which helped to raise awareness about the threats and the best mitigations known at the time the reports were published. Unfortunately, this also led to the documentation of the discovered protocol vulnerabilities being spread among a large number of documents, which are sometimes difficult to identify.
レポートにつながったTCP / IPプロトコルの脆弱性の発見は、報告書が公表された時点で既知の脅威と最高の緩和策についての意識を高めるために助けたのCSIRT（コンピュータセキュリティインシデント対応チーム）とベンダーの数、によって公開されています。残念ながら、これはまた、時には特定することが困難な文書、多数の間で拡散され発見されたプロトコルの脆弱性の文書化につながりました。
For some reason, much of the effort of the security community on the Internet protocols did not result in official documents (RFCs) being issued by the IETF (Internet Engineering Task Force). This basically led to a situation in which "known" security problems have not always been addressed by all vendors. In addition, in many cases, vendors have implemented quick "fixes" to protocol flaws without a careful analysis of their effectiveness and their impact on interoperability [Silbersack2005].
何らかの理由で、インターネット・プロトコル上のセキュリティコミュニティの努力の多くは、IETF（Internet Engineering Task Force）によって発行された公式文書（のRFC）にはなりませんでした。これは、基本的には「既知」のセキュリティ問題は、常にすべてのベンダーによって対処されていない状況に至りました。また、多くの場合、ベンダーはその有効性と[Silbersack2005]相互運用性への影響を慎重に分析することなく、プロトコル上の欠陥への迅速な「修正」を実施しています。
The lack of adoption of these fixes by the IETF means that any system built in the future according to the official TCP/IP specifications will reincarnate security flaws that have already hit our communication systems in the past.
IETFによってこれらの修正プログラムの採用の欠如は、公式のTCP / IPの仕様に応じて、将来的に構築された任意のシステムは、すでに過去に当社の通信システムを直撃しているセキュリティ上の欠陥を転生することを意味します。
Nowadays, producing a secure TCP/IP implementation is a very difficult task, in part because of the lack of a single document that serves as a security roadmap for the protocols. Implementers are faced with the hard task of identifying relevant documentation and differentiating between that which provides correct advisory and that which provides misleading advisory based on inaccurate or wrong assumptions.
今日では、安全なTCP / IPの実装を生成することためのプロトコルのためのセキュリティのロードマップとしての役割を果たす単一のドキュメントの不足の一部で、非常に困難な作業です。実装者は、関連する文書を特定し、正しい助言を提供することと、不正確または間違った仮定に基づいて、誤解を招くような助言を提供することとを区別の困難な課題に直面しています。
There is a clear need for a companion document to the IETF specifications; one that discusses the security aspects and implications of the protocols, identifies the possible threats, discusses the possible countermeasures, and analyzes their respective effectiveness.
IETF仕様にコンパニオン文書が明らかに必要です。 、プロトコルのセキュリティの側面と意味を説明し脅威の可能性を特定し、可能な対応策について説明し、それぞれの有効性を分析する1。
This document is the result of an assessment of the IETF specifications of the Internet Protocol version 4 (IPv4), from a security point of view. Possible threats were identified and, where possible, countermeasures were proposed. Additionally, many implementation flaws that have led to security vulnerabilities have been referenced in the hope that future implementations will not incur the same problems. Furthermore, this document does not limit itself to performing a security assessment of the relevant IETF specifications, but also provides an assessment of common implementation strategies found in the real world.
この文書では、セキュリティの観点から、インターネットプロトコルバージョン4（IPv4）のIETF仕様の評価の結果です。脅威の可能性を同定し、可能な場合、対応策が提案されました。また、セキュリティの脆弱性につながっている多くの実装上の欠陥は、将来の実装が同じ問題が発生しないことを期待して参照されています。さらに、このドキュメントは、関連するIETF仕様のセキュリティアセスメントを実行に自分自身を制限するものではありませんが、また、現実の世界で見られる一般的な実装戦略の評価を提供します。
Many IP implementations have also been subject of the so-called "packet-of-death" vulnerabilities, in which a single specially crafted packet causes the IP implementation to crash or otherwise misbehave. In most cases, the attack packet is simply malformed; in other cases, the attack packet is well-formed, but exercises a little used path through the IP stack. Well-designed IP implementations should protect against these attacks, and therefore this document describes a number of sanity checks that are expected to prevent most of the aforementioned "packet-of-death" attack vectors. We note that if an IP implementation is found to be vulnerable to one of these attacks, administrators must resort to mitigating them by packet filtering.
多くのIPの実装は、単一の特別に細工されたパケットは、IPの実装がクラッシュまたはその他の不正な動作をする原因とする、いわゆる「パケットの死」の脆弱性の対象となっています。ほとんどの場合、攻撃パケットは、単純に不正な形式です。他の例では、攻撃パケットは、十分に形成されているが、IPスタックを介して、ほとんど使用されるパスを行使する。うまく設計されたIPの実装は、これらの攻撃から保護する必要があり、そのため、この文書は、前述の「パケットの死」攻撃ベクトルのほとんどを防ぐことが予想される健全性チェックの数を示します。私たちは、IPの実装は、これらの攻撃の1に対して脆弱であることが判明した場合、管理者は、パケットフィルタリングによってそれらの緩和に頼らなければならないことに注意してください。
Additionally, this document analyzes the security implications from changes in the operational environment since the Internet Protocol was designed. For example, it analyzes how the Internet Protocol could be exploited to evade Network Intrusion Detection Systems (NIDSs) or to circumvent firewalls.
インターネットプロトコルを設計したので、また、この文書は、運用環境の変化から、セキュリティへの影響を分析します。例えば、それは、インターネットプロトコルはネットワーク侵入検知システム（NIDSs）を回避したり、ファイアウォールを回避するために悪用される可能性がどのように分析します。
This document does not aim to be the final word on the security of the Internet Protocol (IP). On the contrary, it aims to raise awareness about many security threats based on the IP protocol that have been faced in the past, those that we are currently facing, and those we may still have to deal with in the future. It provides advice for the secure implementation of the Internet Protocol (IP), but also provides insights about the security aspects of the Internet Protocol that may be of help to the Internet operations community.
この文書は、インターネットプロトコル（IP）のセキュリティ上の最後の言葉であることを目的としていません。逆に、それはこれらの私たちが現在直面している、そしてそれらの私たちはまだ将来的に対処しなければならないかもしれない、過去に直面されているIPプロトコルに基づいて、多くのセキュリティ上の脅威に関する意識を高めることを目指しています。これは、インターネット・プロトコル（IP）の安全な実施のためのアドバイスを提供するだけでなく、インターネットの運用コミュニティに助けになるかもしれインターネットプロトコルのセキュリティの側面についての洞察を提供します。
Feedback from the community is more than encouraged to help this document be as accurate as possible and to keep it updated as new threats are discovered.
コミュニティからのフィードバックは、この文書は、可能な限り正確であることを助けるために、新たな脅威が発見されるとそれが更新さを維持することが推奨以上です。
This document is heavily based on the "Security Assessment of the Internet Protocol" [CPNI2008] released by the UK Centre for the Protection of National Infrastructure (CPNI), available at http://www.cpni.gov.uk/Products/technicalnotes/3677.aspx.
この文書は大きく[CPNI2008] http://www.cpni.gov.uk/Products/technicalnotesで入手可能な国家インフラ（CPNI）の保護、英国センターが発表し、「インターネットプロトコルのセキュリティ評価」に基づいています/3677.aspx。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
While there are a number of protocols that affect the way in which IP systems operate, this document focuses only on the specifications of the Internet Protocol (IP). For example, routing and bootstrapping protocols are considered out of the scope of this project.
IPシステムが動作する方法に影響を与えるプロトコルの数がありますが、このドキュメントでは、インターネットプロトコル（IP）の仕様に焦点を当てています。例えば、ルーティング及びブートストラッププロトコルは、このプロジェクトの範囲外であると考えられます。
The following IETF RFCs were selected as the primary sources for the assessment as part of this work: o RFC 791, "INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION" (45 pages).
次のIETFのRFCは、この作業の一部として評価するための主要な源として選択した：RFC 791、「インターネットプロトコルDARPAインターネットプログラムプロトコル仕様」（45ページ）O。
o RFC 815, "IP DATAGRAM REASSEMBLY ALGORITHMS" (9 pages).
O RFC 815、 "IPデータグラム再組み立て要素アルゴリズム"（9ページ）。
o RFC 919, "BROADCASTING INTERNET DATAGRAMS" (8 pages).
O RFC 919、 "放送インターネットデータグラム"（8ページ）。
o RFC 950, "Internet Standard Subnetting Procedure" (18 pages)
O RFC 950、 "インターネット標準のサブネッティング手順"（18ページ）
o RFC 1112, "Host Extensions for IP Multicasting" (17 pages)
O RFC 1112、 "IPマルチキャスティングのためのホスト拡大"（17ページ）
o RFC 1122, "Requirements for Internet Hosts -- Communication Layers" (116 pages).
OのRFC 1122、 "インターネットホストのための要件 - 通信層"（116ページ）。
o RFC 1812, "Requirements for IP Version 4 Routers" (175 pages).
O RFC 1812、 "IPバージョン4つのルータのための要件"（175ページ）。
o RFC 2474, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers" (20 pages).
OのRFC 2474、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"（20ページ）。
o RFC 2475, "An Architecture for Differentiated Services" (36 pages).
OのRFC 2475、 "差別化サービスのためのアーキテクチャ"（36ページ）。
o RFC 3168, "The Addition of Explicit Congestion Notification (ECN) to IP" (63 pages).
OのRFC 3168、 "IPへの明示的輻輳通知（ECN）の追加"（63ページ）。
o RFC 4632, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan" (27 pages).
O RFC 4632、「クラスレスドメイン間ルーティング（CIDR）：インターネットアドレスの割り当てと集約計画」（27ページ）。
This document is basically organized in two parts: "Internet Protocol header fields" and "Internet Protocol mechanisms". The former contains an analysis of each of the fields of the Internet Protocol header, identifies their security implications, and discusses possible countermeasures for the identified threats. The latter contains an analysis of the security implications of the mechanisms implemented by the Internet Protocol.
「インターネットプロトコルヘッダフィールド」および「インターネットプロトコルメカニズム」：このドキュメントは、基本的に2つの部分で構成されています。前者は、インターネットプロトコルヘッダの各フィールドの分析が含まれている、彼らのセキュリティへの影響を識別し、識別された脅威の可能な対策を説明します。後者は、インターネットプロトコルにより実装機構のセキュリティへの影響の分析を含んでいます。
The Internet Protocol (IP) provides a basic data transfer function for passing data blocks called "datagrams" from a source host to a destination host, across the possible intervening networks. Additionally, it provides some functions that are useful for the interconnection of heterogeneous networks, such as fragmentation and reassembly.
インターネット・プロトコル（IP）が可能介在ネットワーク間で、宛先ホストに送信元ホストから「データグラム」と呼ばれるデータブロックを渡すための基本的なデータ転送機能を提供します。また、このような断片化および再組立てのように、異種ネットワークの相互接続のために有用であるいくつかの機能を提供します。
The "datagram" has a number of characteristics that makes it convenient for interconnecting systems [Clark1988]:
「データグラム」は、[Clark1988]システムを相互接続することが便利になり多くの特性を有します。
o It eliminates the need of connection state within the network, which improves the survivability characteristics of the network.
Oこれは、ネットワークの生存性が向上し、ネットワーク内の接続状態の必要がなくなります。
o It provides a basic service of data transport that can be used as a building block for other transport services (reliable data transport services, etc.).
Oこれは、他の輸送サービス（信頼性の高いデータ・トランスポート・サービスなど）のためのビルディングブロックとして使用することができ、データ転送の基本的なサービスを提供しています。
o It represents the minimum network service assumption, which enables IP to be run over virtually any network technology.
OそれはIPを有効に最小ネットワークサービス仮定は、事実上すべてのネットワーク技術の上で実行されるように表しています。
The IETF specifications of the Internet Protocol define the syntax of the protocol header, along with the semantics of each of its fields. Figure 1 shows the format of an IP datagram, as specified in [RFC0791].
インターネットプロトコルのIETF仕様は、各フィールドの意味論と共に、プロトコルヘッダの構文を定義します。 [RFC0791]で指定されるように図1は、IPデータグラムのフォーマットを示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [ Options ] | [ Padding ] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Internet Protocol Header Format
図1：インターネットプロトコルヘッダー形式
Even though the minimum IP header size is 20 bytes, an IP module might be handed an (illegitimate) "datagram" of less than 20 bytes. Therefore, before doing any processing of the IP header fields, the following check should be performed by the IP module on the packets handed by the link layer:
最小のIPヘッダサイズは20バイトであっても、IPモジュールは、20バイト未満の（不正な）「データグラム」を渡されるかもしれません。したがって、IPヘッダフィールドのいずれかの処理を実行する前に、次のチェックは、リンク層によって渡さパケット上のIPモジュールによって実行されるべきです。
LinkLayer.PayloadSize >= 20
LinkLayer.PayloadSize> = 20
where LinkLayer.PayloadSize is the length (in octets) of the datagram passed from the link layer to the IP layer.
LinkLayer.PayloadSizeはIPレイヤにリンク層から渡されたデータグラムの（オクテット）長さです。
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented reflecting the packet drop).
パケットがこのチェックに合格しない場合、それは廃棄されるべきであり、このイベントが記録されるべきである（例えば、カウンタは、パケット損失を反映してインクリメントすることができます）。
The following subsections contain further sanity checks that should be performed on IP packets.
以下のサブセクションでは、IPパケットで実行する必要があり、さらに健全性チェックが含まれています。
This is a 4-bit field that indicates the version of the Internet Protocol (IP), and thus the syntax of the packet. For IPv4, this field must be 4.
これにより、インターネットプロトコル（IP）のバージョン、およびパケットのシンタックスを示す4ビットのフィールドです。 IPv4の場合、このフィールドは4でなければなりません。
When a link-layer protocol de-multiplexes a packet to an Internet module, it does so based on a Protocol Type field in the data-link packet header.
リンク層プロトコル逆多重化インターネットモジュールにパケットが、それがそうデータリンクパケットヘッダ内のプロトコルタイプフィールドに基づいてない場合。
In theory, different versions of IP could coexist on a network by using the same Protocol Type at the link layer, but a different value in the Version field of the IP header. Thus, a single IP module could handle all versions of the Internet Protocol, differentiating them by means of this field.
理論的には、IPの異なるバージョンは、リンク層で同一のプロトコルタイプを使用して、ネットワーク上で共存できるが、IPヘッダのバージョンフィールドの異なる値。このように、単一のIPモジュールは、このフィールドによって、それらを区別する、インターネット・プロトコルのすべてのバージョンを扱うことができます。
However, in practice different versions of IP are identified by a different Protocol Type (e.g., EtherType in the case of Ethernet) number in the link-layer protocol header. For example, IPv4 datagrams are encapsulated in Ethernet frames using an EtherType of 0x0800, while IPv6 datagrams are encapsulated in Ethernet frames using an EtherType of 0x86DD [IANA_ET].
しかし、実際にはIPの異なるバージョンは、異なるプロトコルタイプ（イーサネットの場合には、例えば、イーサタイプ）リンク層プロトコルのヘッダ内の番号によって識別されます。 IPv6データグラムが[IANA_ET] 0x86DDのイーサタイプを使用して、イーサネットフレーム内にカプセル化されている間、例えば、IPv4のデータグラムは、0x0800でのイーサタイプを使用して、イーサネットフレーム内にカプセル化されています。
Therefore, if an IPv4 module receives a packet, the Version field must be checked to be 4. If this check fails, the packet should be silently dropped, and this event should be logged (e.g., a counter could be incremented reflecting the packet drop). If an implementation does not perform this check, an attacker could use a different value for the Version field, possibly evading NIDSs that decide which pattern-matching rules to apply based on the Version field.
したがって、IPv4のモジュールは、パケットを受信した場合は、このチェックが失敗した場合は、バージョン・フィールドは4であることを確認しなければならない、（例えば、パケットは黙って落とされるべき、とこのイベントがログに記録されなければならない、カウンタは、パケットドロップを反映してインクリメントすることができ）。実装は、このチェックを実行しない場合、攻撃者は、パターンマッチングのルールは、バージョンフィールドに基づいて適用するかを決めることおそらくNIDSsを回避、バージョンフィールドに異なる値を使用することができます。
If the link-layer protocol employs a specific "Protocol Type" value for encapsulating IPv4 packets (e.g., as is the case of Ethernet), a node should check that IPv4 packets are de-multiplexed to the IPv4 module when such value was used for the Protocol Type field of the link-layer protocol. If a packet does not pass this check, it should be silently dropped.
リンク層プロトコル（イーサネットの場合のように、例えば）IPv4パケットをカプセル化するための特定の「プロトコルタイプ」値を採用した場合、そのような値のために使用した場合、ノードは、IPv4パケットは、IPv4モジュールに逆多重化されていることを確認する必要がありますリンク層プロトコルのプロトコルタイプフィールド。パケットは、このチェックに合格しない場合、それは静かに落とされなければなりません。
An attacker could encapsulate IPv4 packets using other link-layer "Protocol Type" values to try to subvert link-layer Access Control Lists (ACLs) and/or for tampering with NIDSs.
攻撃者は、および/またはNIDSs改ざんのためのリンク層のアクセス制御リスト（ACL）を破壊しようとする他のリンク層「プロトコルタイプ」の値を使用してIPv4パケットをカプセル化することができます。
The IHL (Internet Header Length) field indicates the length of the Internet header in 32-bit words (4 bytes). The following paragraphs describe a number of sanity checks to be performed on the IHL field, such that possible packet-of-death vulnerabilities are avoided.
IHL（インターネットヘッダ長）フィールドは、32ビット・ワード（4バイト）のインターネットヘッダの長さを示します。次の段落では、正気の数が可能なパケットの死の脆弱性が回避されるように、IHLフィールド上で実行されるチェックについて説明します。
As the minimum datagram size is 20 bytes, the minimum legal value for this field is 5. Therefore, the following check should be enforced:
最小データグラムサイズは20バイトで、このフィールドの最小正当な値であるように、以下のチェックが実施されるべきで、そのため5です。
IHL >= 5
IHL> = 5
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented reflecting the packet drop).
パケットがこのチェックに合格しない場合、それは廃棄されるべきであり、このイベントが記録されるべきである（例えば、カウンタは、パケット損失を反映してインクリメントすることができます）。
For obvious reasons, the Internet header cannot be larger than the whole Internet datagram of which it is part. Therefore, the following check should be enforced:
明白な理由のために、インターネットヘッダは、それが一部である全体のインターネットデータグラムよりも大きくすることができません。そのため、以下のチェックが強制される必要があります。
IHL * 4 <= Total Length
IHL * 4 <=全長
This needs to refer to the size of the datagram as specified by the sender in the Total Length field, since link layers might have added some padding (see Section 3.4).
これは、リンク層は（セクション3.4を参照）、いくつかのパディングを追加している可能性があるため、全長フィールドに送信者によって指定されたデータグラムのサイズを参照する必要があります。
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented reflecting the packet drop).
パケットがこのチェックに合格しない場合、それは廃棄されるべきであり、このイベントが記録されるべきである（例えば、カウンタは、パケット損失を反映してインクリメントすることができます）。
The above check allows for Internet datagrams with no data bytes in the payload that, while nonsensical for virtually every protocol that runs over IP, are still legal.
上記のチェックはIP上で動作ほぼすべてのプロトコルのための無意味ながら、まだ法的です、ペイロード内のデータバイトとインターネットデータグラムが可能になります。
Figure 2 shows the original syntax of the Type of Service field, as defined by RFC 791 [RFC0791] and updated by RFC 1349 [RFC1349]. This definition has been superseded long ago (see Sections 3.3.2.1 and 3.3.2.2), but it is still assumed by some deployed implementations.
RFC 791 [RFC0791]で定義され、RFC 1349 [RFC1349]によって更新されるよう図2は、サービスフィールドのタイプの元の構文を示しています。この定義は、（セクション3.3.2.1と3.3.2.2を参照）ずっと前に取って代わられましたが、それはまだいくつかの展開の実装が想定されます。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | D | T | R | C | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 2: Type of Service Field (Original Interpretation)
図2：サービスフィールドのタイプ（オリジナルの解釈）
+----------+----------------------------------------------+
| Bits 0-2 | Precedence |
+----------+----------------------------------------------+
| Bit 3 | 0 = Normal Delay, 1 = Low Delay |
+----------+----------------------------------------------+
| Bit 4 | 0 = Normal Throughput, 1 = High Throughput |
+----------+----------------------------------------------+
| Bit 5 | 0 = Normal Reliability, 1 = High Reliability |
+----------+----------------------------------------------+
| Bit 6 | 0 = Normal Cost, 1 = Minimize Monetary Cost |
+----------+----------------------------------------------+
| Bits 7 | Reserved for Future Use (must be zero) |
+----------+----------------------------------------------+
Table 1: Semantics of the TOS Bits
表1：TOSビットのセマンティクス
+-----+-----------------+
| 111 | Network Control |
+-----+-----------------+
| 110 | Internetwork |
+-----+-----------------+
| 101 | CRITIC/ECP |
+-----+-----------------+
| 100 | Flash Override |
+-----+-----------------+
| 011 | Flash |
+-----+-----------------+
| 010 | Immediate |
+-----+-----------------+
| 001 | Priority |
+-----+-----------------+
| 000 | Routine |
+-----+-----------------+
Table 2: Semantics of the Possible Precedence Field Values
表2：使用可能な優先順位フィールド値のセマンティクス
The Type of Service field can be used to affect the way in which the packet is treated by the systems of a network that process it. Section 4.2.1 ("Precedence-Ordered Queue Service") and Section 4.2.2
サービスフィールドのタイプは、パケットがそれを処理するネットワークのシステムによって処理される方法に影響を与えるために使用することができます。 4.2.1項（「優先順序キューサービス」）および4.2.2項
("Weak Type of Service") of this document describe the security implications of the Type of Service field in the forwarding of packets.
このドキュメントの（「サービスの弱いタイプ」）は、パケットの転送にサービスフィールドのタイプのセキュリティへの影響について説明します。
The Differentiated Services Architecture is intended to enable scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop [RFC2475]. RFC 2474 [RFC2474] redefined the IP "Type of Service" octet, introducing a Differentiated Services Field (DS Field). Figure 3 shows the format of the field.
差別化サービスアーキテクチャは、すべてのホップ[RFC2475]でのフローごとの状態とシグナリングを必要とせずに、インターネットにおけるスケーラブルなサービスの差別を有効にすることを意図しています。 RFC 2474 [RFC2474]は差別化されたサービス分野（DSフィールド）を導入、オクテットIP「サービスの種類」を再定義しました。図3は、フィールドのフォーマットを示しています。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| DSCP | CU |
+---+---+---+---+---+---+---+---+
Figure 3: Revised Structure of the Type of Service Field (RFC 2474)
図3：サービスフィールドのタイプの改訂構造（RFC 2474）
The DSCP ("Differentiated Services CodePoint") is used to select the treatment the packet is to receive within the Differentiated Services Domain. The CU ("Currently Unused") field was, at the time the specification was issued, reserved for future use. The DSCP field is used to select a PHB (Per-Hop Behavior), by matching against the entire 6-bit field.
DSCP（「差別化サービスコードポイント」）は、パケットが差別化サービスドメイン内で受信することで、治療を選択するために使用されます。 CU（「現在未使用」）フィールドは、仕様は将来の使用のために予約、発行された時点で、でした。 DSCPフィールドは、全体の6ビットのフィールドに対して照合することによって、PHB（ホップ単位動作）を選択するために使用されます。
Considering that the DSCP field determines how a packet is treated within a Differentiated Services (DS) domain, an attacker could send packets with a forged DSCP field to perform a theft of service or even a Denial-of-Service (DoS) attack. In particular, an attacker could forge packets with a codepoint of the type '11x000' which, according to Section 4.2.2.2 of RFC 2474 [RFC2474], would give the packets preferential forwarding treatment when compared with the PHB selected by the codepoint '000000'. If strict priority queuing were utilized, a continuous stream of such packets could cause a DoS to other flows that have a DSCP of lower relative order.
DSCPフィールドは、パケットが差別化サービス（DS）ドメイン内で扱われる方法を決定することを考慮すると、攻撃者は、サービスの盗難、あるいはサービス拒否（DoS）攻撃を実行するために偽造DSCPフィールドを持つパケットを送信することができます。具体的には、攻撃者がコードポイント「000000によって選択されたPHBと比較した場合、RFC 2474 [RFC2474]のセクション4.2.2.2によれば、パケットを優先転送処理を与えるであろう、「11x000」タイプのコードポイントでパケットを偽造することができ」。完全優先キューイングを使用した場合、そのようなパケットの連続ストリームは、より低い相対的な順序のDSCPを持つ他のフローにDoS攻撃を引き起こす可能性があります。
As the DS field is incompatible with the original Type of Service field, both DS domains and networks using the original Type of Service field should protect themselves by remarking the corresponding field where appropriate, probably deploying remarking boundary nodes. Nevertheless, care must be taken so that packets received with an unrecognized DSCP do not cause the handling system to malfunction.
DSフィールドは、サービスフィールドの元の型と適合しない場合、サービスフィールドの元の型を使用して、両方のDSドメインおよびネットワークは、おそらく境界ノードを再マーキング展開、適切な場合に対応するフィールドをリマークすることによって自分自身を保護しなければなりません。認識されていないDSCPで受信したパケットは、故障にハンドリングシステムを起こさないようにもかかわらず、注意しなければなりません。
RFC 3168 [RFC3168] specifies a mechanism for routers to signal congestion to hosts exchanging IP packets, by marking the offending packets rather than discarding them. RFC 3168 defines the ECN field, which utilizes the CU field defined in RFC 2474 [RFC2474]. Figure 4 shows the current syntax of the IP Type of Service field, with the DSCP field used for Differentiated Services and the ECN field.
RFC 3168 [RFC3168]は、問題のパケットをマーキングではなく、それらを廃棄することによって、IPパケットを交換するホストに輻輳をシグナリングするルータのための機構を指定します。 RFC 3168は、RFC 2474 [RFC2474]で定義されたCUのフィールドを利用ECNフィールドを定義します。図4は、差別化サービスとECNフィールドに使用されるDSCPフィールドで、サービス分野のIPタイプの現在の構文を示しています。
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DS FIELD, DSCP | ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 4: The Differentiated Services and ECN Fields in IP
図4：IPとの差別化されたサービスとECNフィールド
As such, the ECN field defines four codepoints:
このように、ECNフィールドは、4つのコードポイントを定義します。
+-----------+-----------+
| ECN field | Codepoint |
+-----------+-----------+
| 00 | Not-ECT |
+-----------+-----------+
| 01 | ECT(1) |
+-----------+-----------+
| 10 | ECT(0) |
+-----------+-----------+
| 11 | CE |
+-----------+-----------+
Table 3: ECN Codepoints
表3：ECNコードポイント
ECN is an end-to-end transport protocol mechanism based on notifications by routers through which a packet flow passes. To allow this interaction to happen on the fast path of routers, the ECN field is located at a fixed location in the IP header. However, its use must be negotiated at the transport layer, and the accumulated congestion notifications must be communicated back to the sending node using transport protocol means. Thus, ECN support must be specified per transport protocol.
ECNは、パケットフローが通過するルータによって通知に基づいて、エンド・ツー・エンドのトランスポート・プロトコル機構です。この相互作用は、ルータの高速経路で発生できるように、ECNフィールドは、IPヘッダ内の固定位置に配置されています。しかし、その使用はトランスポート層でネゴシエートされなければならない、と累積輻輳通知は、トランスポートプロトコルの手段を使用して送信ノードに返送されなければなりません。このように、ECNのサポートは、トランスポートプロトコルごとに指定する必要があります。
[RFC6040] specifies how the Explicit Congestion Notification (ECN) field of the IP header should be constructed on entry to and exit from any IP-in-IP tunnel.
[RFC6040]はIPヘッダーの明示的輻輳通知（ECN）フィールドは、任意のIPインIPトンネルからの入退室に構成されるべき方法を指定します。
The security implications of ECN are discussed in detail in a number of Sections of RFC 3168. Of the possible threats discussed in the ECN specification, we believe that one that can be easily exploited is that of a host falsely indicating ECN-Capability.
ECNのセキュリティへの影響がECN仕様で説明可能な脅威のRFC 3168.のセクションの数で詳しく説明されている、我々は簡単に悪用される可能性があります1つは、ホストの誤っECN-能力を示すことであると信じています。
An attacker could set the ECT codepoint in the packets it sends, to signal the network that the endpoints of the transport protocol are ECN-capable. Consequently, when experiencing moderate congestion, routers using active queue management based on Random Early Detection (RED) would mark the packets (with the CE codepoint) rather than discard them. In this same scenario, packets of competing flows that do not have the ECT codepoint set would be dropped. Therefore, an attacker would get better network service than the competing flows.
攻撃者は、トランスポートプロトコルのエンドポイントがECN-可能なネットワークを知らせるために、それが送信するパケットにECTコードポイントを設定することができました。その結果、（CEコードポイントを持つ）パケットをマークではなく、それらを捨てるだろう適度な混雑、ランダム早期検出（RED）に基づいて、アクティブキュー管理を使用してルータを経験したとき。この同じシナリオでは、ECTコードポイントが設定されていないフローを、競合のパケットはドロップされます。そのため、攻撃者が競合するフローよりも優れたネットワークサービスになるだろう。
However, if this moderate congestion turned into heavy congestion, routers should switch to drop packets, regardless of whether or not the packets have the ECT codepoint set.
この適度な混雑が混雑になっている場合しかし、ルータは関係なく、パケットがECTコードポイントが設定されているかどうかの、パケットをドロップするように切り替える必要があります。
A number of other threats could arise if an attacker was a man in the middle (i.e., was in the middle of the path the packets travel to get to the destination host). For a detailed discussion of those cases, we urge the reader to consult Section 16 of RFC 3168.
攻撃者は中間者（すなわち、パケットが宛先ホストに到達するために移動する経路の途中にあった）であった場合は、他の脅威の数が発生する可能性があります。これらの例詳細な議論のために、我々は、RFC 3168のセクション16に相談する読者を促します。
There is also ongoing work in the research community and the IETF to define alternate semantics for the CU/ECN field of IP TOS octet (see [RFC5559], [RFC5670], and [RFC5696]). The application of these methods must be confined to tightly administered domains, and on exit from such domains, all packets need to be (re-)marked with ECN semantics.
現在進行中の研究コミュニティでの作業やIP TOSオクテットのCU / ECNフィールドの代わりの意味を定義するIETFは、（[RFC5559]、[RFC5670]、および[RFC5696]を参照）もあります。これらの方法の適用は、しっかり投与ドメインに制限されなければならない、そのようなドメインからの出口に、すべてのパケットが（再）ECNセマンティクスでマークする必要があります。
The Total Length field is the length of the datagram, measured in bytes, including both the IP header and the IP payload. Being a 16-bit field, it allows for datagrams of up to 65535 bytes. RFC 791 [RFC0791] states that all hosts should be prepared to receive datagrams of up to 576 bytes (whether they arrive as a whole, or in fragments). However, most modern implementations can reassemble datagrams of at least 9 Kbytes.
全長フィールドは、IPヘッダとIPペイロードの両方を含む、バイト単位で測定され、データグラムの長さです。 16ビットのフィールドであること、それは65535バイトまでのデータグラムすることができます。 RFC 791 [RFC0791]は、すべてのホストは、最大576バイト（これらは、全体として、またはその断片に到着するかどうか）のデータグラムを受信するために用意されるべきであると述べています。しかし、最も近代的な実装では、少なくとも9バイトのデータグラムを再構築することができます。
Usually, a host will not send to a remote peer an IP datagram larger than 576 bytes, unless it is explicitly signaled that the remote peer is able to receive such "large" datagrams (for example, by means of TCP's Maximum Segment Size (MSS) option). However, systems should assume that they may receive datagrams larger than 576 bytes, regardless of whether or not they signal their remote peers to do so. In fact, it is common for Network File System (NFS) [RFC3530]
明示的にリモートピアがTCPの最大セグメントサイズ（MSSによって、例えば（例えば、「大」データグラムを受信することが可能であることを知らされていない限り通常、ホストは、リモートピアに576バイトを超えるIPデータグラムを送信しません）オプション）。しかし、システムは、彼らは関係なく、彼らがそうする彼らのリモートピアを通知するか否かの、576バイトを超えるデータグラムを受け取ることができることを前提とすべきです。実際には、ネットワークファイルシステム（NFS）[RFC3530]のために一般的です
implementations to send datagrams larger than 576 bytes, even without explicit signaling that the destination system can receive such "large" datagram.
宛先システムは、「大きな」データグラムを受信することができることも明示的なシグナリングなしに、576バイトを超えるデータグラムを送信するために実装。
Additionally, see the discussion in Section 4.1 ("Fragment Reassembly") regarding the possible packet sizes resulting from fragment reassembly.
さらに、フラグメント再構成に起因する可能パケットサイズに関するセクション4.1（「フラグメント再構成」）での議論を参照。
Implementations should be aware that the IP module could be handed a packet larger than the value actually contained in the Total Length field. Such a difference usually has to do with legitimate padding bytes at the link-layer protocol, but it could also be the result of malicious activity by an attacker. Furthermore, even when the maximum length of an IP datagram is 65535 bytes, if the link-layer technology in use allows for payloads larger than 65535 bytes, an attacker could forge such a large link-layer packet, meaning it for the IP module. If the IP module of the receiving system were not prepared to handle such an oversized link-layer payload, an unexpected failure might occur. Therefore, the memory buffer used by the IP module to store the link-layer payload should be allocated according to the payload size reported by the link layer, rather than according to the Total Length field of the IP packet it contains.
実装は、IPモジュールは、実際に全長フィールドに含まれる値よりも大きなパケットを渡すことができることを認識する必要があります。このような違いは、通常、リンク層プロトコルでの合法的なパディングバイトに関係していますが、それはまた、攻撃者が悪質な活動の結果である可能性があります。使用中のリンク層技術が65535バイトを超えるペイロードを可能にする場合はIPデータグラムの最大長は、65535バイトである場合にもまた、攻撃者は、IPモジュールのことを意味する、このような大規模なリンク層パケットを偽造することができました。受信システムのIPモジュールは、このような特大リンク層ペイロードを処理する準備ができていないならば、予期しない障害が発生することがあります。したがって、リンク層ペイロードを格納するためにIPモジュールによって使用されるメモリバッファはなく、それに含まれるIPパケットの合計長フィールドに従って、リンク層によって報告されたペイロードサイズに応じて割り当てられるべきです。
The IP module could also be handed a packet that is smaller than the actual IP packet size claimed by the Total Length field. This could be used, for example, to produce an information leakage. Therefore, the following check should be performed:
IPモジュールはまた、全長フィールドが主張する実際のIPパケットのサイズよりも小さいパケットを渡すことができます。これは、情報漏洩を生成するために、例えば、使用することができます。したがって、次のチェックを実行する必要があります。
LinkLayer.PayloadSize >= Total Length
LinkLayer.PayloadSize> =全長
If this check fails, the IP packet should be dropped, and this event should be logged (e.g., a counter could be incremented reflecting the packet drop). As the previous expression implies, the number of bytes passed by the link layer to the IP module should contain at least as many bytes as claimed by the Total Length field of the IP header.
このチェックが失敗した場合、IPパケットは廃棄されるべきであり、このイベントがログに記録されるべきである（例えば、カウンタは、パケット損失を反映してインクリメントすることができます）。前の式が示すように、IPヘッダの全長フィールドであって、IPモジュールにリンク層から渡されたバイトの数は、少なくとも同じバイト数を含むべきです。
[US-CERT2002] is an example of the exploitation of a forged IP Total Length field to produce an information leakage attack.
[US-CERT2002】情報漏洩攻撃を生成するために偽造IP全長フィールドの搾取の一例です。
The Identification field is set by the sending host to aid in the reassembly of fragmented datagrams. At any time, it needs to be unique for each set of {Source Address, Destination Address, Protocol}.
識別フィールドは、断片化したデータグラムの再組み立てを助けるために送信ホストによって設定されます。いつでも、それは{送信元アドレス、宛先アドレス、プロトコル}のセットごとに一意である必要があります。
In many systems, the value used for this field is determined at the IP layer, on a protocol-independent basis. Many of those systems also simply increment the IP Identification field for each packet they send.
多くのシステムでは、このフィールドに使用される値は、プロトコルに依存しない基づいて、IPレイヤで決定されます。これらのシステムの多くは、単に彼らが送る各パケットのIP識別フィールドをインクリメントします。
This implementation strategy is inappropriate for a number of reasons. Firstly, if the Identification field is set on a protocol-independent basis, it will wrap more often than necessary, and thus the implementation will be more prone to the problems discussed in [Kent1987] and [RFC4963]. Secondly, this implementation strategy opens the door to an information leakage that can be exploited in a number of ways.
この実装戦略は、いくつかの理由で不適当です。識別フィールドは、プロトコルに依存しない基づいて設定されている場合、まず、それが必要以上に折り返され、従って、実装が[Kent1987]と[RFC4963]で説明した問題をより受けやすいであろう。第二に、この実装戦略は、いくつかの方法で利用することができ、情報漏洩への扉を開きます。
[Sanfilippo1998a] describes how the Identification field can be leveraged to determine the packet rate at which a given system is transmitting information. Later, [Sanfilippo1998b] described how a system with such an implementation can be used to perform a stealth port scan to a third (victim) host. [Sanfilippo1999] explained how to exploit this implementation strategy to uncover the rules of a number of firewalls. [Bellovin2002] explains how the IP Identification field can be exploited to count the number of systems behind a NAT. [Fyodor2004] is an entire paper on most (if not all) of the ways to exploit the information provided by the Identification field of the IP header.
【Sanfilippo1998a】識別フィールドは、特定のシステム情報を送信されたパケットレートを決定するために活用することができる方法について説明。後、[Sanfilippo1998bこのような実装にシステムがステルスポートは、第三（被害者）ホストにスキャンを実行するために使用することができる方法を説明しました。 【Sanfilippo1999】ファイアウォールの数の規則を発見するために、この実施戦略を利用する方法を説明します。 [Bellovin2002] IP識別フィールドは、NATの背後にあるシステムの数をカウントするために利用する方法について説明します。 【Fyodor2004】IPヘッダの識別フィールドによって提供される情報を利用する方法のほとんど（全てではない）で全体の紙です。
Section 4.1 contains a discussion of the security implications of the IP fragment reassembly mechanism, which is the primary "consumer" of this field.
4.1節では、この分野の主要な「消費者」であるIPフラグメント再構成機構のセキュリティへの影響についての議論が含まれています。
As the IP Identification field is only used for the reassembly of datagrams, some operating systems (such as Linux) decided to set this field to 0 in all packets that have the DF bit set. This would, in principle, avoid any type of information leakage. However, it was detected that some non-RFC-compliant middle-boxes fragmented packets even if they had the DF bit set. In such a scenario, all datagrams originally sent with the DF bit set would all result in fragments with an Identification field of 0, which would lead to problems ("collision" of the Identification number) in the reassembly process.
IP識別フィールドのみデータグラムの再組み立てのために使用されるように、（Linuxなど）一部のオペレーティングシステムは、DFビットがセットされているすべてのパケット0にこのフィールドを設定することを決めました。これは、原理的には、情報漏洩のいずれかのタイプを避けるだろう。しかし、それはいくつかの非RFC準拠のミドルボックスは、彼らがDFビットが設定されていた場合でも、パケットを断片化することを検出しました。そのようなシナリオでは、すべてのデータグラムは、もともとDFビットセット再構成プロセスにおける問題（識別番号の「衝突」）につながる0の識別フィールドを有する断片であろうすべての結果と共に送ら。
Linux (and Solaris) later set the IP Identification field on a per-IP-address basis. This avoids some of the security implications of the IP Identification field, but not all. For example, systems behind a load balancer can still be counted.
Linuxの（およびSolarisは）後でごとのIPアドレスベースでIP識別フィールドを設定します。これがすべてではありませんが、IP識別フィールドのセキュリティへの影響のいくつかを回避することができます。たとえば、ロードバランサの背後にあるシステムは、まだ数えることができます。
Contrary to common wisdom, the IP Identification field does not need to be system-wide unique for each packet, but has to be unique for each {Source Address, Destination Address, Protocol} tuple.
常識に反して、IP識別フィールドは、パケットごとにシステム全体で一意である必要はなく、各{送信元アドレス、宛先アドレス、プロトコル}タプルに対して一意でなければなりません。
For instance, the TCP specification defines a generic send() function that takes the IP ID as one of its arguments.
例えば、TCPの仕様は、引数の1つとして、IP IDを取る汎用センド（）関数を定義します。
We provide an analysis of the possible security improvements that could be implemented, based on whether the protocol using the services of IP is connection-oriented or connection-less.
私たちは、IPのサービスを使用してプロトコルが接続指向またはコネクションレスであるかどうかに基づいて、実装することができ可能なセキュリティ改善の分析を提供します。
To avoid the security implications of the information leakage described above, a pseudo-random number generator (PRNG) could be used to set the IP Identification field on a {Source Address, Destination Address} basis (for each connection-oriented transport protocol).
上記情報漏洩のセキュリティへの影響を回避するために、擬似乱数発生器（PRNG）が（各コネクション型トランスポートプロトコルのための）{送信元アドレス、宛先アドレス}に基づいて、IP識別フィールドを設定するために使用することができます。
[RFC4086] provides advice on the generation of pseudo-random numbers.
[RFC4086]は擬似乱数の生成にアドバイスを提供します。
[Klein2007] is a security advisory that describes a weakness in the pseudo-random number generator (PRNG) employed for the generation of the IP Identification by a number of operating systems.
【Klein2007】オペレーティングシステムの数でIP識別の生成に用いられる擬似乱数発生器（PRNG）の弱点を記述するセキュリティ勧告です。
While in theory a pseudo-random number generator could lead to scenarios in which a given Identification number is used more than once in the same time span for datagrams that end up getting fragmented (with the corresponding potential reassembly problems), in practice, this is unlikely to cause trouble.
理論的には、擬似乱数生成器は、シナリオにつながるながらた所定の識別番号が、実際には、（対応する潜在的な再組み立ての問題に）断片化なっ終わるデータグラムのための同じ時間帯に複数回使用され、これはトラブルを引き起こす可能性は低いです。
By default, most implementations of connection-oriented protocols, such as TCP, implement some mechanism for avoiding fragmentation (such as the Path-MTU Discovery mechanism described in [RFC1191]). Thus, fragmentation will only take place if a non-RFC-compliant middle-box that still fragments packets even when the DF bit is set is placed somewhere along the path that the packets travel to get to the destination host. Once the sending system is signaled by the middle-box (by means of an ICMP "fragmentation needed and DF bit set" error message) that it should reduce the size of the packets it sends, fragmentation would be avoided. Also, for reassembly problems to arise, the same Identification value would need to be reused very frequently, and either strong packet reordering or packet loss would need to take place.
デフォルトでは、TCPなどのコネクション型プロトコルのほとんどの実装では、（例えば、[RFC1191]に記載のパスMTU発見メカニズムとして）フラグメンテーションを回避するためのいくつかのメカニズムを実装します。 DFビットが設定されている場合でも、まだパケットをフラグメント化非RFC準拠のミドルボックスはどこかにパケットが宛先ホストに到達するために移動路に沿って配置されている場合。このように、断片化が唯一の場所がかかります送信システムは、それが送信するパケットのサイズを縮小する必要があること（ICMP「フラグメンテーション必要とDFビットセット」エラーメッセージを用いて）の中間ボックスによって通知されると、断片化が回避されることになります。再組み立ての問題が発生するためにも、同じ識別値が非常に頻繁に再利用する必要があるだろう、との強いパケット並べ替えやパケット損失のどちらかは場所を取る必要があります。
Nevertheless, regardless of what policy is used for selecting the Identification field, with the current link speeds fragmentation is already bad enough (i.e., very likely to lead to fragment reassembly errors) to rely on it. A mechanism for avoiding fragmentation (such as [RFC1191] or [RFC4821] should be implemented, instead.
それにもかかわらず、関係なく、ポリシーが現在のリンク速度の断片化と、識別フィールドを選択するために使用されているものの、それに依存する（フラグメント再構成エラーにつながることが、すなわち、非常に可能性が高い）、既に十分に悪いです。このような[RFC1191]または[RFC4821]として（断片化を回避するための機構ではなく、実施されるべきです。
Connectionless transport protocols often have these characteristics:
コネクションレスのトランスポートプロトコルは、多くの場合、これらの特性があります。
o lack of flow-control mechanisms,
フロー制御メカニズムのO欠如、
o lack of packet sequencing mechanisms, and/or,
Oパケットシーケンシングメカニズムの欠如、および/または、
o lack of reliability mechanisms (such as "timeout and retransmit").
（例えば、「タイムアウトおよび再送信」という）の信頼性メカニズムのOの欠如。
This basically means that the scenarios and/or applications for which connection-less transport protocols are used assume that:
これは基本的にコネクションレスのトランスポートプロトコルが使用されるシナリオ及び/又はアプリケーションがそれを仮定することを意味します。
o Applications will be used in environments in which packet reordering is very unlikely (such as Local Area Networks), as the transport protocol itself does not provide data sequencing.
Oアプリケーションは、トランスポートプロトコル自体はデータのシーケンシングを提供しないように、パケットの並べ替えは、（ローカル・エリア・ネットワークなど）は非常に低いとした環境で使用されます。
o The data transfer rates will be low enough that flow control will be unnecessary.
Oデータ転送速度は、フロー制御が不要になることを十分に低くなります。
o Packet loss is can be tolerated and/or is unlikely.
Oパケット損失は許容および/またはそうであることができています。
With these assumptions in mind, the Identification field could still be set according to a pseudo-random number generator (PRNG).
念頭に置いてこれらの仮定を用いて、識別フィールドは、依然として、擬似乱数発生器（PRNG）に応じて設定することができます。
[RFC4086] provides advice on the generation of pseudo-random numbers.
[RFC4086]は擬似乱数の生成にアドバイスを提供します。
In the event a given Identification number was reused while the first instance of the same number is still on the network, the first IP datagram would be reassembled before the fragments of the second IP datagram get to their destination.
イベントでは与えられた識別番号が同じ番号の最初のインスタンスがネットワークに残っている間に、第2のIPデータグラムのフラグメントが彼らの目的地に着く前に、最初のIPデータグラムを再組み立てられる再利用しました。
In the event this was not the case, the reassembly of fragments would result in a corrupt datagram. While some existing work [Silbersack2005] assumes that this error would be caught by some upper-layer error detection code, the error detection code in question (such as UDP's checksum) might not be able to reliably detect data corruption arising from the replacement of a complete data block (as is the case in corruption arising from collision of IP Identification numbers).
イベントでは、これはそうではありませんでした、フラグメントの再構築が破損しているデータグラムをもたらすであろう。いくつかの既存の作業【Silbersack2005]このエラーは、いくつかの上位層のエラー検出コードによって捕捉されることを前提としながら、（例えば、UDPのチェックサムなど）当該誤り検出符号が確実の置換から生じるデータの破損を検出することができないかもしれません完全なデータ・ブロック（IP識別番号の衝突に起因する破損の場合であるように）。
In the case of UDP, unfortunately some systems have been known to not enable the UDP checksum by default. For most applications, packets containing errors should be dropped by the transport layer and not delivered to the application. A small number of applications may benefit from disabling the checksum; for example, streaming media where it is desired to avoid dropping a complete sample for a single-bit error, and UDP tunneling applications where the payload (i.e., the inner packet) is protected by its own transport checksum or other error detection mechanism.
UDPの場合は、残念ながらいくつかのシステムでは、デフォルトではUDPチェックサムを有効にしないことが知られています。ほとんどのアプリケーションでは、エラーを含むパケットは、トランスポート層でドロップする必要があり、アプリケーションに配信されません。アプリケーション少数のチェックサムを無効にするから利益を得ることができます。例えば、単一ビットエラーの完全なサンプルを落下回避することが所望されるメディア、およびペイロード（すなわち、インナパケット）は、独自の輸送チェックサムまたは他のエラー検出機構によって保護されるUDPトンネリングアプリケーションストリーミング。
In general, if IP Identification number collisions become an issue for the application using the connection-less protocol, the application designers should consider using a different transport protocol (which hopefully avoids fragmentation).
IP識別番号衝突がコネクションレスプロトコルを使用するアプリケーションのための課題となっている場合、一般的に、アプリケーション設計者は、（できれば断片化を回避する）、異なるトランスポート・プロトコルを使用することを検討すべきです。
It must be noted that an attacker could intentionally exploit collisions of IP Identification numbers to perform a DoS attack, by sending forged fragments that would cause the reassembly process to result in a corrupt datagram that either would be dropped by the transport protocol or would incorrectly be handed to the corresponding application. This issue is discussed in detail in Section 4.1 ("Fragment Reassembly").
再構築プロセスは、どちらかは、トランスポートプロトコルによって廃棄されます破損しているデータグラムをもたらすことが原因でしょうか、正しくあろうと偽造の断片を送信することにより、攻撃者が意図的にDoS攻撃を実行するためにIP識別番号の衝突を利用することに留意しなければなりません対応するアプリケーションに手渡しました。この問題は、4.1節（「フラグメント再構成」）で詳しく説明されています。
The IP header contains 3 control bits, two of which are currently used for the fragmentation and reassembly function.
IPヘッダは、現在断片化と再アセンブリ機能のために使用される2つのうち3つの制御ビットを含んでいます。
As described by RFC 791, their meaning is:
RFC 791で説明したように、その意味は以下のとおりです。
o Bit 0: reserved, must be zero (i.e., reserved for future standardization)
Oビット0：予約は、ゼロでなければならない（すなわち、将来の標準化のために予約）
o Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment
Oビット1：1 =がフラグメント不可（DF）0 =月フラグメント、
o Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments
Oビット2：（MF）0 =最後のフラグメント、1 =以上の断片
The DF bit is usually set to implement the Path-MTU Discovery (PMTUD) mechanism described in [RFC1191]. However, it can also be exploited by an attacker to evade Network Intrusion Detection Systems. An attacker could send a packet with the DF bit set to a system monitored by a NIDS, and depending on the Path-MTU to the intended recipient, the packet might be dropped by some intervening router (because of being too big to be forwarded without fragmentation), without the NIDS being aware of it.
DFビットは、通常、[RFC1191]に記載の経路MTU探索（PMTUD）機構を実装するために設定されています。しかし、また、ネットワーク侵入検知システムを回避するために、攻撃者によって悪用される可能性があります。 DFでパケットを送信することができ、攻撃者はNIDSによって監視システムに設定し、目的の受信者にパスMTUに応じてビット、パケットは理由なしで転送されるにはあまりに巨大であることの（いくつかの介在ルータによって廃棄される可能性があります断片化）、NIDSはそれを意識することなく。
+---+
| H |
+---+ Victim host
|
Router A | MTU=1500
|
+---+ +---+ +---+
| R |-----| R |---------| R |
+---+ +---+ +---+
| MTU=17914 Router B
+---+ |
| S |-----+
+---+ |
|
NIDS Sensor |
|
_ ___/---\______ Attacker
/ \_/ \_ +---+
/ Internet |---------| H |
\_ __/ +---+
\__ __ ___/ <------
\___/ \__/ 17914-byte packet
DF bit set
Figure 5: NIDS Evasion by Means of the Internet Protocol DF Bit
図5：インターネットプロトコルDFビットによりNIDSの回避
In Figure 3, an attacker sends a 17914-byte datagram meant for the victim host in the same figure. The attacker's packet probably contains an overlapping IP fragment or an overlapping TCP segment, aiming at "confusing" the NIDS, as described in [Ptacek1998]. The packet is screened by the NIDS sensor at the network perimeter, which probably reassembles IP fragments and TCP segments for the purpose of assessing the data transferred to and from the monitored systems. However, as the attacker's packet should transit a link with an MTU smaller than 17914 bytes (1500 bytes in this example), the router that encounters that this packet cannot be forwarded without fragmentation (Router B) discards the packet, and sends an ICMP "fragmentation needed and DF bit set" error message to the source host. In this scenario, the NIDS may remain unaware that the screened packet never reached the intended destination, and thus get an incorrect picture of the data being transferred to the monitored systems.
図3では、攻撃者は、同図の被害者のホストのためのもの17914バイトのデータグラムを送信します。攻撃者のパケットは、おそらく[Ptacek1998]で説明したように、「混乱」NIDSを目指し、重複IPフラグメントまたは重複するTCPセグメントが含まれています。パケットは、おそらくにし、監視対象システムから転送されたデータを評価するために、IPフラグメントやTCPセグメントを再構成ネットワークの境界、でNIDSセンサーによってスクリーニングされます。しかし、攻撃者のパケットべきトランジットMTUより小さい17914バイト（この例では1500バイト）のリンクとして、このパケットが断片化することなく転送することができないことを検出したルータ（ルータB）」は、パケットを破棄し、ICMPを送信します断片化が必要とDFは、ソースホストに設定され、「エラーメッセージビット。このシナリオでは、NIDSは、スクリーニング、パケットが意図された宛先に到達したことがないことに気づかないまま、したがって、監視対象システムに転送されるデータの不正確な画像を得ることができます。
[Shankar2003] introduces a technique named "Active Mapping" that prevents evasion of a NIDS by acquiring sufficient knowledge about the network being monitored, to assess which packets will arrive at the intended recipient, and how they will be interpreted by it.
【Shankar2003】パケットが意図された受信者に到達するどの評価するために、監視されているネットワークについての十分な知識を取得することにより、NIDSの回避を防止する「アクティブ・マッピング」、およびどのようにそれが解釈されるであろうという名前の技術を導入します。
Some firewalls are known to drop packets that have both the MF (More Fragments) and the DF (Don't Fragment) bits set. While in principle such a packet might seem nonsensical, there are a number of reasons for which non-malicious packets with these two bits set can be found in a network. First, they may exist as the result of some middle-box processing a packet that was too large to be forwarded without fragmentation. Instead of simply dropping the corresponding packet and sending an ICMP error message to the source host, some middle-boxes fragment the packet (copying the DF bit to each fragment), and also send an ICMP error message to the originating system. Second, some systems (notably Linux) set both the MF and the DF bits to implement Path-MTU Discovery (PMTUD) for UDP. These scenarios should be taken into account when configuring firewalls and/or tuning NIDSs.
一部のファイアウォールは、MF（複数の断片）とDF（しないでくださいフラグメント）設定されたビットの両方を持つパケットをドロップすることが知られています。原則的に、このようなパケットが無意味なように見えるかもしれませんが、設定これら2つのビットを持つ非悪意のあるパケットがネットワーク内で見つけることができる理由がいくつかあります。まず、それらは断片化せずに転送するには大きすぎるたパケットを処理するいくつかのミドルボックスの結果として存在してもよいです。代わりに、単に対応するパケットをドロップし、ソースホストにICMPエラーメッセージを送信する、いくつかの中間のボックスは、（各フラグメントにDFビットをコピー）パケットを断片化し、また、発信システムにICMPエラーメッセージを送信します。第二に、いくつかのシステム（特にLinux）がUDPのためのパスMTUディスカバリ（PMTUD）を実装するためにMFとDFビットの両方を設定します。ファイアウォールの設定、および/またはNIDSsをチューニングする際にこれらのシナリオを考慮に入れるべきです。
Section 4.1 contains a discussion of the security implications of the IP fragment reassembly mechanism.
4.1節は、IPフラグメント再構成機構のセキュリティへの影響についての議論が含まれています。
The Fragment Offset is used for the fragmentation and reassembly of IP datagrams. It indicates where in the original datagram payload the payload of the fragment belongs, and is measured in units of eight bytes. As a consequence, all fragments (except the last one), have to be aligned on an 8-byte boundary. Therefore, if a packet has the MF flag set, the following check should be enforced:
フラグメントオフセットは、IPデータグラムの断片化と再構築のために使用されています。これは、元のデータグラムのペイロードに断片のペイロードが属する場所を示す、及び8バイトの単位で測定されます。その結果、（最後のものを除く）すべてのフラグメントは、8バイト境界で整列する必要があります。パケットがMFフラグが設定されている場合、したがって、以下のチェックが実施されるべきです。
(Total Length - IHL * 4) % 8 == 0
（総丈 - IHL * 4）％8 == 0
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented reflecting the packet drop).
パケットがこのチェックに合格しない場合、それは廃棄されるべきであり、このイベントが記録されるべきである（例えば、カウンタは、パケット損失を反映してインクリメントすることができます）。
Given that Fragment Offset is a 13-bit field, it can hold a value of up to 8191, which would correspond to an offset 65528 bytes within the original (non-fragmented) datagram. As such, it is possible for a fragment to implicitly claim to belong to a datagram larger than 65535 bytes (the maximum size for a legitimate IP datagram). Even when the fragmentation mechanism would seem to allow fragments that could reassemble into such large datagrams, the intent of the specification is to allow for the transmission of datagrams of up to 65535 bytes. Therefore, if a given fragment would reassemble into a datagram of more than 65535 bytes, the resulting datagram should be dropped, and this event should be logged (e.g., a counter could be incremented reflecting the packet drop). To detect such a case, the following check should be enforced on all packets for which the Fragment Offset contains a non-zero value:
オフセット断片は13ビットのフィールドであることを考えると、それは元の（非断片化）データグラム内のオフセット65528のバイトに対応する8191までの値を保持することができます。断片は暗黙65535バイト（正当なIPデータグラムの最大サイズ）よりも大きいデータグラムに属していると主張する。このように、それが可能です断片化機構は、大きなデータグラムに再構築できたフラグメントを許可するように思われる場合でも、本明細書の意図は、最大65535バイトのデータグラムの送信を可能にすることです。与えられた断片を超える65535バイトのデータグラムに再構築するかどうしたがって、得られたデータグラムをドロップする必要があり、このイベントがログに記録されるべきである（例えば、カウンタは、パケット損失を反映してインクリメントすることができます）。このような場合を検出するために、以下のチェックがオフセットフラグメントが非ゼロ値が含まれているすべてのパケットに適用されるべきです。
Fragment Offset * 8 + (Total Length - IHL * 4) + IHL_FF * 4 <= 65535
フラグメントオフセット* 8 +（総丈 - IHL * 4）+ IHL_FF * 4 <= 65535
where IHL_FF is the IHL field of the first fragment (the one with a Fragment Offset of 0).
IHL_FFは、最初のフラグメント（0のオフセットフラグメントを有するもの）のIHLフィールドです。
If a fragment does not pass this check, it should be dropped.
フラグメントは、このチェックに合格しない場合、それは廃棄されなければなりません。
If IHL_FF is not yet available because the first fragment has not yet arrived, for a preliminary, less rigid test, IHL_FF == IHL should be assumed, and the test is simplified to:
IHL_FFがまだ利用可能でない場合、最初のフラグメントがまだ予備的、低剛性試験のために、到着していないため、IHL_FF == IHLが想定されるべきであり、試験がに簡略化されます。
Fragment Offset * 8 + Total Length <= 65535
フラグメントオフセット* 8 +全長<= 65535
Once the first fragment is received, the full sanity check described earlier should be applied, if that fragment contains "don't copy" options.
最初のフラグメントが受信されると、その断片が、オプションの「コピーしない」が含まれている場合、前述の完全な健全性チェックは、適用されるべきです。
In the worst-case scenario, an attacker could craft IP fragments such that the reassembled datagram reassembled into a datagram of 131043 bytes.
最悪のシナリオでは、攻撃者が再組み立てデータグラムが131043バイトのデータグラムに再構築するようなIPフラグメントを作成する可能性があります。
Such a datagram would result when the first fragment has a Fragment Offset of 0 and a Total Length of 65532, and the second (and last) fragment has a Fragment Offset of 8189 (65512 bytes), and a Total Length of 65535. Assuming an IHL of 5 (i.e., a header length of 20 bytes), the reassembled datagram would be 65532 + (65535 - 20) = 131047 bytes.
最初のフラグメントが0のオフセットフラグメントおよび65532の全長を有し、第2の（そして最後の）フラグメントが8189（65512バイト）のオフセットフラグメントと仮定すると65535の合計の長さを有する場合、そのようなデータグラムが生じます= 131047バイト - 5のIHL（すなわち、20バイトのヘッダ長）が、再組立データグラムは65532 +（20 65535）であろう。
Additionally, the IP module should implement all the necessary measures to be able to handle such illegitimate reassembled datagrams, so as to avoid them from overflowing the buffer(s) used for the reassembly function.
再構成機能のために使用されるバッファ（複数可）をオーバーフローするのを避けるように、また、IPモジュールは、そのような不正な再構築されたデータグラムを処理することができるようにするすべての必要な措置を講じなければなりません。
[CERT1996c] and [Kenney1996] describe the exploitation of this issue to perform a DoS attack.
[CERT1996c]と[Kenney1996] DoS攻撃を実行するには、この問題の悪用を記述する。
Section 4.1 contains a discussion of the security implications of the IP fragment reassembly mechanism.
4.1節は、IPフラグメント再構成機構のセキュリティへの影響についての議論が含まれています。
The Time to Live (TTL) field has two functions: to bound the lifetime of the upper-layer packets (e.g., TCP segments) and to prevent packets from looping indefinitely in the network.
（TTL）フィールドを生存時間は、2つの機能を有している：に上位層パケット（例えば、TCPセグメント）の寿命を結合し、ネットワーク内で無限にループからパケットを防止します。
Originally, this field was meant to indicate the maximum time a datagram was allowed to remain in the Internet system, in units of seconds. As every Internet module that processes a datagram must decrement the TTL by at least one, the original definition of the TTL field became obsolete, and in practice it is interpreted as a hop count (see Section 5.3.1 of [RFC1812]).
もともと、このフィールドは、データグラムが秒単位で、インターネットシステムに残存させた最大時間を示すためのものでした。少なくとも一つによってTTLをデクリメントしなければならないデータグラムを処理するすべてのインターネットモジュールとして、TTLフィールドの元の定義が時代遅れになり、実際には、ホップ数として解釈される（[RFC1812]のセクション5.3.1を参照）。
Most systems allow the administrator to configure the TTL to be used for the packets they originate, with the default value usually being a power of 2, or 255 (e.g., see [Arkin2000]). The recommended value for the TTL field, as specified by the IANA is 64 [IANA_IP_PARAM]. This value reflects the assumed "diameter" of the Internet, plus a margin to accommodate its growth.
ほとんどのシステムでは、管理者が（例えば、[Arkin2000]参照）デフォルト値は通常2、又は255のパワーであると、それらは発信パケットに使用されるTTLを設定することを可能にします。 IANAによって指定されるようにTTLフィールドの推奨値は、64 [IANA_IP_PARAM]です。この値は、インターネットの仮定「直径」に加え、その成長に対応するためのマージンを反映しています。
The TTL field has a number of properties that are interesting from a security point of view. Given that the default value used for the TTL is usually either a power of two, or 255, chances are that unless the originating system has been explicitly tuned to use a non-default value, if a packet arrives with a TTL of 60, the packet was originally sent with a TTL of 64. In the same way, if a packet is received with a TTL of 120, chances are that the original packet had a TTL of 128.
TTLフィールドは、セキュリティの観点から興味深い性質がいくつかあります。 TTLのために使用されるデフォルト値は、通常は2、または255の電源のいずれかであることを考えると、チャンスは、元のシステムが明示的にパケットが60のTTLに到着した場合、デフォルト以外の値を使用するように調整されていない限りということですパケット120のTTLで受信された場合、パケットが最初に、同様に64のTTLで送信された、可能性が元のパケット128のTTLを有していることです。
This discussion assumes there was no protocol scrubber, transparent proxy, or some other middle-box that overwrites the TTL field in a non-standard way, between the originating system and the point of the network in which the packet was received.
この議論には、プロトコルスクラバ、透過プロキシ、または元のシステムとパケットが受信されたネットワークの点との間に、非標準的な方法でTTLフィールドを上書きするいくつかの他のミドルボックスはなかった前提。
Determining the TTL with which a packet was originally sent by the source system can help to obtain valuable information. Among other things, it may help in:
パケットが最初にソース・システムによって送信されたとTTLを決定することは、貴重な情報を得るのを助けることができます。とりわけ、それはに役立つことがあります。
o Fingerprinting the originating operating system.
O元のオペレーティングシステムをフィンガープリント。
o Fingerprinting the originating physical device.
O元の物理デバイスをフィンガープリント。
o Mapping the network topology.
Oネットワークトポロジをマッピングします。
o Locating the source host in the network topology.
ネットワークトポロジの元ホストの検索、O。
o Evading Network Intrusion Detection Systems.
ネットワーク侵入検知システムを回避O。
However, it can also be used to perform important functions such as:
しかし、またのような重要な機能を実行するために使用することができます。
o Improving the security of applications that make use of the Internet Protocol (IP).
インターネット・プロトコル（IP）を利用するアプリケーションのセキュリティを向上させるO。
o Limiting spread of packets.
パケットの拡散を制限するO。
Different operating systems use a different default TTL for the packets they send. Thus, asserting the TTL with which a packet was originally sent will help heuristics to reduce the number of possible operating systems in use by the source host. It should be noted that since most systems use only a handful of different default values, the granularity of OS fingerprinting that this technique provides is negligible. Additionally, these defaults may be configurable (system-wide or per protocol), and managed systems may employ such opportunities for operational purposes and to defeat the capability of fingerprinting heuristics.
異なるオペレーティングシステムは、彼らが送信するパケットのために別のデフォルトのTTLを使用します。このように、パケットが最初に送信されたとのTTLをアサートすると、ヒューリスティックは、送信元ホストが使用している可能性オペレーティングシステムの数を減らすのに役立ちます。ほとんどのシステムは、異なるデフォルト値のほんの一握りを使用しているため、この技術が提供するOSフィンガープリントの粒度はごくわずかであることに留意すべきです。加えて、これらのデフォルトを設定（システム全体またはプロトコルごと）であってもよく、管理システムは、運用目的のためにそのような機会を利用してもよいし、指紋ヒューリスティックの能力を無効にします。
3.8.2. Fingerprinting the Physical Device from which the Packets Originate
3.8.2. パケットが由来する物理デバイスをフィンガープリント
When several systems are behind a middle-box such as a NAT or a load balancer, the TTL may help to count the number of systems behind the middle-box. If each of the systems behind the middle-box uses a different default TTL value for the packets it sends, or each system is located at different distances in the network topology, an attacker could stimulate responses from the devices being fingerprinted, and responses that arrive with different TTL values could be assumed to come from a different devices.
いくつかのシステムでは、NATなどの中間ボックスやロードバランサの背後にある場合には、TTLは、ミドルボックスの背後にあるシステムの数をカウントするのを助けることができます。ミドルボックスの背後にあるシステムの各々は、それが送信する、または各システムは、ネットワークトポロジ内の異なる距離に配置されているパケットの異なるデフォルトTTL値を使用している場合、攻撃者は、フィンガープリントされているデバイスからの応答を刺激することができ、及び到着応答別のTTL値と異なるデバイスから来ると想定することができます。
Of course, there are many other (and much more precise) techniques to fingerprint physical devices. One weakness of this method is that, while many systems differ in the default TTL value that they use, there are also many implementations which use the same default TTL value. Additionally, packets sent by a given device may take different routes (e.g., due to load sharing or route changes), and thus a given packet may incorrectly be presumed to come from a different device, when in fact it just traveled a different route.
もちろん、物理的なデバイスを指紋ために、他の多くの（とはるかに正確な）テクニックがあります。この方法の一つの弱点は、多くのシステムは、彼らが使用するデフォルトTTL値が異なるが、同じデフォルトTTL値を使用する多くの実装もある、ということです。さらに、所与のデバイスによって送信されたパケットは、（共有又は経路変更を読み込むことにより、例えば、）異なる経路をとることができ、したがって、所与のパケットが誤って実際にはわずかに異なる経路を走行したときに、別のデバイスから来ると推定されてもよいです。
However, these defaults may be configurable (system-wide or per protocol) and managed systems may employ such opportunities for operational purposes and to defeat the capability of fingerprinting heuristics.
しかしながら、これらのデフォルト値は、動作の目的のためにそのような機会を利用することができる構成（システム全体またはプロトコルごと）および管理システムであってもよく、指紋ヒューリスティックの能力を無効にします。
An originating host may set the TTL field of the packets it sends to progressively increasing values in order to elicit an ICMP error message from the routers that decrement the TTL of each packet to zero, and thereby determine the IP addresses of the routers on the path to the packet's destination. This procedure has been traditionally employed by the traceroute tool.
元ホストは、それが徐々にゼロに各パケットのTTLをデクリメントルータからICMPエラーメッセージを誘発するために値を増加させるために送信するパケットのTTLフィールドを設定し、それによって、経路上のルータのIPアドレスを決定することができますパケットの宛先へ。この手順では、伝統的にtracerouteのツールで採用されています。
The TTL field may also be used to locate the source system in the network topology [Northcutt2000].
TTLフィールドは、ネットワーク・トポロジー[Northcutt2000]内のソースシステムの位置を確認するために使用されてもよいです。
+---+ +---+ +---+ +---+ +---+
| A |-----| R |------| R |----| R |-----| R |
+---+ +---+ +---+ +---+ +---+
/ | / \
/ | / \
/ | / +---+
/ +---+ +---+ +---+ | E |
/ | R |----| R |------| R |-- +---+
/ +---+ +---+\ +---+ \
/ / / \ \ \
/ ---- / +---+ \ \+---+
/ / / | F | \ | D |
+---+ +---+ +---+ \ +---|
| R |----------| R |-- \
+---+ +---+ \ \
| \ / \ +---+| +---+
| \ / ----| R |------| R |
| \ / +---+ +---+
+---+ \ +---+ +---+
| B | \| R |----| C |
+---+ +---+ +---+
Figure 6: Tracking a Host by Means of the TTL Field
図6：TTLフィールドを用いてホストを追跡
Consider network topology of Figure 6. Assuming that an attacker ("F" in the figure) is performing some type of attack that requires forging the Source Address (such as for a TCP-based DoS reflection attack), and some of the involved hosts are willing to cooperate to locate the attacking system.
攻撃者（図中の「F」）が（例えばTCPベースのDoS反射攻撃のような）ソースアドレスを偽造する必要が攻撃のいくつかの種類を行っていると仮定すると、図6のネットワークトポロジを考慮して、関与するホストの一部攻撃システムの位置を確認するために協力して喜んでいます。
Assuming that:
仮定して：
o All the packets A gets have a TTL of 61.
OすべてのパケットAは61のTTLを有してなります。
o All the packets B gets have a TTL of 61.
OすべてのパケットBは61のTTLを有してなります。
o All the packets C gets have a TTL of 61.
OすべてのパケットのC 61のTTLを有してなります。
o All the packets D gets have a TTL of 62.
OすべてのパケットDは、62のTTLを持って取得します。
Based on this information, and assuming that the system's default value was not overridden, it would be fair to assume that the original TTL of the packets was 64. With this information, the number of hops between the attacker and each of the aforementioned hosts can be calculated.
この情報に基づいて、システムのデフォルト値が上書きされなかったと仮定すると、パケットの元のTTLがこの情報で64であったと仮定する公正であろう、攻撃することができ、前述のホストのそれぞれとの間のホップ数計算されます。
The attacker is:
攻撃者は、次のとおりです。
o Four hops away from A.
OフォーA.から離れホップ
o Four hops away from B.
OフォーBから離れホップ
o Four hops away from C.
OフォーC.から離れホップ
o Four hops away from D.
OフォーD.から離れホップ
In the network setup of Figure 3, the only system that satisfies all these conditions is the one marked as the "F".
図3のネットワーク設定では、これらの条件を全て満たす唯一のシステムは、「F」とマークされたものです。
The scenario described above is for illustration purposes only. In practice, there are a number of factors that may prevent this technique from being successfully applied:
上述したシナリオは、単に例示の目的のためのものです。実際には、正常に適用されることから、この技術を防止することができる多くの要因があります。
o Unless there is a "large" number of cooperating systems, and the attacker is assumed to be no more than a few hops away from these systems, the number of "candidate" hosts will usually be too large for the information to be useful.
そこ協力システムの「大」の数であり、攻撃者が離れてこれらのシステムから数ホップ以下でもないと想定されていない限り情報が有用であるために、O、「候補」ホストの数は、通常は大きすぎるだろう。
o The attacker may be using a non-default TTL value, or, what is worse, using a pseudo-random value for the TTL of the packets it sends.
O攻撃者は、それが送信するパケットのTTLのための擬似ランダム値を用いて、さらに悪いことには、デフォルト以外のTTL値を使用すること、又はもよいです。
o The packets sent by the attacker may take different routes, as a result of a change in network topology, load sharing, etc., and thus may lead to an incorrect analysis.
O攻撃者によって送信されたパケット等のネットワークトポロジー、負荷分散の変化の結果として、異なる経路をとることができ、従って、不正確な分析をもたらし得ます。
The TTL field can be used to evade Network Intrusion Detection Systems. Depending on the position of a sensor relative to the destination host of the examined packet, the NIDS may get a different picture from that of the intended destination system. As an example, a sensor may process a packet that will expire before getting to the destination host. A general countermeasure for this type of attack is to normalize the traffic that gets to an organizational network. Examples of such traffic normalization can be found in [Paxson2001]. OpenBSD Packet Filter is an example of a packet filter that includes TTL-normalization functionality [OpenBSD-PF]
TTLフィールドは、ネットワーク侵入検知システムを回避するために使用することができます。検査パケットの宛先ホストに対するセンサの位置に応じて、NIDSは、意図された宛先装置とは異なる画像を得ることができます。例として、センサーは、宛先ホストに入る前に期限切れになり、パケットを処理することができます。この種の攻撃のための一般的な対策は、組織のネットワークに到達するトラフィックを正規化することです。そのようなトラフィックの正規化の例は、[Paxson2001]に見出すことができます。 OpenBSDのパケットフィルタは、TTL-正規化機能を含むパケットフィルタ[OpenBSDの-PF]の一例です
3.8.6. Improving the Security of Applications That Make Use of the Internet Protocol (IP)
3.8.6. インターネット・プロトコル（IP）を利用するアプリケーションのセキュリティを向上させます
In some scenarios, the TTL field can be also used to improve the security of an application, by restricting the hosts that can communicate with the given application [RFC5082]. For example, there are applications for which the communicating systems are typically in the same network segment (i.e., there are no intervening routers). Such an application is the BGP (Border Gateway Protocol) utilized by two peer routers (usually on a shared link medium).
いくつかのシナリオでは、TTLフィールドは、所与のアプリケーション[RFC5082]と通信できるホストを制限することによって、アプリケーションのセキュリティを向上させるために使用することができます。例えば、通信システムは、同じネットワークセグメントに典型的であるために用途がある（すなわち、介在ルータが存在しません）。そのようなアプリケーションが（通常は共有リンク媒体上の）2つのピアルータによって利用されるBGP（ボーダーゲートウェイプロトコル）です。
If both systems use a TTL of 255 for all the packets they send to each other, then a check could be enforced to require all packets meant for the application in question to have a TTL of 255.
両方のシステムは、彼らが相互に送信するすべてのパケットのための255のTTLを使用する場合は、チェックが255のTTLを持つことが問題のアプリケーションのためのもので、すべてのパケットを必要とするように強制することができます。
As all packets sent by systems that are not in the same network segment will have a TTL smaller than 255, those packets will not pass the check enforced by these two cooperating peers. This check reduces the set of systems that may perform attacks against the protected application (BGP in this case), thus mitigating the attack vectors described in [NISCC2004] and [Watson2004].
同じネットワークセグメントに含まれていないシステムによって送信されたすべてのパケットが255よりも小さいTTLを有するであろうように、これらのパケットは、これら2つのつの協働するピアによって強制チェックを通過しないであろう。このチェックは、[NISCC2004】このように記載された攻撃ベクトルを軽減、保護されたアプリケーション（この場合、BGP）攻撃を実行することができるシステムのセットを減少させ、[Watson2004]。
This same check is enforced for related ICMP error messages, with the intent of mitigating the attack vectors described in [NISCC2005] and [RFC5927].
これと同じチェックは[NISCC2005]と[RFC5927]で説明攻撃ベクトルを軽減する目的で、関連するICMPエラーメッセージのために適用されます。
The TTL field can be used in a similar way in scenarios in which the cooperating systems are not in the same network segment (i.e., multi-hop peering). In that case, the following check could be enforced:
TTLフィールドは、協働システムは、同じネットワークセグメント（すなわち、マルチホップピアリング）にされていないシナリオで同様に使用することができます。その場合には、次のチェックを強制することができます。
TTL >= 255 - DeltaHops
TTL> = 255 - DeltaHops
This means that the set of hosts from which packets will be accepted for the protected application will be reduced to those that are no more than DeltaHops away. While for obvious reasons the level of protection will be smaller than in the case of directly connected peers, the use of the TTL field for protecting multi-hop peering still reduces the set of hosts that could potentially perform a number of attacks against the protected application.
これは、パケットが保護されたアプリケーションのために受理されるから、ホストのセットが離れDeltaHopsにすぎないものにまで低減されることを意味します。保護のレベルは、直接接続されたピアの場合よりも小さくなる明白な理由のために、マルチホップピアリングを保護するためのTTLフィールドの使用は、依然として潜在保護されたアプリケーションに対する攻撃の数を実行できるホストのセットを減少させながら。
This use of the TTL field has been officially documented by the IETF under the name "Generalized TTL Security Mechanism" (GTSM) in [RFC5082].
TTLフィールドのこの使用は、正式名[RFC5082]で「一般TTLセキュリティメカニズム」（GTSM）の下にIETFによって文書化されています。
Some protocol scrubbers enforce a minimum value for the TTL field of the packets they forward. It must be understood that depending on the minimum TTL being enforced, and depending on the particular network setup, the protocol scrubber may actually help attackers to fool the GTSM, by "raising" the TTL of the attacking packets.
いくつかのプロトコルスクラバーは、パケットフォワードそれらのTTLフィールドの最小値を強制します。強制されている最小TTLに応じて、特定のネットワーク設定に応じて、プロトコルスクラバーは、実際に攻撃者は、攻撃パケットのTTLを「引き上げる」ことで、GTSMをだますのに役立つことができることを理解しなければなりません。
The originating host sets the TTL field to a small value (frequently 1, for link-scope services) in order to artificially limit the (topological) distance the packet is allowed to travel. This is suggested in Section 4.2.2.9 of RFC 1812 [RFC1812]. Further discussion of this technique can be found in RFC 1112 [RFC1112].
発信元ホストがパケットを移動させる距離人為（トポロジー）を制限するために、（リンクスコープサービスの頻繁1）小さい値にTTLフィールドを設定します。これは、RFC 1812 [RFC1812]のセクション4.2.2.9で提案されます。この技術のさらなる議論は、RFC 1112 [RFC1112]に見出すことができます。
The Protocol field indicates the protocol encapsulated in the Internet datagram. The Protocol field may not only contain a value corresponding to a protocol implemented by the system processing the packet, but also a value corresponding to a protocol not implemented, or even a value not yet assigned by the IANA [IANA_PROT_NUM].
プロトコルフィールドは、インターネットデータグラムにカプセル化されたプロトコルを示します。プロトコルフィールドは、パケットを処理するシステムだけでなく、実装されていないプロトコルに対応する値、またはまだIANA [IANA_PROT_NUM]によって割り当てられていない値で実装されたプロトコルに対応する値がないだけ含んでいてもよいです。
While in theory there should not be security implications from the use of any value in the protocol field, there have been security issues in the past with systems that had problems when handling packets with some specific protocol numbers [Cisco2003] [CERT2003].
理論的には、プロトコルフィールドの任意の値を使用することから、セキュリティへの影響があってはならないものの、いくつかの特定のプロトコル番号[Cisco2003] [CERT2003]でパケットを処理する際の問題を抱えていたシステムと、過去にセキュリティ上の問題がありました。
A host (i.e., end-system) that receives an IP packet encapsulating a Protocol it does not support should drop the corresponding packet, log the event, and possibly send an ICMP Protocol Unreachable (type 3, code 2) error message.
それは、対応するパケットをドロップイベントログ、および場合によってはICMPプロトコル到達不能（タイプ3、コード2）エラーメッセージを送信しなければならないサポートしないプロトコルをカプセル化するIPパケットを受信したホスト（すなわち、エンドシステム）。
The Header Checksum field is an error-detection mechanism meant to detect errors in the IP header. While in principle there should not be security implications arising from this field, it should be noted that due to non-RFC-compliant implementations, the Header Checksum might be exploited to detect firewalls and/or evade NIDSs.
ヘッダチェックサムフィールドは、IPヘッダ内のエラーを検出することを意味エラー検出メカニズムです。原則的には、このフィールドに起因するセキュリティ上の影響があってはならないが、非RFC準拠の実装に、ヘッダチェックサムは、ファイアウォールを検出および/またはNIDSsを回避するために悪用される可能性があることに留意すべきです。
[Ed3f2002] describes the exploitation of the TCP checksum for performing such actions. As there are Internet routers known to not check the IP Header Checksum, and there might also be middle-boxes (NATs, firewalls, etc.) not checking the IP checksum allegedly due to performance reasons, similar malicious activity to the one described in [Ed3f2002] might be performed with the IP checksum.
[Ed3f2002】このようなアクションを実行するためのTCPチェックサムの搾取を説明しています。パフォーマンス上の理由で説明したのと同様の悪質な活動に伝えられるところでIPチェックサムをチェックしていないIPヘッダチェックサムをチェックしないことが知られているインターネットルータがあり、また、（などのNAT、ファイアウォール、）ミドルボックスがあるかもしれないとして、[ Ed3f2002] IPチェックサムで実行されることがあります。
The Source Address of an IP datagram identifies the node from which the packet originated.
IPデータグラムの送信元アドレスは、パケットが発信されたノードを識別します。
Strictly speaking, the Source Address of an IP datagram identifies the interface of the sending system from which the packet was sent, (rather than the originating "system"), as in the Internet Architecture there's no concept of "node address".
厳密に言えば、IPデータグラムの送信元アドレスは、「ノードアドレス」の概念がありませんインターネットアーキテクチャのように、パケットを送信した送信側システムのインタフェース、（というよりも、元「システム」）を識別します。
Unfortunately, it is trivial to forge the Source Address of an Internet datagram because of the apparent lack of consistent "egress filtering" near the edge of the network. This has been exploited in the past for performing a variety of DoS attacks [NISCC2004] [RFC4987] [CERT1996a] [CERT1996b] [CERT1998a] and for impersonating other systems in scenarios in which authentication was based on the Source Address of the sending system [daemon91996].
残念ながら、あるため、ネットワークのエッジ付近の一貫した「出口フィルタリング」の見かけの不足のインターネットデータグラムの送信元アドレスを偽造することは簡単です。これは、DoS攻撃[NISCC2004] [RFC4987] [CERT1996a] [CERT1996b] [CERT1998a]のさまざまなを行うために、認証は、送信システムの送信元アドレスに基づいたシナリオ内の他のシステムを偽装するために、過去に利用されてきました[ daemon91996]。
The extent to which these attacks can be successfully performed in the Internet can be reduced through deployment of ingress/egress filtering in the Internet routers. [NISCC2006] is a detailed guide on ingress and egress filtering. [RFC2827] and [RFC3704] discuss ingress filtering. [GIAC2000] discusses egress filtering. [SpooferProject] measures the Internet's susceptibility to forged Source Address IP packets.
これらの攻撃が成功したインターネットで行なうことができる程度は、インターネットルータの入口/出口フィルタリングの導入によって削減することができます。 【NISCC2006】入力および出力フィルタリングの詳細なガイドです。 [RFC2827]と[RFC3704]は入力フィルタリングを議論します。 【GIAC2000】出力フィルタリングを論じています。 [SpooferProject]偽造ソースアドレス、IPパケットにインターネットの感受性を測定します。
Even when the obvious field on which to perform checks for ingress/egress filtering is the Source Address and Destination Address fields of the IP header, there are other occurrences of IP addresses on which the same type of checks should be performed. One example is the IP addresses contained in the payload of ICMP error messages, as discussed in [RFC5927] and [Gont2006].
上で明らかフィールドに入力するためのチェックを実行する場合であっても/出口フィルタリングは、IPヘッダの送信元アドレスおよび宛先アドレスフィールドであり、チェックの同じタイプを実行すべきでIPアドレスの他の出現があります。一例では、[RFC5927]で説明したように、ICMPエラーメッセージのペイロードに含まれるIPアドレスであり、[Gont2006]。
There are a number of sanity checks that should be performed on the Source Address of an IP datagram. Details can be found in Section 4.3 ("Addressing").
IPデータグラムの送信元アドレスに実行する必要があり健全性チェックの数があります。詳細は、4.3節（「アドレス指定」）に記載されています。
Additionally, there exist freely available tools that allow administrators to monitor which IP addresses are used with which MAC addresses [LBNL2006]. This functionality is also included in many NIDSs.
また、管理者は、MACは、[LBNL2006】アドレスれる使用されるIPアドレスを監視することができ、自由に利用できるツールが存在します。この機能は、多くのNIDSsに含まれています。
It is also very important to understand that authentication should never rely solely on the Source Address used by the communicating systems.
その認証は、通信システムで使用される送信元アドレスだけに頼るべきではありません理解することも非常に重要です。
The Destination Address of an IP datagram identifies the destination host to which the packet is meant to be delivered.
IPデータグラムの宛先アドレスは、パケットが配信されることを意図されている宛先ホストを識別します。
Strictly speaking, the Destination Address of an IP datagram identifies the interface of the destination network interface, rather than the destination "system", as in the Internet Architecture there's no concept of "node address".
厳密に言えば、IPデータグラムの宛先アドレスは、「ノードアドレス」の概念がありませんインターネットアーキテクチャのように、宛先ネットワークインタフェースのインタフェースではなく、先「システム」を識別します。
There are a number of sanity checks that should be performed on the Destination Address of an IP datagram. Details can be found in Section 4.3 ("Addressing").
IPデータグラムの宛先アドレスに実行する必要があり健全性チェックの数があります。詳細は、4.3節（「アドレス指定」）に記載されています。
According to RFC 791, IP options must be implemented by all IP modules, both in hosts and gateways (i.e., end-systems and intermediate-systems). This means that the general rules for assembling, parsing, and processing of IP options must be implemented. RFC 791 defines a set of options that "must be understood", but this set has been updated by RFC 1122 [RFC1122], RFC 1812 [RFC1812], and other documents. Section 3.13.2 of this document describes for each option type the current understanding of the implementation requirements. IP systems are required to ignore options they do not implement.
RFC 791によれば、IPオプションは、ホストとゲートウェイ（すなわち、エンドシステムと中間システム）の両方で、すべてのIPモジュールによって実施されなければなりません。これは、組立解析、およびIPオプションの処理のための一般的なルールが実装されなければならないことを意味します。 RFC 791は、「理解しなければならない」というオプションのセットを定義しますが、このセットは、RFC 1122 [RFC1122]、RFC 1812 [RFC1812]、および他の文書によって更新されています。このドキュメントのセクション3.13.2は、各オプションのタイプのための実装要件の現在の理解を説明しています。 IPシステムは、それらが実装していないオプションを無視する必要があります。
It should be noted that while a number of IP options have been specified, they are generally only used for troubleshooting purposes (except for the Router Alert option and the different Security options).
IPオプションの数が指定されているが、それらは一般的にのみ（ルータアラートオプションと異なるセキュリティオプションを除く）トラブルシューティングの目的のために使用されていることに留意すべきです。
There are two cases for the format of an option:
オプションのフォーマットのための2つのケースがあります。
o Case 1: A single byte of option-type.
Oケース1：オプション・タイプのシングルバイト。
o Case 2: An option-type byte, an option-length byte, and the actual option-data bytes.
oケース2：オプション型バイト、オプション長バイト、および実際のオプションデータバイト。
In Case 2, the option-length byte counts the option-type byte and the option-length byte, as well as the actual option-data bytes.
ケース2では、オプションの長さのバイトは、オプション型のバイトとオプション長のバイトだけでなく、実際のオプションデータバイトをカウントします。
All current and future options except End of Option List (Type = 0) and No Operation (Type = 1), are of Class 2.
オプションリストの最後（タイプ= 0）と動作なし（タイプ= 1）を除くすべての現在および将来のオプションは、クラス2です。
The option-type has three fields:
オプション型は、3つのフィールドがあります。
o 1 bit: copied flag.
O 1ビット：コピーフラグ。
o 2 bits: option class.
O 2ビット：オプションクラス。
o 5 bits: option number.
O 5ビット：オプション番号。
This format allows for the creation of new options for the extension of the Internet Protocol (IP) and their transparent treatment on intermediate-systems that do not "understand" them, under direction of the first three functional parts.
この形式は、最初の三つの機能部品の指示の下で、それらを「理解」していない中間のシステム上のインターネット・プロトコル（IP）とその透明治療の延長のための新しいオプションを作成できます。
The copied flag indicates whether this option should be copied to all fragments in the event the packet carrying it needs to be fragmented:
コピーされたフラグは、このオプションは、それを運ぶパケットがフラグメント化する必要がイベント内のすべてのフラグメントにコピーする必要があるかどうかを示します。
o 0 = not copied.
O 0 =コピーされません。
o 1 = copied.
1 O =コピー。
The values for the option class are:
オプションクラスの値は次のとおりです。
o 0 = control.
= 0コントロール。
o 1 = reserved for future use.
O 1 =は、将来の使用のために予約します。
o 2 = debugging and measurement.
O 2 =デバッグおよび測定。
o 3 = reserved for future use.
O 3 =は、将来の使用のために予約します。
Finally, the option number identifies the syntax of the rest of the option.
最後に、オプション番号は、オプションの残りの構文を識別します。
[IANA_IP_PARAM] contains the list of the currently assigned IP option numbers. It should be noted that IP systems are required to ignore those options they do not implement.
[IANA_IP_PARAM]現在割り当てられているIPオプション番号のリストが含まれています。 IPシステムは、彼らが実装していないこれらのオプションを無視する必要があることに留意すべきです。
The following subsections discuss security issues that apply to all IP options. The proposed checks should be performed in addition to any option-specific checks proposed in the next sections.
以下のサブセクションでは、すべてのIPオプションに適用されるセキュリティ上の問題を議論します。提案されたチェックは、次のセクションで提案されている任意のオプション固有のチェックに加えて行われるべきです。
Router manufacturers tend to do IP option processing on the main processor, rather than on line cards. Unless special care is taken, this represents DoS risk, as there is potential for overwhelming the router with option processing.
ルータのメーカーは、メインプロセッサ上ではなく、ラインカード上のIPオプションの処理を行う傾向にあります。特別な注意が取られない限り、オプション処理を持つルータを圧倒する可能性があるとして、これは、DoS攻撃のリスクを表します。
To reduce the impact of these packets on the system performance, a few countermeasures could be implemented: o Rate-limit the number of packets with IP options that are processed by the system.
システムのパフォーマンス上のこれらのパケットの影響を低減するために、いくつかの対策を実施することができますレート制限oをシステムによって処理されているIPオプション付きパケットの数を。
o Enforce a limit on the maximum number of options to be accepted on a given Internet datagram.
O指定したインターネットデータグラムに受け入れられるためのオプションの最大数の制限を強制します。
The first check avoids a flow of packets with IP options to overwhelm the system in question. The second check avoids packets with many IP options to affect the performance of the system.
最初のチェックは、問題のシステムを圧倒するIPオプション付きパケットの流れを回避することができます。第2のチェックは、システムのパフォーマンスに影響を与えるために、多くのIPオプション付きパケットを避けることができます。
Section 3.2.1.8 of RFC 1122 [RFC1122] states that all the IP options received in IP datagrams must be passed to the transport layer (or to ICMP processing when the datagram is an ICMP message). Therefore, care in option processing must be taken not only at the Internet layer but also in every protocol module that may end up processing the options included in an IP datagram.
RFC 1122のセクション3.2.1.8 [RFC1122]は（データグラムがICMPメッセージである場合、またはICMP処理へ）IPデータグラムに受信されたすべてのIPオプションは、トランスポート層に渡さなければならないと述べています。そのため、オプション処理におけるケアは、インターネット層でもIPデータグラムに含まれてオプションの処理に終わる可能性があり、すべてのプロトコルモジュールではないだけに注意しなければなりません。
There are a number of sanity checks that should be performed on IP options before further option processing is done. They help prevent a number of potential security problems, including buffer overflows. When these checks fail, the packet carrying the option should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
さらにオプション処理が行われる前にIPオプションで実行する必要があり健全性チェックの数があります。彼らは、バッファオーバーフローなど、潜在的なセキュリティ上の問題の数を、防ぐのに役立ちます。これらのチェックが失敗した場合、オプションを運ぶパケットは廃棄されるべきで、このイベントが記録されるべきである（例えば、カウンタは、パケット損失を反映するようにインクリメントすることができます）。
RFC 1122 [RFC1122] recommends to send an ICMP "Parameter Problem" message to the originating system when a packet is dropped because of an invalid value in a field, such as the cases discussed in the following subsections. Sending such a message might help in debugging some network problems. However, it would also alert attackers about the system that is dropping packets because of the invalid values in the protocol fields.
RFC 1122 [RFC1122]は、パケットが、次のサブセクションで説明したケースとして、理由フィールドに無効値でドロップされたときに、発信システムにICMP「パラメータ問題」メッセージを送信することをお勧めします。そのようなメッセージを送信すると、いくつかのネットワークの問題のデバッグに役立つかもしれません。しかし、それはまたあるため、プロトコルフィールドに無効な値のパケットをドロップされたシステムについての攻撃を警告します。
We advice that systems default to sending an ICMP "Parameter Problem" error message when a packet is dropped because of an invalid value in a protocol field (e.g., as a result of dropping a packet due to the sanity checks described in this section). However, we recommend that systems provide a system-wide toggle that allows an administrator to override the default behavior so that packets can be silently dropped when an invalid value in a protocol field is encountered.
パケットが（これは、このセクションで説明サニティ・チェックにパケットをドロップした結果として、例えば）ので、プロトコルフィールドに無効値でドロップされたときにICMP「パラメータ問題」エラーメッセージを送信するために、我々はアドバイスそのシステムのデフォルト。しかし、我々は、システムは、プロトコルフィールドに無効な値が検出されたときにパケットが静かにドロップできるように、管理者がデフォルトの動作をオーバーライドすることができ、システム全体のトグルを提供することをお勧めします。
Option length
オプション長
Section 3.2.1.8 of RFC 1122 explicitly states that the IP layer must not crash as the result of an option length that is outside the possible range, and mentions that erroneous option lengths have been observed to put some IP implementations into infinite loops.
RFC 1122のセクション3.2.1.8は、明示的にIP層は、可能な範囲外にあるオプションの長さの結果としてクラッシュしてはならないと述べて、誤ったオプションの長さが無限ループにいくつかのIPの実装を置くことが観察されていることを言及しています。
For options that belong to the "Case 2" described in the previous section, the following check should be performed:
前のセクションで説明した「ケース2」に属しているオプションについては、次のチェックを実行する必要があります。
option-length >= 2
オプション長> = 2
The value "2" accounts for the option-type byte and the option-length byte.
オプション型のバイトとオプション長のバイトの値が「2」のアカウント。
This check prevents, among other things, loops in option processing that may arise from incorrect option lengths.
このチェックは、とりわけ、防止間違ったオプションの長さから生じる可能性があるオプションの処理でループします。
Additionally, while the option-length byte of IP options of "Case 2" allows for an option length of up to 255 bytes, there is a limit on legitimate option length imposed by the space available for options in the IP header.
「ケース2」のIPオプションのオプションの長さのバイトは、最大255バイトのオプションの長さを可能にしながら加えて、IPヘッダ内のオプションのために利用可能な空間によって課さ正当オプションの長さには限界があります。
For all options of "Case 2", the following check should be enforced:
「ケース2」のすべてのオプションについて、以下のチェックが強制される必要があります。
option-offset + option-length <= IHL * 4
オプション・オフセット+オプション長<= IHL * 4
Where option-offset is the offset of the first byte of the option within the IP header, with the first byte of the IP header being assigned an offset of 0.
オプションオフセットは、IPヘッダの最初のバイトが0のオフセットを割り当てられると、IPヘッダ内のオプションの最初のバイトのオフセットです。
This check assures that the option does not claim to extend beyond the IP header. If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
このチェックはオプションでは、IPヘッダを超えて拡張するために主張しないことを保証します。パケットは、このチェックに合格しない場合は、それをドロップしなければならない、とこのイベントがログに記録されなければならない（例えば、カウンタは、パケットドロップを反映するためにインクリメントすることができます）。
The aforementioned check is meant to detect forged option-length values that might make an option overlap with the IP payload. This would be particularly dangerous for those IP options that request the processing systems to write information into the option-data area (such as the Record Route option), as it would allow the generation of overflows.
上記のチェックは、IPペイロードを持つオプションが重複したりすることがありますフォージドオプションの長さの値を検出するためのものです。これは、オーバーフローの発生を可能にするように、（例えば、経路記録オプションとして）オプションデータ領域に情報を書き込むための処理システムを要求したIPオプションのために特に危険です。
Data types
データタイプ
Many IP options use pointer and length fields. Care must be taken as to the data type used for these fields in the implementation. For example, if an 8-bit signed data type were used to hold an 8-bit pointer, then, pointer values larger than 128 might mistakenly be interpreted as negative numbers, and thus might lead to unpredictable results.
多くのIPオプションは、ポインタと長さフィールドを使用します。ケアは、実装では、これらのフィールドに使用されるデータ型にと注意する必要があります。 8ビットの符号付きデータ型は、8ビットのポインタを保持するために使用された場合、例えば、その後、128よりも大きいポインタ値が誤って負の数として解釈される可能性があり、したがって、予期しない結果につながる可能性があります。
This option is used to indicate the "end of options" in those cases in which the end of options would not coincide with the end of the Internet Protocol header. Octets in the IP header following the "End of Option List" are to be regarded as padding (they should set to 0 by the originator and must to be ignored by receiving nodes).
このオプションは、オプションの終わりには、インターネットプロトコルヘッダの終わりと一致しないであろうに、それらの例には、「オプションの終わり」を示すために使用されます。 「オプションリストの末尾」次のIPヘッダのオクテットはパディングとして見なされるべきである（それらは創始者によって0に設定しなければならず、受信ノードによって無視される必要があります）。
However, an originating node could alternatively fill the remaining space in the Internet header with No Operation options (see Section 3.13.2.2). The End of Option List option allows slightly more efficient parsing on receiving nodes and should be preferred by packet originators. All IP systems are required to understand both encodings.
しかしながら、発信元ノードは、代替的にノーオペレーションオプションでインターネットヘッダーの残りのスペースを埋めることができ（セクション3.13.2.2を参照）。オプション一覧オプションの終わりには、受信ノードに少しより効率的な解析を可能にし、パケットの発信者に好まれるべきです。すべてのIPシステムは、両方のエンコーディングを理解する必要があります。
The No Operation option is basically meant to allow the sending system to align subsequent options in, for example, 32-bit boundaries, but it can also be used at the end of the options (see Section 3.13.2.1).
ノーオペレーションオプションは基本的に送信側システムは、例えば、32ビット境界の後続オプションを整列することを可能にすることを意味するが、また、（項3.13.2.1を参照）オプションの終わりに使用することができます。
With a single exception (see Section 3.13.2.13), this option is the only IP option defined so far that can occur in multiple instances in a single IP packet.
唯一の例外では（セクション3.13.2.13を参照）、このオプションは、単一のIPパケットに複数のインスタンスで発生する可能性があり、これまでに定義された唯一のIPオプションです。
This option does not have security implications.
このオプションは、セキュリティ上の意味合いを持っていません。
This option lets the originating system specify a number of intermediate-systems a packet must pass through to get to the destination host. Additionally, the route followed by the packet is recorded in the option. The receiving host (end-system) must use the reverse of the path contained in the received LSRR option.
このオプションは、元のシステムは、パケットが宛先ホストに到達するために通過しなければならない中間システムの数を指定できます。また、パケットに続くルートはオプションに記録されています。受信ホスト（エンドシステム）は、受信LSRRオプションに含まれるパスの逆を使用しなければなりません。
The LSSR option can be of help in debugging some network problems. Some ISP (Internet Service Provider) peering agreements require support for this option in the routers within the peer of the ISP.
LSSRオプションは、いくつかのネットワーク問題をデバッグするのに役立つことができます。いくつかのISP（インターネットサービスプロバイダ）ピアリング契約はISPのピア内のルータでは、このオプションのサポートを必要としています。
The LSRR option has well-known security implications. Among other things, the option can be used to:
LSRRオプションは、よく知られたセキュリティ上の意味を持っています。とりわけ、オプションがするために使用することができます。
o Bypass firewall rules
Oバイパスファイアウォールルール
o Reach otherwise unreachable Internet systems
Oそれ以外の場合は到達不可能インターネットシステムをリーチ
o Establish TCP connections in a stealthy way
Oひそかな方法でTCPコネクションを確立します
o Learn about the topology of a network
Oネットワークのトポロジについて学びます
o Perform bandwidth-exhaustion attacks
O帯域枯渇攻撃を実行します
Of these attack vectors, the one that has probably received the least attention is the use of the LSRR option to perform bandwidth exhaustion attacks. The LSRR option can be used as an amplification method for performing bandwidth-exhaustion attacks, as an attacker could make a packet bounce multiple times between a number of systems by carefully crafting an LSRR option.
これらの攻撃ベクトルの、おそらく最も注目を集めている1は、帯域幅が枯渇攻撃を実行するためのLSRRオプションを使用することです。 LSRRオプションは、攻撃者がパケットを注意深くLSRRオプションを作り上げることにより、システムの数との間に複数回バウンス作ることができるように、帯域幅消耗攻撃を実行するための増幅方法として使用することができます。
This is the IPv4-version of the IPv6 amplification attack that was widely publicized in 2007 [Biondi2007]. The only difference is that the maximum length of the IPv4 header (and hence the LSRR option) limits the amplification factor when compared to the IPv6 counterpart.
これは、広く[Biondi2007] 2007年に公表されたIPv6の増幅攻撃のIPv4のバージョンです。唯一の違いは、IPv6対応物と比較した場合、IPv4ヘッダ（ひいてはLSRRオプション）の最大長さは、増幅率を制限することです。
While the LSSR option may be of help in debugging some network problems, its security implications outweigh any legitimate use.
LSSRオプションは、いくつかのネットワークの問題をデバッグするのに役立つかもしれないが、そのセキュリティへの影響は、正当な利用を上回ります。
All systems should, by default, drop IP packets that contain an LSRR option, and should log this event (e.g., a counter could be incremented to reflect the packet drop). However, they should provide a system-wide toggle to enable support for this option for those scenarios in which this option is required. Such system-wide toggle should default to "off" (or "disable").
すべてのシステムは、デフォルトでは、LSRRオプションが含まれているIPパケットをドロップする必要があり、（例えば、カウンタはパケットドロップを反映するためにインクリメントすることができる）、このイベントをログに記録する必要があります。しかし、彼らは、このオプションが必要とされるこれらのシナリオは、このオプションのサポートを有効にするには、システム全体のトグルを提供する必要があります。このようなシステム全体のトグルが「オフ」（または「無効」）をデフォルトとすべきです。
[OpenBSD1998] is a security advisory about an improper implementation of such a system-wide toggle in 4.4BSD kernels.
【OpenBSD1998] 4.4BSDカーネルにおけるそのようなシステム全体のトグルの不適切な実装に関するセキュリティアドバイザリです。
Section 3.3.5 of RFC 1122 [RFC1122] states that a host may be able to act as an intermediate hop in a source route, forwarding a source-routed datagram to the next specified hop. We strongly discourage host software from forwarding source-routed datagrams.
RFC 1122のセクション3.3.5 [RFC1122]は、ホストが次の指定されたホップに送信元経路データグラムを転送し、送信元経路における中間ホップとして作用することができるかもしれないと述べています。私たちは強くソースルートデータグラムを転送するからホストソフトウェアを落胆します。
If processing of source-routed datagrams is explicitly enabled in a system, the following sanity checks should be performed.
ソースルートデータグラムの処理が明示的にシステムで有効になっている場合は、以下の健全性チェックを実行する必要があります。
RFC 791 states that this option should appear, at most, once in a given packet. Thus, if a packet contains more than one LSRR option, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). Additionally, packets containing a combination of LSRR and SSRR options should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
RFC 791は、このオプションが2回与えられたパケットに、最大で、表示されるべきであると述べています。パケットが複数LSRRオプションが含まれている場合はこのように、それをドロップする必要があり、このイベントがログに記録されるべきである（例えば、カウンタは、パケット損失を反映するようにインクリメントすることができます）。また、LSRR及びSSRRオプションの組み合わせを含むパケットが廃棄されるべきで、このイベントが記録されるべきである（例えば、カウンタは、パケット損失を反映するようにインクリメントすることができます）。
As all other IP options of "Case 2", the LSSR contains a Length field that indicates the length of the option. Given the format of the option, the Length field should be checked to have a minimum value of three and be 3 (3 + n*4):
「ケース2」の他のすべてのIPオプションとして、LSSRは、オプションの長さを示す長さフィールドが含まれています。オプションの形式を考えると、長さフィールドは、3（3 + N * 4）3の最小値を持っていることを確認する必要があります。
LSRR.Length % 4 == 3 && LSRR.Length != 0
LSRR.Length％4 == 3 && LSRR.Length！= 0
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
パケットは、このチェックに合格しない場合は、それをドロップしなければならない、とこのイベントがログに記録されなければならない（例えば、カウンタは、パケットドロップを反映するためにインクリメントすることができます）。
The Pointer is relative to this option. Thus, the minimum legal value is 4. Therefore, the following check should be performed.
ポインタは、このオプションに関連しています。したがって、最小の法的な値は4したがって、以下のチェックが実行されるべきです。
LSRR.Pointer >= 4
LSRR.Pointer> = 4
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). Additionally, the Pointer field should be a multiple of 4. Consequently, the following check should be performed:
パケットは、このチェックに合格しない場合は、それをドロップしなければならない、とこのイベントがログに記録されなければならない（例えば、カウンタは、パケットドロップを反映するためにインクリメントすることができます）。また、ポインタフィールドは、結果的に4の倍数である必要があり、次のチェックを実行する必要があります。
LSRR.Pointer % 4 == 0
％4 == 0 LSRR.Pointer
If a packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
パケットは、このチェックに合格しない場合は、それをドロップしなければならない、とこのイベントがログに記録されなければならない（例えば、カウンタは、パケットドロップを反映するためにインクリメントすることができます）。
When a system receives an IP packet with the LSRR option passing the above checks, it should check whether or not the source route is empty. The option is empty if:
システムは、上記のチェックを通過LSRRオプションでIPパケットを受信すると、送信元経路が空であるか否かを確認しなければなりません。オプションがあれば空であります：
LSRR.Pointer > LSRR.Length
LSRR.Pointer> LSRR.Length
In that case, routing should be based on the Destination Address field, and no further processing should be done on the LSRR option.
その場合には、ルーティングは、宛先アドレスフィールドに基づくべきで、それ以上の処理はLSRRオプションで行われるべきではありません。
[Microsoft1999] is a security advisory about a vulnerability arising from improper validation of the LSRR.Pointer field.
【Microsoft1999] LSRR.Pointerフィールドの不適切な検証に起因する脆弱性に関するセキュリティ勧告です。
If the address in the Destination Address field has been reached, and the option is not empty, the next address in the source route replaces the address in the Destination Address field, and the IP address of the interface that will be used to forward this datagram is recorded in its place in the LSRR.Data field. Then, the LSRR.Pointer. is incremented by 4.
宛先アドレスフィールドのアドレスに達した、とオプションが空でない場合は、ソースルートの次のアドレスが宛先アドレスフィールドのアドレス、およびこのデータグラムを転送するために使用されるインターフェイスのIPアドレスを置き換えますLSRR.Dataフィールドにその場所に記録されています。その後、LSRR.Pointer。 4インクリメントされます。
Note that the sanity checks for the LSRR.Length and the LSRR.Pointer fields described above ensure that if the option is not empty, there will be (4*n) octets in the option. That is, there will be at least one IP address to read and enough room to record the IP address of the interface that will be used to forward this datagram.
LSRR.Lengthと上記LSRR.Pointerフィールドの健全性チェックはオプションが空でない場合、オプションで（4×n）のオクテットが存在するであろうことを保証することに注意してください。それは、少なくとも1つのIPアドレス読み取り、このデータグラムを転送するために使用されるインターフェイスのIPアドレスを記録するのに十分な余地があるだろう、です。
The LSRR must be copied on fragmentation. This means that if a packet that carries the LSRR is fragmented, each of the fragments will have to go through the list of systems specified in the LSRR option.
LSRRは断片化にコピーする必要があります。これはLSRRを運ぶパケットが断片化されている場合、各断片がLSRRオプションで指定されたシステムのリストを通過しなければならないことを意味します。
This option allows the originating system to specify a number of intermediate-systems a packet must pass through to get to the destination host. Additionally, the route followed by the packet is recorded in the option, and the destination host (end-system) must use the reverse of the path contained in the received SSRR option.
このオプションは、パケットが宛先ホストに到達するために通過しなければならない中間システムの数を指定するには、元のシステムを可能にします。また、パケットに続く経路はオプションで記録され、宛先ホスト（エンドシステム）は、受信SSRRオプションに含まれるパスの逆を使用しなければなりません。
This option is similar to the Loose Source and Record Route (LSRR) option, with the only difference that in the case of SSRR, the route specified in the option is the exact route the packet must take (i.e., no other intervening routers are allowed to be in the route).
このオプションは、SSRRの場合には、オプションで指定されたルートは、パケットが取る必要があります正確なルートである唯一の違いと、ルーズソースとRecordルート（LSRR）オプションに似ている（つまり、他の介在ルータが許可されていませんルートにあるように）。
The SSSR option can be of help in debugging some network problems. Some ISP (Internet Service Provider) peering agreements require support for this option in the routers within the peer of the ISP.
SSSRオプションは、いくつかのネットワーク問題をデバッグするのに役立つことができます。いくつかのISP（インターネットサービスプロバイダ）ピアリング契約はISPのピア内のルータでは、このオプションのサポートを必要としています。
The SSRR option has the same security implications as the LSRR option. Please refer to Section 3.13.2.3 for a discussion of such security implications.
SSRRオプションはLSRRオプションと同じセキュリティ上の意味を持っています。このようなセキュリティへの影響についての議論は、セクション3.13.2.3を参照してください。
As with the LSRR, while the SSSR option may be of help in debugging some network problems, its security implications outweigh any legitimate use of it.
SSSRのオプションは、一部のネットワークの問題をデバッグするのに役立つかもしれないがLSRRと同じように、そのセキュリティの意味はそれのいずれかの合法的な使用を上回ります。
All systems should, by default, drop IP packets that contain an SSRR option, and should log this event (e.g., a counter could be incremented to reflect the packet drop). However, they should provide a system-wide toggle to enable support for this option for those scenarios in which this option is required. Such system-wide toggle should default to "off" (or "disable").
すべてのシステムは、デフォルトでは、SSRRオプションが含まれているIPパケットをドロップする必要があり、（例えば、カウンタはパケットドロップを反映するためにインクリメントすることができる）、このイベントをログに記録する必要があります。しかし、彼らは、このオプションが必要とされるこれらのシナリオは、このオプションのサポートを有効にするには、システム全体のトグルを提供する必要があります。このようなシステム全体のトグルが「オフ」（または「無効」）をデフォルトとすべきです。
[OpenBSD1998] is a security advisory about an improper implementation of such a system-wide toggle in 4.4BSD kernels.
【OpenBSD1998] 4.4BSDカーネルにおけるそのようなシステム全体のトグルの不適切な実装に関するセキュリティアドバイザリです。
In the event processing of the SSRR option were explicitly enabled, the same sanity checks described for the LSRR option in Section 3.13.2.3 should be performed on the SSRR option. Namely, sanity checks should be performed on the option length (SSRR.Length) and the pointer field (SSRR.Pointer).
SSRRオプションのイベント処理を明示的に有効にされたでは、セクション3.13.2.3にLSRRオプションで説明したのと同じ健全性チェックがSSRRオプションで実行する必要があります。すなわち、健全性チェックはオプションの長さ（SSRR.Length）とポインタフィールド（SSRR.Pointer）上で実行されるべきです。
If the packet passes the aforementioned sanity checks, the receiving system should determine whether the Destination Address of the packet corresponds to one of its IP addresses. If does not, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
パケットは、前述の健全性チェックをパスした場合、受信システムは、パケットの宛先アドレスは、そのIPアドレスのいずれかに該当するかどうかを判断する必要があります。ない場合は、それをドロップしなければならない、とこのイベントがログに記録されなければならない（例えば、カウンタは、パケットドロップを反映するためにインクリメントすることができます）。
Contrary to the IP Loose Source and Record Route (LSRR) option, the SSRR option does not allow in the route other routers than those contained in the option. If the system implements the weak end-system model, it is allowed for the system to receive a packet destined to any of its IP addresses, on any of its interfaces. If the system implements the strong end-system model, a packet destined to it can be received only on the interface that corresponds to the IP address contained in the Destination Address field [RFC1122].
IPルーズソースとRecordルート（LSRR）オプションに反して、SSRRオプションがオプションに含まれているもの以外の経路の他のルータに許可していません。システムが弱いエンドシステムモデルを実装している場合、そのインターフェイスのいずれかで、そのIPアドレスのいずれか宛のパケットを受信するようにシステムに許可されています。システムは、強力なエンド・システム・モデルを実装する場合、それに宛てたパケットは、宛先アドレスフィールド[RFC1122]に含まれるIPアドレスに対応するインタフェースにのみ受信することができます。
If the packet passes this check, the receiving system should determine whether the source route is empty or not. The option is empty if:
パケットがこのチェックに合格した場合、受信システムは、ソース経路が空であるか否かを決定しなければなりません。オプションがあれば空であります：
SSRR.Pointer > SSRR.Length
SSRR.Pointer> SSRR.Length
In that case, if the address in the destination field has not been reached, the packet should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
宛先フィールドのアドレスに達していない場合この場合、パケットは廃棄されるべきで、このイベントが記録されるべきである（例えば、カウンタは、パケット損失を反映するようにインクリメントすることができます）。
[Microsoft1999] is a security advisory about a vulnerability arising from improper validation of the SSRR.Pointer field.
【Microsoft1999] SSRR.Pointerフィールドの不適切な検証に起因する脆弱性に関するセキュリティ勧告です。
If the option is not empty, and the address in the Destination Address field has been reached, the next address in the source route replaces the address in the Destination Address field, and the IP address of the interface that will be used to forward this datagram is recorded in its place in the source route (SSRR.Data field). Then, the SSRR.Pointer is incremented by 4.
オプションが空でないと、宛先アドレスフィールドのアドレスに達した場合は、ソースルートの次のアドレスが宛先アドレスフィールドのアドレス、およびこのデータグラムを転送するために使用されるインターフェイスのIPアドレスを置き換えますソースルート（SSRR.Dataフィールド）にその場所に記録されています。その後、SSRR.Pointerは4インクリメントされます。
Note that the sanity checks for the SSRR.Length and the SSRR.Pointer fields described above ensure that if the option is not empty, there will be (4*n) octets in the option. That is, there will be at least one IP address to read, and enough room to record the IP address of the interface that will be used to forward this datagram.
SSRR.Lengthと上記SSRR.Pointerフィールドの健全性チェックはオプションが空でない場合、オプションで（4×n）のオクテットが存在するであろうことを保証することに注意してください。それは、少なくとも1つのIPアドレス読むこと、およびこのデータグラムを転送するために使用されるインターフェイスのIPアドレスを記録するのに十分な余地があるだろう、です。
The SSRR option must be copied on fragmentation. This means that if a packet that carries the SSRR is fragmented, each of the fragments will have to go through the list of systems specified in the SSRR option.
SSRRオプションは断片化にコピーする必要があります。これはSSRRを運ぶパケットが断片化されている場合、各断片がSSRRオプションで指定されたシステムのリストを通過しなければならないことを意味します。
This option provides a means to record the route that a given packet follows.
このオプションは、与えられたパケットは、以下のルートを記録するための手段を提供します。
The option begins with an 8-bit option code, which is equal to 7. The second byte is the option length, which includes the option-type byte, the option-length byte, the pointer byte, and the actual option-data. The third byte is a pointer into the route data, indicating the first byte of the area in which to store the next route data. The pointer is relative to the option start.
オプションでは、第二のバイトはオプション型バイト、オプション長バイト、ポインタ・バイト、および実際のオプションデータを含むオプションの長さであり、7に等しい8ビットのオプションコード、始まります。 3番目のバイトは、次の経路データを格納する領域の最初のバイトを示し、経路データへのポインタです。ポインタは、オプションの開始に相対的です。
RFC 791 states that this option should appear, at most, once in a given packet. Therefore, if a packet has more than one instance of this option, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
RFC 791は、このオプションが2回与えられたパケットに、最大で、表示されるべきであると述べています。パケットがこのオプションの複数のインスタンスを有する場合、したがって、それをドロップする必要があり、このイベントがログに記録されるべきである（例えば、カウンタは、パケット損失を反映するようにインクリメントすることができます）。
The same sanity checks performed for the Length field and the Pointer field of the LSRR and the SSRR options should be performed on the Length field (RR.Length) and the Pointer field (RR.Pointer) of the RR option. As with the LSRR and SSRR options, if the packet does not pass these checks it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
LengthフィールドとLSRRとSSRRオプションのポインタフィールドに対して行わ同じ健全性チェックは、長さフィールド（RR.Length）及びRRオプションのポインタフィールド（RR.Pointer）上で実行されるべきです。パケットがこれらのチェックをパスしない場合LSRR及びSSRRオプションと同様に、それは廃棄されるべきであり、このイベントがログに記録されるべきである（例えば、カウンタは、パケット損失を反映するようにインクリメントすることができます）。
When a system receives an IP packet with the Record Route option that passes the above checks, it should check whether there is space in the option to store route information. The option is full if:
システムは、上記のチェックに合格経路記録オプションを使用してIPパケットを受信すると、経路情報を格納するためのオプションにスペースがあるかどうかを確認しなければなりません。オプションがあればいっぱいです。
RR.Pointer > RR.Length
RR.Pointer> RR.Length
If the option is full, the datagram should be forwarded without further processing of this option.
オプションがいっぱいの場合、データグラムは、このオプションの更なる処理なしに転送する必要があります。
If the option is not full (i.e., RR.Pointer <= RR.Length), the IP address of the interface that will be used to forward this datagram should be recorded into the area pointed to by the RR.Pointer, and RR.Pointer should then incremented by 4.
オプションは（すなわち、RR.Pointer <= RR.Length）一杯になっていない場合は、このデータグラムを転送するために使用されるインターフェイスのIPアドレスは、領域に記録されなければならないRR.Pointer、及びRRによって指さ。ポインタは、その後、4ずつ増加する必要があります。
This option is not copied on fragmentation, and thus appears in the first fragment only. If a fragment other than the one with offset 0 contains the Record Route option, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
このオプションは断片化にコピーされ、したがって、最初のフラグメントだけに表示されていません。以外の断片が0レコードルートオプションが含まれているオフセット場合、それは廃棄されるべきであり、このイベントがログに記録されるべきである（例えば、カウンタは、パケット損失を反映するようにインクリメントすることができます）。
The Record Route option can be exploited to learn about the topology of a network. However, the limited space in the IP header limits the usefulness of this option for that purpose if the target network is several hops away.
経路記録オプションは、ネットワークのトポロジについて学ぶために悪用される可能性があります。ターゲット・ネットワークが数ホップ離れている場合は、IPヘッダ内の限られたスペースには、その目的のために、このオプションの有用性を制限しています。
The Stream Identifier option originally provided a means for the 16-bit SATNET stream Identifier to be carried through networks that did not support the stream concept.
ストリーム識別子オプションは元々ストリーム概念をサポートしないネットワークを介して、16ビットSATNETストリーム識別子のための手段を提供します。
However, as stated by Section 4.2.2.1 of RFC 1812 [RFC1812], this option is obsolete. Therefore, it must be ignored by the processing systems.
RFC 1812 [RFC1812]のセクション4.2.2.1で述べたようにしかし、このオプションは廃止されました。したがって、処理システムによって無視されなければなりません。
In the case of legacy systems still using this option, the length field of the option should be checked to be 4. If the option does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
まだこのオプションを使用してレガシーシステムの場合は、オプションは、このチェックに合格しない場合はオプションの長さフィールドは4であることをチェックする必要があり、それがドロップする必要があり、このイベントがログに記録されなければならない（例えば、カウンタ可能性）パケットドロップを反映するためにインクリメントさ。
RFC 791 states that this option appears at most once in a given datagram. Therefore, if a packet contains more than one instance of this option, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
RFC 791は、このオプションが与えられたデータグラムで、最高1回表示されていることを述べています。パケットがこのオプションの複数のインスタンスを含む場合、したがって、それをドロップする必要があり、このイベントがログに記録されるべきである（例えば、カウンタは、パケット損失を反映するようにインクリメントすることができます）。
This option provides a means for recording the time at which each system processed this datagram. The timestamp option has a number of security implications. Among them are the following: o It allows an attacker to obtain the current time of the systems that process the packet, which the attacker may find useful in a number of scenarios.
このオプションは、各システムがこのデータグラムを処理した時刻を記録するための手段を提供します。タイムスタンプオプションは、セキュリティ上の影響の数を持っています。中でも以下である：攻撃者は、攻撃者がシナリオの数に有用かもしれパケットを処理するシステムの現在時刻を取得することができOを
o It may be used to map the network topology, in a similar way to the IP Record Route option.
O IP経路記録オプションと同様に、ネットワークトポロジをマッピングするために使用することができます。
o It may be used to fingerprint the operating system in use by a system processing the datagram.
Oはデータグラムを処理するシステムによって使用されているオペレーティングシステムをフィンガープリントするために使用することができます。
o It may be used to fingerprint physical devices by analyzing the clock skew.
Oクロック・スキューを解析することにより、物理デバイスをフィンガープリントするために使用することができます。
Therefore, by default, the timestamp option should be ignored.
そのため、デフォルトでは、タイムスタンプオプションは無視されるべきです。
For those systems that have been explicitly configured to honor this option, the rest of this subsection describes some sanity checks that should be enforced on the option before further processing.
このオプションを明示的に尊重するように設定されているそれらのシステムの場合、このサブセクションの残りの部分は、さらに処理する前にオプションで適用されなければならないいくつかの健全性チェックを説明しています。
The option begins with an option-type byte, which must be equal to 68. The second byte is the option-length, which includes the option-type byte, the option-length byte, the pointer, and the overflow/flag byte. The minimum legal value for the option-length byte is 4, which corresponds to an Internet Timestamp option that is empty (no space to store timestamps). Therefore, upon receipt of a packet that contains an Internet Timestamp option, the following check should be performed:
オプションは、オプション型バイト、オプション長バイト、ポインタ、およびオーバーフロー/フラグ・バイトを含む第2のバイトはオプション長さ68に等しくなければならないオプション型バイトから始まります。オプション長さのバイトの最小法定値は空であるインターネットタイムスタンプオプション（タイムスタンプを格納するためのスペースなし）に対応する、4です。そのため、インターネットのタイムスタンプオプションを含むパケットを受信すると、次のチェックを実行する必要があります。
IT.Length >= 4
IT.Length> = 4
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
パケットは、このチェックに合格しない場合は、それをドロップしなければならない、とこのイベントがログに記録されなければならない（例えば、カウンタは、パケットドロップを反映するためにインクリメントすることができます）。
The Pointer is an index within this option, counting the option type octet as octet #1. It points to the first byte of the area in which the next timestamp data should be stored and thus, the minimum legal value is 5. Since the only change of the Pointer allowed by RFC 791 is incrementing it by 4 or 8, the following checks should be performed on the Internet Timestamp option, depending on the Flag value (see below).
ポインタは、オクテット＃1として、オプションタイプのオクテットを数えて、このオプション内のインデックスです。これは、次のタイムスタンプデータを格納すべき領域の最初のバイトを指すとRFC 791によって許可さポインタの変化のみが4または8でそれをインクリメントしているので、したがって、最小法定値は5であり、次のチェック（下記参照）フラグの値に応じて、インターネットタイムスタンプオプションで実行する必要があります。
If IT.Flag is equal to 0, the following check should be performed:
IT.Flagが0に等しい場合、次のチェックを実行する必要があります。
IT.Pointer %4 == 1 && IT.Pointer != 1
IT.Pointer％4 == 1 && IT.Pointer！= 1
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
パケットは、このチェックに合格しない場合は、それをドロップしなければならない、とこのイベントがログに記録されなければならない（例えば、カウンタは、パケットドロップを反映するためにインクリメントすることができます）。
Otherwise, the following sanity check should be performed on the option:
それ以外の場合は、以下の健全性チェックはオプションで実行する必要があります。
IT.Pointer % 8 == 5
％8 == 5 IT.Pointer
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
パケットは、このチェックに合格しない場合は、それをドロップしなければならない、とこのイベントがログに記録されなければならない（例えば、カウンタは、パケットドロップを反映するためにインクリメントすることができます）。
The flag field has three possible legal values:
フラグフィールドは、次の3つの有効な値があります。
o 0: Record time stamps only, stored in consecutive 32-bit words.
0：レコードタイムスタンプのみ、連続する32ビットワードに格納されています。
o 1: Record each timestamp preceded with the Internet address of the registering entity.
1 O：登録エンティティのインターネットアドレスで始まる各タイムスタンプを記録します。
o 3: The internet address fields of the option are pre-specified. An IP module only registers its timestamp if it matches its own address with the next specified Internet address.
3 O：オプションのインターネットアドレスフィールドが事前に指定されています。それは次の指定されたインターネットアドレスと自身のアドレスと一致した場合、IPモジュールは、そのタイムスタンプを登録します。
Therefore the following check should be performed:
したがって、次のチェックを実行する必要があります。
IT.Flag == 0 || IT.Flag == 1 || IT.Flag == 3
IT.Flag == 0 || IT.Flag == 1 || IT.Flag == 3
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
パケットは、このチェックに合格しない場合は、それをドロップしなければならない、とこのイベントがログに記録されなければならない（例えば、カウンタは、パケットドロップを反映するためにインクリメントすることができます）。
The timestamp field is a right-justified 32-bit timestamp in milliseconds since UTC. If the time is not available in milliseconds, or cannot be provided with respect to UTC, then any time may be inserted as a timestamp, provided the high-order bit of the timestamp is set, to indicate this non-standard value.
タイムスタンプフィールドは、UTCからのミリ秒で右揃え32ビットのタイムスタンプです。時間はミリ秒単位で利用できない、またはUTCに対して提供することができない場合は、いつでもこの非標準値を示すために、タイムスタンプの上位ビットが設定されて設けられ、タイムスタンプとして挿入することができます。
According to RFC 791, the initial contents of the timestamp area must be initialized to zero, or Internet address/zero pairs. However, Internet systems should be able to handle non-zero values, possibly discarding the offending datagram.
RFC 791によると、タイムスタンプ領域の初期内容がゼロに初期化されなければならない、またはインターネットアドレス/ゼロのペア。しかし、インターネットシステムは、おそらく問題のあるデータグラムを破棄し、非ゼロの値を処理することができるはずです。
When an Internet system receives a packet with an Internet Timestamp option, it decides whether it should record its timestamp in the option. If it determines that it should, it should then determine whether the timestamp data area is full, by means of the following check:
インターネットシステムは、インターネットタイムスタンプオプション付きパケットを受信すると、それはオプションでそのタイムスタンプを記録するかどうかを決定します。それはそれが必要と判断した場合、それは、次のチェックにより、タイムスタンプデータ領域が満杯であるかどうかを判断する必要があります。
IT.Pointer > IT.Length
IT.Pointer> IT.Length
If this condition is true, the timestamp data area is full. If not, there is room in the timestamp data area.
この条件が真である場合には、タイムスタンプデータ領域がいっぱいです。ない場合は、タイムスタンプデータ領域の余地があります。
If the timestamp data area is full, the overflow byte should be incremented, and the packet should be forwarded without inserting the timestamp. If the overflow byte itself overflows, the packet should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
タイムスタンプデータ領域が一杯になると、オーバーフローバイトはインクリメントされなければならない、とパケットがタイムスタンプを挿入せずに転送する必要があります。オーバーフローバイト自体がオーバーフローした場合、パケットは廃棄されるべきで、このイベントが記録されるべきである（例えば、カウンタは、パケット損失を反映するようにインクリメントすることができます）。
If the timestamp data area is not full, then processing continues as follows (note that the above checks on IT.Pointer ensure that there is room for another entry in the option):
タイムスタンプデータ領域が満杯でない場合、次のように処理を継続する（IT.Pointerに上記チェックはオプションで別のエントリの余地があることを保証することに注意してください）。
o If IT.Flag is 0, then the system's 32-bit timestamp is stored into the area pointed to by the pointer byte and the pointer byte is incremented by 4.
IT.Flagが0の場合、Oは、システムの32ビットのタイムスタンプは、ポインタ・バイトによって指し示さポインタ・バイトを4だけインクリメントされた領域に格納されます。
o If IT.Flag is 1, then the IP address of the system is stored into the area pointed to by the pointer byte, followed by the 32-bit system timestamp, and the pointer byte is incremented by 8.
IT.Flagが1である場合、Oは、システムのIPアドレスは、領域に格納される32ビットのシステムタイムスタンプが続くポインタ・バイトによって指し示され、ポインタ・バイトは8だけインクリメントされます。
o Otherwise (IT.Flag is 3), if the IP address in the first 4 bytes pointed to by IT.Pointer matches one of the IP addresses assigned to an interface of the system, then the system's timestamp is stored into the area pointed to by IT.Pointer + 4, and the pointer byte is incremented by 8.
Oそうでない場合（IT.Flagが3である）、最初の4バイトにIPアドレスがIT.Pointerによって指し示さ場合、システムのインターフェイスに割り当てられたIPアドレスのいずれかと一致し、システムのタイムスタンプは、領域に格納され指さIT.Pointer + 4、及びポインタのバイトを8インクリメントされます。
[Kohno2005] describes a technique for fingerprinting devices by measuring the clock skew. It exploits, among other things, the timestamps that can be obtained by means of the ICMP timestamp request messages [RFC0791]. However, the same fingerprinting method could be implemented with the aid of the Internet Timestamp option.
【Kohno2005】クロック・スキューを測定することにより、フィンガープリントデバイスの技術が記載されています。それは、とりわけ、ICMPタイムスタンプ要求メッセージ[RFC0791]によって得ることができるタイムスタンプを利用します。しかし、同じフィンガープリント方法は、インターネットタイムスタンプオプションの助けを借りて実施することができます。
The Router Alert option is defined in RFC 2113 [RFC2113] and later updates to it have been clarified by RFC 5350 [RFC5350]. It contains a 16-bit Value governed by an IANA registry (see [RFC5350]). The Router Alert option has the semantic "routers should examine this packet more closely, if they participate in the functionality denoted by the Value of the option".
それはRFC 5350 [RFC5350]によって明らかにされているようにルータアラートオプションは、RFC 2113 [RFC2113]以降のアップデートで定義されています。それは、IANAレジストリによって支配16ビット値を含む（[RFC5350]を参照）。ルータアラートオプションは、「彼らはオプションの値によって示される機能に参加した場合に、より密接にこのパケットを調べる必要がありますルータ」意味を持っています。
According to the syntax of the option as defined in RFC 2113, the following check should be enforced, if the router supports this option:
ルータは、このオプションをサポートしている場合、RFC 2113で定義されているオプションの構文によると、次のチェックは、強制する必要があります。
RA.Length == 4
RA.Length == 4
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
パケットは、このチェックに合格しない場合は、それをドロップしなければならない、とこのイベントがログに記録されなければならない（例えば、カウンタは、パケットドロップを反映するためにインクリメントすることができます）。
A packet that contains a Router Alert option with an option value corresponding to functionality supported by an active module in the router will not go through the router's fast-path but will be processed in the slow path of the router, handing it over for closer inspection to the modules that has registered the matching option value. Therefore, this option may impact the performance of the systems that handle the packet carrying it.
ルータにアクティブモジュールによってサポートされる機能に対応するオプション値でルータアラートオプションが含まれているパケットは、ルータの高速パスを通過しませんが、精密検査のためにそれを手渡す、ルータの低速パスで処理されますマッチングオプション値が登録されているモジュールに。そのため、このオプションは、それを運ぶパケットを処理するシステムのパフォーマンスに影響を与える可能性があります。
[ROUTER-ALERT] analyzes the security implications of the Router Alert option, and identifies controlled environments in which the Router Alert option can be used safely.
[ROUTER-ALERT]はルータ警告オプションのセキュリティへの影響を解析し、ルータ警告オプションが安全に使用することができる制御された環境を識別する。
As explained in RFC 2113 [RFC2113], hosts should ignore this option.
RFC 2113 [RFC2113]で説明したように、ホストはこのオプションを無視すべきです。
This option was defined in RFC 1063 [RFC1063] and originally provided a mechanism to discover the Path-MTU.
このオプションは、RFC 1063 [RFC1063]で定義されており、本来はパスMTUを発見するためのメカニズムを提供しました。
This option is obsolete, and therefore any packet that is received containing this option should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
このオプションは廃止され、したがって（例えば、カウンタは、パケット損失を反映するようにインクリメントすることができる）、このオプションを含む受信された任意のパケットは廃棄されるべきで、このイベントが記録されるべきです。
This option is defined in RFC 1063 [RFC1063], and originally provided a mechanism to discover the Path-MTU.
このオプションは、RFC 1063 [RFC1063]で定義され、そして元々パスMTUを発見するためのメカニズムを提供します。
This option is obsolete, and therefore any packet that is received containing this option should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
このオプションは廃止され、したがって（例えば、カウンタは、パケット損失を反映するようにインクリメントすることができる）、このオプションを含む受信された任意のパケットは廃棄されるべきで、このイベントが記録されるべきです。
This option is defined in RFC 1393 [RFC1393], and originally provided a mechanism to trace the path to a host.
このオプションは、RFC 1393 [RFC1393]で定義され、そして本来ホストへのパスをトレースするための機構が設けられています。
The Traceroute option was specified as "experimental", and it was never deployed on the public Internet. Therefore, any packet that is received containing this option should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
tracerouteのオプションは、「実験」として指定されていた、それは公共のインターネット上で展開されていませんでした。したがって、このオプションを含む受信された任意のパケットは廃棄されるべきで、このイベントが記録されるべきである（例えば、カウンタは、パケット損失を反映するようにインクリメントすることができます）。
This option is used by Multi-Level-Secure (MLS) end-systems and intermediate-systems in specific environments to [RFC1108]:
このオプションは、[RFC1108]に特定の環境におけるマルチレベルセキュア（MLS）エンドシステムと中間システムによって使用されます。
o Transmit from source to destination in a network standard representation the common security labels required by computer security models,
O、ネットワークの標準的な表現でソースから宛先へのコンピュータ・セキュリティ・モデルによって必要とされる共通のセキュリティ・ラベルを送信
o Validate the datagram as appropriate for transmission from the source and delivery to the destination, and
Oソースおよび宛先への配信からの送信に応じてデータグラムを検証し、そして
o Ensure that the route taken by the datagram is protected to the level required by all protection authorities indicated on the datagram.
Oデータグラムによって取られた経路は、データグラムに表示されているすべての保護当局によって必要なレベルまで保護されていることを確認してください。
It is specified by RFC 1108 [RFC1108] (which obsoletes RFC 1038 [RFC1038]).
これは、RFC 1108 [RFC1108]で指定されている（RFC 1038 [RFC1038]を時代遅れ）。
RFC 791 [RFC0791] defined the "Security Option" (Type=130), which used the same option type as the DoD Basic Security option discussed in this section. The "Security Option" specified in RFC 791 is considered obsolete by Section 3.2.1.8 of RFC 1122, and therefore the discussion in this section is focused on the DoD Basic Security option specified by RFC 1108 [RFC1108].
RFC 791 [RFC0791]は、このセクションで説明国防総省基本セキュリティオプションとして同じオプションタイプを使用する「セキュリティオプション」（タイプ= 130）、定義されました。 RFC 791で指定された「セキュリティオプション」RFC 1122のセクション3.2.1.8で廃止されたと考えられ、そのため、この節での議論は、RFC 1108 [RFC1108]で指定された国防総省の基本的なセキュリティオプションに焦点を当てています。
Section 4.2.2.1 of RFC 1812 states that routers "SHOULD implement this option".
RFC 1812のセクション4.2.2.1は、ルータが、「このオプションを実装する必要があります」と述べています。
The DoD Basic Security option is currently implemented in a number of operating systems (e.g., [IRIX2008], [SELinux2009], [Solaris2007], and [Cisco2008]), and deployed in a number of high-security networks.
DoDの基本的なセキュリティ・オプションは、現在（例えば、[IRIX2008]、[SELinux2009]、[Solaris2007]、および[Cisco2008]）オペレーティングシステムの数に実装し、高セキュリティネットワークの数に配備されています。
Systems that belong to networks in which this option is in use should process the DoD Basic Security option contained in each packet as specified in [RFC1108].
このオプションが使用されているネットワークに属しているシステムでは、[RFC1108]で指定された各パケットに含まれる国防総省の基本的なセキュリティオプションを処理する必要があります。
RFC 1108 states that the option should appear at most once in a datagram. Therefore, if more than one DoD Basic Security option (BSO) appears in a given datagram, the corresponding datagram should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
RFC 1108はオプションがデータグラムで高々一度現れるべきであると述べています。複数の国防総省基本的なセキュリティオプション（BSO）が与えられたデータグラムに表示されている場合そのため、対応するデータグラムをドロップする必要があり、このイベントがログに記録されなければならない（例えば、カウンタは、パケットドロップを反映するためにインクリメントすることができます）。
RFC 1108 states that the option Length is variable, with a minimum option Length of 3 bytes. Therefore, the following check should be performed:
RFC 1108は、3バイトの最小オプション長で、オプションの長さが可変であることを述べています。したがって、次のチェックを実行する必要があります。
BSO.Length >= 3
BSO.Length> = 3
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
パケットは、このチェックに合格しない場合は、それをドロップしなければならない、とこのイベントがログに記録されなければならない（例えば、カウンタは、パケットドロップを反映するためにインクリメントすることができます）。
Current deployments of the security options described in this section and the two subsequent sections have motivated the specification of a "Common Architecture Label IPv6 Security Option (CALIPSO)" for the IPv6 protocol [RFC5570].
セキュリティオプションの現在の展開では、このセクションで説明し、2つの以降のセクションでは、IPv6プロトコル[RFC5570]のための「共通のアーキテクチャラベルIPv6セキュリティオプション（CALIPSO）」の仕様を動機としています。
This option permits additional security labeling information, beyond that present in the Basic Security option (Section 3.13.2.13), to be supplied in an IP datagram to meet the needs of registered authorities. It is specified by RFC 1108 [RFC1108].
このオプションは、登録機関のニーズを満たすためにIPデータグラムに供給されるように、基本的なセキュリティオプション（セクション3.13.2.13）でその存在を超えて、追加のセキュリティラベリング情報を許可します。これは、RFC 1108 [RFC1108]で指定されています。
This option may be present only in conjunction with the DoD Basic Security option. Therefore, if a packet contains a DoD Extended Security option (ESO), but does not contain a DoD Basic Security option, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). It should be noted that, unlike the DoD Basic Security option, this option may appear multiple times in a single IP header.
このオプションは、国防総省の基本的なセキュリティオプションと組み合わせて存在することができます。そのため、パケットが国防総省拡張セキュリティオプション（ESO）が含まれていますが、国防総省の基本的なセキュリティオプションが含まれていない場合は、それをドロップしなければならない、とこのイベントがログに記録されなければならない（例えば、カウンタはパケットドロップを反映するためにインクリメントすることができます） 。国防総省の基本的なセキュリティオプションとは異なり、このオプションは、単一のIPヘッダーで複数回表示されることがあり、ことに留意すべきです。
Systems that belong to networks in which this option is in use, should process the DoD Extended Security option contained in each packet as specified in RFC 1108 [RFC1108].
RFC 1108 [RFC1108]で指定され、このオプションが使用されているネットワークに属しているシステムでは、各パケットに含まれる国防総省拡張セキュリティオプションを処理する必要があります。
RFC 1108 states that the option Length is variable, with a minimum option Length of 3 bytes. Therefore, the following check should be performed:
RFC 1108は、3バイトの最小オプション長で、オプションの長さが可変であることを述べています。したがって、次のチェックを実行する必要があります。
ESO.Length >= 3
ESO.Length> = 3
If the packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
パケットは、このチェックに合格しない場合は、それをドロップしなければならない、とこのイベントがログに記録されなければならない（例えば、カウンタは、パケットドロップを反映するためにインクリメントすることができます）。
This option was proposed by the Trusted Systems Interoperability Group (TSIG), with the intent of meeting trusted networking requirements for the commercial trusted systems market place. It is specified in [CIPSO1992] and [FIPS1994].
このオプションは、市販の信頼できるシステム市場の場所のための信頼できるネットワーク要件を満たすことを意図して、信頼されたシステムの相互運用性・グループ（TSIG）によって提案されました。これは、[FIPS1994] [CIPSO1992]で指定し、されています。
The TSIG proposal was taken to the Commercial Internet Security Option (CIPSO) Working Group of the IETF [CIPSOWG1994], and an Internet-Draft was produced [CIPSO1992]. The Internet-Draft was never published as an RFC, but the proposal was later standardized by the U.S. National Institute of Standards and Technology (NIST) as "Federal Information Processing Standard Publication 188" [FIPS1994].
TSIGの提案は、商用インターネットセキュリティオプションIETF [CIPSOWG1994]の（CIPSO）ワーキンググループに運ばれた、およびインターネットドラフトは[CIPSO1992]を製造しました。 [FIPS1994]インターネットドラフトは、RFCとして公開されることはなかったが、提案は、後に「連邦情報処理標準出版188」として標準技術の米国国立研究所（NIST）によって標準化されました。
It is currently implemented in a number of operating systems (e.g., IRIX [IRIX2008], Security-Enhanced Linux [SELinux2009], and Solaris [Solaris2007]), and deployed in a number of high-security networks.
これは、現在のオペレーティングシステム（例えば、IRIX [IRIX2008]、セキュリティが強化Linuxの[SELinux2009]、およびSolaris [Solaris2007]）の数に実装し、安全性の高いネットワークの数に展開されています。
[Zakrzewski2002] and [Haddad2004] provide an overview of a Linux implementation.
[Zakrzewski2002]と[Haddad2004] Linuxの実装の概要を説明します。
Systems that belong to networks in which this option is in use should process the CIPSO option contained in each packet as specified in [CIPSO1992].
【CIPSO1992]で指定されるように、このオプションが使用されているネットワークに属しているシステムは、各パケットに含まれるCIPSOオプションを処理しなければなりません。
According to the option syntax specified in [CIPSO1992], the following validation check should be performed:
[CIPSO1992]で指定されたオプションの構文によると、次の検証チェックを実行する必要があります。
CIPSO.Length >= 6
Sipsoklenth> = 6
If a packet does not pass this check, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
パケットは、このチェックに合格しない場合は、それをドロップしなければならない、とこのイベントがログに記録されなければならない（例えば、カウンタは、パケットドロップを反映するためにインクリメントすることができます）。
This option is defined in RFC 1770 [RFC1770] and originally provided unreliable UDP delivery to a set of addresses included in the option.
このオプションは、[RFC1770] RFC 1770で定義されており、元々はオプションに含まれたアドレスのセットに信頼性のないUDP配信を提供します。
This option is obsolete. If a received packet contains this option, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
このオプションは廃止されました。受信したパケットは、このオプションが含まれている場合は、それをドロップしなければならない、とこのイベントがログに記録されなければならない（例えば、カウンタは、パケットドロップを反映するためにインクリメントすることができます）。
To accommodate networks with different Maximum Transmission Units (MTUs), the Internet Protocol provides a mechanism for the fragmentation of IP packets by end-systems (hosts) and/or intermediate-systems (routers). Reassembly of fragments is performed only by the end-systems.
異なる最大伝送単位（MTUの）とのネットワークを収容するために、インターネットプロトコルは、エンドシステム（ホスト）、および/または中間システム（ルータ）によってIPパケットの断片化のためのメカニズムを提供します。断片の再組み立ては、唯一のエンドシステムによって行われます。
[Cerf1974] provides the rationale for why packet reassembly is not performed by intermediate-systems.
【Cerf1974】パケット再構築が中間システムによって実行されていない理由のために根拠を提供します。
During the last few decades, IP fragmentation and reassembly has been exploited in a number of ways, to perform actions such as evading NIDSs, bypassing firewall rules, and performing DoS attacks.
過去数十年の間に、IPフラグメンテーションと再構成は、このような、NIDSsを回避するファイアウォールルールをバイパスし、DoS攻撃を実行するなどのアクションを実行するために、いくつかの方法で利用されてきました。
[Bendi1998] and [Humble1998] are examples of the exploitation of these issues for performing DoS attacks. [CERT1997] and [CERT1998b] document these issues. [Anderson2001] is a survey of fragmentation attacks. [US-CERT2001] is an example of the exploitation of IP fragmentation to bypass firewall rules. [CERT1999] describes the implementation of fragmentation attacks in Distributed Denial-of-Service (DDoS) attack tools.
【Bendi1998]および[Humble1998] DoS攻撃を実行するため、これらの問題の開発の例です。 [CERT1997]と[CERT1998b]これらの問題を文書化します。 [Anderson2001]フラグメンテーション攻撃の調査です。 [US-CERT2001]は、ファイアウォールルールをバイパスするIPフラグメンテーションの利用の一例です。 [CERT1999]分散型サービス拒否（DDoS）攻撃ツールで断片化攻撃の実装について説明します。
The problem with IP fragment reassembly basically has to do with the complexity of the function, in a number of aspects:
IPフラグメント再構成の問題は、基本的な側面の数に、機能の複雑さに関係しています。
o Fragment reassembly is a stateful operation for a stateless protocol (IP). The IP module at the host performing the reassembly function must allocate memory buffers both for temporarily storing the received fragments and to perform the reassembly function. Attackers can exploit this fact to exhaust memory buffers at the system performing the fragment reassembly.
O断片再組み立ては、ステートレス・プロトコル（IP）のためのステートフルな動作です。再アセンブリ機能を実行するホストのIPモジュールは、両方の一時的に受信された断片を格納するためのメモリバッファを割り当てる必要があり、再アセンブリ機能を実行します。攻撃者は、フラグメント再構成を実行するシステムのメモリバッファを排出するために、この事実を利用することができます。
o The fragmentation and reassembly mechanisms were designed at a time in which the available bandwidths were very different from the bandwidths available nowadays. With the current available bandwidths, a number of interoperability problems may arise, and these issues may be intentionally exploited by attackers to perform DoS attacks.
O断片化と再アセンブリのメカニズムは、利用可能な帯域幅は、今日利用可能な帯域幅は非常に異なるされた時点で設計しました。現在利用可能な帯域幅を使用すると、相互運用性の問題の数が発生する可能性があり、これらの問題は、意図的にDoS攻撃を実行するために、攻撃者によって悪用されることがあります。
o Fragment reassembly must usually be performed without any knowledge of the properties of the path the fragments follow. Without this information, hosts cannot make any educated guess on how long they should wait for missing fragments to arrive.
Oフラグメント再構成は、通常フラグメントが従う経路の特性の知識なしに行われなければなりません。この情報がなければ、ホストは、彼らが到着する断片を逃すために待機する時間上の任意の推測をすることはできません。
o The fragment reassembly algorithm, as described by the IETF specifications, is ambiguous, and allows for a number of interpretations, each of which has found place in different TCP/IP stack implementations.
フラグメント再構成アルゴリズムO、IETF仕様で記載されているように、曖昧であり、そして異なるTCP / IPスタック実装で場所を見つけた各々が解釈の数を可能にします。
o The reassembly process is somewhat complex. Fragments may arrive out of order, duplicated, overlapping each other, etc. This complexity has lead to numerous bugs in different implementations of the IP protocol.
Oリアセンブルプロセスは多少複雑です。フラグメントは、この複雑さは、IPプロトコルの異なる実装における多くのバグをもたらしたなど、互いにオーバーラップ、複製、順不同で到着することができます。
When an IP datagram is received by an end-system, it will be temporarily stored in system memory, until the IP module processes it and hands it to the protocol machine that corresponds to the encapsulated protocol.
IPデータグラムがエンドシステムによって受信されたときにIPモジュールがそれを処理し、カプセル化されたプロトコルに対応するプロトコル・マシンに渡すまで、それは一時的に、システムメモリに格納されます。
In the case of fragmented IP packets, while the IP module may perform preliminary processing of the IP header (such as checking the header for errors and processing IP options), fragments must be kept in system buffers until all fragments are received and are reassembled into a complete Internet datagram.
断片化されたIPパケットの場合には、IPモジュールは、（例えば、エラーや処理IPオプションのヘッダをチェックするように）IPヘッダの予備的処理を行ってもよいが、フラグメントは全ての断片が受信されるまで、システムバッファに保持されなければならずに再構築されます完全なインターネットデータグラム。
As mentioned above, because the Internet layer will not usually have information about the characteristics of the path between the system and the remote host, no educated guess can be made on the amount of time that should be waited for the other fragments to arrive. Therefore, the specifications recommend to wait for a period of time that is acceptable for virtually all the possible network scenarios in which the protocols might operate. After that time has elapsed, all the received fragments for the corresponding incomplete packet are discarded.
インターネット層は、通常、システムとリモートホスト間の経路の特性に関する情報を持っていないので、上述したように、全く推測が到着する他のフラグメントを待つされなければならない時間の量に行うことはできません。そのため、仕様はプロトコルが動作する可能性のあるほぼすべての可能なネットワークシナリオに許容される期間を待つことをお勧めします。その時間が経過した後、対応する不完全なパケットのためのすべての受信されたフラグメントが破棄されます。
The original IP Specification, RFC 791 [RFC0791], states that systems should wait for at least 15 seconds for the missing fragments to arrive. Systems that follow the "Example Reassembly Procedure" described in Section 3.2 of RFC 791 may end up using a reassembly timer of up to 4.25 minutes, with a minimum of 15 seconds. Section 3.3.2 ("Reassembly") of RFC 1122 corrected this advice, stating that the reassembly timeout should be a fixed value between 60 and 120 seconds.
オリジナルのIPの仕様、RFC 791 [RFC0791]は、行方不明の断片が到着するためのシステムは、少なくとも15秒間待つ必要があると述べています。 RFC 791のセクション3.2に記載された「例の再組み立て手順」に従うシステムは、15秒以上で、最大で4.25分の再構築タイマーを使用して終わる可能性があります。 RFC 1122の3.3.2項（「再アセンブリ」）は、再アセンブリタイムアウトが60秒から120秒の間に固定された値であることを述べ、このアドバイスを修正しました。
However, the longer the system waits for the missing fragments to arrive, the longer the corresponding system resources must be tied to the corresponding packet. The amount of system memory is finite, and even with today's systems, it can still be considered a scarce resource.
しかし、行方不明の断片が到着するのをシステムが待って長く、長く、対応するシステムリソースは、対応するパケットに接続する必要があります。システムメモリの量は有限であり、さらには今日のシステムで、それはまだ希少資源とみなすことができます。
An attacker could take advantage of the uncomfortable situation the system performing fragment reassembly is in, by sending forged fragments that will never reassemble into a complete datagram. That is, an attacker would send many different fragments, with different IP IDs, without ever sending all the necessary fragments that would be needed to reassemble them into a full IP datagram. For each of the fragments, the IP module would allocate resources and tie them to the corresponding fragment, until the reassembly timer for the corresponding packet expires.
攻撃者は、完全なデータグラムに組み立て直すことは決してありません鍛造断片を送信することにより、フラグメント再構成を実行するシステムが入っている不快な状況の利点を取ることができます。これは、攻撃者がこれまでにフルIPデータグラムにそれらを再構成するために必要とされるであろうすべての必要な断片を送信することなく、異なるIP IDを持つ、多くの異なる断片を送信し、です。断片のそれぞれについて、IPモジュールは、リソースを割り当てますし、対応するパケットの再構築タイマーが切れるまで、対応する断片にそれらを結びます。
There are some implementation strategies which could increase the impact of this attack. For example, upon receipt of a fragment, some systems allocate a memory buffer that will be large enough to reassemble the whole datagram. While this might be beneficial in legitimate cases, this just amplifies the impact of the possible attacks, as a single small fragment could tie up memory buffers for the size of an extremely large (and unlikely) datagram. The implementation strategy suggested in RFC 815 [RFC0815] leads to such an implementation.
この攻撃の影響を高めることができ、いくつかの実装方法があります。例えば、フラグメントの受信時に、いくつかのシステムは、全体のデータグラムを再構築するのに十分な大きさであろうメモリ・バッファを割り当てます。これは正当な場合に有益であるかもしれないが、単一の小さな断片が非常に大きい（および低い）データグラムのサイズのためにメモリバッファをタイアップ可能性として、これは単に、可能な攻撃の影響を増幅します。 RFC 815で提案されている実装戦略は、[RFC0815]は、このような実装につながります。
The impact of the aforementioned attack may vary depending on some specific implementation details:
前述の攻撃の影響は、いくつかの特定の実装の詳細に依存して変化し得ます。
o If the system does not enforce limits on the amount of memory that can be allocated by the IP module, then an attacker could tie all system memory to fragments, at which point the system would become unusable, perhaps crashing.
システムは、IPモジュールによって割り当て可能なメモリの量に制限を強制しない場合はO、攻撃者は、システムがクラッシュおそらく、使用できなくなるであろう点で、フラグメントにすべてのシステムメモリを結ぶことができました。
o If the system enforces limits on the amount of memory that can be allocated by the IP module as a whole, then, when this limit is reached, all further IP packets that arrive would be discarded, until some fragments time out and free memory is available again.
システム全体としてのIPモジュールによって割り当て可能なメモリの量に制限を強制する場合、この制限に達したときに、いくつかのフラグメントアウト時間と空きメモリがあるまで、O、次いで、到着するすべてのさらなるIPパケットは、廃棄されます再び使用可能。
o If the system enforces limits on the amount memory that can be allocated for the reassembly of fragments, then, when this limit is reached, all further fragments that arrive would be discarded, until some fragment(s) time out and free memory is available again.
システムがこの限界に達すると、その後、断片の再組み立てのために割り当てることができる量のメモリの制限を強制した場合、いくつかの断片（単数または複数）を時間と空きメモリが利用可能になるまでO、到着するすべてのさらなる断片は、廃棄されます再び。
4.1.1.2. Problems That Arise from the Length of the IP Identification Field
4.1.1.2。 IP識別フィールドの長さから生じる問題
The Internet Protocols are currently being used in environments that are quite different from the ones in which they were conceived. For instance, the availability of bandwidth at the time the Internet Protocol was designed was completely different from the availability of bandwidth in today's networks.
インターネットプロトコルは、現在、それらが考案されたものとは全く異なる環境で使用されています。例えば、インターネットプロトコルが設計された時点での帯域幅の利用可能性は、今日のネットワークの帯域幅の利用可能性とは全く異なっていました。
The Identification field is a 16-bit field that is used for the fragmentation and reassembly function. In the event a datagram gets fragmented, all the corresponding fragments will share the same {Source Address, Destination Address, Protocol, Identification number} four-tuple. Thus, the system receiving the fragments will be able to uniquely identify them as fragments that correspond to the same IP datagram. At a given point in time, there must be at most only one packet in the network with a given four-tuple. If not, an Identification number "collision" might occur, and the receiving system might end up "mixing" fragments that correspond to different IP datagrams which simply reused the same Identification number.
識別フィールドは、断片化と再アセンブリ機能のために使用される16ビットのフィールドです。データグラムが断片化されます場合には、すべての対応するフラグメントは、同じ{ソースアドレス、宛先アドレス、プロトコル、識別番号}四タプルを共有します。従って、フラグメントを受信するシステムが一意に同じIPデータグラムに対応するフラグメントとしてそれらを識別することができるであろう。ある時点で、与えられた4組と、ネットワーク内で最も唯一つのパケットが存在しなければなりません。そうでない場合、識別番号「衝突」が発生する可能性があり、受信システムは、単に、同一の識別番号を再利用し、異なるIPデータグラムに対応するフラグメントを「混合」に終わるかもしれません。
For example, sending over a 1 Gbit/s path a continuous stream of (UDP) packets of roughly 1 kb size that all get fragmented into two equally sized fragments of 576 octets each (minimum reassembly buffer size) would repeat the IP Identification values within less than 0.65 seconds (assuming roughly 10% link layer overhead); with shorter packets that still get fragmented, this figure could easily drop below 0.4 seconds. With a single IP packet dropped in this short time frame, packets would start to be reassembled wrongly and continuously once in such interval until an error detection and recovery algorithm at an upper layer lets the application back out.
例えば、1ギガビット/秒パスにすべてが576オクテットそれぞれ（最小再アセンブリバッファサイズ）の2つの等しいサイズのフラグメントに断片得るおおよそ1kbのサイズの（UDP）パケットの連続ストリーム上で送信内のIP識別値を繰り返すことになります未満で0.65秒（約10％のリンクレイヤオーバーヘッドを仮定して）。まだ断片化され得る短いパケットで、この数字は簡単に0.4秒以下に低下可能性があります。単一のIPパケットは、この短い時間枠にドロップすると、上位層でのエラー検出と回復アルゴリズムは、アプリケーションがバックアウトすることができますまで、パケットは、そのような間隔で一度誤って、継続的に再組み立てされ始めるだろう。
For each group of fragments whose Identification numbers "collide", the fragment reassembly will lead to corrupted packets. The IP payload of the reassembled datagram will be handed to the corresponding upper-layer protocol, where the error will (hopefully) be detected by some error detecting code (such as the TCP checksum) and the packet will be discarded.
識別番号「衝突」フラグメントの各グループのために、断片再組み立ては、破損したパケットにつながります。再組み立てデータグラムのIPペイロードは、エラーが（たぶん）（例えば、TCPチェックサムのような）いくつかのエラー検出コードによって検出され、パケットが破棄される対応する上位層プロトコルに渡されます。
An attacker could exploit this fact to intentionally cause a system to discard all or part of the fragmented traffic it gets, thus performing a DoS attack. Such an attacker would simply establish a flow of fragments with different IP Identification numbers, to trash all or part of the IP Identification space. As a result, the receiving system would use the attacker's fragments for the reassembly of legitimate datagrams, leading to corrupted packets which would later (and hopefully) get dropped.
攻撃者が意図的にこのようにDoS攻撃を実行し、それを取得断片化されたトラフィックの全部または一部を破棄するシステムを引き起こすために、この事実を悪用する可能性があります。このような攻撃者は単にIP識別空間の全部または一部をゴミ箱に、異なるIP識別番号とフラグメントの流れを確立します。その結果、受信システムは、後に（そして、できれば）廃棄されます破損したパケットにつながる、正当なデータグラムの再構築のために攻撃者のフラグメントを使用します。
In most cases, use of a long fragment timeout will benefit the attacker, as forged fragments will keep the IP Identification space trashed for a longer period of time.
鍛造断片は、時間の長い期間のためにゴミ箱IP識別空間を維持するようほとんどの場合、長い断片タイムアウトの使用は、攻撃者の利益になります。
4.1.1.3. Problems That Arise from the Complexity of the Reassembly Algorithm
4.1.1.3。再構築アルゴリズムの複雑から生じる問題
As IP packets can be duplicated by the network, and each packet may take a different path to get to the destination host, fragments may arrive not only out of order and/or duplicated but also overlapping. This means that the reassembly process can be somewhat complex, with the corresponding implementation being not specifically trivial.
IPパケットがネットワークによって複製することができ、かつ各パケットが宛先ホストに到達するために別のパスを取ることと、断片は、および/または複製にも重なって順不同ではないだけで到着するかもしれません。これは、再構成プロセスは、対応する実装は、特に簡単ではないことと、多少複雑になる可能性があることを意味します。
[Shannon2001] analyzes the causes and attributes of fragment traffic measured in several types of WANs.
【Shannon2001]原因およびWANのいくつかのタイプで測定フラグメントトラフィックの属性を分析します。
During the years, a number of attacks have exploited bugs in the reassembly function of several operating systems, producing buffer overflows that have led, in most cases, to a crash of the attacked system.
年の間に、攻撃の数は、攻撃を受けたシステムのクラッシュに、ほとんどの場合、つながっているバッファオーバーフローを生成する、いくつかのオペレーティング・システムの再構築機能のバグを悪用しています。
4.1.1.4. Problems That Arise from the Ambiguity of the Reassembly Process
4.1.1.4。再構築プロセスのあいまいさから生じる問題
Network Intrusion Detection Systems (NIDSs) typically monitor the traffic on a given network with the intent of identifying traffic patterns that might indicate network intrusions.
ネットワーク侵入検知システム（NIDSs）は、典型的には、ネットワーク侵入を示す可能性があるトラフィックパターンを特定する目的で特定のネットワーク上のトラフィックを監視します。
In the presence of IP fragments, in order to detect illegitimate activity at the transport or application layers (i.e., any protocol layer above the network layer), a NIDS must perform IP fragment reassembly.
IPフラグメントの存在下で、トランスポートまたはアプリケーション層（ネットワーク層上、すなわち、任意のプロトコル層）で不正なアクティビティを検出するために、NIDSはIPフラグメント再構成を実行しなければなりません。
In order to correctly assess the traffic, the result of the reassembly function performed by the NIDS should be the same as that of the reassembly function performed by the intended recipient of the packets.
正しくトラフィックを評価するために、NIDSによって実行される再構成関数の結果は、パケットの意図された受信者によって実行される再構成関数と同じであるべきです。
However, a number of factors make the result of the reassembly process ambiguous:
しかし、多くの要因は、再構築プロセスの結果が曖昧にします：
o The IETF specifications are ambiguous as to what should be done in the event overlapping fragments were received. Thus, in the presence of overlapping data, the system performing the reassembly function is free to honor either the first set of data received, the latest copy received, or any other copy received in between.
IETF仕様は、イベントの重複断片に何をすべきかに関して、あいまいであるoを受け取りました。したがって、データを重複の存在下で、再アセンブリ機能を実行するシステムは、データの最初のセットは、最新のコピーを受信し、または他の任意のコピーの間に受信し、受信されたいずれかの尊重して自由です。
o As the specifications do not enforce any specific fragment timeout value, different systems may choose different values for the fragment timeout. This means that given a set of fragments received at some specified time intervals, some systems will reassemble the fragments into a full datagram, while others may timeout the fragments and therefore drop them.
仕様は、任意の特定のフラグメントタイムアウト値を強制しないようにO、異なるシステムは、フラグメントタイムアウトの異なる値を選択することができます。これは、他の人がフラグメントタイムアウト、したがってそれらを落とすかもしれないが、いくつかの指定された時間間隔で受信されたフラグメントのセットが与えられると、いくつかのシステムは、完全なデータグラムに断片を再構成することを意味します。
o As mentioned before, as the fragment buffers get full, a DoS condition will occur unless some action is taken. Many systems flush part of the fragment buffers when some threshold is reached. Thus, depending on fragment load, timing issues, and flushing policy, a NIDS may get incorrect assumptions about how (and if) fragments are being reassembled by their intended recipient.
フラグメントバッファがいっぱいもらうとして、いくつかのアクションが実行されない限り、前に述べたようにO、、DoS状態が発生します。多くのシステムいくつかのしきい値に達したフラグメントバッファのフラッシュ部分。このように、フラグメントの負荷に応じて、問題、およびフラッシングポリシータイミング、NIDSは、フラグメントは自分の意図した受信者によって再組み立てされているか（と場合）に関する誤った仮定を得ることができます。
As originally discussed by [Ptacek1998], these issues can be exploited by attackers to evade intrusion detection systems.
元々[Ptacek1998]で議論したように、これらの問題は、侵入検知システムを回避するために攻撃者によって利用することができます。
There exist freely available tools to forcefully fragment IP datagrams so as to help evade Intrusion Detection Systems. Frag router [Song1999] is an example of such a tool; it allows an attacker to perform all the evasion techniques described in [Ptacek1998]. Ftester [Barisani2006] is a tool that helps to audit systems regarding fragmentation issues.
侵入検知システムを逃れる手助けするように強制的にIPデータグラムを断片化するために自由に利用できるツールが存在します。フラグ・ルータは、[Song1999】このようなツールの一例です。それは、攻撃者が[Ptacek1998]に記載されているすべての回避技術を実行することを可能にします。 Ftesterは[Barisani2006]断片化の問題について監査システムに役立つツールです。
One approach to fragment filtering involves keeping track of the results of applying filter rules to the first fragment (i.e., the fragment with a Fragment Offset of 0), and applying them to subsequent fragments of the same packet. The filtering module would maintain a list of packets indexed by the Source Address, Destination Address, Protocol, and Identification number. When the initial fragment is seen, if the MF bit is set, a list item would be allocated to hold the result of filter access checks. When packets with a non-zero Fragment Offset come in, look up the list element with a matching Source Address/Destination Address/Protocol/ Identification and apply the stored result (pass or block). When a fragment with a zero MF bit is seen, free the list element. Unfortunately, the rules of this type of packet filter can usually be bypassed. [RFC1858] describes the details of the involved technique.
フラグメントフィルタリングするための一つのアプローチは、最初のフラグメント（0のオフセットフラグメントと、すなわち、断片）にフィルタルールを適用し、同じパケットの後続のフラグメントにそれらを適用した結果を追跡することを含みます。フィルタリングモジュールは、送信元アドレス、宛先アドレス、プロトコル、および識別番号によってインデックス付けされたパケットのリストを維持するであろう。最初のフラグメントが見られる場合MFビットが設定されている場合、リスト項目は、フィルタアクセスチェックの結果を保持するために割り当てられます。オフセット非ゼロ断片とパケットが入ってきたときに、一致するソースアドレス/宛先アドレス/プロトコル/身分証明書をリスト要素を検索し、格納された結果（合格またはブロック）を適用します。ゼロMFビットを有する断片を見たとき、リスト要素を解放します。残念ながら、パケットフィルタのこのタイプのルールは、通常はバイパスすることができます。 [RFC1858]は関与手法の詳細について説明します。
A design choice usually has to be made as to how to allocate memory to reassemble the fragments of a given packet. There are basically two options: o Upon receipt of the first fragment, allocate a buffer that will be large enough to concatenate the payload of each fragment.
設計上の選択は、通常、与えられたパケットのフラグメントを再構成するためにメモリを割り当てる方法がなされる必要があります。 2つのオプションが基本的にあります：最初のフラグメントを受け取るとO、各フラグメントのペイロードを連結するのに十分な大きさであろうバッファを割り当てます。
o Upon receipt of the first fragment, create the first node of a linked list to which each of the following fragments will be linked. When all fragments have been received, copy the IP payload of each of the fragments (in the correct order) to a separate buffer that will be handed to the protocol being encapsulated in the IP payload.
O最初のフラグメントを受信すると、次のフラグメントのそれぞれがリンクされたリンクされたリストの最初のノードを作成します。すべてのフラグメントが受信された場合、IPペイロード内にカプセル化されたプロトコルに渡されるであろう別のバッファへの（正しい順序で）の断片の各々のIPペイロードをコピーします。
While the first of the choices might seem to be the most straightforward, it implies that even when a single small fragment of a given packet is received, the amount of memory that will be allocated for that fragment will account for the size of the complete IP datagram, thus using more system resources than what is actually needed.
選択肢の最初のが最も簡単なように見えるかもしれませんが、それは与えられたパケットの単一の小さな断片が受信された場合でも、そのフラグメントのために割り当てられますメモリの量は、完全なIPの大きさを占めるようになることを意味しデータグラムは、これ実際に必要とされるものよりも多くのシステムリソースを使用します。
Furthermore, the only situation in which the actual size of the whole datagram will be known is when the last fragment of the packet is received first, as that is the only packet from which the total size of the IP datagram can be asserted. Otherwise, memory should be allocated for the largest possible packet size (65535 bytes).
パケットの最後のフラグメントを最初に受信された場合には、IPデータグラムの合計サイズがアサート可能な唯一のパケットであるとしてさらに、全体のデータグラムの実際のサイズは知られている唯一の状況です。そうでなければ、メモリは、可能な最大パケットサイズ（65535バイト）に割り当てられるべきです。
The IP module should also enforce a limit on the amount of memory that can be allocated for IP fragments, as well as a limit on the number of fragments that at any time will be allowed in the system. This will basically limit the resources spent on the reassembly process, and prevent an attacker from trashing the whole system memory.
IPモジュールは、IPフラグメントのために割り当て可能なメモリの量、ならびに任意の時点でシステムに許可されるフラグメントの数の制限に制限を適用すべきです。これは、基本的に再構築プロセスに費やすリソースを制限し、システム全体のメモリを捨てるから、攻撃者を防ぐことができます。
Furthermore, the IP module should keep a different buffer for IP fragments than for complete IP datagrams. This will basically separate the effects of fragment attacks on non-fragmented traffic. Most TCP/IP implementations, such as that in Linux and those in BSD-derived systems, already implement this.
さらに、IPモジュールは、完全なIPデータグラムのためのよりIPフラグメントのために別のバッファを維持する必要があります。これは基本的に非断片化トラフィックのフラグメント攻撃の影響を分離します。 LinuxなどのそれとBSD由来のシステムのものとほとんどのTCP / IPの実装は、すでにこれを実装します。
[Jones2002] analyzes the amount of memory that may be needed for the fragment reassembly buffer depending on a number of network characteristics.
【Jones2002】ネットワークの特性の数に応じて断片再組み立てバッファのために必要とすることができるメモリの量を解析します。
In the case of those attacks that aim to consume the memory buffers used for fragments, and those that aim to cause a collision of IP Identification numbers, there are a number of countermeasures that can be implemented.
それらの断片のために使用されるメモリ・バッファを消費することを目指して攻撃、IP識別番号の衝突を引き起こすことを目的とするものの場合には、実装することができる対策がいくつかあります。
Even with these countermeasures in place, there is still the issue of what to do when the buffer pool used for IP fragments gets full. Basically, if the fragment buffer is full, no instance of communication that relies on fragmentation will be able to progress.
でも、代わりにこれらの対策で、IPフラグメントのために使用されるバッファー・プールが満杯になったときに何をすべきかの問題が依然として存在しています。断片バッファが満杯である場合、基本的には、断片化に依存している通信のインスタンスが進行することができなくなります。
Unfortunately, there are not many options for reacting to this situation. If nothing is done, all the instances of communication that rely on fragmentation will experience a denial of service. Thus, the only thing that can be done is flush all or part of the fragment buffer, on the premise that legitimate traffic will be able to make use of the freed buffer space to allow communication flows to progress.
残念ながら、このような状況に反応するための多くのオプションがありません。何もしていない場合は、断片化に依存している通信のすべてのインスタンスは、サービス拒否が発生します。このように、行うことができる唯一のことは、正当なトラフィックが通信中に流れできるように解放されたバッファスペースを利用することができるようになりますことを前提に、フラグメントバッファのフラッシュ全部または一部です。
There are a number of factors that should be taken into consideration when flushing the fragment buffers. First, if a fragment of a given packet (i.e., fragment with a given Identification number) is flushed, all the other fragments that correspond to the same datagram should be flushed. As in order for a packet to be reassembled all of its fragments must be received by the system performing the reassembly function, flushing only a subset of the fragments of a given packet would keep the corresponding buffers tied to fragments that would never reassemble into a complete datagram. Additionally, care must be taken so that, in the event that subsequent buffer flushes need to be performed, it is not always the same set of fragments that get dropped, as such a behavior would probably cause a selective DoS to the traffic flows to which that set of fragments belongs.
フラグメントバッファをフラッシュする際に考慮すべき多くの要因があります。所与のパケットの断片（すなわち、付与された識別番号を有するフラグメント）がフラッシュされた場合、まず、同じデータグラムに対応するすべての他のフラグメントは、フラッシュされるべきです。パケットが再組み立てされるためのようにそのフラグメントのすべてが完全に組み立て直すことはないフラグメントに縛ら対応するバッファを続けるだろう与えられたパケットのフラグメントのサブセットのみを洗い流す、再構築機能を実行するシステムが受信されなければなりませんデータグラム。さらに、ケアは、このような行動は、おそらくトラフィックに選択的にDoS攻撃を引き起こすとして、その後のバッファのフラッシュを実行する必要がいる場合には、それは、常にドロップ取得断片の同じセットではありませんように、これに流れて注意する必要がありますフラグメントのセットが属しています。
Many TCP/IP implementations define a threshold for the number of fragments that, when reached, triggers a fragment-buffer flush. Some systems flush 1/2 of the fragment buffer when the threshold is reached. As mentioned before, the idea of flushing the buffer is to create some free space in the fragment buffer, on the premise that this will allow for new and legitimate fragments to be processed by the IP module, thus letting communication survive the overwhelming situation. On the other hand, the idea of flushing a somewhat large portion of the buffer is to avoid flushing always the same set of packets.
多くのTCP / IPの実装は、到達した場合、断片バッファのフラッシュをトリガフラグメント数に対する閾値を定義します。フラグメントバッファの1/2フラッシュいくつかのシステムのしきい値に達しました。前に述べたように、バッファをフラッシュのアイデアは、このように通信が圧倒的な状況を乗り切るせ、IPモジュールによって処理される新しい合法的な断片を可能にすることを前提に、フラグメントバッファに空き領域を作成することです。一方、バッファの幾分大部分を洗い流すのアイデアは、常にパケットの同じセットをフラッシング回避することです。
One of the difficulties in implementing countermeasures for the fragmentation attacks described throughout Section 4.1 is that it is difficult to perform validation checks on the received fragments. For instance, the fragment on which validity checks could be performed, the first fragment, may be not the first fragment to arrive at the destination host.
4.1節を通じて記載フラグメンテーション攻撃のための対策を実施する際の困難の一つは、受け取った断片に検証チェックを行うことは困難であるということです。例えば、妥当性チェックは、最初のフラグメントを行うことができたフラグメントは、宛先ホストに到着しない最初のフラグメントであってもよいです。
Fragments cannot only arrive out of order because of packet reordering performed by the network, but also because the system (or systems) that fragmented the IP datagram may indeed transmit the fragments out of order. A notable example of this is the Linux TCP/IP stack, which transmits the fragments in reverse order.
断片は、ネットワークによって実行される並べ替えため、パケットの順序が狂って到着し、しかしすることができないためにも、実際に注文のうちの断片を送信することができるIPデータグラムを断片化システム（またはシステム）。本の顕著な例は、逆の順序でフラグメントを送信LinuxのTCP / IPスタック、です。
This means that we cannot enforce checks on the fragments for which we allocate reassembly resources, as the first fragment we receive for a given packet may be some other fragment than the first one (the one with an Fragment Offset of 0).
これは与えられたパケットのために受信する最初のフラグメントが最初の（0のオフセットフラグメントを有するもの）よりもいくつかの他の断片とすることができるように、我々は、我々が再アセンブリリソースを割り当てる対象の断片にチェックを強制することができないことを意味します。
However, at the point in which we decide to free some space in the fragment buffer, some refinements can be done to the flushing policy. The first thing we would like to do is to stop different types of traffic from interfering with each other. This means, in principle, that we do not want fragmented UDP traffic to interfere with fragmented TCP traffic. In order to implement this traffic separation for the different protocols, a different fragment buffer pool would be needed, in principle, for each of the 256 different protocols that can be encapsulated in an IP datagram.
しかし、我々はフラグメントバッファ内のいくつかの領域を解放することを決定した時点で、いくつかの改良がフラッシングポリシーに行うことができます。私たちがやりたいまず最初はお互いに干渉からのトラフィックの種類を停止することです。これは、私たちが断片化UDPトラフィックが断片化されたTCPトラフィックに干渉しないことを、原則的に、意味します。異なるプロトコルのためにこのトラフィック分離を実現するために、異なる断片バッファプールは、IPデータグラムにカプセル化することができる256個の異なるプロトコルのそれぞれについて、原理的に、必要とされるであろう。
We believe a trade-off is to implement two separate fragment buffers: one for IP datagrams that encapsulate IPsec packets and another for the rest of the traffic. This basically means that traffic not protected by IPsec will not interfere with those flows of communication that are being protected by IPsec.
トラフィックの残りのIPsecパケットと別のものをカプセル化したIPデータグラムの1：私たちは、トレードオフの2つの別々のフラグメントバッファを実装することであると信じています。これは基本的にIPsecによって保護されていないトラフィックにIPsecによって保護されている通信のこれらのフローを妨害しないことを意味します。
The processing of each of these two different fragment buffer pools would be completely independent from each other. In the case of the IPsec fragment buffer pool, when the buffers needs to be flushed, the following refined policy could be applied:
これら二つの異なるフラグメントバッファプールのそれぞれの処理は、互いに完全に独立であろう。バッファがフラッシュされる必要があるのIPsecフラグメントバッファ・プールの場合には、次の精製のポリシーを適用することができます。
o First, for each packet for which the IPsec header has been received, check that the Security Parameters Index (SPI) field of the IPsec header corresponds to an existing IPsec Security Association (SA), and probably also check that the IPsec sequence number is valid. If the check fails, drop all the fragments that correspond to this packet.
Oまず、IPsecヘッダが受信されたパケット毎に、IPsecヘッダのセキュリティパラメータインデックス（SPI）フィールドは、既存のIPsecセキュリティアソシエーション（SA）に対応しており、おそらくIPsecのシーケンス番号であることを確認することを確認有効。チェックが失敗した場合、このパケットに対応するすべてのフラグメントをドロップします。
o Second, if still more fragment buffers need to be flushed, drop all the fragments that correspond to packets for which the full IPsec header has not yet been received. The number of packets for which this flushing is performed depends on the amount of free space that needs to be created.
さらによりフラグメントバッファをフラッシュする必要がある場合は、O第二に、完全なIPsecヘッダがまだ受信されていないため、パケットに対応するすべてのフラグメントをドロップ。この洗浄が行われるため、パケットの数は、作成する必要がある空き領域の量に依存します。
o Third, if after flushing packets with invalid IPsec information (First step), and packets on which validation checks could not be performed (Second step), there is still not enough space in the fragment buffer, drop all the fragments that correspond to packets that passed the checks of the first step, until the necessary free space is created.
O第三には、無効なIPsecの情報（第1ステップ）、および検証チェックが実行できなかったパケット（第二ステップ）でパケットをフラッシングした後、フラグメントバッファ内に十分なスペースがまだ存在しない場合、パケットに対応するすべてのフラグメントをドロップ必要な空き領域が作成されるまで、それは、最初のステップのチェックを通過しました。
The rationale behind this policy is that, at the point of flushing fragment buffers, we prefer to keep those packets on which we could successfully perform a number of validation checks, over those packets on which those checks failed, or the checks could not even be performed.
この政策の理論的根拠は、フラグメントバッファのフラッシュの時点で、我々はそれらのチェックに失敗したそれらのパケット上で、我々は成功した検証チェックの数を実行することができた上でそれらのパケットを維持することを好む、または小切手でもあることができなかった、ということです行きました。
By checking both the IPsec SPI and the IPsec sequence number, it is virtually impossible for an attacker that is off-path to perform a DoS attack to communication flows being protected by IPsec.
IPsecのSPIとのIPsecシーケンス番号の両方をチェックすることによって、それは、IPsecによって保護されている通信フローに対するDoS攻撃を実行するオフパスで攻撃者にとっては事実上不可能です。
Unfortunately, some IP implementations (such as that in Linux [Linux]), when performing fragmentation, send the corresponding fragments in reverse order. In such cases, at the point of flushing the fragment buffer, legitimate fragments will receive the same treatment as the possible forged fragments.
フラグメンテーションを行う場合残念ながら、（例えばLinuxの[Linuxの]のもののような）いくつかのIP実装は、逆の順序に対応するフラグメントを送信します。このような場合には、フラグメントバッファをフラッシュした時点で、正当な断片は可能鍛造断片と同じ処理を受けます。
This refined flushing policy provides an increased level of protection against this type of resource exhaustion attack, while not making the situation of out-of-order IPsec-secured traffic worse than with the simplified flushing policy described in the previous section.
前のセクションで説明した単純化されたフラッシング方針により悪いアウトオブオーダーIPsecで保護されているトラフィックの状況を作っていないながら、この洗練されたフラッシングポリシーは、リソースの枯渇のこの種の攻撃に対する保護レベルの増加を提供します。
RFC 1122 [RFC1122] states that the reassembly timeout should be a fixed value between 60 and 120 seconds. The rationale behind these long timeout values is that they should accommodate any path characteristics, such as long-delay paths. However, it must be noted that this timer is really measuring inter-fragment delays, or, more specifically, fragment jitter.
RFC 1122 [RFC1122]は再組立てタイムアウトが60と120秒の間、固定値でなければならないと述べています。これらの長いタイムアウト値の背後にある理論的根拠は、それらがそのような長い遅延経路などの任意の経路特性を、対応すべきであるということです。しかし、このタイマーが本当にフラグメントジッタ、より具体的には、間の断片の遅延を測定する、またはされていることに留意しなければなりません。
If all fragments take paths of similar characteristics, the inter-fragment delay will usually be, at most, a few seconds. Nevertheless, even if fragments take different paths of different characteristics, the recommended 60 to 120 seconds are, in practice, excessive.
すべてのフラグメントは、同様の特性のパスを取る場合は、インターフラグメント遅延は通常、せいぜい、数秒になります。それにも関わらず、フラグメントは異なる特性の異なるパスを取る場合でも、推奨さ60〜120秒では、実際には、過度のです。
Some systems have already reduced the fragment timeout to 30 seconds [Linux]. The fragment timeout could probably be further reduced to approximately 15 seconds; although further research on this issue is necessary.
一部のシステムでは、すでに30秒[Linuxの]にフラグメントタイムアウトが減少しています。フラグメントタイムアウトは、おそらく、さらに約15秒に短縮することができ、この問題についてであるが、さらに研究が必要です。
It should be noted that in network scenarios of long-delay and high-bandwidth (usually referred to as "Long-Fat Networks"), using a long fragment timeout would likely increase the probability of collision of IP ID numbers. Therefore, in such scenarios it is highly desirable to avoid the use of fragmentation with techniques such as PMTUD [RFC1191] or PLPMTUD [RFC4821].
長い遅延と高帯域幅のネットワークシナリオに可能性の高いIPのID番号の衝突の確率を増加させるの長さの断片のタイムアウトを使用して、（通常は「ロングファットネットワーク」と呼ばれる）ことに留意すべきです。したがって、このようなシナリオでは、PMTUD [RFC1191]またはPLPMTUD [RFC4821]などの技術を有する断片の使用を回避することが非常に望ましいです。
[Shankar2003] introduces a technique named "Active Mapping" that prevents evasion of a NIDS by acquiring sufficient knowledge about the network being monitored, to assess which packets will arrive at the intended recipient, and how they will be interpreted by it. [Novak2005] describes some techniques that are applied by the Snort [Snort] NIDS to avoid evasion.
【Shankar2003】パケットが意図された受信者に到達するどの評価するために、監視されているネットワークについての十分な知識を取得することにより、NIDSの回避を防止する「アクティブ・マッピング」、およびどのようにそれが解釈されるであろうという名前の技術を導入します。 【Novak2005】回避を避けるためのSnort [Snortの】NIDSによって適用されるいくつかの技術が記載されています。
One of the classical techniques to bypass firewall rules involves sending packets in which the header of the encapsulated protocol is fragmented. Even when it would be legal (as far as the IETF specifications are concerned) to receive such a packets, the MTUs of the network technologies used in practice are not that small to require the header of the encapsulated protocol to be fragmented (e.g., see [RFC2544]). Therefore, the system performing reassembly should drop all packets which fragment the upper-layer protocol header, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
ファイアウォールルールをバイパスする古典的な技術の一つは、カプセル化されたプロトコルのヘッダは、断片化されたパケットを送信することを含みます。そのようなパケットを受信する（限りIETF仕様は懸念しているように）合法であろう場合であっても、実際に使用されるネットワーク技術のMTUが断片化されるカプセル化されたプロトコルのヘッダを必要とすること小さくない（例えば、参照[RFC2544]）。したがって、再アセンブリを実行するシステムは、上位層プロトコルのヘッダを断片化するすべてのパケットをドロップする必要があり、このイベントが記録されるべきである（例えば、カウンタは、パケット損失を反映するようにインクリメントすることができます）。
Additionally, given that many middle-boxes such as firewalls create state according to the contents of the first fragment of a given packet, it is best that, in the event an end-system receives overlapping fragments, it honors the information contained in the fragment that was received first.
また、ファイアウォールなどの多くのミドルボックスが所与のパケットの最初のフラグメントの内容に応じて状態を作成することを考えると、それは、エンドシステムがフラグメントを重複受信する場合には、それがフラグメントに含まれる情報を表彰、それが最良ですそれは、最初に受信しました。
RFC 1858 [RFC1858] describes the abuse of IP fragmentation to bypass firewall rules. RFC 3128 [RFC3128] corrects some errors in RFC 1858.
RFC 1858 [RFC1858]は、ファイアウォールルールをバイパスするIPフラグメンテーションの乱用を説明しています。 RFC 3128 [RFC3128]は、RFC 1858でいくつかのエラーを修正します。
Section 5.3.3.1 of RFC 1812 [RFC1812] states that routers should implement precedence-ordered queue service. This means that when a packet is selected for output on a (logical) link, the packet of highest precedence that has been queued for that link is sent. Section 5.3.3.2 of RFC 1812 advises routers to default to maintaining strict precedence-ordered service.
RFC 1812 [RFC1812]のセクション5.3.3.1は、ルータが優先順序キューサービスを実装するべきであると述べています。これは、パケットが（論理）リンク上の出力を選択した場合、そのリンクのためにキューイングされた最も高い優先度のパケットが送信されることを意味します。 RFC 1812のセクション5.3.3.2は、厳格な優先順のサービスを維持するためにデフォルトにルータをアドバイスします。
Unfortunately, given that it is trivial to forge the IP precedence field of the IP header, an attacker could simply forge a high precedence number in the packets it sends to illegitimately get better network service. If precedence-ordered queued service is not required in a particular network infrastructure, it should be disabled, and thus all packets would receive the same type of service, despite the values in their Type of Service or Differentiated Services fields.
残念ながら、IPヘッダーのIP precedenceフィールドを偽造するのは簡単であることを考えると、攻撃者は単にそれが不正優れたネットワークサービスを取得するために送信するパケットで高い優先順位番号を偽造する可能性があります。優先度順の待ち行列に入れサービスは、特定のネットワーク・インフラストラクチャで必要とされていない場合は、無効にする必要があり、したがって、すべてのパケットがサービスや差別化サービス分野の彼らのタイプの値にもかかわらず、サービスの同じ種類を受け取ることになります。
When precedence-ordered queue service is required in the network infrastructure, in order to mitigate the attack vector discussed in the previous paragraph, edge routers or switches should be configured to police and remark the Type of Service or Differentiated Services values, according to the type of service at which each end-system has been allowed to send packets.
優先順序キューサービスがネットワークインフラストラクチャに必要とされる場合、前の段落で述べた攻撃ベクトルを軽減するために、エッジルータまたはスイッチが警察に設定され、サービスや差別化サービス値のタイプを発言する必要があり、種類に応じて、サービスの各エンドシステムは、パケットを送信することを許可された時。
Bullet 4 of Section 5.3.3.3 of RFC 1812 states that routers "MUST NOT change precedence settings on packets it did not originate". However, given the security implications of the Precedence field, it is fair for routers, switches, or other middle-boxes, particularly those in the network edge, to overwrite the Type of Service (or Differentiated Services) field of the packets they are forwarding, according to a configured network policy (this is the specified behavior for DS domains [RFC2475]).
RFC 1812のセクション5.3.3.3の弾丸4は、ルータは、「それが発信されなかったパケットに優先順位の設定を変更してはならない」と述べています。しかし、優先順位フィールドのセキュリティへの影響を考えると、それは転送されるパケットのフィールドサービス（または差別化サービス）のタイプを上書きするために、ルータ、スイッチ、または他の中央ボックス、ネットワークのエッジにおいて、特にそれらの公正です、設定されたネットワークポリシーに従って（これはDSドメイン[RFC2475]に指定された動作です）。
Sections 5.3.3.1 and 5.3.6 of RFC 1812 state that if precedence-ordered queue service is implemented and enabled, the router "MUST NOT discard a packet whose precedence is higher than that of a packet that is not discarded". While this recommendation makes sense given the semantics of the Precedence field, it is important to note that it would be simple for an attacker to send packets with forged high Precedence value to congest some internet router(s), and cause all (or most) traffic with a lower Precedence value to be discarded.
優先順序キューサービスが実装され、有効になっている場合、ルータは「優先破棄されていないパケットよりも高いパケットを廃棄してはならない」というセクション5.3.3.1およびRFCの5.3.6は、1812年の状態。この勧告は、優先フィールドのセマンティクス与えられた意味がありますが、それはいくつかのインターネットルータ（複数可）混雑する鍛造高い優先順位値を持つパケットを送信するために、攻撃者のための簡単なもので、すべての（またはほとんど）を引き起こすことに注意することが重要です優先順位の低い値を持つトラフィックが破棄されます。
Section 5.2.4.3 of RFC 1812 describes the algorithm for determining the next-hop address (i.e., the forwarding algorithm). Bullet 3, "Weak TOS", addresses the case in which routes contain a "type of service" attribute. It states that in case a packet contains a non-default TOS (i.e., 0000), only routes with the same TOS or with the default TOS should be considered for forwarding that packet. However, this means that if among the longest match routes for a given packet are routes with some TOS other than the one contained in the received packet, and no routes with the default TOS, the corresponding packet would be dropped. This may or may not be a desired behavior.
RFC 1812のセクション5.2.4.3は、次ホップアドレス（即ち、転送アルゴリズム）を決定するためのアルゴリズムを記載しています。弾丸3、「弱いTOSは」、ルートは属性「サービスの種類」が含まれている場合に対応しています。それは場合に、パケットがそのパケットを転送するために考慮されるべきである非デフォルトTOS（すなわち、0000）、同じTOS有するか、デフォルトのTOSを持つルートのみが含まれていることを述べています。しかし、これは、与えられたパケットの最長一致ルートのうち、受信したパケットに含まれる1つ以外のTOSを持つルート、およびデフォルトのTOSとのない経路である場合、対応するパケットが廃棄されることを意味します。これは、または所望の行動であってもなくてもよいです。
An alternative for the case in which among the "longest match" routes there are only routes with non-default type of service that do not match the TOS contained in the received packet, would be to use a route with any other TOS. While this route would most likely not be able to address the type of service requested by packet, it would, at least, provide a "best effort" service.
「最長マッチ」の経路のうち、受信したパケットに含まれるTOSと一致しないサービスのデフォルト以外のタイプのルートのみが存在する場合の代替手段は、他のTOSのルートを使用することであろう。このルートが最も可能性の高いパケットによって要求されたサービスの種類に対処することはできないだろうが、それは、少なくとも、「ベストエフォート」のサービスを提供します。
It must be noted that Section 5.3.2 of RFC 1812 allows routers to not honor the TOS field. Therefore, the proposed alternative behavior is still compliant with the IETF specifications.
RFC 1812のセクション5.3.2は、ルータがTOSフィールドを称えるないことを可能にすることに留意しなければなりません。したがって、提案された代替行動はまだIETF仕様に準拠しています。
While officially specified in the RFC series, TOS-based routing is not widely deployed in the Internet.
正式にRFCシリーズで指定しますが、TOSベースのルーティングは、インターネットで広く展開されていません。
In the case of broadcast link-layer technologies, in order for a system to transfer an IP datagram it must usually first map an IP address to the corresponding link-layer address (for example, by means of the Address Resolution Protocol (ARP) [RFC0826]) . This means that while this operation is being performed, the packets that would require such a mapping would need to be kept in memory. This may happen both in the case of hosts and in the case of routers.
放送リンク層技術の場合には、IPデータグラムを転送するシステムのために、それは通常、最初の[（例えば、アドレス解決プロトコル（ARP）によって、対応するリンク層アドレスにIPアドレスをマップする必要がありますRFC0826]）。これは、この操作が行われている間、そのようなマッピングを必要とするパケットはメモリに保持する必要があることを意味します。これは、ホストの場合やルータの場合は、両方が起こることがあります。
This situation might be exploited by an attacker, which could send a large amount of packets to a non-existent host that would supposedly be directly connected to the attacked router. While trying to map the corresponding IP address into a link-layer address, the attacked router would keep in memory all the packets that would need to make use of that link-layer address. At the point in which the mapping function times out, depending on the policy implemented by the attacked router, only the packet that triggered the call to the mapping function might be dropped. In that case, the same operation would be repeated for every packet destined to the non-existent host. Depending on the timeout value for the mapping function, this situation might lead the router to run out of free buffer space, with the consequence that incoming legitimate packets would have to be dropped, or that legitimate packets already stored in the router's buffers might get dropped. Both of these situations would lead either to a complete DoS or to a degradation of the network service.
この状況は、おそらく直接攻撃ルータに接続される、存在しないホストに大量のパケットを送信することができ、攻撃者によって悪用される可能性があります。リンク層アドレスに対応するIPアドレスをマップしようとしますが、攻撃ルータはメモリにそのリンク層アドレスを利用するために必要となるすべてのパケットを続けるだろう。時点で、ここでマッピング機能がタイムアウトし、攻撃ルータによって実装ポリシーに応じて、マッピング関数の呼び出しをトリガーのみパケットはドロップされる可能性があります。その場合は、同じ操作は、存在しないホスト宛のパケットごとに繰り返されます。マッピング機能のタイムアウト値に応じて、このような状況は、着信正当なパケットが廃棄されなければならないという結果で、空きバッファ領域が不足するようにルータを導くかもしれない、またはすでにルータのバッファに格納されている正当なパケットが廃棄される可能性があります。これらの状況のどちらも、いずれかの完全なDoS攻撃やネットワークサービスの低下につながります。
One countermeasure to this problem would be to drop, at the point the mapping function times out, all the packets destined to the address that timed out. In addition, a "negative cache entry" might be kept in the module performing the matching function, so that for some amount of time, the mapping function would return an error when the IP module requests to perform a mapping for some address for which the mapping has recently timed out.
この問題に対する一つの対策は、マッピング機能がタイムアウトする時点で、ドロップするだろう、タイムアウトしたアドレス宛てのすべてのパケット。 IPモジュールの要求がためのいくつかのアドレスのマッピングを実行する際に、ある程度の時間のために、マッピング関数がエラーを返すように、また、「負のキャッシュエントリは」、マッチング機能を実行するモジュールに保持される可能性がありますマッピングは最近、タイムアウトしました。
A common implementation strategy for routers is that when a packet is received that requires an ARP resolution to be performed before the packet can be forwarded, the packet is dropped and the router is then engaged in the ARP procedure.
ルータのための一般的な実装戦略は、パケットは、パケットが転送される前に実行されるARPの解像度を必要とする受信した場合、パケットがドロップされることで、ルータは、次に、ARP手順に従事しています。
In some scenarios, it may be necessary for a host or router to drop packets from the output queue. In the event that one of such packets happens to be an IP fragment, and there were other fragments of the same packet in the queue, those other fragments should also be dropped. The rationale for this policy is that it is nonsensical to spend system resources on those other fragments, because, as long as one fragment is missing, it will be impossible for the receiving system to reassemble them into a complete IP datagram.
ホストやルータは、出力キューからパケットをドロップするためにいくつかのシナリオでは、それが必要な場合があります。そのようなパケットの1つがIP断片であることを起こる、キュー内の同じパケットの他のフラグメントが存在した場合に、それらの他のフラグメントも削除しなければなりません。この政策の理論的根拠は、受信システムは、完全なIPデータグラムにそれらを再構成することは、それは不可能になります限り、一つの断片が欠落しているとして、ので、それらの他のフラグメント上のシステムリソースを過ごすために無意味であるということです。
Some systems have been known to drop just a subset of fragments of a given datagram, leading to a denial-of-service condition, as only a subset of all the fragments of the packets were actually transferred to the next hop.
パケットのすべてのフラグメントのサブセットのみが実際に次のホップに転送されたように、一部のシステムでは、サービス拒否（DoS）状態を引き起こす、与えられたデータグラムのフラグメントのサブセットだけをドロップすることが知られています。
It is important to understand that while there are some addresses that are supposed to be unreachable from the public Internet (such as the private IP addresses described in RFC 1918 [RFC1918], or the "loopback" address), there are a number of tricks an attacker can perform to reach those IP addresses that would otherwise be unreachable (e.g., exploit the LSRR or SSRR IP options). Therefore, when applicable, packet filtering should be performed at the private network boundary to assure that those addresses will be unreachable.
（RFC 1918 [RFC1918]で説明したプライベートIPアドレス、または「ループバック」アドレスなど）公共のインターネットからの到達不能になっているいくつかのアドレスがある一方で、トリックの数があることを理解することが重要です攻撃者は、（例えば、LSRRまたはSSRR IPオプションを利用する）それ以外の場合は到達不能になり、それらのIPアドレスに到達するために実行することができます。そのため、該当する場合、パケットフィルタリングは、これらのアドレスが到達不能になることを保証するために、プライベートネットワークの境界で実行する必要があります。
Similarly, link-local unicast addresses [RFC3927] and multicast addresses with limited scope (link- and site-local addresses) should not be accessible from outside the proper network boundaries and not be passed across these boundaries.
同様に、リンクローカルユニキャストアドレス[RFC3927]と限られた範囲（リンク - およびサイトローカルアドレス）を持つマルチキャストアドレスは、適切なネットワーク境界の外部からアクセス可能であるべきではないし、これらの境界を越えて渡されることはありません。
[RFC5735] provides a summary of special use IPv4 addresses.
[RFC5735]は特別な使用のIPv4アドレスの要約を提供します。
The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets:
IANA（Internet Assigned Numbers Authority）は、民間のインターネットのIPアドレス空間の次の三つのブロックを予約しました：
o 10.0.0.0 - 10.255.255.255 (10/8 prefix) o 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
172.31.255.255（172.16 / 12プレフィックス） - 172.16.0.0 O 10.255.255.255（10/8プレフィックス） - O 10.0.0.0
o 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
O 192.168.0.0 - 192.168.255.255（192.168 / 16プレフィックス）
Use of these address blocks is described in RFC 1918 [RFC1918].
これらのアドレスブロックの使用は、RFC 1918 [RFC1918]に記述されています。
Where applicable, packet filtering should be performed at the organizational perimeter to assure that these addresses are not reachable from outside the private network where such addresses are employed.
該当する場合、パケットフィルタリングは、これらのアドレスは、アドレスが使用されているプライベートネットワークの外部から到達可能でないことを保証するために組織の境界で行われるべきです。
The former Class D addresses correspond to the 224/4 address block and are used for Internet multicast. Therefore, if a packet is received with a "Class D" address as the Source Address, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). Additionally, if an IP packet with a multicast Destination Address is received for a connection-oriented protocol (e.g., TCP), the packet should be dropped (see Section 4.3.5), and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
前者のクラスDアドレスは224/4アドレスブロックに対応し、インターネットマルチキャストのために使用されます。パケットが送信元アドレスとして「クラスD」アドレスで受信された場合そのため、それをドロップする必要があり、このイベントがログに記録されるべきである（例えば、カウンタは、パケット損失を反映するようにインクリメントすることができます）。さらに、マルチキャスト宛先アドレスを持つIPパケットがコネクション指向のプロトコル（例えば、TCP）のために受信されている場合、パケットは（4.3.5項を参照）をドロップする必要があり、このイベントがログに記録されなければならない（例えば、カウンタができ）パケットドロップを反映するためにインクリメントさ。
The former Class E addresses correspond to the 240/4 address block, and are currently reserved for experimental use. As a result, a most routers discard packets that contain a "Class" E address as the Source Address or Destination Address. If a packet is received with a 240/4 address as the Source Address and/or the Destination Address, the packet should be dropped and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
前者のクラスEのアドレスは、4分の240個のアドレスブロックに対応し、現在実験的な使用のために予約されています。その結果、ほとんどのルータは、送信元アドレスまたは宛先アドレスとして「クラス」Eアドレスを含むパケットを破棄する。パケットが送信元アドレスおよび/または宛先アドレスとして4分の240のアドレスで受信した場合、パケットは廃棄されなければならないと、このイベントがログに記録されなければならない（例えば、カウンタは、パケットドロップを反映するためにインクリメントすることができます）。
It should be noted that the broadcast address 255.255.255.255 still must be treated as indicated in Section 4.3.7 of this document.
このドキュメントのセクション4.3.7に示されるように、ブロードキャストアドレス255.255.255.255は、まだ処理されなければならないことに留意すべきです。
For connection-oriented protocols, such as TCP, shared state is maintained between only two endpoints at a time. Therefore, if an IP packet with a multicast (or broadcast) Destination Address is received for a connection-oriented protocol (e.g., TCP), the packet should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
TCPなどのコネクション型プロトコルのために、共有状態は、一度に2つのエンドポイント間で維持されます。宛先アドレスは、コネクション指向のプロトコル（例えば、TCP）のために受信されたマルチキャスト（またはブロードキャスト）とIPパケットの場合はそのため、パケットは廃棄されなければならない、とこのイベントがログに記録されなければならない（例えば、カウンタがにインクリメントすることができ）パケットドロップを反映しています。
Originally, the IETF specifications did not permit IP addresses to have the value 0 or -1 (shorthand for all bits set to 1) for any of the Host number, network number, or subnet number fields, except for the cases indicated in Section 4.3.7. However, this changed fundamentally with the deployment of Classless Inter-Domain Routing (CIDR) [RFC4632], as with CIDR a system cannot know a priori what the subnet mask is for a particular IP address.
もともと、IETF仕様は、IPは、セクション4.3に示されている場合を除き、ホスト数、ネットワーク番号、またはサブネット番号フィールドのいずれかの値が0または-1（1に設定されているすべてのビットの省略形）を持っているアドレスを許可していませんでした。7。しかし、このシステムはサブネットマスクは、特定のIPアドレス何のためにあるのかを先験的に知ることができないCIDRと同じように、クラスレスドメイン間ルーティング（CIDR）[RFC4632]の展開を根本的に変わりました。
Many systems now allow administrators to use the values 0 or -1 for those fields. Despite that according to the original IETF specifications these addresses are illegal, modern IP implementations should consider these addresses to be valid.
多くのシステムは現在、管理者は、これらのフィールドの値が0または-1を使用することができます。それにもかかわらず、これらのアドレスは違法で元IETF仕様に応じて、近代的なIPの実装は、これらのアドレスが有効であることを考慮すべきです。
RFC 1812 [RFC1812] discusses the use of some special Internet addresses, which is of interest to perform some sanity checks on the Source Address and Destination Address fields of an IP packet. It uses the following notation for an IP address:
RFC 1812 [RFC1812]はIPパケットの送信元アドレスと宛先アドレスフィールドにいくつかの健全性チェックを実行するために重要であるいくつかの特別なインターネットアドレスの使用を論じています。これは、IPアドレスの次の表記法を使用しています：
{ <Network-prefix>, <Host-number> }
{<ネットワークプレフィックス>、<ホスト番号>}
where the length of the network prefix is generally implied by the network mask assigned to the IP interface under consideration.
ここで、ネットワークプレフィックスの長さは、一般に、検討中のIPインターフェースに割り当てられたネットワークマスクによって暗示されています。
RFC 1122 [RFC1122] contained a similar discussion of special Internet addresses, including some of the form { <Network-prefix>, <Subnet-number>, <Host-number> }. However, as explained in Section 4.2.2.11 of RFC 1812, in a CIDR world, the subnet number is clearly an extension of the network prefix and cannot be distinguished from the remainder of the prefix.
RFC 1122 [RFC1122]は、フォームの一部を含む、特殊なインターネットアドレスの同様の議論を含ま{<ネットワークプレフィックス>、<サブネット番号>、<ホスト番号>}。しかし、RFC 1812のセクション4.2.2.11で説明したように、CIDRの世界では、サブネット番号は明らかにネットワークプレフィックスの拡張であり、プレフィックスの残りの部分と区別することはできません。
{0, 0}
｛０、 ０｝
This address means "this host on this network". It is meant to be used only during the initialization procedure, by which the host learns its own IP address.
このアドレスは、「このネットワーク上でこのホスト」を意味します。ホストは、自身のIPアドレスを学習することにより、初期化手続き中にのみ使用されることを意味しています。
If a packet is received with 0.0.0.0 as the Source Address for any purpose other than bootstrapping, the corresponding packet should be silently dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). If a packet is received with 0.0.0.0 as the Destination Address, it should be silently dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
パケットがブートストラップ以外の目的のために元アドレスとして0.0.0.0を用いて受信された場合、対応するパケットは、黙って滴下し、このイベントをログに記録しなければならないべきである（例えば、カウンタは、パケット損失を反映するようにインクリメントすることができます）。パケットは、宛先アドレスとして0.0.0.0を用いて受信された場合、それは黙って廃棄されるべきであり、このイベントがログに記録されるべきである（例えば、カウンタは、パケット損失を反映するようにインクリメントすることができます）。
{0, Host number}
{0、ホスト番号}
This address means "the specified host, in this network". As in the previous case, it is meant to be used only during the initialization procedure by which the host learns its own IP address. If a packet is received with such an address as the Source Address for any purpose other than bootstrapping, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). If a packet is received with such an address as the Destination Address, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
このアドレスは、「このネットワークで指定されたホストを、」意味します。前の場合のように、ホストが自身のIPアドレスを学習することにより、初期化手続きの際にのみ使用されることを意味しています。パケットがブートストラップ以外の目的のためのソースアドレスなどのアドレスを受信した場合、それは廃棄されるべきであり、このイベントがログに記録されるべきである（例えば、カウンタは、パケット損失を反映するようにインクリメントすることができます）。パケットは、宛先アドレスとして、そのようなアドレスを受信した場合、それは廃棄されるべきであり、このイベントがログに記録されるべきである（例えば、カウンタは、パケット損失を反映するようにインクリメントすることができます）。
{-1, -1}
｛ー１、 ー１｝
This address is the local broadcast address. It should not be used as a source IP address. If a packet is received with 255.255.255.255 as the Source Address, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
このアドレスは、ローカルブロードキャストアドレスです。これは、送信元IPアドレスとして使用すべきではありません。パケットが送信元アドレスとして255.255.255.255を受信した場合、それはドロップしなければならない、とこのイベントがログに記録されなければならない（例えば、カウンタは、パケットドロップを反映するためにインクリメントすることができます）。
Some systems, when receiving an ICMP echo request, for example, will use the Destination Address in the ICMP echo request packet as the Source Address of the response they send (in this case, an ICMP echo reply). Thus, when such systems receive a request sent to a broadcast address, the Source Address of the response will contain a broadcast address. This should be considered a bug, rather than a malicious use of the limited broadcast address.
ICMPエコー要求を受信したときにいくつかのシステムは、例えば、彼らが送る応答（この場合には、ICMPエコー応答）の送信元アドレスとしてICMPエコー要求パケットの宛先アドレスを使用します。このようなシステムは、ブロードキャストアドレスに送信された要求を受信したときにこのように、応答の送信元アドレスはブロードキャストアドレスが含まれています。これはバグではなく、限られたブロードキャストアドレスの悪質な使用を考慮すべきです。
{Network number, -1}
{ネットワーク番号、-1}
This is the directed broadcast to the specified network. As recommended by RFC 2644 [RFC2644], routers should not forward network-directed broadcasts. This avoids the corresponding network from being utilized as, for example, a "smurf amplifier" [CERT1998a].
これは、指定されたネットワークに直接ブロードキャストです。 RFC 2644 [RFC2644]によって推奨されているように、ルータは、ネットワーク向けのブロードキャストを転送してはなりません。これは、例えば、として利用されることから、対応するネットワークを避け、「スマーフ増幅器」[CERT1998a]。
As noted in Section 4.3.6 of this document, many systems now allow administrators to configure these addresses as unicast addresses for network interfaces. In such scenarios, routers should forward these addresses as if they were traditional unicast addresses.
このドキュメントのセクション4.3.6で述べたように、多くのシステムは現在、管理者は、ネットワークインターフェイスのユニキャストアドレスとしてこれらのアドレスを設定することができます。彼らは伝統的なユニキャストアドレスであるかのようなシナリオでは、ルータはこれらのアドレスを転送する必要があります。
In some scenarios, a host may have knowledge about a particular IP address being a network-directed broadcast address, rather than a unicast address (e.g., that IP address is configured on the local system as a "broadcast address"). In such scenarios, if a system can infer that the Source Address of a received packet is a network- directed broadcast address, the packet should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
いくつかのシナリオでは、ホストは、ネットワーク向けのブロードキャストアドレスではなく、ユニキャストアドレス（例えば、IPアドレスが「ブロードキャストアドレス」のように、ローカルシステム上に設定されていること）である特定のIPアドレスに関する知識を有していてもよいです。システムは、受信したパケットの送信元アドレスは、ネットワーク - ダイレクトブロードキャストアドレスであることを推測することができた場合、そのようなシナリオでは、パケットが廃棄されなければならない、とこのイベントがログに記録されなければならない（例えば、カウンタは、パケットドロップを反映するためにインクリメントすることができ）。
As noted in Section 4.3.6 of this document, with the deployment of CIDR [RFC4632], it may be difficult for a system to infer whether a particular IP address that does not belong to a directly attached subnet is a broadcast address.
CIDR [RFC4632]の展開このドキュメントのセクション4.3.6で述べたように、システムが直接接続されたサブネットに属していない特定のIPアドレスがブロードキャストアドレスであるか否かを推測することが困難であってもよいです。
{127.0.0.0/8, any}
{127.0.0.0/8、任意}
This is the internal host loopback address. Any packet that arrives on any physical interface containing this address as the Source Address, the Destination Address, or as part of a source route (either LSRR or SSRR), should be dropped.
これは、内部ホストのループバックアドレスです。送信元アドレス、宛先アドレスとして、このアドレスを含むすべての物理インターフェイスに到着したパケットは、またはソースルート（LSRRまたはSSRRのいずれか）の一環として、廃棄されるべきです。
For example, packets with a Destination Address in the 127.0.0.0/8 address block that are received on an interface other than loopback should be silently dropped. Packets received on any interface other than loopback with a Source Address corresponding to the system receiving the packet should also be dropped.
例えば、ループバック以外のインターフェイス上で受信された127.0.0.0/8アドレスブロックの宛先アドレスを持つパケットは静かであるべきで滴下。パケットを受信したシステムに対応するソースアドレスとループバック以外のインターフェイス上で受信されたパケットも削除しなければなりません。
In all the above cases, when a packet is dropped, this event should be logged (e.g., a counter could be incremented to reflect the packet drop).
パケットがドロップされ、すべての上記の場合において、このイベントが記録されるべきである（例えば、カウンタは、パケット損失を反映するようにインクリメントすることができます）。
This document discusses the security implications of the Internet Protocol (IP) and a number of implementation strategies that help to mitigate a number of vulnerabilities found in the protocol during the last 25 years or so.
この文書は、インターネットプロトコル（IP）と過去25年ほどの間に、プロトコルで見つかった脆弱性の数を軽減するのに役立つ実装戦略の数のセキュリティへの影響について説明します。
The author wishes to thank Alfred Hoenes for providing very thorough reviews of earlier versions of this document, thus leading to numerous improvements.
著者は、このように多くの改良につながる、このドキュメントの以前のバージョンの非常に徹底的なレビューを提供するためのアルフレッドHoenesに感謝したいです。
The author would like to thank Jari Arkko, Ron Bonica, Stewart Bryant, Adrian Farrel, Joel Jaeggli, Warren Kumari, Bruno Rohee, and Andrew Yourtchenko for providing valuable comments on earlier versions of this document.
作者はこのドキュメントの以前のバージョンで貴重なコメントを提供するためのヤリArkko、ロンBonica、スチュワートブライアント、エードリアンファレル、ジョエルJaeggli、ウォーレン・クマリ、ブルーノRohee、そしてアンドリューYourtchenkoに感謝したいと思います。
This document was written by Fernando Gont on behalf of the UK CPNI (United Kingdom's Centre for the Protection of National Infrastructure), and is heavily based on the "Security Assessment of the Internet Protocol" [CPNI2008] published by the UK CPNI in 2008.
この文書は、英国CPNI（国家インフラの保護のためのイギリスのセンター）に代わってフェルナンドGontによって書かれた、と重く[CPNI2008] 2008年に英国CPNI発行の「インターネットプロトコルのセキュリティ評価」に基づいています。
The author would like to thank Randall Atkinson, John Day, Juan Fraschini, Roque Gagliano, Guillermo Gont, Martin Marino, Pekka Savola, and Christos Zoulas for providing valuable comments on earlier versions of [CPNI2008], on which this document is based.
著者は、この文書の基になっている[CPNI2008]以前のバージョン、上の貴重なコメントを提供するためのランドール・アトキンソン、ジョン・デイ、フアンFraschini、ロケガリアーノ、ギジェルモGont、マーティン・マリノ、ペッカSavola、およびクリストスZoulasのを感謝したいと思います。
The author would like to thank Randall Atkinson and Roque Gagliano, who generously answered a number of questions.
著者はランドール・アトキンソンと寛大にいくつかの質問に答えロケガリアーノを、感謝したいと思います。
Finally, the author would like to thank UK CPNI (formerly NISCC) for their continued support.
最後に、著者は彼らの継続的な支援のために英国CPNI（旧NISCC）を感謝したいと思います。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[RFC0826]プラマー、D.、「イーサネットアドレス解決プロトコル：またはイーサネットハードウェア上で送信するためのイーサネットアドレスを48ビットに、ネットワーク・プロトコル・アドレス変換」、STD 37、RFC 826、1982年11月。
[RFC1038] St. Johns, M., "Draft revised IP security option", RFC 1038, January 1988.
[RFC1038]セントジョンズ、M.、1988年1月、RFC 1038 "ドラフトは、IPセキュリティオプションを改訂しました"。
[RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP MTU discovery options", RFC 1063, July 1988.
[RFC1063]ムガール人、J.、ケント、C.、ヤマウズラ、C.、およびK. McCloghrie、 "IP MTUディスカバリオプション"、RFC 1063、1988年7月。
[RFC1108] Kent, S., "U.S", RFC 1108, November 1991.
[RFC1108]ケント、S.、 "米"、RFC 1108、1991年11月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]デアリング、S.、STD 5、RFC 1112 "IPマルチキャスティングのためのホスト拡大"、1989年8月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[RFC1349] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, July 1992.
[RFC1349] Almquist、P.、 "インターネットプロトコルスイートでサービスの種類"、RFC 1349、1992年7月。
[RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, January 1993.
[RFC1393]マルキン、G.、 "tracerouteのIPオプションの使用"、RFC 1393、1993年1月。
[RFC1770] Graff, C., "IPv4 Option for Sender Directed Multi-Destination Delivery", RFC 1770, March 1995.
[RFC1770] Graffの、C.、RFC 1770 "送信者監督マルチ先の配達のためのIPv4オプション"、1995年3月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、RFC 1812、1995年6月 "IPバージョン4つのルータのための要件"。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113]カッツ、D.、 "IPルータアラートオプション"、RFC 2113、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[RFC2644] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, August 1999.
[RFC2644] Senie、D.、 "ルータでのダイレクトブロードキャストのデフォルトの変更"、BCP 34、RFC 2644、1999年8月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]ファーガソン、P.およびD. Senie、 "ネットワーク入力フィルタリング：IP Source Address Spoofingを使うサービス攻撃の敗北拒否"、BCP 38、RFC 2827、2000年5月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.およびP. Savola、 "マルチホームネットワークの入力フィルタリング"、BCP 84、RFC 3704、2004年3月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC3927]チェシャー、S.、Aboba、B.、およびE.ガットマン、 "IPv4のリンクローカルアドレスの動的構成"、RFC 3927、2005年5月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[RFC4632]フラー、V.およびT.李、 "クラスレスドメイン間ルーティング（CIDR）：インターネットアドレスの割り当てと集計プラン"、BCP 122、RFC 4632、2006年8月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]マシス、M.とJ. Heffner、 "パケット化レイヤのパスMTUディスカバリ"、RFC 4821、2007年3月。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
[RFC5082]ギル、V.、Heasley、J.、マイヤー、D.、Savola、P.、およびC. Pignataro、 "一般TTLセキュリティメカニズム（GTSM）"、RFC 5082、2007年10月。
[RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the IPv4 and IPv6 Router Alert Options", RFC 5350, September 2008.
[RFC5350]マナー、J.およびA.マクドナルド、 "IPv4とIPv6ルータアラートオプションのためのIANAの考慮事項"、RFC 5350、2008年9月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735]コットン、M.およびL. Vegoda、 "特別の使用のIPv4アドレス"、BCP 153、RFC 5735、2010年1月。
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, November 2010.
[RFC6040]ブリスコウ、B.、 "明示的輻輳通知のトンネリング"、RFC 6040、2010年11月。
[Anderson2001] Anderson, J., "An Analysis of Fragmentation Attacks", 2001, <http://www.ouah.org/fragma.html>.
【Anderson2001]アンダーソン、J.、 "断片化攻撃の分析"、2001年、<http://www.ouah.org/fragma.html>。
[Arkin2000] Arkin, "IP TTL Field Value with ICMP (Oops - Identifying Windows 2000 again and more)", 2000, <http://ofirarkin.files.wordpress.com/2008/11/ ofirarkin2000-06.pdf>.
[Arkin2000]アーキン、 "ICMPとIP TTLフィールド値（おっと - 再びWindows 2000の特定とそれ以上）"、2000年、<http://ofirarkin.files.wordpress.com/2008/11/ ofirarkin2000-06.pdf>。
[Barisani2006] Barisani, A., "FTester - Firewall and IDS testing tool", 2001, <http://dev.inversepath.com/trac/ftester>.
【Barisani2006] Barisani、A.、 "FTester - ファイアウォールとIDSテストツール"、2001年、<http://dev.inversepath.com/trac/ftester>。
[Bellovin1989] Bellovin, S., "Security Problems in the TCP/IP Protocol Suite", Computer Communication Review Vol. 19, No. 2, pp. 32-48, 1989.
[Bellovin1989] Bellovin氏、S.、コンピュータコミュニケーションレビュー集 "TCP / IPプロトコルスイートのセキュリティ問題"。 19、第2号、PP。32-48、1989。
[Bellovin2002] Bellovin, S., "A Technique for Counting NATted Hosts", IMW'02 Nov. 6-8, 2002, Marseille, France, 2002.
[Bellovin2002] Bellovin氏、S.、 "NATtedホストをカウントするための技術"、IMW'02 11月6-8、2002、マルセイユ、フランス、2002年。
[Bendi1998] Bendi, "Bonk exploit", 1998, <http://www.insecure.org/sploits/ 95.NT.fragmentation.bonk.html>.
【Bendi1998] Bendiは、1998年の "ボンクが悪用"、<http://www.insecure.org/sploits/ 95.NT.fragmentation.bonk.html>。
[Biondi2007] Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", CanSecWest 2007 Security Conference, 2007, <http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf>.
[Biondi2007]ビオンディ、P.およびA. Ebalard、 "IPv6ルーティングヘッダのセキュリティ"、たCanSecWest 2007セキュリティ会議、2007年、<http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf>。
[CERT1996a] CERT, "CERT Advisory CA-1996-01: UDP Port Denial-of-Service Attack", 1996, <http://www.cert.org/advisories/CA-1996-01.html>.
[CERT1996a] CERT、 "CERT勧告CA-1996から01：UDPポートサービス拒否攻撃"、1996年、<http://www.cert.org/advisories/CA-1996-01.html>。
[CERT1996b] CERT, "CERT Advisory CA-1996-21: TCP SYN Flooding and IP Spoofing Attacks", 1996, <http://www.cert.org/advisories/CA-1996-21.html>.
[CERT1996b] CERT、 "CERT勧告CA-1996から1921：TCP SYNフラッドとIPスプーフィング攻撃"、1996年、<http://www.cert.org/advisories/CA-1996-21.html>。
[CERT1996c] CERT, "CERT Advisory CA-1996-26: Denial-of-Service Attack via ping", 1996, <http://www.cert.org/advisories/CA-1996-26.html>.
[CERT1996c] CERT、 "CERT勧告CA-1996から26：pingを経由してサービス拒否攻撃"、1996年、<http://www.cert.org/advisories/CA-1996-26.html>。
[CERT1997] CERT, "CERT Advisory CA-1997-28: IP Denial-of-Service Attacks", 1997, <http://www.cert.org/advisories/CA-1997-28.html>.
[CERT1997] CERT、 "CERT勧告CA-1997から28：IPサービス拒否攻撃"、1997年、<http://www.cert.org/advisories/CA-1997-28.html>。
[CERT1998a] CERT, "CERT Advisory CA-1998-01: Smurf IP Denial-of-Service Attacks", 1998, <http://www.cert.org/advisories/CA-1998-01.html>.
[CERT1998a] CERT、 "CERT勧告CA-1998から01：スマーフIPサービス拒否攻撃"、1998年、<http://www.cert.org/advisories/CA-1998-01.html>。
[CERT1998b] CERT, "CERT Advisory CA-1998-13: Vulnerability in Certain TCP/IP Implementations", 1998, <http://www.cert.org/advisories/CA-1998-13.html>.
[CERT1998b] CERT、 "CERT勧告CA-1998から1913：特定のTCP / IP実装の脆弱性"、1998年、<http://www.cert.org/advisories/CA-1998-13.html>。
[CERT1999] CERT, "CERT Advisory CA-1999-17: Denial-of-Service Tools", 1999, <http://www.cert.org/advisories/CA-1999-17.html>.
[CERT1999] CERT、 "CERT勧告CA-1999から1917：サービス拒否ツール"、1999年、<http://www.cert.org/advisories/CA-1999-17.html>。
[CERT2003] CERT, "CERT Advisory CA-2003-15: Cisco IOS Interface Blocked by IPv4 Packet", 2003, <http://www.cert.org/advisories/CA-2003-15.html>.
[CERT2003] CERT、：2003年 "CERT勧告CA-2003から15のCisco IOSインターフェイスがIPv4パケットでブロックされた"、<http://www.cert.org/advisories/CA-2003-15.html>。
[CIPSO1992] CIPSO, "COMMERCIAL IP SECURITY OPTION (CIPSO 2.2)", Work in Progress, 1992.
【CIPSO1992] CIPSO、 "商用IPセキュリティ・オプション（CIPSO 2.2）"、進行、1992年ワーク。
[CIPSOWG1994] CIPSOWG, "Commercial Internet Protocol Security Option (CIPSO) Working Group", 1994, <http://www.ietf.org/ proceedings/94jul/charters/cipso-charter.html>.
[CIPSOWG1994] CIPSOWG、 "商用インターネットプロトコルセキュリティオプション（CIPSO）ワーキンググループ"、1994年、<http://www.ietf.org/手続き/ 94jul /チャーター/ CIPSO-charter.html>。
[CPNI2008] Gont, F., "Security Assessment of the Internet Protocol", 2008, <http://www.cpni.gov.uk/Docs/InternetProtocol.pdf>.
[CPNI2008] Gont、F.、 "インターネットプロトコルのセキュリティ評価"、2008年、<http://www.cpni.gov.uk/Docs/InternetProtocol.pdf>。
[Cerf1974] Cerf, V. and R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Transactions on Communications Vol. 22, No. 5, May 1974, pp. 637-648, 1974.
【Cerf1974]サーフ、V.、およびR.カーン、「パケットネットワーク相互通信のためのプロトコル」、通信巻に関するIEEEトランザクション。 22、第5号、1974年5月、頁637から648、1974。
[Cisco2003] Cisco, "Cisco Security Advisory: Cisco IOS Interface Blocked by IPv4 packet", 2003, <http://www.cisco.com/en/ US/products/ products_security_advisory09186a00801a34c2.shtml>.
[Cisco2003]シスコ、：2003年、<http://www.cisco.com/en/米国/製品/ products_security_advisory09186a00801a34c2.shtml> "シスコセキュリティアドバイザリのCisco IOSインターフェイスは、IPv4パケットによってブロックされました"。
[Cisco2008] Cisco, "Cisco IOS Security Configuration Guide, Release 12.2", 2003, <http://www.cisco.com/en/US/docs/ios/12_2/ security/configuration/guide/scfipso.html>.
[Cisco2008]シスコ、 "Cisco IOSのセキュリティコンフィギュレーションガイド、リリース12.2"、2003年、<http://www.cisco.com/en/US/docs/ios/12_2/セキュリティ/設定/ガイド/ scfipso.html>。
[Clark1988] Clark, D., "The Design Philosophy of the DARPA Internet Protocols", Computer Communication Review Vol. 18, No. 4, 1988.
[Clark1988]クラーク、D.、「DARPAインターネットプロトコルの設計理念」、コンピュータコミュニケーションレビュー集。 18、第4号、1988。
[Ed3f2002] Ed3f, "Firewall spotting and networks analysis with a broken CRC", Phrack Magazine, Volume 0x0b, Issue 0x3c, Phile #0x0c of 0x10, 2002, <http://www.phrack.org/ issues.html?issue=60&id=12&mode=txt>.
[Ed3f2002] Ed3f、 "壊れたCRCとファイアウォールスポッティングやネットワーク分析"、Phrackマガジン、ボリュームの0x0Bの、発行0x3cの、0x10ののPhile番号の0x0Cの2002年、<http://www.phrack.org/ issues.html？問題= 60、ID = 12＆モード= TXT>。
[FIPS1994] FIPS, "Standard Security Label for Information Transfer", Federal Information Processing Standards Publication. FIP PUBS 188, 1994, <http://csrc.nist.gov/publications/fips/ fips188/fips188.pdf>.
[FIPS1994] FIPS、「情報伝達のための標準セキュリティ・ラベル」、連邦情報処理規格公表。 FIP PUBS 188、1994、<http://csrc.nist.gov/publications/fips/ fips188 / fips188.pdf>。
[Fyodor2004] Fyodor, "Idle scanning and related IP ID games", 2004, <http://www.insecure.org/nmap/idlescan.html>.
[Fyodor2004]フョードル、 "アイドルスキャンと関連するIP IDのゲーム"、2004年、<http://www.insecure.org/nmap/idlescan.html>。
[GIAC2000] GIAC, "Egress Filtering v 0.2", 2000, <http://www.sans.org/y2k/egress.htm>.
【GIAC2000] GIAC、 "出力フィルタV 0.2"、2000年、<http://www.sans.org/y2k/egress.htm>。
[Gont2006] Gont, F., "Advanced ICMP packet filtering", 2006, <http://www.gont.com.ar/papers/icmp-filtering.html>.
[Gont2006] Gont、F.、 "高度なICMPパケットフィルタリング"、2006年、<http://www.gont.com.ar/papers/icmp-filtering.html>。
[Haddad2004] Haddad, I. and M. Zakrzewski, "Security Distribution for Linux Clusters", Linux Journal, 2004, <http://www.linuxjournal.com/article/6943>.
[Haddad2004]ハダッド、I.およびM. Zakrzewski、 "Linuxのクラスタのためのセキュリティの配布"、Linuxのジャーナル、2004年、<http://www.linuxjournal.com/article/6943>。
[Humble1998] Humble, "Nestea exploit", 1998, <http://www.insecure.org/sploits/ linux.PalmOS.nestea.html>.
【Humble1998]ハンブル、<http://www.insecure.org/sploits/ linux.PalmOS.nestea.html>、1998年 "Nesteaが利用します"。
[IANA_ET] IANA, "Ether Types", <http://www.iana.org/assignments/ethernet-numbers>.
[IANA_ET] IANA、 "イーサタイプ"、<http://www.iana.org/assignments/ethernet-numbers>。
[IANA_IP_PARAM] IANA, "IP Parameters", <http://www.iana.org/assignments/ip-parameters>.
[IANA_IP_PARAM] IANA、 "IPパラメータ"、<http://www.iana.org/assignments/ip-parameters>。
[IANA_PROT_NUM] IANA, "Protocol Numbers", <http://www.iana.org/assignments/protocol-numbers>.
[IANA_PROT_NUM] IANA、 "プロトコル番号"、<http://www.iana.org/assignments/protocol-numbers>。
[IRIX2008] IRIX, "IRIX 6.5 trusted_networking(7) manual page", 2008, <http://techpubs.sgi.com/library/tpl/cgi-bin/ getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/a_man/ cat7/trusted_networking.z>.
【IRIX2008] IRIX、 "IRIX 6.5 trusted_networking（7）のマニュアルページ" 2008年、<http://techpubs.sgi.com/library/tpl/cgi-bin/ getdoc.cgi？コル= 0650＆DB =マン＆FNAME =は/ usr /シェア/ catmanは/ a_man / CAT7 / trusted_networking.z>。
[Jones2002] Jones, R., "A Method Of Selecting Values For the Parameters Controlling IP Fragment Reassembly", 2002, <ftp://ftp.cup.hp.com/dist/networking/briefs/ ip_reass_tuning.txt>.
[Jones2002]ジョーンズ、R.、 "制御するパラメータIPフラグメント再の値を選択する方法"、2002年、<ftp://ftp.cup.hp.com/dist/networking/briefs/ ip_reass_tuning.txt>。
[Kenney1996] Kenney, M., "The Ping of Death Page", 1996, <http://www.insecure.org/sploits/ping-o-death.html>.
[Kenney1996]ケニー、M.、 "死ページのPingの" 1996年、<http://www.insecure.org/sploits/ping-o-death.html>。
[Kent1987] Kent, C. and J. Mogul, "Fragmentation considered harmful", Proc. SIGCOMM '87 Vol. 17, No. 5, October 1987, 1987.
【Kent1987]ケント、C.及びJ.モーグルは、PROC、 "断片化は、有害と考え"。 SIGCOMM '87巻。 17、第5号、1987年10月、1987。
[Klein2007] Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S Predictable IP ID Vulnerability", 2007, <http://www.trusteer.com/files/ OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP _ID_Vulnerability.pdf>.
[Klein2007]クライン、A.、 "OpenBSDのDNSキャッシュポイズニングと複数のO / S予測可能なIP IDの脆弱性"、2007年、<http://www.trusteer.com/files/ OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP _ID_Vulnerability.pdf>。
[Kohno2005] Kohno, T., Broido, A., and kc. Claffy, "Remote Physical Device Fingerprinting", IEEE Transactions on Dependable and Secure Computing Vol. 2, No. 2, 2005.
【Kohno2005】河野、T.、Broido、A.、およびKC。 Claffy、「リモート物理デバイスフィンガープリント」、高信頼かつセキュアコンピューティングの巻上のIEEEトランザクション。図2に示すように、第2号、2005年
[LBNL2006] LBNL/NRG, "arpwatch tool", 2006, <http://ee.lbl.gov/>.
[LBNL2006] LBNL / NRG、 "arpwatchのツール"、2006年、<http://ee.lbl.gov/>。
[Linux] Linux Kernel Organization, "The Linux Kernel Archives", <http://www.kernel.org>.
[Linuxの] Linuxカーネルの組織、 "Linuxカーネルアーカイブ"、<http://www.kernel.org>。
[Microsoft1999] Microsoft, "Microsoft Security Program: Microsoft Security Bulletin (MS99-038). Patch Available for "Spoofed Route Pointer" Vulnerability", 1999, <http://www.microsoft.com/ technet/security/bulletin/ms99-038.mspx>.
[Microsoft1999]マイクロソフト、 "マイクロソフトセキュリティプログラム：マイクロソフトセキュリティ情報（MS99-038）で利用可能なパッチ。 "/ ms99偽装ルートポインタ" 脆弱性"、1999年、<http://www.microsoft.com/のTechNet /セキュリティ/掲示板-038.mspx>。
[NISCC2004] NISCC, "NISCC Vulnerability Advisory 236929: Vulnerability Issues in TCP", 2004, <http://www.cpni.gov.uk>.
[NISCC2004] NISCC、 "NISCCの脆弱性諮問236929：TCPの脆弱性の問題"、2004年、<http://www.cpni.gov.uk>。
[NISCC2005] NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP: Vulnerability Issues in ICMP packets with TCP payloads", 2005, <http://www.gont.com.ar/advisories/index.html>.
[NISCC2005] NISCC、 "NISCCの脆弱性の諮問532967 / NISCC / ICMP：TCPペイロードを持つICMPパケットの脆弱性の問題"、2005年、<http://www.gont.com.ar/advisories/index.html>。
[NISCC2006] NISCC, "NISCC Technical Note 01/2006: Egress and Ingress Filtering", 2006, <http://www.cpni.gov.uk>.
[NISCC2006] NISCC、 "NISCCテクニカルノート01/2006：出口と入力フィルタリング"、2006年、<http://www.cpni.gov.uk>。
[Northcutt2000] Northcut, S. and Novak, "Network Intrusion Detection - An Analyst's Handbook", Second Edition New Riders Publishing, 2000.
[Northcutt2000] Northcut、S.およびノバック、「ネットワーク侵入検知 - アナリストのためのハンドブック」、第2版の新しいライダー出版、2000。
[Novak2005] Novak, "Target-Based Fragmentation Reassembly", 2005, <http://www.snort.org/assets/165/target_based_frag.pdf>.
【Novak2005]ノバック、 "ターゲットベースの断片再アセンブリ" 2005年、<http://www.snort.org/assets/165/target_based_frag.pdf>。
[OpenBSD-PF] Sanfilippo, S., "PF: Scrub (Packet Normalization)", 2010, <ftp://ftp.openbsd.org/pub/OpenBSD/doc/pf-faq.pdf>.
[OpenBSDの-PF]サンフィリポ、S.、 "PF：スクラブ（パケット正規化）"、2010年<ftp://ftp.openbsd.org/pub/OpenBSD/doc/pf-faq.pdf>。
[OpenBSD1998] OpenBSD, "OpenBSD Security Advisory: IP Source Routing Problem", 1998, <http://www.openbsd.org/advisories/sourceroute.txt>.
[OpenBSD1998] OpenBSDの、 "OpenBSDのセキュリティアドバイザリ：IPソースルーティング問題"、1998年、<http://www.openbsd.org/advisories/sourceroute.txt>。
[Paxson2001] Paxson, V., Handley, M., and C. Kreibich, "Network Intrusion Detection: Evasion, Traffic Normalization, and End-to-End Protocol Semantics", USENIX Conference, 2001.
[Paxson2001]パクソン、V.、ハンドリー、M.、およびC. Kreibich、 "ネットワーク侵入検知：回避、トラフィック正規化、およびエンドツーエンドのプロトコルセマンティクス"、USENIX会議、2001。
[Ptacek1998] Ptacek, T. and T. Newsham, "Insertion, Evasion and Denial of Service: Eluding Network Intrusion Detection", 1998, <http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps>.
[Ptacek1998] Ptacek、T.とT. Newsham、 "挿入、回避およびサービス拒否：逃亡ネットワーク侵入検知"、1998年、<http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98。 PS>。
[RFC0815] Clark, D., "IP datagram reassembly algorithms", RFC 815, July 1982.
[RFC0815]クラーク、D.、 "IPデータグラムの再構築アルゴリズム"、RFC 815、1982年7月。
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995.
[RFC1858] Ziemba、G.、リード、D.、およびP. Trainaの、 "IPフラグメントフィルタリングのためのセキュリティの考慮事項"、RFC 1858、1995年10月。
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
、RFC 2544、1999年3月 "ネットワーク相互接続デバイスのためのベンチマーキング方法論" [RFC2544]ブラドナー、S.とJ. McQuaid、。
[RFC3128] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, June 2001.
[RFC3128]、RFC 3128、2001年6月・ミラー、I.、 "タイニーフラグメント攻撃（RFC 1858）のバリアントに対する保護"。
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC3530] Shepler、S.、キャラハン、B.、ロビンソン、D.、Thurlow、R.、Beame、C.、アイスラー、M.、およびD. Noveck、 "ネットワークファイルシステム（NFS）バージョン4プロトコル"、 RFC 3530、2003年4月。
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, July 2007.
[RFC4963] Heffner、J.、マティス、M.、およびB.チャンドラー、 "高速データレートでのIPv4の再構築エラー"、RFC 4963、2007年7月。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007.
[RFC4987]エディ、W.、 "TCPのSYNフラッド攻撃と共通の軽減策"、RFC 4987、2007年8月。
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN) Architecture", RFC 5559, June 2009.
[RFC5559] Eardley、P.、 "プリ輻輳通知（PCN）アーキテクチャ"、RFC 5559、2009年6月。
[RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common Architecture Label IPv6 Security Option (CALIPSO)", RFC 5570, July 2009.
[RFC5570] StJohns、M.、アトキンソン、R.、およびG.トーマス、 "共通のアーキテクチャラベルIPv6のセキュリティオプション（CALIPSO）"、RFC 5570、2009年7月。
[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-Nodes", RFC 5670, November 2009.
[RFC5670] Eardley、P.、 "メーターとPCN-ノードのマーキング行動"、RFC 5670、2009年11月。
[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline Encoding and Transport of Pre-Congestion Information", RFC 5696, November 2009.
[RFC5696] Moncaster、T.、ブリスコー、B.、およびM. Menth、 "プレ輻輳情報のベースライン符号化及びトランスポート"、RFC 5696、2009年11月。
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.
[RFC5927] Gont、F.、 "TCPに対するICMP攻撃"、RFC 5927、2010年7月。
[ROUTER-ALERT] Le Faucheur, F., Ed., "IP Router Alert Considerations and Usage", Work in Progress, June 2011.
[ROUTER-ALERT]ルFaucheur、F.、エド。、 "IPルータアラートの考慮事項および使用方法"、進歩、2011年6月での作業。
[SELinux2009] NSA, "Security-Enhanced Linux", <http://www.nsa.gov/research/selinux/>.
[SELinux2009] NSA、 "セキュリティが強化のLinux"、<http://www.nsa.gov/research/selinux/>。
[Sanfilippo1998a] Sanfilippo, S., "about the ip header id", Post to Bugtraq mailing-list, Mon Dec 14 1998, <http://www.kyuzz.org/antirez/papers/ipid.html>.
[Sanfilippo1998a]サンフィリッポ、S.、 "IPヘッダのIDについて"、ポストにBugtraqへのメーリングリスト、月1998年12月14日、<http://www.kyuzz.org/antirez/papers/ipid.html>。
[Sanfilippo1998b] Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list, 1998, <http://www.kyuzz.org/antirez/papers/dumbscan.html>.
[Sanfilippo1998b]サンフィリッポ、S.、 "アイドルスキャン"、ポストにBugtraqメーリング・リストに、1998年、<http://www.kyuzz.org/antirez/papers/dumbscan.html>。
[Sanfilippo1999] Sanfilippo, S., "more ip id", Post to Bugtraq mailing-list, 1999, <http://www.kyuzz.org/antirez/papers/moreipid.html>.
[Sanfilippo1999]サンフィリッポ、S.、 "複数のIP ID"、ポストにBugtraqメーリング・リストに、1999年、<http://www.kyuzz.org/antirez/papers/moreipid.html>。
[Shankar2003] Shankar, U. and V. Paxson, "Active Mapping: Resisting NIDS Evasion Without Altering Traffic", 2003, <http://www.icir.org/vern/papers/activemap-oak03.pdf>.
[Shankar2003]シャンカル、U.およびV.パクソン、 "アクティブ・マッピング：トラフィックを変更することなく、NIDSの回避に抵抗"、2003年、<http://www.icir.org/vern/papers/activemap-oak03.pdf>。
[Shannon2001] Shannon, C., Moore, D., and K. Claffy, "Characteristics of Fragmented IP Traffic on Internet Links", 2001.
[Shannon2001]シャノン、C.、ムーア、D.、およびK. Claffy、 "インターネットリンク上の断片化IPトラフィックの特性"、2001年。
[Silbersack2005] Silbersack, M., "Improving TCP/IP security through randomization without sacrificing interoperability", EuroBSDCon 2005 Conference, 2005, <http://www.silby.com/eurobsdcon05/eurobsdcon_slides.pdf>.
[Silbersack2005] Silbersack、M.、 "相互運用性を犠牲にすることなく、ランダム化を通じてTCP / IPセキュリティの改善"、EuroBSDCon 2005会議、2005年、<http://www.silby.com/eurobsdcon05/eurobsdcon_slides.pdf>。
[Snort] Sourcefire, Inc., "Snort", <http://www.snort.org>.
[Snortの] Sourcefireの社、 "Snortの"、<http://www.snort.org>。
[Solaris2007] Oracle, "ORACLE SOLARIS WITH TRUSTED EXTENSIONS", 2007, <h ttp://www.oracle.com/us/products/servers-storage/solaris/ solaris-trusted-ext-ds-075583.pdf>.
[Solaris2007]オラクル、 "Trusted ExtensionsがORACLE SOLARIS"、2007年、<時間TTP：//www.oracle.com/us/products/servers-storage/solaris/ Solarisの信頼-EXT-DS-075583.pdf>。
[Song1999] Song, D., "Frag router tool", <http://www.monkey.org/~dugsong/fragroute/>.
[Song1999]ソング、D.、 "FRAGルータツール"、<http://www.monkey.org/~dugsong/fragroute/>。
[SpooferProject] MIT ANA, "Spoofer Project", 2010, <http://spoofer.csail.mit.edu/index.php>.
[SpooferProject] MIT ANA、 "スプーフィングプロジェクト"、2010年、<http://spoofer.csail.mit.edu/index.php>。
[US-CERT2001] US-CERT, "US-CERT Vulnerability Note VU#446689: Check Point FireWall-1 allows fragmented packets through firewall if Fast Mode is enabled", 2001, <http://www.kb.cert.org/vuls/id/446689>.
[US-CERT2001]米国のCERTは、：http://www.kb.cert.org <2001年、 "US-CERTの脆弱性ノートVU＃446689高速モードが有効になっている場合は、チェック・ポイントのFireWall-1は、ファイアウォールを介して断片化されたパケットを許可します" / vuls / ID / 446689>。
[US-CERT2002] US-CERT, "US-CERT Vulnerability Note VU#310387: Cisco IOS discloses fragments of previous packets when Express Forwarding is enabled", 2002.
[US-CERT2002]米国-CERT、 "US-CERT脆弱性ノートVU＃310387：エクスプレスフォワーディングが有効になっている場合、Cisco IOSは、前のパケットのフラグメントを開示している" 2002年。
[Watson2004] Watson, P., "Slipping in the Window: TCP Reset Attacks", CanSecWest Conference, 2004.
[Watson2004]ワトソン、P.は、 "ウィンドウに滑り：TCPリセット攻撃"、たCanSecWest会議、2004。
[Zakrzewski2002] Zakrzewski, M. and I. Haddad, "Linux Distributed Security Module", 2002, <http://www.linuxjournal.com/article/6215>.
[Zakrzewski2002] Zakrzewski、M.およびI.ハダッドは、<http://www.linuxjournal.com/article/6215>、2002年 "Linuxはセキュリティモジュールを分散しました"。
[daemon91996] daemon9, route, and infinity, "IP-spoofing Demystified (Trust-Relationship Exploitation)", Phrack Magazine, Volume Seven, Issue Forty-Eight, File 14 of 18, 1988, <htt p://www.phrack.org/issues.html?issue=48&id=14&mode=txt>.
[daemon91996] daemon9、ルート、および無限大、 "IPスプーフィング詳解（信頼関係搾取）"、Phrack誌、巻七号四十八、18の14ファイル、1988年、<HTT P：//www.phrack .ORG / issues.html？問題= 48＆ID = 14＆モード= TXT>。
Author's Address
著者のアドレス
Fernando Gont UK Centre for the Protection of National Infrastructure
国家インフラの保護のためのフェルナンドGont英国センター
EMail: fernando@gont.com.ar URI: http://www.cpni.gov.uk
電子メール：URI fernando@gont.com.ar：http://www.cpni.gov.uk