[要約] RFC 7126は、IPv4オプションを含むIPv4パケットのフィルタリングに関する推奨事項を提供しています。その目的は、ネットワーク管理者が効果的なフィルタリングポリシーを実装し、ネットワークのセキュリティとパフォーマンスを向上させることです。
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 7126 UTN-FRH / SI6 Networks
BCP: 186 R. Atkinson
Category: Best Current Practice Consultant
ISSN: 2070-1721 C. Pignataro
Cisco
February 2014
Recommendations on Filtering of IPv4 Packets Containing IPv4 Options
IPv4オプションを含むIPv4パケットのフィルタリングに関する推奨事項
Abstract
概要
This document provides advice on the filtering of IPv4 packets based on the IPv4 options they contain. Additionally, it discusses the operational and interoperability implications of dropping packets based on the IP options they contain.
このドキュメントでは、IPv4パケットに含まれるIPv4オプションに基づいたIPv4パケットのフィルタリングに関するアドバイスを提供します。さらに、パケットに含まれるIPオプションに基づいてパケットをドロップすることの運用および相互運用性の影響についても説明します。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化したものです。
This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。 Internet Engineering Steering Group（IESG）による公開が承認されています。 BCPの詳細については、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/rfc7126.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7126で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology and Conventions Used in This Document . . . . 3
1.2. Operational Focus . . . . . . . . . . . . . . . . . . . . 4
2. IP Options . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. General Security Implications of IP Options . . . . . . . . . 5
3.1. Processing Requirements . . . . . . . . . . . . . . . . . 5
4. Advice on the Handling of Packets with Specific IP Options . 7
4.1. End of Option List (Type = 0) . . . . . . . . . . . . . . 7
4.2. No Operation (Type = 1) . . . . . . . . . . . . . . . . . 7
4.3. Loose Source and Record Route (LSRR) (Type = 131) . . . . 8
4.4. Strict Source and Record Route (SSRR) (Type = 137) . . . 10
4.5. Record Route (Type = 7) . . . . . . . . . . . . . . . . . 11
4.6. Stream Identifier (Type = 136) (obsolete) . . . . . . . . 12
4.7. Internet Timestamp (Type = 68) . . . . . . . . . . . . . 13
4.8. Router Alert (Type = 148) . . . . . . . . . . . . . . . . 14
4.9. Probe MTU (Type = 11) (obsolete) . . . . . . . . . . . . 15
4.10. Reply MTU (Type = 12) (obsolete) . . . . . . . . . . . . 16
4.11. Traceroute (Type = 82) . . . . . . . . . . . . . . . . . 16
4.12. DoD Basic Security Option (Type = 130) . . . . . . . . . 17
4.13. DoD Extended Security Option (Type = 133) . . . . . . . . 20
4.14. Commercial IP Security Option (CIPSO) (Type = 134) . . . 22
4.15. VISA (Type = 142) . . . . . . . . . . . . . . . . . . . . 23
4.16. Extended Internet Protocol (Type = 145) . . . . . . . . . 24
4.17. Address Extension (Type = 147) . . . . . . . . . . . . . 25
4.18. Sender Directed Multi-Destination Delivery (Type = 149) . 25
4.19. Dynamic Packet State (Type = 151) . . . . . . . . . . . . 26
4.20. Upstream Multicast Pkt. (Type = 152) . . . . . . . . . . 26
4.21. Quick-Start (Type = 25) . . . . . . . . . . . . . . . . . 27
4.22. RFC3692-Style Experiment (Types = 30, 94, 158, and 222) . 28
4.23. Other IP Options . . . . . . . . . . . . . . . . . . . . 29
5. Security Considerations . . . . . . . . . . . . . . . . . . . 31
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.1. Normative References . . . . . . . . . . . . . . . . . . 31
7.2. Informative References . . . . . . . . . . . . . . . . . 32
This document discusses the filtering of IPv4 packets based on the IPv4 options they contain. Since various protocols may use IPv4 options to some extent, dropping packets based on the options they contain may have implications on the proper functioning of such protocols. Therefore, this document attempts to discuss the operational and interoperability implications of such dropping. Additionally, it outlines what a network operator might do in typical enterprise or Service Provider environments. This document also draws and is partly derived from [RFC6274], which also received review from the operational community.
このドキュメントでは、IPv4パケットに含まれるIPv4オプションに基づくIPv4パケットのフィルタリングについて説明します。さまざまなプロトコルがある程度IPv4オプションを使用する可能性があるため、それらに含まれるオプションに基づいてパケットをドロップすると、そのようなプロトコルの適切な機能に影響を与える可能性があります。したがって、このドキュメントでは、このような削除による運用上および相互運用性の影響について説明します。さらに、一般的なエンタープライズ環境またはサービスプロバイダー環境でネットワークオペレーターが行う可能性のあることについても概説します。この文書はまた、運用コミュニティからレビューを受けた[RFC6274]から引用されたものであり、その一部は引用されています。
We note that data seems to indicate that there is a current widespread practice of blocking IPv4 optioned packets. There are various plausible approaches to minimize the potential negative effects of IPv4 optioned packets while allowing some option semantics. One approach is to allow for specific options that are expected or needed, and have a default deny. A different approach is to deny unneeded options and have a default allow. Yet a third possible approach is to allow for end-to-end semantics by ignoring options and treating packets as un-optioned while in transit. Experiments and currently available data tend to support the first or third approaches as more realistic. Some results regarding the current state of affairs with respect to dropping packets containing IP options can be found in [MEDINA] and [FONSECA]. Additionally, [BREMIER-BARR] points out that the deployed Internet already has many routers that do not process IP options.
データは、IPv4オプションパケットをブロックするという現在広く行われている慣行があることを示しているようです。いくつかのオプションのセマンティクスを許可しながら、IPv4オプションパケットの潜在的な悪影響を最小限に抑えるためのさまざまなもっともらしいアプローチがあります。 1つのアプローチは、予想または必要とされる特定のオプションを許可し、デフォルトで拒否することです。別のアプローチは、不要なオプションを拒否し、デフォルトで許可することです。しかし、3つ目の可能なアプローチは、オプションを無視して、転送中にパケットをオプションなしとして扱うことで、エンドツーエンドのセマンティクスを可能にすることです。実験と現在入手可能なデータは、最初のアプローチまたは3番目のアプローチをより現実的にサポートする傾向があります。 IPオプションを含むパケットのドロップに関する現在の状況に関するいくつかの結果は、[MEDINA]および[FONSECA]にあります。さらに、[BREMIER-BARR]は、展開されたインターネットにはすでにIPオプションを処理しない多くのルーターがあることを指摘しています。
We also note that while this document provides advice on dropping packets on a "per IP option type", not all devices (routers, security gateways, and firewalls) may provide this capability with such granularity. Additionally, even in cases in which such functionality is provided, an operator might want to specify a dropping policy with a coarser granularity (rather than on a "per IP option type" granularity), as indicated above.
また、このドキュメントでは「IPオプションタイプごと」にパケットをドロップすることについてのアドバイスを提供しますが、すべてのデバイス（ルーター、セキュリティゲートウェイ、ファイアウォール）がこのような粒度でこの機能を提供できるわけではないことにも注意してください。さらに、そのような機能が提供されている場合でも、オペレーターは、上記のように、（「IPオプションタイプごと」の粒度ではなく）より粗い粒度でドロップポリシーを指定することができます。
Finally, in scenarios in which processing of IP options by intermediate systems is not required, a widespread approach is to simply ignore IP options and process the corresponding packets as if they do not contain any IP options.
最後に、中間システムによるIPオプションの処理が不要なシナリオでは、IPオプションを無視し、対応するパケットにIPオプションが含まれていないかのように、対応するパケットを単に処理するという広範なアプローチがあります。
The terms "fast path", "slow path", and associated relative terms ("faster path" and "slower path") are loosely defined as in Section 2 of [RFC6398].
「高速パス」、「低速パス」、および関連する相対的な用語（「高速パス」および「低速パス」）は、[RFC6398]のセクション2のように大まかに定義されています。
Because of the security-oriented nature of this document, we are deliberately including some historical citations. The goal is to explicitly retain and show history, as well as remove ambiguity and confusion.
このドキュメントのセキュリティ指向の性質のため、いくつかの歴史的な引用を意図的に含めています。目標は、履歴を明示的に保持して表示することと、あいまいさと混乱を取り除くことです。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
All of the recommendations in this document have been made in an effort to optimize for operational community consensus, as best the authors have been able to determine that. This has included not only accepting feedback from public lists, but also accepting off-list feedback from people at various network operators (e.g. Internet Service Providers, content providers, educational institutions, commercial firms).
このドキュメントのすべての推奨事項は、作者が最善を尽くして決定できるように、運用コミュニティのコンセンサスを最適化するために作成されました。これには、公開リストからのフィードバックを受け入れるだけでなく、さまざまなネットワークオペレーター（インターネットサービスプロバイダー、コンテンツプロバイダー、教育機関、企業など）の人々からのオフリストフィードバックの受け入れも含まれます。
IP options allow for the extension of the Internet Protocol. As specified in [RFC0791], there are two cases for the format of an option:
IPオプションにより、インターネットプロトコルの拡張が可能になります。 [RFC0791]で指定されているように、オプションの形式には2つのケースがあります。
o Case 1: A single byte of option-type.
o ケース1：1バイトのオプションタイプ。
o Case 2: An option-type byte, an option-length byte, and the actual option-data bytes.
o ケース2：オプションタイプバイト、オプション長バイト、および実際のオプションデータバイト。
IP options of Case 1 have the following syntax:
ケース1のIPオプションの構文は次のとおりです。
+-+-+-+-+-+-+-+-+- - - - - - - - -
| option-type | option-data
+-+-+-+-+-+-+-+-+- - - - - - - - -
The length of IP options of Case 1 is implicitly specified by the option-type byte.
ケース1のIPオプションの長さは、オプションタイプバイトによって暗黙的に指定されます。
IP options of Case 2 have the following syntax:
ケース2のIPオプションの構文は次のとおりです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| option-type | option-length | option-data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
In this case, the option-length byte counts the option-type byte and the option-length byte, as well as the actual option-data bytes.
この場合、オプション長バイトは、オプションタイプバイトとオプション長バイト、および実際のオプションデータバイトをカウントします。
All current and future options, except "End of Option List" (Type = 0) and "No Operation" (Type = 1), are of Class 2.
「オプションリストの終わり」（タイプ= 0）および「操作なし」（タイプ= 1）を除くすべての現在および将来のオプションは、クラス2です。
The option-type has three fields:
option-typeには3つのフィールドがあります。
o 1 bit: copied flag.
o 1ビット：コピーされたフラグ。
o 2 bits: option class.
o 2ビット：オプションクラス。
o 5 bits: option number.
o 5ビット：オプション番号。
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 =将来の使用のために予約されています。
This format allows for the creation of new options for the extension of the Internet Protocol (IP).
この形式では、インターネットプロトコル（IP）の拡張用の新しいオプションを作成できます。
Finally, the option number identifies the syntax of the rest of the option.
最後に、オプション番号はオプションの残りの構文を識別します。
The "IP OPTION NUMBERS" registry [IANA-IP] contains the list of the currently assigned IP option numbers.
「IPオプション番号」レジストリ[IANA-IP]には、現在割り当てられているIPオプション番号のリストが含まれています。
Historically, most IP routers used a general-purpose CPU to process IP packets and forward them towards their destinations. This same CPU usually also processed network management traffic (e.g., SNMP), configuration commands (e.g., command line interface), and various routing protocols (e.g., RIP, OSPF, BGP, IS-IS) or other control protocols (e.g., RSVP, ICMP). In such architectures, it has been common for the general-purpose CPU also to perform any packet filtering that has been enabled on the router (or router interface). An IP router built using this architecture often has a significant Distributed Denial-of-Service (DDoS) attack risk if the router control plane (e.g., CPU) is overwhelmed by a large number of IPv4 packets that contain IPv4 options.
これまで、ほとんどのIPルーターは、汎用CPUを使用してIPパケットを処理し、宛先に向けて転送していました。この同じCPUは通常、ネットワーク管理トラフィック（SNMPなど）、構成コマンド（コマンドラインインターフェイスなど）、およびさまざまなルーティングプロトコル（RIP、OSPF、BGP、IS-ISなど）またはその他の制御プロトコル（RSVPなど）も処理しました、ICMP）。このようなアーキテクチャでは、汎用CPUがルーター（またはルーターインターフェイス）で有効になっているパケットフィルタリングを実行することも一般的です。このアーキテクチャを使用して構築されたIPルーターは、ルーターコントロールプレーン（CPUなど）がIPv4オプションを含む多数のIPv4パケットに圧倒されると、多くの場合、分散型サービス拒否（DDoS）攻撃のリスクが高くなります。
From about 1995 onwards, a growing number of IP routers have incorporated silicon specialized for IP packet processing (i.e., Field-Programmable Gate Array (FPGA), Application-Specific Integrated Circuit (ASIC)), thereby separating the function of IP packet forwarding from the other functions of the router. Such router architectures tend to be more resilient to DDoS attacks that might be seen in the global public Internet. Depending upon various implementation and configuration details, routers with a silicon packet-forwarding engine can handle high volumes of IP packets containing IP options without any adverse impact on packet-forwarding rates or on the router's control plane (e.g., general-purpose CPU). Some implementations have a configuration knob simply to forward all IP packets containing IP options at wire-speed in silicon, as if the IP packet did not contain any IP options ("ignore options & forward"). Other implementations support wire-speed silicon-based packet filtering, thereby enabling packets containing certain IP options to be selectively dropped ("drop"), packets containing certain other IP options to have those IP options ignored ("ignore options & forward"), and other packets containing different IP options to have those options processed, either on a general-purpose CPU or using custom logic (e.g., FPGA, ASIC), while the packet is being forwarded ("process option & forward").
1995年以降、IPパケット処理に特化したシリコン（フィールドプログラマブルゲートアレイ（FPGA）、特定用途向け集積回路（ASIC）など）を組み込んだIPルーターが増え、IPパケット転送の機能がルータの他の機能。このようなルーターアーキテクチャは、グローバルなパブリックインターネットで見られるDDoS攻撃に対してより耐性がある傾向があります。さまざまな実装と構成の詳細に応じて、シリコンパケット転送エンジンを搭載したルーターは、IPオプションを含む大量のIPパケットを処理でき、パケット転送速度やルーターのコントロールプレーン（汎用CPUなど）に悪影響を与えません。一部の実装には、IPパケットにIPオプションが含まれていないかのように（ "オプションを無視して転送"）、シリコンのワイヤースピードでIPオプションを含むすべてのIPパケットを転送する構成ノブがあります。その他の実装では、ワイヤスピードのシリコンベースのパケットフィルタリングがサポートされているため、特定のIPオプションを含むパケットを選択的にドロップ（「ドロップ」）でき、その他の特定のIPオプションを含むパケットでは、それらのIPオプションを無視（「オプションを無視して転送」）できます。パケットの転送中に、汎用CPUまたはカスタムロジック（FPGA、ASICなど）を使用してオプションを処理するために、さまざまなIPオプションを含む他のパケット。
Broadly speaking, any IP packet that requires processing by an IP router's general-purpose CPU can be a DDoS risk to that router's general-purpose CPU (and thus to the router itself). However, at present, the particular architectural and engineering details of the specific IP router being considered are important to understand when evaluating the operational security risks associated with a particular IP packet type or IP option type.
大まかに言えば、IPルーターの汎用CPUによる処理を必要とするIPパケットは、そのルーターの汎用CPU（つまりルーター自体）に対するDDoSリスクになる可能性があります。ただし、現時点では、特定のIPパケットタイプまたはIPオプションタイプに関連する運用上のセキュリティリスクを評価する際に、検討中の特定のIPルーターの特定のアーキテクチャおよびエンジニアリングの詳細を理解することが重要です。
Operators are urged to consider the capabilities of potential IP routers for IP option filtering and handling as they make deployment decisions in the future.
オペレーターは、将来の展開を決定する際に、潜在的なIPルーターのIPオプションのフィルタリングと処理の機能を検討する必要があります。
Additional considerations for protecting the control plane from packets containing IP options can be found in [RFC6192].
IPオプションを含むパケットからコントロールプレーンを保護するための追加の考慮事項は、[RFC6192]にあります。
Finally, in addition to advice to operators, this document also provides advice to router, security gateway, and firewall implementers in terms of providing the capability to filter packets with different granularities: both on a "per IP option type" granularity (to maximize flexibility) as well as more coarse filters (to minimize configuration complexity).
最後に、オペレーターへのアドバイスに加えて、このドキュメントでは、ルーター、セキュリティゲートウェイ、ファイアウォールの実装者に、さまざまな粒度でパケットをフィルターする機能を提供するというアドバイスも提供します。 ）およびより粗いフィルター（構成の複雑さを最小限に抑えるため）。
The following subsections contain a description of each of the IP options that have so far been specified, a discussion of possible interoperability implications if packets containing such options are dropped, and specific advice on whether to drop packets containing these options in a typical enterprise or Service Provider environment.
以下のサブセクションには、これまでに指定された各IPオプションの説明、そのようなオプションを含むパケットがドロップされた場合に起こりうる相互運用性の影響、およびこれらのオプションを含むパケットをドロップするかどうかに関する一般的なエンタープライズまたはサービスに関する具体的なアドバイスが含まれますプロバイダー環境。
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.
このオプションは、オプションの終わりがインターネットプロトコルヘッダーの終わりと一致しない場合の「オプションの終わり」を示すために使用されます。
Specified in RFC 791 [RFC0791].
RFC 791 [RFC0791]で指定されています。
No specific security issues are known for this IPv4 option.
このIPv4オプションに関する特定のセキュリティ問題は知られていません。
Packets containing any IP options are likely to include an End of Option List. Therefore, if packets containing this option are dropped, it is very likely that legitimate traffic is blocked.
IPオプションを含むパケットには、オプションリストの終わりが含まれる可能性があります。したがって、このオプションを含むパケットがドロップされると、正当なトラフィックがブロックされる可能性が高くなります。
Routers, security gateways, and firewalls SHOULD NOT drop packets because they contain this option.
ルーター、セキュリティゲートウェイ、およびファイアウォールには、このオプションが含まれているため、パケットをドロップしないでください。
The no-operation option is basically meant to allow the sending system to align subsequent options in, for example, 32-bit boundaries.
操作なしのオプションは、基本的には、送信システムが後続のオプションを、たとえば32ビット境界に整列できるようにするためのものです。
Specified in RFC 791 [RFC0791].
RFC 791 [RFC0791]で指定されています。
No specific security issues are known for this IPv4 option.
このIPv4オプションに関する特定のセキュリティ問題は知られていません。
Packets containing any IP options are likely to include a No Operation option. Therefore, if packets containing this option are dropped, it is very likely that legitimate traffic is blocked.
IPオプションを含むパケットには、操作なしオプションが含まれている可能性があります。したがって、このオプションを含むパケットがドロップされると、正当なトラフィックがブロックされる可能性が高くなります。
Routers, security gateways, and firewalls SHOULD NOT drop packets because they contain this option.
ルーター、セキュリティゲートウェイ、およびファイアウォールには、このオプションが含まれているため、パケットをドロップしないでください。
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オプションの組み合わせを含むパケットはドロップする必要があり、このイベントはログに記録する必要があります（たとえば、パケットドロップを反映するためにカウンターをインクリメントできます）。
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 Internet Service Provider (ISP) peering agreements require support for this option in the routers within the peer of the ISP.
LSSRオプションは、一部のネットワーク問題のデバッグに役立ちます。一部のインターネットサービスプロバイダー（ISP）のピアリング契約では、ISPのピア内のルーターでこのオプションをサポートする必要があります。
Specified in RFC 791 [RFC0791].
RFC 791 [RFC0791]で指定されています。
The LSRR option has well-known security implications [RFC6274]. Among other things, the option can be used to:
LSRRオプションには、よく知られているセキュリティ上の影響があります[RFC6274]。特に、このオプションは次の目的で使用できます。
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 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オプションを慎重に作成することにより、複数のシステム間でパケットを複数回バウンスさせる可能性があるため、帯域幅枯渇攻撃を実行するための増幅方法として使用できます。
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バージョンです[Biondi2007]。唯一の違いは、IPv4ヘッダー（したがってLSRRオプション）の最大長が、IPv6ヘッダーと比較した場合に増幅係数を制限することです。
Additionally, some implementations have been found to fail to include proper sanity checks on the LSRR option, thus leading to security issues. These specific issues are believed to be solved in all modern implementations.
さらに、一部の実装では、LSRRオプションに適切な健全性チェックが含まれていないことが判明しているため、セキュリティの問題が発生します。これらの特定の問題は、すべての最新の実装で解決されると考えられています。
[Microsoft1999] is a security advisory about a vulnerability arising from improper validation of the Pointer field of the LSRR option.
[Microsoft1999]は、LSRRオプションのポインターフィールドの不適切な検証から生じる脆弱性に関するセキュリティアドバイザリです。
Finally, we note that some systems were known for providing a system-wide toggle to enable support for this option for those scenarios in which this option is required. However, improper implementation of such a system-wide toggle caused those systems to support the LSRR option even when explicitly configured not to do so.
最後に、このオプションが必要なシナリオでこのオプションのサポートを有効にするシステム全体のトグルを提供することで知られているシステムがあることに注意してください。ただし、このようなシステム全体のトグルの不適切な実装により、明示的に構成されていない場合でも、これらのシステムはLSRRオプションをサポートしていました。
[OpenBSD1998] is a security advisory about an improper implementation of such a system-wide toggle in 4.4BSD kernels. This issue was resolved in later versions of the corresponding operating system.
[OpenBSD1998]は、4.4BSDカーネルでのこのようなシステム全体のトグルの不適切な実装に関するセキュリティ勧告です。この問題は、対応するオペレーティングシステムの新しいバージョンで解決されました。
Network troubleshooting techniques that may employ the LSRR option (such as ping or traceroute with the appropriate arguments) would break when using the LSRR option. (Ping and traceroute without IPv4 options are not impacted.) Nevertheless, it should be noted that it is virtually impossible to use the LSRR option for troubleshooting, due to widespread dropping of packets that contain the option.
LSRRオプションを使用すると、LSRRオプションを使用するネットワークトラブルシューティングテクニック（適切な引数を使用したpingまたはtracerouteなど）が機能しなくなります。 （IPv4オプションのないpingおよびtracerouteは影響を受けません。）それにもかかわらず、オプションを含むパケットの広範なドロップにより、トラブルシューティングにLSRRオプションを使用することは事実上不可能であることに注意してください。
Routers, security gateways, and firewalls SHOULD implement an option-specific configuration knob to select whether packets with this option are dropped, packets with this IP option are forwarded as if they did not contain this IP option, or packets with this option are processed and forwarded as per [RFC0791]. The default setting for this knob SHOULD be "drop", and the default setting MUST be documented.
ルーター、セキュリティゲートウェイ、ファイアウォールは、オプション固有の構成ノブを実装して、このオプションのパケットをドロップするか、このIPオプションのパケットをこのIPオプションが含まれていないかのように転送するか、またはこのオプションのパケットを処理して、 [RFC0791]に従って転送されます。このノブのデフォルト設定は「ドロップ」である必要があり、デフォルト設定を文書化する必要があります。
Please note that treating packets with LSRR as if they did not contain this option can result in such packets being sent to a different device than the initially intended destination. With appropriate ingress filtering, this should not open an attack vector into the infrastructure. Nonetheless, it could result in traffic that would never reach the initially intended destination. Dropping these packets prevents unnecessary network traffic and does not make end-to-end communication any worse.
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).
このオプションは、Loose Source and Record Route（LSRR）オプションに似ていますが、SSRRの場合、オプションで指定されたルートは、パケットが通過する必要がある正確なルートです（つまり、他の介在ルーターは許可されません）。ルートにいる）。
The SSRR option can be of help in debugging some network problems. Some ISP peering agreements require support for this option in the routers within the peer of the ISP.
SSRRオプションは、いくつかのネットワーク問題のデバッグに役立ちます。一部のISPピアリング契約では、ISPのピア内のルーターでこのオプションのサポートが必要です。
Specified in RFC 791 [RFC0791].
RFC 791 [RFC0791]で指定されています。
The SSRR option has the same security implications as the LSRR option. Please refer to Section 4.3 for a discussion of such security implications.
SSRRオプションには、LSRRオプションと同じセキュリティ上の意味があります。このようなセキュリティへの影響については、セクション4.3を参照してください。
Network troubleshooting techniques that may employ the SSRR option (such as ping or traceroute with the appropriate arguments) would break when using the SSRR option. (Ping and traceroute without IPv4 options are not impacted.) Nevertheless, it should be noted that it is virtually impossible to use the SSRR option for trouble-shooting, due to widespread dropping of packets that contain such option.
SSRRオプションを使用すると、SSRRオプションを使用する可能性のあるネットワークトラブルシューティングテクニック（適切な引数を使用したpingまたはtracerouteなど）が機能しなくなります。 （IPv4オプションのないpingおよびtracerouteは影響を受けません。）それにもかかわらず、そのようなオプションを含むパケットの広範囲なドロップにより、トラブルシューティングにSSRRオプションを使用することは事実上不可能であることに注意してください。
Routers, security gateways, and firewalls SHOULD implement an option-specific configuration knob to select whether packets with this option are dropped, packets with this IP option are forwarded as if they did not contain this IP option, or packets with this option are processed and forwarded as per [RFC0791]. The default setting for this knob SHOULD be "drop", and the default setting MUST be documented.
ルーター、セキュリティゲートウェイ、ファイアウォールは、オプション固有の構成ノブを実装して、このオプションのパケットをドロップするか、このIPオプションのパケットをこのIPオプションが含まれていないかのように転送するか、またはこのオプションのパケットを処理して、 [RFC0791]に従って転送されます。このノブのデフォルト設定は「ドロップ」である必要があり、デフォルト設定を文書化する必要があります。
Please note that treating packets with SSRR as if they did not contain this option can result in such packets being sent to a different device that the initially intended destination. With appropriate ingress filtering this should not open an attack vector into the infrastructure. Nonetheless, it could result in traffic that would never reach the initially intended destination. Dropping these packets prevents unnecessary network traffic, and does not make end-to-end communication any worse.
このオプションが含まれていないかのようにSSRRでパケットを処理すると、そのようなパケットが最初に意図した宛先とは異なるデバイスに送信される可能性があることに注意してください。適切な入力フィルタリングを使用すると、インフラストラクチャへの攻撃ベクトルが開かれることはありません。それにもかかわらず、最初に意図した宛先に到達しないトラフィックが発生する可能性があります。これらのパケットをドロップすると、不要なネットワークトラフィックが防止され、エンドツーエンドの通信が悪化することはありません。
This option provides a means to record the route that a given packet follows.
このオプションは、特定のパケットがたどるルートを記録する手段を提供します。
Specified in RFC 791 [RFC0791].
RFC 791 [RFC0791]で指定されています。
This option can be exploited to map the topology of a network. However, the limited space in the IP header limits the usefulness of this option for that purpose.
このオプションを利用して、ネットワークのトポロジーをマップできます。ただし、IPヘッダーのスペースが限られているため、この目的でのこのオプションの有用性は制限されます。
Network troubleshooting techniques that may employ the RR option (such as ping with the RR option) would break when using the RR option. (Ping without IPv4 options is not impacted.) Nevertheless, it should be noted that it is virtually impossible to use such techniques due to widespread dropping of packets that contain RR options.
RRオプションを使用すると、RRオプションを使用するネットワークトラブルシューティングテクニック（RRオプションを使用したpingなど）が機能しなくなります。 （IPv4オプションのないpingは影響を受けません。）それにもかかわらず、RRオプションを含むパケットが広範囲にドロップされるため、このような手法を使用することは事実上不可能であることに注意してください。
Routers, security gateways, and firewalls SHOULD implement an option-specific configuration knob to select whether packets with this option are dropped, packets with this IP option are forwarded as if they did not contain this IP option, or packets with this option are processed and forwarded as per [RFC0791]. The default setting for this knob SHOULD be "drop", and the default setting MUST be documented.
ルーター、セキュリティゲートウェイ、ファイアウォールは、オプション固有の構成ノブを実装して、このオプションのパケットをドロップするか、このIPオプションのパケットをこのIPオプションが含まれていないかのように転送するか、またはこのオプションのパケットを処理して、 [RFC0791]に従って転送されます。このノブのデフォルト設定は「ドロップ」である必要があり、デフォルト設定を文書化する必要があります。
The Stream Identifier option originally provided a means for the 16-bit SATNET stream Identifier to be carried through networks that did not support the stream concept.
ストリーム識別子オプションは、元々、16ビットSATNETストリーム識別子を、ストリームの概念をサポートしていないネットワークを介して伝送する手段を提供していました。
However, as stated by Section 3.2.1.8 of RFC 1122 [RFC1122] and Section 4.2.2.1 of RFC 1812 [RFC1812], this option is obsolete. Therefore, it must be ignored by the processing systems. See also [IANA-IP] and [RFC6814].
ただし、RFC 1122 [RFC1122]のセクション3.2.1.8およびRFC 1812 [RFC1812]のセクション4.2.2.1で述べられているように、このオプションは廃止されました。したがって、処理システムでは無視する必要があります。 [IANA-IP]と[RFC6814]も参照してください。
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 is obsolete. There is no current use for this option.
このオプションは廃止されました。このオプションは現在使用されていません。
Specified in RFC 791 [RFC0791], and deprecated in RFC 1122 [RFC1122] and RFC 1812 [RFC1812]. This option has been formally obsoleted by [RFC6814].
RFC 791 [RFC0791]で指定され、RFC 1122 [RFC1122]およびRFC 1812 [RFC1812]で廃止されました。このオプションは、[RFC6814]によって正式に廃止されました。
No specific security issues are known for this IPv4 option.
このIPv4オプションに関する特定のセキュリティ問題は知られていません。
None.
なし。
Routers, security gateways, and firewalls SHOULD drop IP packets containing a Stream Identifier option.
ルーター、セキュリティゲートウェイ、およびファイアウォールは、ストリーム識別子オプションを含むIPパケットをドロップする必要があります（SHOULD）。
This option provides a means for recording the time at which each system (or a specified set of systems) processed this datagram, and it may optionally record the addresses of the systems providing the timestamps.
このオプションは、各システム（または指定されたシステムのセット）がこのデータグラムを処理した時刻を記録する手段を提供し、タイムスタンプを提供するシステムのアドレスをオプションで記録する場合があります。
Specified by RFC 791 [RFC0791].
RFC 791 [RFC0791]で指定されています。
The timestamp option has a number of security implications [RFC6274]. Among them are:
タイムスタンプオプションは、セキュリティに多くの影響を及ぼします[RFC6274]。それらの中には：
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 Record Routeオプションと同様の方法でネットワークトポロジをマップするために使用できます。
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 クロックスキューを分析することにより、物理デバイスの指紋をとるために使用できます。
[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]を使用して取得できるタイムスタンプを利用します。ただし、インターネットタイムスタンプオプションを使用すると、同じフィンガープリント方法を実装できます。
Network troubleshooting techniques that may employ the Internet Timestamp option (such as ping with the Timestamp option) would break when using the Timestamp option. (Ping without IPv4 options is not impacted.) Nevertheless, it should be noted that it is virtually impossible to use such techniques due to widespread dropping of packets that contain Internet Timestamp options.
Timestampオプションを使用すると、インターネットタイムスタンプオプションを使用するネットワークトラブルシューティングテクニック（Timestampオプションを使用したpingなど）が機能しなくなります。 （IPv4オプションのないpingは影響を受けません。）それにもかかわらず、インターネットタイムスタンプオプションを含むパケットが広範囲にドロップされるため、このような手法を使用することは事実上不可能であることに注意してください。
Routers, security gateways, and firewalls SHOULD drop IP packets containing an Internet Timestamp option.
ルーター、セキュリティゲートウェイ、およびファイアウォールは、インターネットタイムスタンプオプションを含むIPパケットをドロップする必要があります（SHOULD）。
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".
ルーターアラートオプションには、「オプションの値で示される機能にルーターが参加している場合、ルーターはこのパケットをより詳しく調べる必要がある」という意味があります。
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]).
ルーターアラートオプションはRFC 2113 [RFC2113]で定義されており、その後の更新はRFC 5350 [RFC5350]で明確になっています。 IANAレジストリ（[RFC5350]を参照）によって管理される16ビット値が含まれています。
The security implications of the Router Alert option have been discussed in detail in [RFC6398]. Basically, the Router Alert option might be exploited to perform a DoS attack by exhausting CPU resources at the processing routers.
[Router Alert]オプションのセキュリティへの影響は、[RFC6398]で詳細に説明されています。基本的に、ルーターアラートオプションは、処理ルーターでCPUリソースを使い果たすことにより、DoS攻撃を実行するために悪用される可能性があります。
Applications that employ the Router Alert option (such as RSVP [RFC2205]) would break.
ルーターアラートオプションを使用するアプリケーション（RSVP [RFC2205]など）は機能しなくなります。
This option SHOULD be allowed only in controlled environments, where the option can be used safely. [RFC6398] identifies some such environments. In unsafe environments, packets containing this option SHOULD be dropped.
このオプションは、オプションを安全に使用できる制御された環境でのみ許可する必要があります（SHOULD）。 [RFC6398]は、いくつかのそのような環境を識別します。安全でない環境では、このオプションを含むパケットは破棄されるべきです（SHOULD）。
A given router, security gateway, or firewall system has no way of knowing a priori whether this option is valid in its operational environment. Therefore, routers, security gateways, and firewalls SHOULD, by default, ignore the Router Alert option. Additionally, routers, security gateways, and firewalls SHOULD have a configuration setting that governs their reaction in the presence of packets containing the Router Alert option. This configuration setting SHOULD allow to honor and process the option, ignore the option, or drop packets containing this option.
特定のルーター、セキュリティゲートウェイ、またはファイアウォールシステムは、このオプションがその運用環境で有効かどうかをアプリオリに知る方法がありません。したがって、ルーター、セキュリティゲートウェイ、およびファイアウォールは、デフォルトでルーターアラートオプションを無視する必要があります（SHOULD）。さらに、ルーター、セキュリティゲートウェイ、ファイアウォールには、ルーターアラートオプションを含むパケットが存在する場合の反応を制御する構成設定が必要です（SHOULD）。この構成設定は、オプションを尊重して処理すること、オプションを無視すること、またはこのオプションを含むパケットをドロップすることを許可する必要があります（SHOULD）。
This option originally provided a mechanism to discover the Path-MTU. It has been declared obsolete.
このオプションは当初、Path-MTUを検出するメカニズムを提供していました。それは時代遅れであると宣言されました。
This option was originally defined in RFC 1063 [RFC1063] and was obsoleted with RFC 1191 [RFC1191]. This option is now obsolete, as RFC 1191 obsoletes RFC 1063 without using IP options.
このオプションは元々RFC 1063 [RFC1063]で定義され、RFC 1191 [RFC1191]で廃止されました。 RFC 1191はIPオプションを使用せずにRFC 1063を廃止するため、このオプションは廃止されました。
This option is obsolete. This option could have been exploited to cause a host to set its Path MTU (PMTU) estimate to an inordinately low or an inordinately high value, thereby causing performance problems.
このオプションは廃止されました。このオプションを悪用して、ホストがそのパスMTU（PMTU）見積もりを異常に低い値または異常に高い値に設定し、それによってパフォーマンスの問題が発生する可能性があります。
None
なし
This option is NOT employed with the modern "Path MTU Discovery" (PMTUD) mechanism [RFC1191], which employs special ICMP messages (Type 3, Code 4) in combination with the IP DF bit. Packetization Layer PMTUD (PLPMTUD) [RFC4821] can perform PMTUD without the need for any special packets.
このオプションは、特別なICMPメッセージ（タイプ3、コード4）をIP DFビットと組み合わせて使用する最新の「パスMTUディスカバリー」（PMTUD）メカニズム[RFC1191]では使用されません。パケット化層PMTUD（PLPMTUD）[RFC4821]は、特別なパケットを必要とせずにPMTUDを実行できます。
Routers, security gateways, and firewalls SHOULD drop IP packets that contain a Probe MTU option.
ルーター、セキュリティゲートウェイ、およびファイアウォールは、プローブMTUオプションを含むIPパケットをドロップする必要があります（SHOULD）。
This option originally provided a mechanism to discover the Path-MTU. It is now obsolete.
このオプションは当初、Path-MTUを検出するメカニズムを提供していました。現在は使用されていません。
This option was originally defined in RFC 1063 [RFC1063] and was obsoleted with RFC 1191 [RFC1191]. This option is now obsolete, as RFC 1191 obsoletes RFC 1063 without using IP options.
このオプションは元々RFC 1063 [RFC1063]で定義され、RFC 1191 [RFC1191]で廃止されました。 RFC 1191はIPオプションを使用せずにRFC 1063を廃止するため、このオプションは廃止されました。
This option is obsolete. This option could have been exploited to cause a host to set its PMTU estimate to an inordinately low or an inordinately high value, thereby causing performance problems.
このオプションは廃止されました。このオプションを悪用して、ホストがPMTU見積もりを異常に低い値または異常に高い値に設定し、パフォーマンスの問題を引き起こす可能性があります。
None
なし
This option is NOT employed with the modern "Path MTU Discovery" (PMTUD) mechanism [RFC1191], which employs special ICMP messages (Type 3, Code 4) in combination with the IP DF bit. PLPMTUD [RFC4821] can perform PMTUD without the need of any special packets.
このオプションは、特別なICMPメッセージ（タイプ3、コード4）をIP DFビットと組み合わせて使用する最新の「パスMTUディスカバリー」（PMTUD）メカニズム[RFC1191]では使用されません。 PLPMTUD [RFC4821]は、特別なパケットを必要とせずにPMTUDを実行できます。
Routers, security gateways, and firewalls SHOULD drop IP packets that contain a Reply MTU option.
ルーター、セキュリティゲートウェイ、およびファイアウォールは、応答MTUオプションを含むIPパケットをドロップする必要があります（SHOULD）。
This option originally provided a mechanism to trace the path to a host.
このオプションは元々、ホストへのパスを追跡するメカニズムを提供していました。
This option was originally specified by RFC 1393 [RFC1393] as "experimental", and it was never widely deployed on the public Internet. This option has been formally obsoleted by [RFC6814].
このオプションは、もともとRFC 1393 [RFC1393]によって「実験的」として指定されたものであり、公共のインターネット上で広く展開されることはありませんでした。このオプションは、[RFC6814]によって正式に廃止されました。
This option is obsolete. Because this option required each router in the path both to provide special processing and to send an ICMP message, it could have been exploited to perform a DoS attack by exhausting CPU resources at the processing routers.
このオプションは廃止されました。このオプションでは、パス内の各ルーターが特別な処理を提供し、ICMPメッセージを送信する必要があったため、処理ルーターでCPUリソースを使い果たしてDoS攻撃を実行するために悪用された可能性があります。
None
なし
Routers, security gateways, and firewalls SHOULD drop IP packets that contain a Traceroute option.
ルーター、セキュリティゲートウェイ、およびファイアウォールは、Tracerouteオプションを含むIPパケットをドロップする必要があります（SHOULD）。
This option [RFC1108] is used by Multi-Level Secure (MLS) end-systems and intermediate systems in specific environments to:
このオプション[RFC1108]は、特定の環境のマルチレベルセキュア（MLS）エンドシステムおよび中間システムによって、次の目的で使用されます。
o transmit from source to destination in a network standard representation the common security labels required by computer security models [Landwehr81],
o コンピュータのセキュリティモデル[Landwehr81]が必要とする一般的なセキュリティラベルをネットワーク標準表現で送信元から宛先に送信します。
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 データグラムがたどるルートが、データグラムに示されているすべての保護当局が要求するレベルまで保護されていることを確認してください。
The DoD Basic Security Option (BSO) was implemented in IRIX [IRIX2008] and is currently implemented in a number of operating systems (e.g., Security-Enhanced Linux [SELinux2008], Solaris [Solaris2008], and Cisco IOS [Cisco-IPSO]). It is also currently deployed in a number of high-security networks. These networks are typically either in physically secure locations, protected by military/governmental communications security equipment, or both.
DoD Basic Security Option（BSO）はIRIX [IRIX2008]で実装され、現在、多くのオペレーティングシステム（例：Security-Enhanced Linux [SELinux2008]、Solaris [Solaris2008]、およびCisco IOS [Cisco-IPSO]）で実装されています。 。現在、多数の高セキュリティネットワークにも導入されています。これらのネットワークは通常、物理的に安全な場所にあるか、軍事/政府の通信セキュリティ機器によって保護されているか、またはその両方です。
Such networks are typically built using commercial off-the-shelf (COTS) IP routers and Ethernet switches, but they are not normally interconnected with the global public Internet. MLS systems are much more widely deployed now than they were at the time the then-IESG decided to remove IPSO (IP Security Options) from the IETF Standards Track. Since nearly all MLS systems also support IPSO BSO and IPSO ESO, this option is believed to have more deployment now than when the IESG removed this option from the IETF Standards Track. [RFC5570] describes a similar option recently defined for IPv6 and has much more detailed explanations of how sensitivity label options are used in real-world deployments.
このようなネットワークは通常、市販の（COTS）IPルーターとイーサネットスイッチを使用して構築されますが、通常、グローバルなパブリックインターネットと相互接続されていません。 MLSシステムは、当時IESGがIETF標準トラックからIPSO（IPセキュリティオプション）を削除することを決定したときよりもはるかに広く展開されています。ほとんどすべてのMLSシステムがIPSO BSOおよびIPSO ESOもサポートしているため、このオプションは、現在IESGがこのオプションをIETF標準トラックから削除したときよりも多くの展開があると考えられています。 [RFC5570]は、最近IPv6に定義された同様のオプションを説明し、実際の展開で機密ラベルオプションがどのように使用されるかについて、より詳細な説明があります。
It is specified by RFC 1108 [RFC1108], which obsoleted RFC 1038 [RFC1038] (which in turn obsoleted the Security Option defined in RFC 791 [RFC0791]).
これはRFC 1108 [RFC1108]で指定されており、RFC 1038 [RFC1038]は廃止されました（RFC 791 [RFC0791]で定義されたセキュリティオプションは廃止されました）。
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. Later, RFC 1038 [RFC1038] revised the IP security options, and in turn was obsoleted by RFC 1108 [RFC1108]. The "Security Option" specified in RFC 791 is considered obsolete by Section 3.2.1.8 of RFC 1122 [RFC1122] and Section 4.2.2.1 of RFC 1812 [RFC1812], and therefore the discussion in this section is focused on the DoD Basic Security option specified by RFC 1108 [RFC1108].
RFC 791 [RFC0791]は、このセクションで説明するDoD基本セキュリティオプションと同じオプションタイプを使用する「セキュリティオプション」（タイプ= 130）を定義しました。その後、RFC 1038 [RFC1038]はIPセキュリティオプションを改訂し、RFC 1108 [RFC1108]によって廃止されました。 RFC 791で指定された「セキュリティオプション」は、RFC 1122 [RFC1122]のセクション3.2.1.8およびRFC 1812 [RFC1812]のセクション4.2.2.1によって廃止されたと見なされるため、このセクションの説明はDoD基本セキュリティオプションに焦点を当てていますRFC 1108 [RFC1108]で指定されています。
Section 4.2.2.1 of RFC 1812 states that routers "SHOULD implement [this option]".
RFC 1812のセクション4.2.2.1は、ルーターは「[このオプション]を実装する必要がある」と述べています。
Some private IP networks consider IP router-based per-interface selective filtering of packets based on (a) the presence of an IPSO option (including BSO and ESO) and (b) the contents of that IPSO option to be important for operational security reasons. The recent IPv6 Common Architecture Label IPv6 Security Option (CALIPSO) specification discusses this in additional detail, albeit in an IPv6 context [RFC5570].
一部のプライベートIPネットワークでは、（a）IPSOオプション（BSOおよびESOを含む）の存在、および（b）そのIPSOオプションの内容が運用上のセキュリティ上の理由から重要であることに基づいて、パケットのIPルーターベースのインターフェースごとの選択的フィルタリングを検討しています。最近のIPv6共通アーキテクチャラベルIPv6セキュリティオプション（CALIPSO）仕様では、IPv6コンテキスト[RFC5570]ではあるが、これについてさらに詳しく説明しています。
Such private IP networks commonly are built using both commercial and open-source products -- for hosts, guards, firewalls, switches, routers, etc. Some commercial IP routers support this option, as do some IP routers that are built on top of MLS operating systems (e.g., on top of Trusted Solaris [Solaris2008] or Security-Enhanced Linux [SELinux2008]).
このようなプライベートIPネットワークは、一般に、ホスト製品、ガード、ファイアウォール、スイッチ、ルーターなどの商用製品とオープンソース製品の両方を使用して構築されています。MLSの上に構築されている一部のIPルーターと同様に、一部の商用IPルーターはこのオプションをサポートしています。オペレーティングシステム（Trusted Solaris [Solaris2008]またはSecurity-Enhanced Linux [SELinux2008]の上など）。
For example, many Cisco routers that run Cisco IOS include support for selectively filtering packets that contain the IP Security Options (IPSO) with per-interface granularity. This capability has been present in many Cisco routers since the early 1990s [Cisco-IPSO-Cmds]. Some government-sector products reportedly also support the IP Security Options (IPSO), for example, CANEWARE [RFC4949].
たとえば、Cisco IOSを実行する多くのシスコルータは、インターフェイスごとの粒度でIPセキュリティオプション（IPSO）を含むパケットを選択的にフィルタリングするサポートを備えています。この機能は、1990年代初頭以来、多くのシスコルータに存在しています[Cisco-IPSO-Cmds]。伝えられるところによると、一部の政府部門の製品は、例えばCANEWARE [RFC4949]などのIPセキュリティオプション（IPSO）もサポートしています。
Support for the IPSO Basic Security Option also is included in the "IPsec Configuration Policy Information Model" [RFC3585] and in the "IPsec Security Policy Database Configuration MIB" [RFC4807]. Section 4.6.1 of the IP Security Domain of Interpretation [RFC2407] includes support for labeled IPsec security associations compatible with the IP Security Options. (Note: RFC 2407 was obsoleted by [RFC4306], which was obsoleted by [RFC5996].)
IPSO基本セキュリティオプションのサポートは、「IPsec構成ポリシー情報モデル」[RFC3585]と「IPsecセキュリティポリシーデータベース構成MIB」[RFC4807]にも含まれています。 IP Security Domain of Interpretation [RFC2407]のセクション4.6.1には、IPセキュリティオプションと互換性のあるラベル付きIPsecセキュリティアソシエーションのサポートが含まれています。 （注：RFC 2407は[RFC4306]によって廃止され、[RFC5996]によって廃止されました。）
Presence of this option in a packet does not by itself create any specific new threat. Packets with this option ought not normally be seen on the global public Internet.
パケットにこのオプションが存在しても、それ自体は特定の新しい脅威を生み出しません。このオプションを備えたパケットは、通常、グローバルなパブリックインターネットでは見られません。
If packets with this option are blocked or if the option is stripped from the packet during transmission from source to destination, then the packet itself is likely to be dropped by the receiver because it is not properly labeled. In some cases, the receiver might receive the packet but associate an incorrect sensitivity label with the received data from the packet whose BSO was stripped by an intermediate router or firewall. Associating an incorrect sensitivity label can cause the received information either to be handled as more sensitive than it really is ("upgrading") or as less sensitive than it really is ("downgrading"), either of which is problematic.
このオプションが設定されたパケットがブロックされている場合、または送信元から宛先への送信中にオプションがパケットから削除された場合、適切にラベル付けされていないため、パケット自体が受信者によってドロップされる可能性があります。場合によっては、受信者がパケットを受信しても、中間ルーターまたはファイアウォールによってBSOが削除されたパケットから受信したデータに誤った機密ラベルを関連付けることがあります。誤った機密ラベルを関連付けると、受信した情報が実際よりも敏感（「アップグレード」）または実際よりも敏感（「ダウングレード」）に処理される可能性があり、どちらも問題があります。
A given IP router, security gateway, or firewall has no way to know a priori what environment it has been deployed into. Even closed IP deployments generally use exactly the same commercial routers, security gateways, and firewalls that are used in the public Internet.
特定のIPルーター、セキュリティゲートウェイ、またはファイアウォールは、それが展開されている環境をアプリオリに知る方法がありません。クローズドIPの展開でも、一般に、パブリックインターネットで使用されているものとまったく同じ商用ルーター、セキュリティゲートウェイ、およびファイアウォールを使用します。
Since operational problems result in environments where this option is needed if either the option is dropped or IP packets containing this option are dropped, but no harm results if the option is carried in environments where it is not needed, the default configuration SHOULD NOT (a) modify or remove this IP option or (b) drop an IP packet because the IP packet contains this option.
オプションが削除されるか、このオプションを含むIPパケットが削除されると、このオプションが必要な環境では運用上の問題が発生しますが、オプションが不要な環境で実行されても害はないため、デフォルトの構成はすべきではありません（a ）このIPオプションを変更または削除するか、（b）IPパケットにこのオプションが含まれているため、IPパケットをドロップします。
A given IP router, security gateway, or firewall MAY be configured to drop this option or to drop IP packets containing this option in an environment known to not use this option.
特定のIPルーター、セキュリティゲートウェイ、またはファイアウォールは、このオプションを削除するか、このオプションを使用しないことがわかっている環境でこのオプションを含むIPパケットを削除するように構成できます。
For auditing reasons, routers, security gateways, and firewalls SHOULD be capable of logging the numbers of packets containing the BSO on a per-interface basis. Also, routers, security gateways, and firewalls SHOULD be capable of dropping packets based on the BSO presence as well as the BSO values.
監査上の理由から、ルーター、セキュリティゲートウェイ、およびファイアウォールは、インターフェイスごとにBSOを含むパケットの数をログに記録できる必要があります（SHOULD）。また、ルーター、セキュリティゲートウェイ、およびファイアウォールは、BSOの存在とBSOの値に基づいてパケットをドロップできる必要があります（SHOULD）。
This option permits additional security labeling information, beyond that present in the Basic Security Option (Section 4.12), to be supplied in an IP datagram to meet the needs of registered authorities.
このオプションでは、基本的なセキュリティオプション（セクション4.12）にあるものを超える追加のセキュリティラベル情報をIPデータグラムで提供して、登録済み機関のニーズを満たすことができます。
The DoD Extended Security Option (ESO) is specified by RFC 1108 [RFC1108].
DoD拡張セキュリティオプション（ESO）は、RFC 1108 [RFC1108]で指定されています。
Some private IP networks consider IP router-based per-interface selective filtering of packets based on (a) the presence of an IPSO option (including BSO and ESO) and (b) based on the contents of that IPSO option to be important for operational security reasons. The recent IPv6 CALIPSO option specification discusses this in additional detail, albeit in an IPv6 context [RFC5570].
一部のプライベートIPネットワークでは、（a）IPSOオプション（BSOおよびESOを含む）の存在と（b）そのIPSOオプションの内容に基づく運用に重要であることに基づいて、パケットのIPルーターベースのインターフェースごとの選択的フィルタリングを検討していますセキュリティ上の理由。最近のIPv6 CALIPSOオプション仕様では、IPv6コンテキスト[RFC5570]ではあるが、これについてさらに詳しく説明しています。
Such private IP networks commonly are built using both commercial and open-source products -- for hosts, guards, firewalls, switches, routers, etc. Some commercial IP routers support this option, as do some IP routers that are built on top of MLS operating systems (e.g., on top of Trusted Solaris [Solaris2008] or Security-Enhanced Linux [SELinux2008]).
このようなプライベートIPネットワークは、一般に、ホスト製品、ガード、ファイアウォール、スイッチ、ルーターなどの商用製品とオープンソース製品の両方を使用して構築されています。MLSの上に構築されている一部のIPルーターと同様に、一部の商用IPルーターはこのオプションをサポートしています。オペレーティングシステム（Trusted Solaris [Solaris2008]またはSecurity-Enhanced Linux [SELinux2008]の上など）。
For example, many Cisco routers that run Cisco IOS include support for selectively filtering packets that contain the IP Security Options (IPSO) with per-interface granularity. This capability has been present in many Cisco routers since the early 1990s [Cisco-IPSO-Cmds]. Some government sector products reportedly also support the IP Security Options (IPSO), for example, CANEWARE [RFC4949].
たとえば、Cisco IOSを実行する多くのシスコルータは、インターフェイスごとの粒度でIPセキュリティオプション（IPSO）を含むパケットを選択的にフィルタリングするサポートを備えています。この機能は、1990年代初頭以来、多くのシスコルータに存在しています[Cisco-IPSO-Cmds]。伝えられるところによると、一部の政府部門の製品は、例えばCANEWARE [RFC4949]などのIPセキュリティオプション（IPSO）もサポートしています。
Support for the IPSO Extended Security Option also is included in the "IPsec Configuration Policy Information Model" [RFC3585] and in the "IPsec Security Policy Database Configuration MIB" [RFC4807]. Section 4.6.1 of the IP Security Domain of Interpretation [RFC2407] includes support for labeled IPsec security associations compatible with the IP Security Options.
IPSO拡張セキュリティオプションのサポートは、「IPsec構成ポリシー情報モデル」[RFC3585]と「IPsecセキュリティポリシーデータベース構成MIB」[RFC4807]にも含まれています。 IP Security Domain of Interpretation [RFC2407]のセクション4.6.1には、IPセキュリティオプションと互換性のあるラベル付きIPsecセキュリティアソシエーションのサポートが含まれています。
Presence of this option in a packet does not by itself create any specific new threat. Packets with this option ought not normally be seen on the global public Internet.
パケットにこのオプションが存在しても、それ自体は特定の新しい脅威を生み出しません。このオプションを備えたパケットは、通常、グローバルなパブリックインターネットでは見られません。
If packets with this option are blocked or if the option is stripped from the packet during transmission from source to destination, then the packet itself is likely to be dropped by the receiver because it is not properly labeled. In some cases, the receiver might receive the packet but associate an incorrect sensitivity label with the received data from the packet whose ESO was stripped by an intermediate router or firewall. Associating an incorrect sensitivity label can cause the received information either to be handled as more sensitive than it really is ("upgrading") or as less sensitive than it really is ("downgrading"), either of which is problematic.
このオプションが設定されたパケットがブロックされている場合、または送信元から宛先への送信中にオプションがパケットから削除された場合、適切にラベル付けされていないため、パケット自体が受信者によってドロップされる可能性があります。場合によっては、受信者がパケットを受信しても、ESOが中間ルーターまたはファイアウォールによって削除されたパケットから受信したデータに、誤った機密ラベルを関連付けることがあります。誤った機密ラベルを関連付けると、受信した情報が実際よりも敏感（「アップグレード」）または実際よりも敏感（「ダウングレード」）に処理される可能性があり、どちらも問題があります。
A given IP router, security gateway, or firewall has no way to know a priori what environment it has been deployed into. Even closed IP deployments generally use exactly the same commercial routers, security gateways, and firewalls that are used in the public Internet.
特定のIPルーター、セキュリティゲートウェイ、またはファイアウォールは、それが展開されている環境をアプリオリに知る方法がありません。クローズドIPの展開でも、一般に、パブリックインターネットで使用されているものとまったく同じ商用ルーター、セキュリティゲートウェイ、およびファイアウォールを使用します。
Since operational problems result in environments where this option is needed if either the option is dropped or IP packets containing this option are dropped, but no harm results if the option is carried in environments where it is not needed, the default configuration SHOULD NOT (a) modify or remove this IP option or (b) drop an IP packet because the IP packet contains this option.
オプションが削除されるか、このオプションを含むIPパケットが削除されると、このオプションが必要な環境では運用上の問題が発生しますが、オプションが不要な環境で実行されても害はないため、デフォルトの構成はすべきではありません（a ）このIPオプションを変更または削除するか、（b）IPパケットにこのオプションが含まれているため、IPパケットをドロップします。
A given IP router, security gateway, or firewall MAY be configured to drop this option or to drop IP packets containing this option in an environment known to not use this option.
特定のIPルーター、セキュリティゲートウェイ、またはファイアウォールは、このオプションを削除するか、このオプションを使用しないことがわかっている環境でこのオプションを含むIPパケットを削除するように構成できます。
For auditing reasons, routers, security gateways, and firewalls SHOULD be capable of logging the numbers of packets containing the ESO on a per-interface basis. Also, routers, security gateways, and firewalls SHOULD be capable of dropping packets based on the ESO presence as well as the ESO values.
監査上の理由から、ルーター、セキュリティゲートウェイ、ファイアウォールは、インターフェイスごとにESOを含むパケットの数をログに記録できる必要があります（SHOULD）。また、ルーター、セキュリティゲートウェイ、およびファイアウォールは、ESOの存在とESOの値に基づいてパケットをドロップできる必要があります（SHOULD）。
This option was proposed by the Trusted Systems Interoperability Group (TSIG), with the intent of meeting trusted networking requirements for the commercial trusted systems marketplace.
このオプションは、Trusted Systems Interoperability Group（TSIG）によって提案され、商用の信頼できるシステム市場の信頼できるネットワーク要件を満たすことを目的としています。
It was implemented in IRIX [IRIX2008] and is currently implemented in a number of operating systems (e.g., Security-Enhanced Linux [SELinux2008] and Solaris [Solaris2008]). It is also currently deployed in a number of high-security networks.
これはIRIX [IRIX2008]で実装され、現在、多くのオペレーティングシステム（例：Security-Enhanced Linux [SELinux2008]およびSolaris [Solaris2008]）で実装されています。現在、多数の高セキュリティネットワークにも導入されています。
This option is specified in [CIPSO] and [FIPS1994]. There are zero known IP router implementations of CIPSO. Several MLS operating systems support CIPSO, generally the same MLS operating systems that support IPSO.
このオプションは、[CIPSO]および[FIPS1994]で指定されています。 CIPSOの既知のIPルーター実装はありません。複数のMLSオペレーティングシステムがCIPSOをサポートしています。通常、IPSOをサポートする同じMLSオペレーティングシステムです。
The TSIG proposal was taken to the Commercial Internet Security Option (CIPSO) Working Group of the IETF [CIPSOWG1994], and an Internet-Draft was produced [CIPSO]. 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の商用インターネットセキュリティオプション（CIPSO）ワーキンググループ[CIPSOWG1994]に提出され、インターネットドラフトが作成されました[CIPSO]。 Internet-DraftはRFCとして公開されたことはありませんでしたが、この提案は後に米国連邦情報・技術局（NIST）によって「連邦情報処理標準出版物188」[FIPS1994]として標準化されました。
Presence of this option in a packet does not by itself create any specific new threat. Packets with this option ought not normally be seen on the global public Internet.
パケットにこのオプションが存在しても、それ自体は特定の新しい脅威を生み出しません。このオプションを備えたパケットは、通常、グローバルなパブリックインターネットでは見られません。
If packets with this option are blocked or if the option is stripped from the packet during transmission from source to destination, then the packet itself is likely to be dropped by the receiver because it is not properly labeled. In some cases, the receiver might receive the packet but associate an incorrect sensitivity label with the received data from the packet whose CIPSO was stripped by an intermediate router or firewall. Associating an incorrect sensitivity label can cause the received information either to be handled as more sensitive than it really is ("upgrading") or as less sensitive than it really is ("downgrading"), either of which is problematic.
このオプションが設定されたパケットがブロックされている場合、または送信元から宛先への送信中にオプションがパケットから削除された場合、適切にラベル付けされていないため、パケット自体が受信者によってドロップされる可能性があります。場合によっては、受信者がパケットを受信しても、中間ルーターまたはファイアウォールによってCIPSOが取り除かれたパケットから受信したデータに誤った機密ラベルを関連付けることがあります。誤った機密ラベルを関連付けると、受信した情報が実際よりも敏感（「アップグレード」）または実際よりも敏感（「ダウングレード」）に処理される可能性があり、どちらも問題があります。
Because of the design of this option, with variable syntax and variable length, it is not practical to support specialized filtering using the CIPSO information. No routers or firewalls are known to support this option. However, routers, security gateways, and firewalls SHOULD NOT by default modify or remove this option from IP packets and SHOULD NOT by default drop packets because they contain this option. For auditing reasons, routers, security gateways, and firewalls SHOULD be capable of logging the numbers of packets containing the CIPSO on a per-interface basis. Also, routers, security gateways, and firewalls SHOULD be capable of dropping packets based on the CIPSO presence.
このオプションの設計は可変構文と可変長であるため、CIPSO情報を使用した特殊なフィルタリングをサポートすることは現実的ではありません。このオプションをサポートしているルーターやファイアウォールはありません。ただし、ルーター、セキュリティゲートウェイ、およびファイアウォールは、デフォルトでこのオプションを変更またはIPパケットから削除する必要があり（SHOULD NOT）、デフォルトでパケットをドロップする必要があります（このオプションが含まれているため）。監査上の理由から、ルーター、セキュリティゲートウェイ、およびファイアウォールは、インターフェイスごとにCIPSOを含むパケットの数をログに記録できる必要があります（SHOULD）。また、ルーター、セキュリティゲートウェイ、およびファイアウォールは、CIPSOの存在に基づいてパケットをドロップできる必要があります（SHOULD）。
This options was part of an experiment at the University of Southern California (USC) and was never widely deployed.
このオプションは南カリフォルニア大学（USC）での実験の一部であり、広く展開されることはありませんでした。
The original option specification is not publicly available. This option has been formally obsoleted by [RFC6814].
オリジナルのオプション仕様は公開されていません。このオプションは、[RFC6814]によって正式に廃止されました。
Not possible to determine (other than the general security implications of IP options discussed in Section 3), since the corresponding specification is not publicly available.
対応する仕様が公開されていないため、（セクション3で説明したIPオプションの一般的なセキュリティへの影響を除いて）判別することはできません。
None.
なし。
Routers, security gateways, and firewalls SHOULD drop IP packets that contain this option.
ルーター、セキュリティゲートウェイ、およびファイアウォールは、このオプションを含むIPパケットをドロップする必要があります（SHOULD）。
The EIP option was introduced by one of the proposals submitted during the IP Next Generation (IPng) efforts to address the problem of IPv4 address exhaustion.
EIPオプションは、IPv4アドレス枯渇の問題に対処するためのIP Next Generation（IPng）の取り組み中に提出された提案の1つによって導入されました。
Specified in [RFC1385]. This option has been formally obsoleted by [RFC6814].
[RFC1385]で指定されています。このオプションは、[RFC6814]によって正式に廃止されました。
This option is obsolete. This option was used (or was intended to be used) to signal that a packet superficially similar to an IPv4 packet actually contained a different protocol, opening up the possibility that an IPv4 node that simply ignored this option would process a received packet in a manner inconsistent with the intent of the sender. There are no known threats arising from this option, other than the general security implications of IP options discussed in Section 3.
このオプションは廃止されました。このオプションを使用して（または使用することを意図して）、IPv4パケットに表面的に類似したパケットが実際に異なるプロトコルを含んでいたことを通知し、このオプションを単に無視したIPv4ノードが受信パケットをある方法で処理する可能性を開きました送信者の意図と矛盾しています。このオプションから生じる既知の脅威はありませんが、セクション3で説明されているIPオプションの一般的なセキュリティへの影響は除きます。
None.
なし。
Routers, security gateways, and firewalls SHOULD drop packets that contain this option.
ルーター、セキュリティゲートウェイ、およびファイアウォールは、このオプションを含むパケットをドロップする必要があります（SHOULD）。
The Address Extension option was introduced by one of the proposals submitted during the IPng efforts to address the problem of IPv4 address exhaustion.
アドレス拡張オプションは、IPv4アドレス枯渇の問題に対処するためのIPngの取り組み中に提出された提案の1つによって導入されました。
Specified in [RFC1475]. This option has been formally obsoleted by [RFC6814].
[RFC1475]で指定されています。このオプションは、[RFC6814]によって正式に廃止されました。
There are no known threats arising from this option, other than the general security implications of IP options discussed in Section 3.
このオプションから生じる既知の脅威はありませんが、セクション3で説明されているIPオプションの一般的なセキュリティへの影響は除きます。
None.
なし。
Routers, security gateways, and firewalls SHOULD drop packets that contain this option.
ルーター、セキュリティゲートウェイ、およびファイアウォールは、このオプションを含むパケットをドロップする必要があります（SHOULD）。
This option originally provided unreliable UDP delivery to a set of addresses included in the option.
このオプションは元々、オプションに含まれる一連のアドレスへの信頼性の低いUDP配信を提供していました。
This option is specified in RFC 1770 [RFC1770]. It has been formally obsoleted by [RFC6814].
このオプションはRFC 1770 [RFC1770]で指定されています。 [RFC6814]によって正式に廃止されました。
This option could have been exploited for bandwidth-amplification in DoS attacks.
このオプションは、DoS攻撃の帯域幅増幅に悪用される可能性があります。
None.
なし。
Routers, security gateways, and firewalls SHOULD drop IP packets that contain a Sender Directed Multi-Destination Delivery option.
ルーター、セキュリティゲートウェイ、およびファイアウォールは、Sender Directed Multi-Destination Deliveryオプションを含むIPパケットをドロップする必要があります（SHOULD）。
The Dynamic Packet State option was used to specify the Dynamic Packet State (DPS) in the context of the differentiated services architecture.
動的パケット状態オプションは、差別化サービスアーキテクチャのコンテキストで動的パケット状態（DPS）を指定するために使用されました。
The Dynamic Packet State option was specified in [DIFFSERV-DPS]. The aforementioned document was meant to be published as "Experimental", but never made it into an RFC. This option has been formally obsoleted by [RFC6814].
動的パケット状態オプションは[DIFFSERV-DPS]で指定されました。前述のドキュメントは「実験的」として公開されることを意図していましたが、RFCにしたことはありません。このオプションは、[RFC6814]によって正式に廃止されました。
Possible threats include theft of service and denial of service. However, we note that this option has never been widely implemented or deployed.
考えられる脅威には、サービスの盗難やサービス拒否があります。ただし、このオプションが広く実装または展開されたことはありません。
None.
なし。
Routers, security gateways, and firewalls SHOULD drop packets that contain this option.
ルーター、セキュリティゲートウェイ、およびファイアウォールは、このオプションを含むパケットをドロップする必要があります（SHOULD）。
This option was meant to solve the problem of doing upstream forwarding of multicast packets on a multi-access LAN.
このオプションは、マルチアクセスLANでマルチキャストパケットのアップストリーム転送を行う際の問題を解決するためのものです。
This option was originally specified in [BIDIR-TREES]. It was never formally standardized in the RFC series and was never widely implemented and deployed. Its use was obsoleted by [RFC5015], which employs a control-plane mechanism to solve the problem of doing upstream forwarding of multicast packets on a multi-access LAN. This option has been formally obsoleted by [RFC6814].
このオプションは元々[BIDIR-TREES]で指定されていました。 RFCシリーズで正式に標準化されることはなく、広く実装および展開されることもありませんでした。マルチプレーンアクセスLANでマルチキャストパケットのアップストリーム転送を行う問題を解決するためにコントロールプレーンメカニズムを採用する[RFC5015]によって、その使用は廃止されました。このオプションは、[RFC6814]によって正式に廃止されました。
This option is obsolete. A router that ignored this option instead of processing it as specified in [BIDIR-TREES] could have forwarded multicast packets to an unintended destination.
このオプションは廃止されました。 [BIDIR-TREES]で指定されているようにこのオプションを処理するのではなく、このオプションを無視したルーターが、マルチキャストパケットを意図しない宛先に転送した可能性があります。
None.
なし。
Routers, security gateways, and firewalls SHOULD drop packets that contain this option.
ルーター、セキュリティゲートウェイ、およびファイアウォールは、このオプションを含むパケットをドロップする必要があります（SHOULD）。
This IP Option is used in the specification of Quick-Start for TCP and IP, which is an experimental mechanism that allows transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and, at times, in the middle of a data transfer (e.g., after an idle period) [RFC4782].
このIPオプションは、TCPとIPのクイックスタートの仕様で使用されます。これは、トランスポートプロトコルがルーターと連携して、開始時、および場合によっては途中で許可される送信速度を決定できるようにする実験的なメカニズムです。データ転送（アイドル期間後など）[RFC4782]。
Specified in RFC 4782 [RFC4782], on the "Experimental" track.
RFC 4782 [RFC4782]の「実験的」トラックで指定されています。
Section 9.6 of [RFC4782] notes that Quick-Start is vulnerable to two kinds of attacks:
[RFC4782]のセクション9.6は、Quick-Startが2種類の攻撃に対して脆弱であることを述べています。
o attacks to increase the routers' processing and state load, and,
o ルーターの処理と状態負荷を増加させる攻撃、および
o attacks with bogus Quick-Start Requests to temporarily tie up available Quick-Start bandwidth, preventing routers from approving Quick-Start Requests from other connections.
o 利用可能なクイックスタート帯域幅を一時的に占有する偽のクイックスタートリクエストによる攻撃。ルーターが他の接続からのクイックスタートリクエストを承認するのを防ぎます。
The Quick-Start functionality would be disabled, and additional delays in TCP's connection establishment (for example) could be introduced. (Please see Section 4.7.2 of [RFC4782].) We note, however, that Quick-Start has been proposed as a mechanism that could be of use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet [RFC4782].
クイックスタート機能が無効になり、TCPの接続確立などに追加の遅延が発生する可能性があります。 （[RFC4782]のセクション4.7.2を参照してください。）ただし、クイックスタートは、制御された環境で使用できるメカニズムとして提案されたものであり、ユビキタスに意図された、または適切なメカニズムとして提案されたものではありません。グローバルインターネット[RFC4782]での展開。
A given router, security gateway, or firewall system has no way of knowing a priori whether this option is valid in its operational environment. Therefore, routers, security gateways, and firewalls SHOULD, by default, ignore the Quick-Start option. Additionally, routers, security gateways, and firewalls SHOULD have a configuration setting that governs their reaction in the presence of packets containing the Quick-Start option. This configuration setting SHOULD allow to honor and process the option, ignore the option, or drop packets containing this option. The default configuration is to ignore the Quick-Start option.
特定のルーター、セキュリティゲートウェイ、またはファイアウォールシステムは、このオプションがその運用環境で有効かどうかをアプリオリに知る方法がありません。したがって、ルーター、セキュリティゲートウェイ、およびファイアウォールは、デフォルトでは、クイックスタートオプションを無視する必要があります。さらに、ルーター、セキュリティゲートウェイ、ファイアウォールには、Quick-Startオプションを含むパケットが存在する場合の反応を制御する構成設定が必要です（SHOULD）。この構成設定は、オプションを尊重して処理すること、オプションを無視すること、またはこのオプションを含むパケットをドロップすることを許可する必要があります（SHOULD）。デフォルトの設定では、Quick-Startオプションは無視されます。
We note that if routers in a given environment do not implement and enable the Quick-Start mechanism, only the general security implications of IP options (discussed in Section 3) would apply.
特定の環境のルーターがクイックスタートメカニズムを実装および有効化していない場合、IPオプションの一般的なセキュリティへの影響（セクション3で説明）のみが適用されます。
Section 2.5 of RFC 4727 [RFC4727] allocates an option number with all defined values of the "copy" and "class" fields for RFC3692-style experiments. This results in four distinct option type codes: 30, 94, 158, and 222.
RFC 4727 [RFC4727]のセクション2.5は、RFC3692スタイルの実験用に「copy」フィールドと「class」フィールドのすべての定義された値を含むオプション番号を割り当てます。これにより、4つの異なるオプションタイプコード、30、94、158、および222が生成されます。
It is only appropriate to use these values in explicitly configured experiments; they MUST NOT be shipped as defaults in implementations.
明示的に構成された実験でこれらの値を使用することのみが適切です。それらは実装のデフォルトとして出荷されてはなりません。
Specified in RFC 4727 [RFC4727] in the context of RFC3692-style experiments.
RFC3692スタイルの実験のコンテキストでRFC 4727 [RFC4727]で指定されています。
No specific security issues are known for this IPv4 option.
このIPv4オプションに関する特定のセキュリティ問題は知られていません。
None.
なし。
Routers, security gateways, and firewalls SHOULD have configuration knobs for IP packets that contain RFC3692-style Experiment options to select between "ignore & forward" and "drop & log". Otherwise, no legitimate experiment using these options will be able to traverse any IP router.
ルーター、セキュリティゲートウェイ、およびファイアウォールには、「無視して転送」と「ドロップしてログ」のどちらかを選択するためのRFC3692スタイルの実験オプションを含むIPパケットの構成ノブが必要です（SHOULD）。そうしないと、これらのオプションを使用した正当な実験でIPルーターを通過できません。
Special care needs to be taken in the case of "drop & log". Devices SHOULD count the number of packets dropped, but the logging of drop events SHOULD be limited so as to not overburden device resources.
「ドロップ＆ログ」の場合は特に注意が必要です。デバイスはドロップされたパケットの数をカウントする必要があります（SHOULD）が、ドロップイベントのロギングはデバイスリソースに過負荷をかけないように制限する必要があります（SHOULD）。
The aforementioned configuration knob SHOULD default to "drop & log".
前述の設定ノブはデフォルトで「ドロップ＆ログ」にすべきです。
Unrecognized IP options are to be ignored. Section 3.2.1.8 of RFC 1122 [RFC1122] specifies this behavior as follows:
認識されないIPオプションは無視されます。 RFC 1122 [RFC1122]のセクション3.2.1.8では、この動作を次のように指定しています。
The IP and transport layer MUST each interpret those IP options that they understand and silently ignore the others.
IPおよびトランスポート層は、それぞれが理解するIPオプションを解釈し、他のオプションを黙って無視しなければなりません（MUST）。
Additionally, Section 4.2.2.6 of RFC 1812 [RFC1812] specifies it as follows:
さらに、RFC 1812 [RFC1812]のセクション4.2.2.6では、次のように指定されています。
A router MUST ignore IP options which it does not recognize.
ルーターは、認識しないIPオプションを無視する必要があります。
This document adds that unrecognized IP options MAY also be logged.
このドキュメントでは、認識されないIPオプションもログに記録される場合があることを追加しています。
Further, routers, security gateways, and firewalls MUST provide the ability to log drop events of IP packets containing unrecognized or obsolete options.
さらに、ルーター、セキュリティゲートウェイ、およびファイアウォールは、認識されないオプションまたは廃止されたオプションを含むIPパケットのドロップイベントをログに記録する機能を提供する必要があります。
A number of additional options are listed in the "IP OPTION NUMBERS" IANA registry [IANA-IP] as of the time this document was last edited. Specifically:
このドキュメントが最後に編集された時点で、いくつかの追加オプションが「IPオプション番号」IANAレジストリ[IANA-IP]にリストされています。具体的には：
Copy Class Number Value Name
---- ----- ------ ----- -------------------------------------------
0 0 10 10 ZSU - Experimental Measurement
1 2 13 205 FINN - Experimental Flow Control
0 0 15 15 ENCODE - ???
1 0 16 144 IMITD - IMI Traffic Descriptor
1 0 22 150 - Unassigned (Released 18 Oct. 2005)
The ENCODE option (type 15) has been formally obsoleted by [RFC6814].
ENCODEオプション（タイプ15）は、[RFC6814]によって正式に廃止されました。
The lack of open specifications for these options makes it impossible to evaluate their security implications.
これらのオプションにはオープンな仕様がないため、セキュリティへの影響を評価することは不可能です。
The lack of open specifications for these options makes it impossible to evaluate the operational and interoperability impact if packets containing these options are blocked.
これらのオプションのオープンな仕様がないため、これらのオプションを含むパケットがブロックされている場合、運用と相互運用性への影響を評価することができません。
Routers, security gateways, and firewalls SHOULD have configuration knobs for IP packets containing these options (or other options not recognized) to select between "ignore & forward" and "drop & log".
ルーター、セキュリティゲートウェイ、ファイアウォールには、これらのオプション（または認識されない他のオプション）を含むIPパケットの構成ノブがあり、「無視して転送」と「ドロップしてログ」を選択する必要があります。
Section 4.23.1 points out that [RFC1122] and [RFC1812] specify that unrecognized IP options MUST be ignored. However, the previous paragraph states that routers, security gateways, and firewalls SHOULD have a configuration option for dropping and logging IP packets containing unrecognized options. While it is acknowledged that this advice contradicts the previous RFCs' requirements, the advice in this document reflects current operational reality.
セクション4.23.1は、[RFC1122]および[RFC1812]が、認識されないIPオプションを無視する必要があることを指定していることを指摘しています。ただし、前の段落では、ルーター、セキュリティゲートウェイ、およびファイアウォールには、認識されないオプションを含むIPパケットをドロップおよびログ記録するための構成オプションがあるべきであると述べています。このアドバイスは以前のRFCの要件と矛盾することは認められていますが、このドキュメントのアドバイスは現在の運用上の現実を反映しています。
Special care needs to be taken in the case of "drop & log". Devices SHOULD count the number of packets dropped, but the logging of drop events SHOULD be limited so as to not overburden device resources.
「ドロップ＆ログ」の場合は特に注意が必要です。デバイスはドロップされたパケットの数をカウントする必要があります（SHOULD）が、ドロップイベントのロギングはデバイスリソースに過負荷をかけないように制限する必要があります（SHOULD）。
This document provides advice on the filtering of IP packets that contain IP options. Dropping such packets can help to mitigate the security issues that arise from use of different IP options. Many of the IPv4 options listed in this document are deprecated and cause no operational impact if dropped. However, dropping packets containing IPv4 options that are in use can cause real operational problems in deployed networks. Therefore, the practice of dropping all IPv4 packets containing one or more IPv4 options without careful consideration is not recommended.
このドキュメントでは、IPオプションを含むIPパケットのフィルタリングに関するアドバイスを提供します。このようなパケットをドロップすると、さまざまなIPオプションの使用から生じるセキュリティ問題を軽減するのに役立ちます。このドキュメントにリストされているIPv4オプションの多くは廃止されており、削除しても運用上の影響はありません。ただし、使用中のIPv4オプションを含むパケットをドロップすると、展開されたネットワークで実際の運用上の問題が発生する可能性があります。したがって、1つ以上のIPv4オプションを含むすべてのIPv4パケットを、慎重に検討せずにドロップすることはお勧めできません。
The authors would like to thank (in alphabetical order) Ron Bonica, C. M. Heard, Merike Kaeo, Panos Kampanakis, Suresh Krishnan, Arturo Servin, SM, and Donald Smith for providing thorough reviews and valuable comments. Merike Kaeo also contributed text used in this document.
著者は、徹底的なレビューと貴重なコメントを提供してくれたRon Bonica、C。M. Heard、Merike Kaeo、Panos Kampanakis、Suresh Krishnan、Arturo Servin、SM、およびDonald Smithに感謝します（アルファベット順）。 Merike Kaeoもこのドキュメントで使用されているテキストに貢献しました。
The authors also wish to thank various network operations folks who supplied feedback on earlier versions of this document but did not wish to be named explicitly in this document.
著者はまた、このドキュメントの以前のバージョンに関するフィードバックを提供したが、このドキュメントで明示的に名前を付けられたくないさまざまなネットワーク運用関係者に感謝します。
Part of this document is initially based on the document "Security Assessment of the Internet Protocol" [CPNI2008] that is the result of a project carried out by Fernando Gont on behalf of UK CPNI (formerly NISCC). Fernando Gont would like to thank UK CPNI (formerly NISCC) for their continued support.
この文書の一部は、最初に文書「インターネットプロトコルのセキュリティ評価」[CPNI2008]に基づいています。これは、フェルナンドゴントが英国のCPNI（旧NISCC）に代わって実施したプロジェクトの結果です。フェルナンドゴントは、英国CPNI（旧NISCC）の継続的な支援に感謝します。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[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月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[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月。
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4727] Fenner、B。、「IPv4、IPv6、ICMPv4、ICMPv6、UDP、およびTCPヘッダーの実験値」、RFC 4727、2006年11月。
[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月。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC5015] Handley、M.、Kouvelas、I.、Speakman、T。、およびL. Vicisano、「Bidirectional Protocol Independent Multicast（BIDIR-PIM）」、RFC 5015、2007年10月。
[RFC6398] Le Faucheur, F., "IP Router Alert Considerations and Usage", BCP 168, RFC 6398, October 2011.
[RFC6398] Le Faucheur、F。、「IPルーターアラートの考慮事項と使用法」、BCP 168、RFC 6398、2011年10月。
[RFC6814] Pignataro, C. and F. Gont, "Formally Deprecating Some IPv4 Options", RFC 6814, November 2012.
[RFC6814] Pignataro、C。およびF. Gont、「正式には一部のIPv4オプションの廃止」、RFC 6814、2012年11月。
[BIDIR-TREES] Estrin, D. and D. Farinacci, "Bi-Directional Shared Trees in PIM-SM", Work in Progress, May 1999.
[BIDIR-TREES] Estrin、D。およびD. Farinacci、「PIM-SMの双方向共有ツリー」、Work in Progress、1999年5月。
[BREMIER-BARR] Bremier-Barr, A. and H. Levy, "Spoofing prevention method", Proceedings of IEEE InfoCom 2005, Volume 1, pp. 536-547, March 2005.
[BREMIER-BARR] Bremier-Barr、A。およびH. Levy、「なりすまし防止方法」、Proceedings of IEEE InfoCom 2005、Volume 1、pp。536-547、2005年3月。
[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 Routing Header Security」、CanSecWest 2007 Security Conference、2007、<http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf>。
[CIPSOWG1994] IETF CIPSO Working Group, "Commercial Internet Protocol Security Option (CIPSO) Charter", 1994, <http://www.ietf.org/proceedings/94jul/charters/ cipso-charter.html>.
[CIPSOWG1994] IETF CIPSOワーキンググループ、「商用インターネットプロトコルセキュリティオプション（CIPSO）憲章」、1994、<http://www.ietf.org/proceedings/94jul/charters/ cipso-charter.html>。
[CIPSO] IETF CIPSO Working Group, "COMMERCIAL IP SECURITY OPTION (CIPSO 2.2)", Work in Progress, 1992.
[CIPSO] IETF CIPSOワーキンググループ、「COMMERCIAL IP SECURITY OPTION（CIPSO 2.2）」、Work in Progress、1992。
[CPNI2008] Gont, F., "Security Assessment of the Internet Protocol", 2008, <http://www.gont.com.ar/papers/InternetProtocol.pdf>.
[CPNI2008] Gont、F。、「インターネットプロトコルのセキュリティ評価」、2008、<http://www.gont.com.ar/papers/InternetProtocol.pdf>。
[Cisco-IPSO-Cmds] Cisco Systems, Inc., "IP Security Options Commands", Cisco IOS Security Command Reference, Release 12.2, <http://www.cisco.com/en/US/docs/ios/12_2/security/ command/reference/srfipso.html>.
[Cisco-IPSO-Cmds] Cisco Systems、Inc。、「IP Security Options Commands」、Cisco IOS Security Command Reference、Release 12.2、<http://www.cisco.com/en/US/docs/ios/12_2/ security / command / reference / srfipso.html>。
[Cisco-IPSO] Cisco Systems, Inc., "Configuring IP Security Options", Cisco IOS Security Configuration Guide, Release 12.2, 2006, <http://www.cisco.com/en/US/docs/ios/12_2/security/ configuration/guide/scfipso.html>.
[Cisco-IPSO] Cisco Systems、Inc。、「Configuring IP Security Options」、Cisco IOS Security Configuration Guide、Release 12.2、2006、<http://www.cisco.com/en/US/docs/ios/12_2/ security / configuration / guide / scfipso.html>。
[DIFFSERV-DPS] Stoica, I., Zhang, H., Venkitaram, N., and J. Mysore, "Per Hop Behaviors Based on Dynamic Packet State", Work in Progress, October 2002.
[DIFFSERV-DPS] Stoica、I.、Zhang、H.、Venkitaram、N。、およびJ. Mysore、「動的パケット状態に基づくホップごとの動作」、進行中の作業、2002年10月。
[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>。
[FONSECA] Fonseca, R., Porter, G., Katz, R., Shenker, S., and I. Stoica, "IP Options are not an option", EECS Department, University of California, Berkeley, December 2005, <http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/ EECS-2005-24.html>.
[FONSECA] Fonseca、R.、Porter、G.、Katz、R.、Shenker、S.、I。Stoica、「IPオプションはオプションではない」、カリフォルニア大学バークレー校EECS部、2005年12月、< http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/ EECS-2005-24.html>。
[IANA-IP] IANA, "IP OPTION NUMBERS", <http://www.iana.org/assignments/ip-parameters>.
[IANA-IP] IANA、「IPオプション番号」、<http://www.iana.org/assignments/ip-parameters>。
[IRIX2008] IRIX, "IRIX 6.5 trusted_networking(7) manual page", 2008, <http://techpubs.sgi.com/library/tpl/cgi-bin/ getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/a_man/ cat7/trusted_networking.z>.
[IRIX2008] IRIX、「IRIX 6.5 trusted_networking（7）マニュアルページ」、2008、<http://techpubs.sgi.com/library/tpl/cgi-bin/ getdoc.cgi？coll = 0650＆db = man＆fname = / usr / share / catman / a_man / cat7 / trusted_networking.z>。
[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]河野徹、ブロイド、A、kc。 Claffy、「Remote Physical Device Fingerprinting」、IEEE Transactions on Dependable and Secure Computing、Vol。 2、No。2、2005。
[Landwehr81] Landwehr, C., "Formal Models for Computer Security", ACM Computing Surveys, Vol. 13, No. 3, Association for Computing Machinery, New York, NY, USA, September 1981.
[Landwehr81] Landwehr、C.、「コンピュータセキュリティの正式モデル」、ACM Computing Surveys、Vol。 13、No。3、Association for Computing Machinery、ニューヨーク、ニューヨーク、米国、1981年9月。
[MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring Interactions Between Transport Protocols and Middleboxes", Proc. 4th ACM SIGCOMM/USENIX Conference on Internet Measurement, October 2004.
[メディナ]メディナ、A。、オールマン、M。、およびS.フロイド、「トランスポートプロトコルとミドルボックス間の相互作用の測定」、Proc。インターネット測定に関する第4回ACM SIGCOMM / USENIX会議、2004年10月。
[Microsoft1999] Microsoft, "Microsoft Security Program: Microsoft Security Bulletin (MS99-038). Patch Available for "Spoofed Route Pointer" Vulnerability", September 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年9月、<http://www.microsoft.com/technet/security/bulletin/ ms99-038.mspx>。
[OpenBSD1998] OpenBSD, "OpenBSD Security Advisory: IP Source Routing Problem", February 1998, <http://www.openbsd.org/advisories/sourceroute.txt>.
[OpenBSD1998] OpenBSD、「OpenBSD Security Advisory：IP Source Routing Problem」、1998年2月、<http://www.openbsd.org/advisories/sourceroute.txt>。
[RFC1038] St. Johns, M., "Draft revised IP security option", RFC 1038, January 1988.
[RFC1038] St. Johns、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 discovery options」、RFC 1063、1988年7月。
[RFC1108] Kent, S., "U.S. Department of Defense Security Options for the Internet Protocol", RFC 1108, November 1991.
[RFC1108]ケントS.、「インターネットプロトコルのための米国国防総省のセキュリティオプション」、RFC 1108、1991年11月。
[RFC1385] Wang, Z., "EIP: The Extended Internet Protocol", RFC 1385, November 1992.
[RFC1385] Wang、Z。、「EIP：The Extended Internet Protocol」、RFC 1385、1992年11月。
[RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, January 1993.
[RFC1393] Malkin、G。、「IPオプションを使用したトレースルート」、RFC 1393、1993年1月。
[RFC1475] Ullmann, R., "TP/IX: The Next Internet", RFC 1475, June 1993.
[RFC1475] Ullmann、R。、「TP / IX：The Next Internet」、RFC 1475、1993年6月。
[RFC1770] Graff, C., "IPv4 Option for Sender Directed Multi-Destination Delivery", RFC 1770, March 1995.
[RFC1770] Graff、C。、「Sender Directed Multi-Destination DeliveryのIPv4オプション」、RFC 1770、1995年3月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、B.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification」、RFC 2205、1997年9月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。
[RFC3585] Jason, J., Rafalow, L., and E. Vyncke, "IPsec Configuration Policy Information Model", RFC 3585, August 2003.
[RFC3585] Jason、J.、Rafalow、L。、およびE. Vyncke、「IPsec構成ポリシー情報モデル」、RFC 3585、2003年8月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「インターネットキーエクスチェンジ（IKEv2）プロトコル」、RFC 4306、2005年12月。
[RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-Start for TCP and IP", RFC 4782, January 2007.
[RFC4782] Floyd、S.、Allman、M.、Jain、A。、およびP. Sarolahti、「Quick-Start for TCP and IP」、RFC 4782、2007年1月。
[RFC4807] Baer, M., Charlet, R., Hardaker, W., Story, R., and C. Wang, "IPsec Security Policy Database Configuration MIB", RFC 4807, March 2007.
[RFC4807] Baer、M.、Charlet、R.、Hardaker、W.、Story、R。、およびC. Wang、「IPsec Security Policy Database Configuration MIB」、RFC 4807、2007年3月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、RFC 4949、2007年8月。
[RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the IPv4 and IPv6 Router Alert Options", RFC 5350, September 2008.
[RFC5350] Manner、J。およびA.マクドナルド、「IPv4およびIPv6ルーターアラートオプションに関するIANAの考慮事項」、RFC 5350、2008年9月。
[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月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）」、RFC 5996、2010年9月。
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router Control Plane", RFC 6192, March 2011.
[RFC6192] Dugal、D.、Pignataro、C。、およびR. Dunn、「Protecting the Router Control Plane」、RFC 6192、2011年3月。
[RFC6274] Gont, F., "Security Assessment of the Internet Protocol Version 4", RFC 6274, July 2011.
[RFC6274] Gont、F。、「インターネットプロトコルバージョン4のセキュリティ評価」、RFC 6274、2011年7月。
[SELinux2008] National Security Agency (United States), "Security-Enhanced Linux - NSA/CSS", January 2009, <http://www.nsa.gov/research/selinux/index.shtml>.
[SELinux2008] National Security Agency（米国）、「Security-Enhanced Linux-NSA / CSS」、2009年1月、<http://www.nsa.gov/research/selinux/index.shtml>。
[Solaris2008] "Solaris Trusted Extensions: Labeled Security for Absolute Protection", 2008, <http://www.oracle.com/technetwork/server-storage/ solaris10/overview/trusted-extensions-149944.pdf>.
[Solaris2008]「Solaris Trusted Extensions：絶対保護のためのラベル付きセキュリティ」、2008、<http://www.oracle.com/technetwork/server-storage/ solaris10 / overview / trusted-extensions-149944.pdf>。
Authors' Addresses
著者のアドレス
Fernando Gont UTN-FRH / SI6 Networks Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
Fernando Gont UTN-FRH / SI6 Networks Evaristo Carriego 2644ブエノスアイレス州ハエド1706アルゼンチン
Phone: +54 11 4650 8472
EMail: fgont@si6networks.com
URI: http://www.si6networks.com
RJ Atkinson Consultant McLean, VA 22103 USA
RJアトキンソンコンサルタントマクリーン、バージニア州22103米国
EMail: rja.lists@gmail.com
Carlos Pignataro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 USA
Carlos Pignataro Cisco Systems、Inc. 7200-12 Kit Creek Road Research Triangle Park、NC 27709 USA
EMail: cpignata@cisco.com