[要約] RFC 8367は、誤った終了に関するIPパケットのガイドラインであり、パケットの誤った終了を防ぐことを目的としています。
Independent Submission T. Mizrahi
Request for Comments: 8367 Marvell
Category: Informational J. Yallouz
ISSN: 2070-1721 Intel
1 April 2018
Wrongful Termination of Internet Protocol (IP) Packets
インターネットプロトコル（IP）パケットの不正終了
Abstract
概要
Routers and middleboxes terminate packets for various reasons. In some cases, these packets are wrongfully terminated. This memo describes some of the most common scenarios of wrongful termination of Internet Protocol (IP) packets and presents recommendations for mitigating them.
ルーターとミドルボックスは、さまざまな理由でパケットを終端します。場合によっては、これらのパケットは誤って終了されます。このメモは、インターネットプロトコル（IP）パケットの不正な終了の最も一般的なシナリオのいくつかを説明し、それらを軽減するための推奨事項を示します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFC Editorは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8367.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8367で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ................................................... 2
2. Abbreviations .................................................. 2
3. Wrongful Termination Scenarios ................................. 3
3.1. Color-Based Termination ................................... 3
3.2. Age-Based Termination ..................................... 3
3.3. Origin-Based Termination .................................. 4
3.4. Length-Based Termination .................................. 4
3.5. IP-Version-Based Termination .............................. 5
3.6. Flag-Based Termination .................................... 5
4. Security Considerations ........................................ 5
5. IANA Considerations ............................................ 5
6. Conclusion ..................................................... 6
7. References ..................................................... 6
7.1. Normative References ...................................... 6
7.2. Informative References .................................... 6
Authors' Addresses ................................................ 6
IP packets are often terminated by network devices. In some cases, control-plane packets are terminated and processed by the local device, while in other cases packets are terminated (discarded) due to a packet filtering mechanism. Packet filtering is widely employed in network devices for sanity checking, policy enforcement, and security. IP routers and middleboxes, such as firewalls, often terminate packets that do not comply with a predefined policy. Unfortunately, some filtering policies cause false positive or unnecessary packet termination. Moreover, these wrongful terminations are sometimes biased and discriminate against packets based on their color, age, origin, length, or IP version.
多くの場合、IPパケットはネットワークデバイスによって終端されます。コントロールプレーンパケットはローカルデバイスによって終了および処理される場合もあれば、パケットフィルタリングメカニズムが原因でパケットが終了（廃棄）される場合もあります。パケットフィルタリングは、正常性チェック、ポリシーの適用、およびセキュリティのためにネットワークデバイスで広く採用されています。 IPルーターやファイアウォールなどのミドルボックスは、多くの場合、事前定義されたポリシーに準拠していないパケットを終端します。残念ながら、一部のフィルタリングポリシーでは、誤検出または不要なパケット終了が発生します。さらに、これらの不正な終端は時々バイアスがかけられ、色、年齢、起源、長さ、またはIPバージョンに基づいてパケットを区別します。
This memo discusses some of the most common scenarios of wrongful termination of IP packets and presents recommendations for preventing such discrimination.
このメモは、IPパケットの不正な終了の最も一般的なシナリオのいくつかについて説明し、そのような差別を防ぐための推奨事項を示します。
IP Internet Protocol
IPインターネットプロトコル
TTL Time To Live
TTL存続時間
OAM Operations, Administration, and Maintenance
OAMの運用、管理、保守
Synopsis
あらすじ
IP packets are terminated due to their color.
IPパケットは、その色のために終了します。
Description
説明文
Routers often employ metering mechanisms [RFC4115]. These mechanisms often support a color-aware mode, in which the packet's color (green, yellow, or red) is used as a criterion in the metering algorithm. This mode has been known to prefer green packets over red and yellow packets.
多くの場合、ルーターは計測メカニズムを採用しています[RFC4115]。これらのメカニズムは、多くの場合、カラー認識モードをサポートしています。このモードでは、パケットの色（緑、黄色、または赤）が測定アルゴリズムの基準として使用されます。このモードは、赤と黄色のパケットよりも緑のパケットを優先することが知られています。
Recommendation
勧告
Use of color-blind metering is recommended, as it allows equal opportunity for packets of different colors.
異なる色のパケットの機会を均等にすることができるので、カラーブラインドメーターの使用をお勧めします。
Synopsis
あらすじ
IP packets are terminated based on their TTL.
IPパケットは、TTLに基づいて終了します。
Description
説明文
The IPv4 TTL field [RFC791] and the IPv6 Hop Limit field [RFC8200] are used for loop prevention. These fields essentially represent the packet's age. A router that receives an IP packet with a TTL value of 0 or 1 typically terminates the packet. In this document, packets with a TTL or Hop Limit of 0 or 1 are referred to as 'senior packets'.
IPv4 TTLフィールド[RFC791]およびIPv6ホップリミットフィールド[RFC8200]は、ループ防止に使用されます。これらのフィールドは、基本的にパケットの経過時間を表します。 TTL値が0または1のIPパケットを受信するルーターは、通常、パケットを終了します。このドキュメントでは、TTLまたはホップ制限が0または1のパケットを「シニアパケット」と呼びます。
Recommendation
勧告
When possible, the practice of reverse discrimination is recommended. Notably, senior packets have been known to be highly effective for OAM tasks, such as Hello [RFC2328] and Traceroute [RFC2151]. Therefore, senior packets should not be easily dismissed; to the extent possible, senior packets should be used in control-plane protocols.
可能であれば、逆差別の実践が推奨されます。特に、シニアパケットは、Hello [RFC2328]やTraceroute [RFC2151]などのOAMタスクに非常に効果的であることが知られています。したがって、上級パケットは簡単に却下されるべきではありません。可能な限り、シニアパケットはコントロールプレーンプロトコルで使用する必要があります。
Synopsis
あらすじ
IP packets are terminated based on their origin (source IP address prefix).
IPパケットは、発信元（送信元IPアドレスプレフィックス）に基づいて終了します。
Description
説明文
Routers and middleboxes often perform IP address filtering. Packets are often discarded based on the prefix of their source IP address. In this memo, prefix-based source address filtering is referred to as origin-based filtering. While source IP address filtering is an acceptable technique for preventing security attacks performed by known attackers, filtering an entire prefix may lead to unnecessary termination of legitimate traffic.
ルーターとミドルボックスは、しばしばIPアドレスフィルタリングを実行します。パケットは、送信元IPアドレスのプレフィックスに基づいて破棄されることがよくあります。このメモでは、プレフィックスベースの送信元アドレスフィルタリングは、発信元ベースのフィルタリングと呼ばれています。送信元IPアドレスフィルタリングは、既知の攻撃者によるセキュリティ攻撃を防ぐための許容可能な手法ですが、プレフィックス全体をフィルタリングすると、正当なトラフィックが不必要に終了する可能性があります。
Recommendation
勧告
Origin-based filtering should be limited, to the extent possible, so as not to punish an entire autonomous system for the crime of a single host. Individual address-based filtering should be preferred in cases where the address of the potential threat is well known.
単一ホストの犯罪に対して自律システム全体を罰しないように、発信元ベースのフィルタリングは可能な限り制限する必要があります。潜在的な脅威のアドレスがよく知られている場合は、個別のアドレスベースのフィルタリングをお勧めします。
Synopsis
あらすじ
Short IP packets are wrongfully terminated due to their length.
短いIPパケットは、長さが原因で誤って終端されます。
Description
説明文
The minimum permissible size of an IPv4 [RFC791] packet is 20 octets, and the minimum size of an IPv6 [RFC8200] packet is 40 octets. However, due to the size limits of Ethernet, it is often the case that IP packets that are shorter than 46 octets are discarded. This is because the minimal Ethernet frame size is 64 octets, the minimal Ethernet header size is 14 octets, and the Ethernet Frame Check Sequence is 4 octets long (i.e., 64 - 14 - 4 = 46). In the context of this memo, legitimate IP packets that are less than 46 octets long are referred to as 'short IP packets'.
IPv4 [RFC791]パケットの最小許容サイズは20オクテットであり、IPv6 [RFC8200]パケットの最小サイズは40オクテットです。ただし、イーサネットのサイズ制限により、46オクテットより短いIPパケットが破棄されることがよくあります。これは、最小イーサネットフレームサイズが64オクテット、最小イーサネットヘッダーサイズが14オクテット、およびイーサネットフレームチェックシーケンスが4オクテット（つまり、64-14-4 = 46）であるためです。このメモのコンテキストでは、46オクテット未満の正当なIPパケットは「短いIPパケット」と呼ばれます。
Recommendation
勧告
Short IP packets should not be discarded. The Ethernet frame length should be enforced at the Ethernet layer, while the IP layer should avoid discrimination of short IP packets.
短いIPパケットは破棄しないでください。イーサネットフレーム長はイーサネットレイヤーで適用する必要がありますが、IPレイヤーは短いIPパケットの識別を回避する必要があります。
Synopsis
あらすじ
IPv6 packets are terminated due to their version.
IPv6パケットは、バージョンが原因で終了します。
Description
説明文
Many routers and middleboxes are configured to process only IPv4 [RFC791] packets and to reject IPv6 [RFC8200] packets.
多くのルーターとミドルボックスは、IPv4 [RFC791]パケットのみを処理し、IPv6 [RFC8200]パケットを拒否するように構成されています。
Recommendation
勧告
It is quite unsettling that there are still networks in which IPv6 packets are deemed unwanted in the second decade of the 21st century. Indeed, IPv6 packets have a slightly shorter payload than IPv4 packets. However, they are essential to the future growth of the Internet. It is time for operators to finally give IPv6 its well-deserved opportunity.
21世紀の20年間でIPv6パケットが望ましくないと見なされるネットワークがまだ存在することは非常に不安です。実際、IPv6パケットのペイロードはIPv4パケットよりもわずかに短いです。ただし、インターネットの将来の成長には不可欠です。オペレーターがついにIPv6にふさわしい機会を与える時が来ました。
Synopsis
あらすじ
IPv4 packets are terminated because their More Fragments (MF) flag is set.
More Fragments（MF）フラグが設定されているため、IPv4パケットは終了します。
Description
説明文
Many routers and middleboxes are configured to discard fragmented packets.
多くのルーターとミドルボックスは、断片化されたパケットを破棄するように構成されています。
Recommendation
勧告
A packet should not be discarded on the grounds of a flag it supports. All flags should be respected, as well as the features they represent.
パケットは、それがサポートするフラグに基づいて破棄されるべきではありません。すべてのフラグと、それらが表す機能を尊重する必要があります。
This memo proposes to practice liberality with respect to IP packet filtering in routers and middleboxes. Arguably, such a liberal approach may compromise security in some cases. Not only must security be done; it must also be seen to be done.
このメモは、ルーターとミドルボックスでのIPパケットフィルタリングに関して自由を実践することを提案しています。おそらく、そのような自由主義的なアプローチは、場合によってはセキュリティを危険にさらす可能性があります。セキュリティを行う必要があるだけでなく、それはまた行われるために見られる必要があります。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
This memo recommends that every router and middlebox be an Equal Opportunity Device, which does not discriminate on the basis of actual or perceived rate, color, age, origin, length, IP version, fragmentation characteristics, higher-layer protocols, or any other IP characteristic.
このメモは、すべてのルーターとミドルボックスが機会均等デバイスであることを推奨しています。これは、実際のまたは認識されたレート、色、年齢、起点、長さ、IPバージョン、フラグメンテーション特性、上位層プロトコル、またはその他のIPに基づいて区別しません。特性。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487 / RFC0791、1981年9月、<https://www.rfc-editor.org/info/rfc791>。
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https://www.rfc-editor.org / info / rfc8200>。
[RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/IP Tools and Utilities", FYI 30, RFC 2151, DOI 10.17487/RFC2151, June 1997, <https://www.rfc-editor.org/info/rfc2151>.
[RFC2151]ケスラー、G.、S。シェパード、「インターネットおよびTCP / IPツールとユーティリティの入門書」、FYI 30、RFC 2151、DOI 10.17487 / RFC2151、1997年6月、<https：//www.rfc-editor .org / info / rfc2151>。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、DOI 10.17487 / RFC2328、1998年4月、<https://www.rfc-editor.org/info/rfc2328>。
[RFC4115] Aboul-Magd, O. and S. Rabie, "A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic", RFC 4115, DOI 10.17487/RFC4115, July 2005, <https://www.rfc-editor.org/info/rfc4115>.
[RFC4115] Aboul-Magd、O。およびS. Rabie、「差別化されたサービス2レート、3色マーカー、プロファイル内トラフィックの効率的な処理」、RFC 4115、DOI 10.17487 / RFC4115、2005年7月、<https： //www.rfc-editor.org/info/rfc4115>。
Authors' Addresses
著者のアドレス
Tal Mizrahi Marvell Email: talmi@marvell.com
Tal Mizrahi Marvellメール：talmi@marvell.com
Jose Yallouz Intel Email: jose@alumni.technion.ac.il
Jose Yallouz Intelメール：jose@alumni.technion.ac.il