[要約] RFC 6274は、IPv4のセキュリティ評価に関する情報を提供するものであり、IPv4の脆弱性と対策についてのガイドラインを提供します。このRFCの目的は、IPv4ネットワークのセキュリティを向上させるための情報を提供することです。
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
インターネットプロトコルバージョン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のIETF仕様と、一般的なIPv4実装によって使用されている多くのメカニズムとポリシーのセキュリティ評価が含まれています。これは、英国の国家インフラストラクチャ保護センター（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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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）インターネットプログラムのトップレベルの目標は、ARPANET [CLARK1988]の大規模なサービスマシンの共有でした。その結果、多くのプロトコル仕様は、セキュリティへの影響を指定し、見落としているプロトコルの運用的側面のみに焦点を当てています。
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].
インターネットテクノロジーは設立以来進化しましたが、インターネットのビルディングブロックは基本的に20年以上前に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仕様には、コンパニオンドキュメントが明確に必要です。プロトコルのセキュリティの側面と意味を議論し、考えられる脅威を特定し、可能な対策を議論し、それぞれの有効性を分析するもの。
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プロトコルに基づいて、多くのセキュリティの脅威についての認識を高めることを目指しています。インターネットプロトコル（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.
このドキュメントは、英国の国家インフラストラクチャ保護センター（CPNI）がリリースした「インターネットプロトコルのセキュリティ評価」[CPNI2008]に大きく基づいており、http：//www.cpni.gov.uk/products/technicalnotesで入手可能/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は、この作業の一部として評価の主要なソースとして選択されました：O RFC 791、「インターネットプロトコルDARPAインターネットプログラムプロトコル仕様」（45ページ）。
o RFC 815, "IP DATAGRAM REASSEMBLY ALGORITHMS" (9 pages).
o RFC 815、「IP Datagram再組み立てアルゴリズム」（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、「明示的な混雑通知（ECN）のIPへの追加」（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仕様は、各フィールドのセマンティクスとともに、プロトコルヘッダーの構文を定義します。図1は、[RFC0791]で指定されている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の異なるバージョンが、リンク層プロトコルヘッダーの異なるプロトコルタイプ（イーサネットの場合のEtherType）数によって識別されます。たとえば、IPv4データグラムは0x0800のEtherTypeを使用してイーサネットフレームにカプセル化され、IPv6データグラムは0x86DD [IANA_ET]のEtherTypeを使用してイーサネットフレームにカプセル化されます。
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にする必要があります。このチェックが失敗した場合、パケットを静かにドロップする必要があり、このイベントを記録する必要があります（たとえば、パケットドロップを反映してカウンターをインクリメントすることができます。）。実装がこのチェックを実行しない場合、攻撃者はバージョンフィールドに異なる値を使用し、バージョンフィールドに基づいて適用するパターンマッチングルールを決定するNIDSを回避する可能性があります。
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.
攻撃者は、他のリンク層「プロトコルタイプ」値を使用してIPv4パケットをカプセル化して、Link-Layer Access Control List（ACLS）を破壊したり、NIDSを改ざんしたりしようとします。
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
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.
図2は、RFC 791 [RFC0791]で定義され、RFC 1349 [RFC1349]によって更新された、サービスフィールドのタイプの元の構文を示しています。この定義はずっと前に置き換えられてきました（セクション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 ("Weak Type of Service") of this document describe the security implications of the Type of Service field in the forwarding of packets.
サービスフィールドのタイプは、パケットがそれを処理するネットワークのシステムによって処理される方法に影響を与えるために使用できます。このドキュメントのセクション4.2.1（「優先順序付けされたキューサービス」）およびセクション4.2.2（「弱いタイプのサービス」）は、パケットの転送におけるサービスフィールドのタイプのセキュリティへの影響について説明しています。
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]は、IP「タイプのサービス」Octetを再定義し、差別化されたサービスフィールド（DSフィールド）を導入しました。図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（ "Distemiated Services CodePoint"）は、パケットが差別化されたサービスドメイン内で受け取る処理を選択するために使用されます。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）ドメイン内でどのように扱われるかを決定することを考慮すると、攻撃者は鍛造DSCPフィールドを備えたパケットを送信して、サービスの盗難またはサービス拒否（DOS）攻撃を実行できます。特に、攻撃者は、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は、DSCPフィールドが差別化されたサービスとECNフィールドに使用されている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-in-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のセキュリティへの影響については、RFC 3168の多くのセクションで詳細に説明されています。ECN仕様で議論されている脅威の可能性については、簡単に活用できるものは、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.
攻撃者は、送信するパケットにECT CodePointを設定して、トランスポートプロトコルのエンドポイントがECN対応であることをネットワークに信号することができます。その結果、中程度の混雑を経験する場合、ランダムな早期検出（RED）に基づいてアクティブキュー管理を使用してルーターがパケットを破棄するのではなく（CE CodePointで）マークします。この同じシナリオでは、ECT CodePointセットを持たない競合するフローのパケットが削除されます。したがって、攻撃者は競合するフローよりも優れたネットワークサービスを取得します。
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 CodePointセットがあるかどうかに関係なく、ルーターはドロップパケットに切り替える必要があります。
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 kバイトのデータグラムを再組み立てることができます。
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] implementations to send datagrams larger than 576 bytes, even without explicit signaling that the destination system can receive such "large" datagram.
通常、ホストは、リモートピアがそのような「大きな」データグラムを受信できることを明示的に合図しない限り、576バイトを超えるIPデータグラムをリモートピアに送信しません（たとえば、TCPの最大セグメントサイズ（MSS）） オプション）。ただし、システムは、リモートピアがそうするように信号を送るかどうかにかかわらず、576バイトを超えるデータグラムを受信する可能性があると想定する必要があります。実際、ネットワークファイルシステム（NFS）[RFC3530]の実装は、宛先システムがそのような「大きな」データグラムを受信できることを明示的に信号することなく、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モジュールに、総長さフィールドに実際に含まれる値よりも大きなパケットを手渡すことができることに注意する必要があります。このような違いは通常、リンク層プロトコルでの正当なパディングバイトに関係していますが、攻撃者による悪意のある活動の結果でもあります。さらに、IPデータグラムの最大長さが65535バイトの場合でも、使用中のリンク層技術が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]は、このような実装を持つシステムを使用して、3番目の（犠牲者）ホストにステルスポートスキャンを実行する方法を説明しました。[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に設定することを決定しました。これは、原則として、あらゆる種類の情報漏れを回避します。ただし、DFビットが設定されていても、RFCに準拠していない中間ボックスが断片化されたパケットがあることが検出されました。このようなシナリオでは、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仕様は、IP IDをその引数の1つとしてとる汎用送信（）関数を定義します。
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]で説明されているPath-MTU発見メカニズムなど）。したがって、DFビットが設定されている場合でもパケットを断片化する非RFCに準拠していないミドルボックスが、パケットが移動して宛先ホストに到達するパスに沿って配置されている場合でも、断片化が行われます。送信システムがミドルボックス（ICMPの「断片化が必要である」を使用して、df bit Set "エラーメッセージによって）によって信号が表示されると、送信するパケットのサイズを縮小する必要があるため、断片化は回避されます。また、再組み立ての問題が発生するには、同じ識別値を非常に頻繁に再利用する必要があり、強力なパケットの並べ替えまたはパケット損失のいずれかが発生する必要があります。
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:
Connectionless Transport Protocolには、多くの場合、これらの特性があります。
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のチェックサムなど）は、Aの置換から生じるデータの破損を確実に検出できない可能性があります。完全なデータブロック（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").
攻撃者は、IP識別番号の衝突を意図的に活用してDOS攻撃を実行できることに注意する必要があります。DOS攻撃を実行することで、再組み立てプロセスを引き起こすためにforgedフラグメントを送信することにより、トランスポートプロトコルによってドロップされるか、誤って削除される腐敗したデータグラムになります。対応するアプリケーションに手渡されます。この問題については、セクション4.1（「フラグメント再組み立て」）で詳しく説明します。
The IP header contains 3 control bits, two of which are currently used for the fragmentation and reassembly function.
IPヘッダーには3つのコントロールビットが含まれており、そのうち2つは断片化と再組み立て機能に使用されています。
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：（df）0 =メイフラグメント、1 =フラグメントしないでください
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]で説明されているPath-MTUディスカバリー（PMTUD）メカニズムを実装するように設定されています。ただし、ネットワーク侵入検知システムを回避するために、攻撃者によって悪用されることもあります。攻撃者は、DFビットをNIDSで監視されたシステムに設定されたパケットを送信できます。Path-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]で説明されているように、NIDを「混乱させる」ことを目的とした、重複するIPフラグメントまたは重複するTCPセグメントが含まれています。パケットは、ネットワーク周辺のNIDSセンサーによってスクリーニングされます。これは、監視対象システムとの間で転送されるデータを評価する目的で、おそらくIPフラグメントとTCPセグメントを再組み立てします。ただし、攻撃者のパケットは、17914バイトより少ないMTU（この例では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]は、監視対象のネットワークに関する十分な知識を獲得することにより、NIDの回避を防ぎ、意図した受信者に到達するパケットとそれによってどのように解釈されるかを評価することにより、「アクティブマッピング」という名前の手法を導入します。
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）は、MFとDFビットの両方を設定して、UDPにPath-MTU Discovery（PMTUD）を実装します。これらのシナリオは、ファイアウォールやチューニングNIDSを構成する際に考慮する必要があります。
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
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ビットフィールドであることを考えると、最大8191の値を保持できます。これは、オリジナルの（非フラグメント）データグラム内のオフセット65528バイトに対応します。そのため、フラグメントが65535バイトを超えるデータグラム（正当なIPデータグラムの最大サイズ）に属していると暗黙的に主張することが可能です。フラグメンテーションメカニズムがこのような大きなデータグラムに再組み立てできる断片を可能にすると思われる場合でも、仕様の意図は、最大65535バイトのデータグラムの送信を可能にすることです。したがって、与えられたフラグメントが65535を超えるバイトのデータグラムに再組み立てされる場合、結果のデータグラムをドロップする必要があり、このイベントを記録する必要があります（たとえば、パケットドロップを反映してカウンターを増加させることができます）。そのようなケースを検出するには、フラグメントオフセットにゼロ以外の値が含まれるすべてのパケットで次のチェックを実施する必要があります。
Fragment Offset * 8 + (Total Length - 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は最初のフラグメントのIHLフィールドです（フラグメントオフセットが0のものです）。
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
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.
最悪のシナリオでは、攻撃者はIPフラグメントを作成して、再組み立てされたデータグラムが131043バイトのデータグラムに再組み立てされるようにすることができます。
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の場合に生成されます。5のIHL（つまり、20バイトのヘッダー長）、再構築されたデータグラムは65532（65535-20）= 131047バイトです。
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.
Live To Live（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]).
もともと、このフィールドは、データグラムがインターネットシステムに秒単位のままであることを許可された最大時間を示すことを目的としていました。データグラムを処理するすべてのインターネットモジュールは、少なくとも1つだけ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.
ほとんどのシステムを使用すると、管理者は、デフォルト値が通常2または255のパワーであるため、管理者が発信するパケットにTTLを使用するように構成できます（例：[arkin2000]を参照）。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で到着した場合、パケットはもともと64のTTLで送信されていました。同じように、パケットが120のTTLで受信された場合、元のパケットのTTLが128の可能性があります。
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).
o インターネットプロトコル（IP）を利用するアプリケーションのセキュリティの改善。
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フィンガープリントの粒度はごくわずかであることに注意してください。さらに、これらのデフォルトは構成可能（システム全体またはプロトコルごと）である場合があり、管理されたシステムは、運用目的で、フィンガープリントヒューリスティックの能力を打ち負かすためにそのような機会を採用する場合があります。
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.
もちろん、フィンガープリント物理デバイスには、他にも多くの（そしてはるかに正確な）テクニックがあります。この方法の弱点の1つは、多くのシステムが使用するデフォルトの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をゼロに減らし、パス上のルーターのIPアドレスのIPアドレスを決定するルーターからICMPエラーメッセージを誘導するために、徐々に増加する値に送信するパケットのTTLフィールドを設定する場合があります。パケットの目的地へ。この手順は、伝統的に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.
図6のネットワークトポロジを検討してください。攻撃者（図の「F」）がソースアドレス（TCPベースのDOS反射攻撃など）を偽造する必要がある攻撃を実行し、関係するホストの一部を実行していると仮定します。攻撃システムを見つけるために協力することをいとわない。
Assuming that:
仮定して：
o All the packets A gets have a TTL of 61.
o すべてのパケットA GetのTTLは61です。
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が取得されます。TTLは61です。
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から4ホップ離れています
o Four hops away from B.
o Bから4ホップ離れている
o Four hops away from C.
o Cから4ホップ離れています
o Four hops away from D.
o Dから4ホップ離れています
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フィールドを使用して、ネットワーク侵入検知システムを回避できます。検査されたパケットの宛先ホストに対するセンサーの位置に応じて、NIDは目的の宛先システムの写真とは異なる画像を取得する場合があります。例として、センサーは、宛先ホストに到達する前に期限切れになるパケットを処理する場合があります。このタイプの攻撃の一般的な対策は、組織ネットワークに到達するトラフィックを正規化することです。このようなトラフィックの正規化の例は、[Paxson2001]にあります。OpenBSDパケットフィルターは、TTL-Normalization機能を含むパケットフィルターの例です[OpenBSD-PF]
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（Border Gateway Protocol）です。
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つの協力的なピアによって実施された小切手に合格しません。このチェックは、保護されたアプリケーションに対して攻撃を実行する可能性のあるシステムのセット（この場合はBGP）を削減し、[NISCC2004]および[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
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].
発信元のホストは、パケットが移動できる（トポロジー）距離を人為的に制限するために、TTLフィールドを小さな値（頻繁に1、リンクスコープサービスの場合）に設定します。これは、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.
サポートされていないプロトコルをカプセル化するIPパケットを受信するホスト（つまり、エンドシステム）は、対応するパケットをドロップし、イベントを記録し、おそらくICMPプロトコルを到達不能（タイプ3、コード2）エラーメッセージを送信する必要があります。
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に準拠していない実装により、ヘッダーチェックサムはファイアウォールやNIDSを回避するために悪用される可能性があることに注意する必要があります。
[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] [CERT1996B] [CERT1996B] [CERT1998A]を実行し、認証が送信システムの情報源アドレスに基づいているシナリオで他のシステムをforみたために活用されてきました[CERT1998A] [CERT1998A] [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].
Ingress/Egressフィルタリングのチェックを実行する明らかなフィールドがIPヘッダーのソースアドレスと宛先アドレスフィールドである場合でも、同じタイプのチェックを実行する必要があるIPアドレスの他の発生があります。1つの例は、[RFC5927]および[Gont2006]で説明されているように、ICMPエラーメッセージのペイロードに含まれるIPアドレスです。
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アドレスを管理者が監視できるようにする自由に利用可能なツールが存在します。この機能は、多くのNIDSにも含まれています。
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.
オプションリストの終了（Type = 0）および操作なし（Type = 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）の拡張のための新しいオプションと、最初の3つの機能部品の指示の下で、それらを「理解」しない中間システムでの透明な処理を作成できます。
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.
o 1 =コピー。
The values for the option class are:
オプションクラスの値は次のとおりです。
o 0 = control.
o 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 [RFC1122]のセクション3.2.1.8は、IPデータグラムで受信したすべてのIPオプションをトランスポートレイヤー（またはデータグラムがICMPメッセージである場合にICMP処理）に渡す必要があることを述べています。したがって、インターネットレイヤーだけでなく、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
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ヘッダー内のオプションの最初のバイトのオフセットであり、IPヘッダーの最初のバイトに0のオフセットが割り当てられます。
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).
NO操作オプションは、基本的に、送信システムが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.
これらの攻撃ベクトルのうち、おそらく最も注目されていないのは、帯域幅の排出攻撃を実行するためにLSRRオプションを使用することです。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.
これは、2007年に広く公表されたIPv6増幅攻撃のIPv4-versionです[Biondi2007]。唯一の違いは、IPv4ヘッダーの最大長（したがってLSRRオプション）が、IPv6の対応物と比較した場合、増幅係数を制限することです。
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 [RFC1122]のセクション3.3.5は、ホストがソースルートで中間ホップとして機能し、ソースにルートしたデータグラムを次の指定ホップに転送できると述べています。ホストソフトウェアがソースにルーティングされたデータグラムを転送することを強く落胆させます。
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は、このオプションがせいぜい特定のパケットに1回表示されるべきであると述べています。したがって、パケットに複数の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（3 n*4）にする必要があります。
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
lsrr.pointer％4 == 0
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の場合、オプションで指定されているルートがパケットが取る必要がある正確なルートであるという唯一の違いがある唯一の違いがあります（つまり、他の介入ルーターは許可されていません。ルートにいること）。
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.
LSRRと同様に、SSSRオプションはいくつかのネットワークの問題をデバッグするのに役立つ可能性がありますが、そのセキュリティへの影響は、それの正当な使用を上回ります。
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ルーズソースおよびレコードルート（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ビットオプションコードから始まります。2番目のバイトはオプション長さで、オプションタイプのバイト、オプション長バイト、ポインターバイト、および実際のオプションデータが含まれます。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は、このオプションがせいぜい特定のパケットに1回表示されるべきであると述べています。したがって、パケットにこのオプションの複数のインスタンスがある場合、ドロップする必要があり、このイベントを記録する必要があります（たとえば、パケットドロップを反映するためにカウンターを増加させることができます）。
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).
LSRRの長さフィールドとポインターフィールドとSSRRオプションのポインターフィールドに対して実行された同じ正気チェックは、RRオプションの長さフィールド（RR.Length）とポインターフィールド（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が指す領域に記録する必要があります。その後、ポインターは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ビットのサットネットストリーム識別子が、ストリームの概念をサポートしていないネットワークを介して運ばれる手段を提供しました。
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:
オプションは、オプションタイプのバイトで始まります。これは68に等しい必要があります。2番目のバイトはオプション長で、オプションタイプのバイト、オプション長バイト、ポインター、オーバーフロー/フラグバイトが含まれます。オプション長バイトの最小法的価値は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).
ポインターはこのオプション内のインデックスであり、オプションタイプのOctetをOctet＃1としてカウントします。次のタイムスタンプデータを保存する必要がある領域の最初のバイトを指し、したがって、最小法的価値は5です。RFC791で許可されたポインターの唯一の変更は4または8で増加するため、次のチェックは次のチェックです。フラグ値に応じて、インターネットタイムスタンプオプションで実行する必要があります（以下を参照）。
If IT.Flag is equal to 0, the following check should be performed:
フラグが0に等しい場合、次のチェックを実行する必要があります。
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
it.pointer％8 == 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 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.
o 0：連続した32ビットワードに保存されたタイムスタンプのみを記録します。
o 1: Record each timestamp preceded with the Internet address of the registering entity.
o 1：登録エンティティのインターネットアドレスに先行する各タイムスタンプを記録します。
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.
o 3：オプションのインターネットアドレスフィールドは事前に指定されています。IPモジュールは、次の指定されたインターネットアドレスと独自のアドレスと一致する場合にのみ、タイムスタンプを登録します。
Therefore the following check should be performed:
したがって、次のチェックを実行する必要があります。
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):
タイムスタンプのデータ領域がいっぱいでない場合、処理は次のように続きます（上記のチェックはそれをチェックします。ポインターは、オプションに別のエントリの余地があることを確認してください）：
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.
o フラグが0の場合、システムの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.
o フラグが1の場合、システムの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アドレスがそれを指している場合、ポインターはシステムのインターフェイスに割り当てられたIPアドレスの1つと一致する場合、システムのタイムスタンプは、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 2113 [RFC2113]で定義されており、その後の更新はRFC 5350 [RFC5350]によって明らかにされています。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]で定義され、元々Path-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]で定義されており、元々Path-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]は、このセクションで説明したDOD基本セキュリティオプションと同じオプションタイプを使用した「セキュリティオプション」（Type = 130）を定義しました。RFC 791で指定された「セキュリティオプション」は、RFC 1122のセクション3.2.1.8で時代遅れと見なされているため、このセクションの議論は、RFC 1108 [RFC1108]によって指定されたDOD基本セキュリティオプションに焦点を当てています。
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 Basicセキュリティオプションは現在、多くのオペレーティングシステム（[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]で指定されているように、各パケットに含まれるDOD基本セキュリティオプションを処理する必要があります。
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は、オプションがデータグラムにせいぜい1回表示されるべきであると述べています。したがって、特定のデータグラムに複数のDOD基本セキュリティオプション（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].
このオプションは、基本的なセキュリティオプション（セクション3.13.2.13）に存在する追加のセキュリティラベル情報を、登録当局のニーズを満たすためにIPデータグラムに提供することを可能にします。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.
このオプションは、DOD基本セキュリティオプションとのみ存在する場合があります。したがって、パケットにDOD拡張セキュリティオプション（ESO）が含まれているが、DOD基本セキュリティオプションが含まれていない場合、ドロップする必要があり、このイベントをログに記録する必要があります（たとえば、パケットドロップを反映するためにカウンターを増加させることができます）。DOD Basic Securityオプションとは異なり、このオプションは単一の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]で指定されているように、各パケットに含まれるDOD拡張セキュリティオプションを処理する必要があります。
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）によって提案されました。[cipso1992]および[fips1994]で指定されています。
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]。インターネットドラフトはRFCとして公開されませんでしたが、この提案は後に米国国立標準技術研究所（NIST）によって「連邦情報処理標準出版188」として標準化されました[FIPS1994]。
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
cipso.length> = 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.
このオプションはRFC 1770 [RFC1770]で定義されており、元々、オプションに含まれる一連のアドレスに信頼性の低い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の断片化と再組み立ては、NIDSの回避、ファイアウォールルールのバイパス、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で説明されている「再組み立て手順の例」に従うシステムは、最大4.25分の再組み立てタイマーを使用して最低15秒で使用することになります。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を使用して、さまざまな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.
o システムがIPモジュールで割り当てることができるメモリの量に制限を強制しない場合、攻撃者はすべてのシステムメモリをフラグメントに結びつけることができ、その時点でシステムが使用できなくなり、おそらくクラッシュします。
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.
o システムがIPモジュール全体で割り当てることができるメモリの量に制限を強制する場合、この制限に到達すると、到着するすべての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 システムがフラグメントの再組み立てに割り当てることができる量メモリに制限を強制する場合、この制限に到達すると、到着するすべてのフラグメントが破棄されます。。
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ビットフィールドです。データグラムが断片化された場合、対応するすべてのフラグメントは、同じ{ソースアドレス、宛先アドレス、プロトコル、識別番号} 4タプルを共有します。したがって、フラグメントを受信するシステムは、同じIPデータグラムに対応するフラグメントとしてそれらを一意に識別できるようになります。特定の時点で、特定の4タプルを備えたネットワーク内のパケットはせいぜい1つのパケットしか存在する必要があります。そうでない場合、識別番号「衝突」が発生する可能性があり、受信システムは、同じ識別番号を単純に再利用する異なる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 gbit/sパスを送信する約1 kbサイズの（udp）パケットの連続ストリームがすべて576オクテットの2つの等しくサイズのフラグメントに断片化されます（最小再組み立てバッファサイズ）は、IP識別値を繰り返します。0.65秒未満（オーバーヘッドが約10％10％と仮定）。まだ断片化されている短いパケットを使用すると、この数字は0.4秒未満に簡単に低下する可能性があります。この短い時間枠で単一のIPパケットがドロップされたため、上層層のエラー検出および回復アルゴリズムがアプリケーションを取り戻すまで、パケットは誤って1回連続的に再組み立てされ始めます。
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.
ほとんどの場合、長いフラグメントタイムアウトの使用は攻撃者に利益をもたらします。FORGEDフラグメントは、IP識別スペースをより長い期間破壊し続けるためです。
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.
何年もの間、多くの攻撃がいくつかのオペレーティングシステムの再組み立て関数のバグを活用しており、ほとんどの場合、攻撃されたシステムのクラッシュにつながったバッファオーバーフローを生成しました。
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フラグメントの存在下では、トランスポートレイヤーまたはアプリケーション層（つまり、ネットワーク層の上のプロトコル層）での違法な活動を検出するために、NIDは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.
トラフィックを正しく評価するために、NIDによって実行される再組み立て関数の結果は、パケットの意図したレシピエントによって実行される再組み立て関数の結果と同じである必要があります。
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.
o IETF仕様は、オーバーラップフラグメントが受信された場合に何をすべきかについて、あいまいです。したがって、重複するデータが存在する場合、再組み立て関数を実行するシステムは、受信した最初のデータセット、受信した最新のコピー、またはその間に受け取ったその他のコピーのいずれかを自由に称えることができます。
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状態が発生します。何らかのしきい値に達すると、多くのシステムがフラグメントバッファーの一部を洗い流します。したがって、フラグメントの負荷、タイミングの問題、およびフラッシングポリシーに応じて、NIDは、意図した受信者によってフラグメントがどのように再組み立てされているかについて誤った仮定を取得する可能性があります。
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.
フラグメントフィルタリングへのアプローチの1つは、フィルタールールを最初のフラグメントに適用した結果（つまり、フラグメントオフセット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全体で説明されている断片化攻撃の対策を実装するのが難しいことの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つをカプセル化するIPデータグラム用の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:
これら2つの異なるフラグメントバッファープールのそれぞれの処理は、互いに完全に独立しています。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情報（最初のステップ）でパケットをフラッシングした後、検証チェックを実行できなかったパケット（2番目のステップ）の後、フラグメントバッファーにまだ十分なスペースがありません。必要な自由スペースが作成されるまで、最初のステップのチェックに合格しました。
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.
残念ながら、一部のIP実装（Linux [Linux]のものなど）は、断片化を実行するときに、対応するフラグメントを逆順序で送信します。そのような場合、フラグメントバッファーを洗い流す時点で、正当なフラグメントは、鍛造された断片と同じ処理を受けます。
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]は、監視対象のネットワークに関する十分な知識を獲得することにより、NIDの回避を防ぎ、意図した受信者に到達するパケットとそれによってどのように解釈されるかを評価することにより、「アクティブマッピング」という名前の手法を導入します。[novak2005]は、回避を避けるために、snort [snort] nidによって適用されるいくつかの技術について説明しています。
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).
ファイアウォールルールをバイパスするための古典的な手法の1つには、カプセル化されたプロトコルのヘッダーが断片化されているパケットの送信が含まれます。そのようなパケットを受信することが合法であっても（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 [RFC1812]は、ルーターが優先順序付きキューサービスを実装する必要があると述べています。これは、（論理）リンクの出力に対してパケットが選択された場合、そのリンクがキューに掲載されている最も優先されるパケットが送信されることを意味します。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優先順位フィールドを偽造することは些細なことであるため、攻撃者は、より良いネットワークサービスを違法に得るために送信するパケットの高い優先順位数を単純に偽造できます。特定のネットワークインフラストラクチャで優先順序付けされたキュー留めサービスが必要ない場合、それは無効にする必要があります。したがって、すべてのパケットは、サービスの種類または差別化されたサービスフィールドの値にもかかわらず、同じタイプのサービスを受信します。
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の弾丸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.
RFC 1812のセクション5.3.3.1および5.3.6は、優先順位順のキューサービスが実装され、有効になっている場合、ルーターは「優先順位が廃棄されていないパケットよりも高いパケットを破棄してはならない」と述べています。この推奨事項は、優先順位のフィールドのセマンティクスを考えると理にかなっていますが、攻撃者がいくつかのインターネットルーターを混雑させるために強制的な優先値のパケットを送信し、すべて（またはほとんど）を引き起こすことが簡単であることに注意することが重要です。廃棄されるより低い優先順位値のトラフィック。
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を使用したルートのみがそのパケットを転送するために検討する必要があると述べています。ただし、これは、特定のパケットの最も長い一致ルートの中に、受信パケットに含まれるTOS以外の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データグラムを転送するためには、通常、最初にIPアドレスを対応するリンクレイヤーアドレスにマッピングする必要があります（たとえば、アドレス解像度プロトコル（ARP）[ARP）[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.
この問題に対抗する1つの対策は、マッピング関数の時間を削除することです。すべてのパケットがタイムアウトしたアドレスに運命づけられています。さらに、「ネガティブキャッシュエントリ」が一致関数を実行するモジュールに保持される可能性があります。そのため、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フラグメントであり、キューに同じパケットの他のフラグメントがあった場合、他のフラグメントもドロップする必要があります。このポリシーの理論的根拠は、他のフラグメントにシステムリソースを使用することは無意味であるということです。なぜなら、1つのフラグメントが欠落している限り、受信システムがそれらを完全な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.
一部のシステムは、特定のデータグラムのフラグメントのサブセットのみを落とすことが知られており、パケットのすべてのフラグメントのサブセットのみが実際に次のホップに転送されたため、サービス拒否条件につながることが知られています。
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アドレスなど）や「ループバック」アドレスなどから到達できないと思われるアドレスがいくつかあることを理解することが重要ですが、多くのトリックがあります攻撃者は、それ以外の場合は到達不可能なIPアドレスに到達するために実行できます（たとえば、LSRRまたはSSRR 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.
同様に、Link-Local Unicastアドレス[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）は、プライベートインターネット用のIPアドレススペースの次の3ブロックを予約しています。
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)
o 10.0.0.0-10.255.255.255（10/8プレフィックス）o 172.16.0.0-172.31.255.255（172.16/12プレフィックス）
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アドレスは240/4アドレスブロックに対応しており、現在実験用に予約されています。その結果、ほとんどのルーターは、「クラス」eアドレスをソースアドレスまたは宛先アドレスとして含むパケットを破棄します。ソースアドレスおよび/または宛先アドレスとして240/4アドレスでパケットが受信された場合、パケットをドロップし、このイベントを記録する必要があります（たとえば、パケットドロップを反映するためにカウンターを増加させることができます）。
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つのエンドポイントのみで維持されます。したがって、マルチキャスト（またはブロードキャスト）宛先アドレスを備えたIPパケットが接続指向のプロトコル（TCPなど）に対して受信された場合、パケットをドロップする必要があり、このイベントを記録する必要があります（たとえば、カウンターを増加させることができます。パケットドロップを反映します）。
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仕様では、セクション4.3に示されているケースを除き、ホスト番号、ネットワーク番号、またはサブネット番号フィールドのいずれかについて、IPアドレスが値0または-1（1に設定されたすべてのビットの速記）を許可しませんでした。。7。ただし、CIDRでは、特定のIPアドレスのサブネットマスクが何であるかを先験的に知ることができないため、クラスレス間ドメインルーティング（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]には、フォーム{<network-prefix>、<subnet-number>、<Host-Number>}など、特別なインターネットアドレスの同様の議論が含まれていました。ただし、RFC 1812のセクション4.2.2.11で説明されているように、CIDRの世界では、サブネット番号は明らかにネットワークプレフィックスの拡張機能であり、プレフィックスの残りの部分と区別することはできません。
{0, 0}
{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}
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.
このドキュメントのセクション4.3.6で述べたように、CIDR [RFC4632]の展開により、直接接続されたサブネットに属さない特定の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.
著者は、このドキュメントの以前のバージョンの非常に徹底的なレビューを提供してくれたAlfred 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.
著者は、この文書の以前のバージョンに関する貴重なコメントを提供してくれたJari Arkko、Ron Bonica、Stewart Bryant、Adrian Farrel、Joel Jaeggli、Warren Kumari、Bruno Rohee、Andrew Youtchenkoに感謝したいと思います。
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（英国の国家インフラ保護センターセンター）を代表してフェルナンドゴントによって書かれており、2008年に英国CPNIによって発行された「インターネットプロトコルのセキュリティ評価」[CPNI2008]に大きく基づいています。
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.
著者は、ランドール・アトキンソン、ジョン・デイ、フアン・フラスキーニ、ロケ・ガグリアーノ、ギレルモ・ゴント、マーティン・マリノ、ペッカ・サヴォラ、クリストス・ズーラスに感謝したいと思います。
The author would like to thank Randall Atkinson and Roque Gagliano, who generously answered a number of questions.
著者は、ランドール・アトキンソンとロケ・ガリアーノに感謝したいと思います。彼は多くの質問にgeneしみなく答えました。
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] Postel、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] Plummer、D。、「イーサネットアドレス解像度プロトコル：または、ネットワークプロトコルアドレスをイーサネットハードウェア上の送信用のビットイーサネットアドレスに変換する」、STD 37、RFC 826、1982年11月。
[RFC1038] St. Johns, M., "Draft revised IP security option", RFC 1038, January 1988.
[RFC1038]セントジョンズ、M。、「ドラフト改訂IPセキュリティオプション」、RFC 1038、1988年1月。
[RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP MTU discovery options", RFC 1063, July 1988.
[RFC1063] Mogul、J.、Kent、C.、Partridge、C。、およびK. McCloghrie、「IP MTUディスカバリーオプション」、RFC 1063、1988年7月。
[RFC1108] Kent, S., "U.S", RFC 1108, November 1991.
[RFC1108] Kent、S。、 "U.S"、RFC 1108、1991年11月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、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] Malkin、G。、「IPオプションを使用したTraceroute」、RFC 1393、1993年1月。
[RFC1770] Graff, C., "IPv4 Option for Sender Directed Multi-Destination Delivery", RFC 1770, March 1995.
[RFC1770] Graff、C。、「送信者向けのIPv4オプション。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[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.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113] Katz、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「差別化されたサービスの建築」、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.セニー、「ネットワークイングレスフィルタリング：IPソースアドレススプーフィングを採用するサービス拒否攻撃の敗北」、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.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704] Baker、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] Cheshire、S.、Aboba、B。、およびE. Guttman、「IPv4 Link-Localアドレスの動的構成」、RFC 3927、2005年5月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、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] Fuller、V。およびT. Li、「クラスレス間ドメインルーティング（CIDR）：インターネットアドレスの割り当てと集約計画」、BCP 122、RFC 4632、2006年8月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、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] Gill、V.、Heasley、J.、Meyer、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] MANER、J。およびA. McDonald、「IPv4およびIPv6ルーターアラートオプションに関するIANAの考慮事項」、RFC 5350、2008年9月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735] Cotton、M。およびL. Vegoda、「Special Use IPv4アドレス」、BCP 153、RFC 5735、2010年1月。
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, November 2010.
[RFC6040] Briscoe、B。、「明示的な混雑通知のトンネル」、RFC 6040、2010年11月。
[Anderson2001] Anderson, J., "An Analysis of Fragmentation Attacks", 2001, <http://www.ouah.org/fragma.html>.
[Anderson2001] Anderson、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] Arkin、「ICMPを使用したIP TTLフィールド値（OOPS- 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 -Firewall and IDS Testing Tool」、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プロトコルスイートのセキュリティ問題」、Computer Communication Review Vol。19、No。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 Hostsをカウントするためのテクニック」、IMW'02 2002年11月6-8日、マルセイユ、フランス、2002年。
[Bendi1998] Bendi, "Bonk exploit", 1998, <http://www.insecure.org/sploits/ 95.NT.fragmentation.bonk.html>.
[Bendi1998] Bendi、 "Bonk Exploit"、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] Biondi、P。およびA. Ebalard、「IPv6ルーティングヘッダーセキュリティ」、Cansecwest 2007 Security Conference、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 Advisory 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 Advisory CA-1996-21：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 Advisory 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 Advisory CA-1997-28：IP Denial-of-Service Attacks」、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 Advisory CA-1998-01：Smurf 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 Advisory CA-1998-13：特定の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 Advisory CA-1999-17：サービス拒否ツール」、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、「CERT Advisory CA-2003-15：IPv4 PacketによってブロックされたCisco IOSインターフェイス」、2003、<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）」、Work in Progress、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/ proceedings/94jul/charters/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] Cerf、V。およびR. Kahn、「パケットネットワーク相互コミュニケーションのプロトコル」、IEEE Transactions on Communications Vol。22、No。5、1974年5月、pp。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] Cisco、「Cisco Security Advisory：Cisco IOSインターフェイスはIPv4 Packetによってブロックされました」、2003年、<http://www.cisco.com/en/ us/us/products_security_advisory09186a00801a34c2.shtml>。
[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、「Cisco IOS Security Configuration Guide、Release 12.2」、2003、<http://www.cisco.com/en/us/docs/ios/12_2/セキュリティ/Configuration/Guide/scfipso.html>。
[Clark1988] Clark, D., "The Design Philosophy of the DARPA Internet Protocols", Computer Communication Review Vol. 18, No. 4, 1988.
[Clark1988] Clark、D。、「DARPAインターネットプロトコルの設計哲学」、Computer Communication Review Vol。18、No。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 Magazine、Volume 0x0B、Issue 0x3c、Phile＃0x0C of 0x10、2002、<http://www.phrack.org/ sexsion.html？= 60＆id = 12＆mode = 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] fyodor、「アイドルスキャンおよび関連するIP IDゲーム」、2004、<http://www.inescure.org/nmap/idlescan.html>。
[GIAC2000] GIAC, "Egress Filtering v 0.2", 2000, <http://www.sans.org/y2k/egress.htm>.
[GIAC2000] GIAC、 "Egress Filtering 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。、「Advanced ICMP Packet Filtering」、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] Haddad、I。およびM. Zakrzewski、「Linux Clustersのセキュリティディストリビューション」、Linux Journal、2004、<http://www.linuxjournal.com/article/6943>。
[Humble1998] Humble, "Nestea exploit", 1998, <http://www.insecure.org/sploits/ linux.PalmOS.nestea.html>.
[humble1998] humble、 "nestea exploit"、1998、<http://www.insecure.org/sploits/ linux.palmos.nestea.html>。
[IANA_ET] IANA, "Ether Types", <http://www.iana.org/assignments/ethernet-numbers>.
[iana_et] iana、 "etherty"、<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）Manual Page"、2008、<http://techpubs.sgi.com/library/tpl/cgi-bin/ getDoc.cgi？Share/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] Jones、R。、「IPフラグメント再組み立てを制御するパラメーターの値を選択する方法」、2002、<ftp://ftp.cup.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] Kenney、M。、「The Ping of Death Page」、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] Kent、C。and J. Mogul、「断片化は有害と考えられている」、Proc。Sigcomm '87 Vol。17、No。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] Klein、A。、「OpenBSD DNSキャッシュ中毒と複数のO/S予測可能なIP ID脆弱性」、2007年、<http://www.trusteer.com/files/ openbsd_dns_cache_poisoning_and_multiple_os_predicable_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] Kohno、T.、Broido、A。、およびKC。Claffy、「リモート物理デバイスフィンガープリント」、信頼できる安全なコンピューティングに関するIEEEトランザクションVol。2、No。2、2005。
[LBNL2006] LBNL/NRG, "arpwatch tool", 2006, <http://ee.lbl.gov/>.
[lbnl2006] lbnl/nrg、 "arpwatch Tool"、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] Microsoft、「Microsoft Security Program：Microsoft Security Bulletin（MS99-038）。「Spoofed Route Pointer」で利用可能なパッチ、1999年、<http://www.microsoft.com/ technet/security/bulletin/ms9999999999999-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。and Novak、「ネットワーク侵入検出 - アナリストのハンドブック」、第2版New Riders Publishing、2000。
[Novak2005] Novak, "Target-Based Fragmentation Reassembly", 2005, <http://www.snort.org/assets/165/target_based_frag.pdf>.
[Novak2005] Novak、「ターゲットベースの断片化再組み立て」、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] Sanfilippo、S。、 "PF：Scrub（Packet remarization）"、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] Paxson、V.、Handley、M。、およびC. Kreibich、「ネットワーク侵入検出：回避、トラフィックの正規化、およびエンドツーエンドのプロトコルセマンティクス」、Usenix Conference、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/ververn/ptacek-newsham-evasion-98。PS>。
[RFC0815] Clark, D., "IP datagram reassembly algorithms", RFC 815, July 1982.
[RFC0815] Clark、D。、「IP Datagram Reasosembly Algorithms」、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.、Reed、D。、およびP. Traina、「IPフラグメントフィルタリングのセキュリティ上の考慮事項」、RFC 1858、1995年10月。
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[RFC2544] Bradner、S。およびJ. McQuaid、「ネットワーク相互接続デバイスのベンチマーク方法論」、RFC 2544、1999年3月。
[RFC3128] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, June 2001.
[RFC3128] Miller、I。、「小さなフラグメント攻撃（RFC 1858）のバリアントに対する保護」、RFC 3128、2001年6月。
[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.、Callaghan、B.、Robinson、D.、Thurlow、R.、Beame、C.、Eisler、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.、Mathis、M。、およびB. Chandler、「IPv4の高データレートでの再組み立てエラー」、RFC 4963、2007年7月。
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007.
[RFC4987] Eddy、W。、「TCP Syn Flooding Attacks and Common Mitigations」、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.、Atkinson、R。、およびG. Thomas、「Common Architecture Label IPv6 Security Option（Calipso）」、RFC 5570、2009年7月。
[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-Nodes", RFC 5670, November 2009.
[RFC5670] Eardley、P。、「PCN-Nodesの計量およびマーキング動作」、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.、Briscoe、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] Le Faucheur、F.、ed。、「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] sanfilippo、S。、「IPヘッダーIDについて」、1998年12月14日、Bugtraq Mailing-Listへの投稿、<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] sanfilippo、S。、「アイドルスキャン」、Bugtraq Mailing-List、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] sanfilippo、S。、「その他のIP ID」、Bugtraq Mailing-List、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] Shankar、U。およびV. Paxson、「アクティブマッピング：トラフィックを変更せずにNIDの回避に抵抗する」、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] Shannon、C.、Moore、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 Conference、2005、<http://www.silby.com/eurobsdcon05/eurobsdcon_slides.pdf>。
[Snort] Sourcefire, Inc., "Snort", <http://www.snort.org>.
[Snort] SourceFire、Inc。、「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] Oracle、「信頼できる拡張機能を備えたOracle Solaris」、2007、<h ttp：//www.oracle.com/us/products/servers-storage/solaris/ solaris-trusted-ext-ds-075583.pdf>。
[Song1999] Song, D., "Frag router tool", <http://www.monkey.org/~dugsong/fragroute/>.
[Song1999] Song、D。、 "Frag Router Tool"、<http://www.monkey.org/~dugsong/fragroute/>。
[SpooferProject] MIT ANA, "Spoofer Project", 2010, <http://spoofer.csail.mit.edu/index.php>.
[SpooferProject] MIT ANA、「Spoofer Project」、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] US-CERT、「US-Certの脆弱性ノートVU＃446689：Point Firewall-1をチェックすると、FASTモードが有効になっている場合、ファイアウォールを介して断片化されたパケットを許可します」、2001年、<http://www.kb.cert.org/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] US-CERT、「US-Certの脆弱性ノートVU＃310387：Cisco IOSは、Express Forwardingが有効になったときに以前のパケットの断片を開示しています」、2002年。
[Watson2004] Watson, P., "Slipping in the Window: TCP Reset Attacks", CanSecWest Conference, 2004.
[Watson2004] Watson、P。、「窓の滑り：TCPリセット攻撃」、Cansecwest Conference、2004。
[Zakrzewski2002] Zakrzewski, M. and I. Haddad, "Linux Distributed Security Module", 2002, <http://www.linuxjournal.com/article/6215>.
[Zakrzewski2002] Zakrzewski、M。and I. Haddad、「Linux分散セキュリティモジュール」、2002年、<http://www.linuxjourn.com/article/6215>。
[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、route、and Infinity、 "IP Spoofing Demystified（Trust Relationship Exploitation）"、Phrack Magazine、Volume 7、Isso 48、File 14 of 18、1988、<htt p：//www.phrack.org/issues.html？issue = 48＆id = 14＆mode = txt>。
Author's Address
著者の連絡先
Fernando Gont UK Centre for the Protection of National Infrastructure
Fernando Gont UK Center for National Infrastructure
EMail: fernando@gont.com.ar
URI: http://www.cpni.gov.uk