[要約] 要約：RFC 8517は、ミドルボックスが提供するトランスポート中心の機能のインベントリを提供し、オペレータの視点から説明しています。目的：このRFCの目的は、ミドルボックスの機能を理解し、ネットワークオペレータが効果的に管理できるようにすることです。
Independent Submission D. Dolson, Ed.
Request for Comments: 8517
Category: Informational J. Snellman
ISSN: 2070-1721
M. Boucadair, Ed.
C. Jacquenet
Orange
February 2019
An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator Perspective
Middleboxesによって提供されるトランスポートセントリック機能のインベントリ：オペレーターの視点
Abstract
概要
This document summarizes an operator's perception of the benefits that may be provided by intermediary devices that execute functions beyond normal IP forwarding. Such intermediary devices are often called "middleboxes".
このドキュメントは、通常のIP転送を超える機能を実行する中間デバイスによって提供される可能性がある利点についてのオペレーターの認識を要約しています。このような中間デバイスは、しばしば「ミドルボックス」と呼ばれます。
RFC 3234 defines a taxonomy of middleboxes and issues in the Internet. Most of those middleboxes utilize or modify application-layer data. This document primarily focuses on devices that observe and act on information carried in the transport layer, and especially information carried in TCP packets.
RFC 3234は、ミドルボックスとインターネットの問題の分類法を定義しています。それらのミドルボックスのほとんどは、アプリケーション層のデータを利用または変更します。このドキュメントでは主に、トランスポート層で運ばれる情報、特にTCPパケットで運ばれる情報を観察して操作するデバイスに焦点を当てています。
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エディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 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/rfc8517.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8517で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Operator Perspective . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Measurements . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Round-Trip Times . . . . . . . . . . . . . . . . . . . . 6
2.3. Measuring Packet Reordering . . . . . . . . . . . . . . . 6
2.4. Throughput and Bottleneck Identification . . . . . . . . 7
2.5. Congestion Responsiveness . . . . . . . . . . . . . . . . 7
2.6. Attack Detection . . . . . . . . . . . . . . . . . . . . 8
2.7. Packet Corruption . . . . . . . . . . . . . . . . . . . . 8
2.8. Application-Layer Measurements . . . . . . . . . . . . . 9
3. Functions beyond Measurement: A Few Examples . . . . . . . . 9
3.1. NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Firewall . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. DDoS Scrubbing . . . . . . . . . . . . . . . . . . . . . 10
3.4. Implicit Identification . . . . . . . . . . . . . . . . . 11
3.5. Performance-Enhancing Proxies . . . . . . . . . . . . . . 11
3.6. Network Coding . . . . . . . . . . . . . . . . . . . . . 12
3.7. Network-Assisted Bandwidth Aggregation . . . . . . . . . 13
3.8. Prioritization and Differentiated Services . . . . . . . 13
3.9. Measurement-Based Shaping . . . . . . . . . . . . . . . . 14
3.10. Fairness to End-User Quota . . . . . . . . . . . . . . . 14
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5.1. Confidentiality and Privacy . . . . . . . . . . . . . . . 14
5.2. Active On-Path Attacks . . . . . . . . . . . . . . . . . 15
5.3. Improved Security . . . . . . . . . . . . . . . . . . . . 15
6. Informative References . . . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
From [RFC3234], "A middlebox is defined as any intermediary device performing functions other than the normal, standard functions of an IP router on the datagram path between a source host and destination host."
[RFC3234]から、「ミドルボックスは、送信元ホストと宛先ホスト間のデータグラムパス上のIPルーターの通常の標準機能以外の機能を実行する中間デバイスとして定義されます。」
Middleboxes are usually (but not exclusively) deployed at locations permitting observation of bidirectional traffic flows. Such locations are typically points where leaf networks connect to the Internet, for example:
ミドルボックスは、通常（ただし、これに限定されません）、双方向のトラフィックフローを監視できる場所に配置されます。このような場所は、通常、リーフネットワークがインターネットに接続するポイントです。次に例を示します。
o Where a residential or business customer connects to its service provider(s), which may include multihoming;
o 住宅またはビジネスの顧客がサービスプロバイダーに接続する場合（マルチホーミングを含む場合があります）。
o On the Gi interface where a Gateway General Packet Radio Service (GPRS) Support Node (GGSN) connects to a Packet Data Network (PDN) (Section 3.1 of [RFC6459]).
o ゲートウェイ一般パケット無線サービス（GPRS）サポートノード（GGSN）がパケットデータネットワーク（PDN）に接続するGiインターフェース（[RFC6459]のセクション3.1）。
For the purposes of this document (and to be consistent with the definition in RFC 3234), middlebox functions may be found in routers and switches in addition to dedicated devices.
このドキュメントの目的のため（およびRFC 3234の定義と一致させるため）、ミドルボックス機能は、専用デバイスに加えてルーターおよびスイッチにも見られる場合があります。
This document itemizes a variety of features provided by middleboxes and by ad hoc analysis performed by operators using packet analyzers.
このドキュメントでは、ミドルボックスと、パケットアナライザーを使用するオペレーターが実行するアドホック分析によって提供されるさまざまな機能について説明します。
Many of the techniques described in this document require stateful analysis of transport streams. A generic state machine is described in [PATH-STATE].
このドキュメントで説明するテクニックの多くは、トランスポートストリームのステートフル分析を必要とします。一般的な状態機械は[PATH-STATE]で説明されています。
This document summarizes an operator's perception of the benefits that may be provided by middleboxes. A primary goal is to provide information to the Internet community to aid understanding of what might be gained or lost by decisions that may affect (or be affected by) middlebox operation in the design of new transport protocols. See Section 1.1 for more details.
このドキュメントは、ミドルボックスによって提供される可能性のある利点についてのオペレーターの認識を要約しています。主な目的は、インターネットコミュニティに情報を提供して、新しいトランスポートプロトコルの設計におけるミドルボックス操作に影響を与える（または影響を受ける）決定によって何が得られるか、または失われるかを理解するのに役立ちます。詳細については、セクション1.1を参照してください。
Network operators are often the ones first called upon when applications fail to function properly, often with user reports about application behaviors (not about packet behaviors). Therefore, it isn't surprising that operators (wanting to be helpful) desire some visibility into flow information to identify how well the problem flows are progressing and how well other flows are progressing.
多くの場合、ネットワークオペレーターは、アプリケーションが適切に機能しない場合に最初に呼び出されます。多くの場合、ユーザーの報告には、アプリケーションの動作（パケットの動作ではない）が含まれます。したがって、オペレーター（役立つことを望んでいる）がフロー情報をある程度可視化して、問題のフローがどれだけうまく進んでいるか、他のフローがどれだけうまく進んでいるかを確認することを望んでも当然です。
Advanced service functions (e.g., Network Address Translators (NATs), firewalls, etc.) [RFC7498] are widely used to achieve various objectives such as IP address sharing, firewalling, avoiding covert channels, detecting and protecting against ever-increasing Distributed Denial of Service (DDoS) attacks, etc. For example, environment-specific designs may require a number of service functions, such as those needed at the Gi interface of a mobile infrastructure [USE-CASE].
高度なサービス機能（ネットワークアドレストランスレータ（NAT）、ファイアウォールなど）[RFC7498]は、IPアドレスの共有、ファイアウォール、隠れチャネルの回避、増え続ける分散拒否の検出と保護などのさまざまな目的を達成するために広く使用されていますサービス（DDoS）攻撃など。たとえば、環境固有の設計では、モバイルインフラストラクチャのGiインターフェースで必要なサービス機能など、いくつかのサービス機能が必要になる場合があります[USE-CASE]。
These sophisticated service functions are located in the network but also in service platforms or intermediate entities (e.g., Content Delivery Networks (CDNs)). Network maintenance and diagnostic operations are complicated, particularly when responsibility is shared among various players.
これらの高度なサービス機能は、ネットワーク内にありますが、サービスプラットフォームまたは中間エンティティ（コンテンツ配信ネットワーク（CDN）など）にもあります。特にさまざまなプレイヤー間で責任が共有される場合、ネットワークの保守と診断操作は複雑になります。
Network Providers are challenged to deliver differentiated services as a competitive business advantage while mastering the complexity of the applications, (continuously) evaluating the impacts on middleboxes, and enhancing customers' quality of experience.
ネットワークプロバイダーは、アプリケーションの複雑さをマスターし、（継続的に）ミドルボックスへの影響を評価し、顧客のエクスペリエンス品質を向上させながら、差別化されたサービスを競争力のあるビジネスアドバンテージとして提供することを求められています。
Despite the complexity, removing all those service functions is not an option because they are used to address constraints that are often typical of the current (and changing) Internet. Operators must deal with constraints such as global IPv4 address depletion and support a plethora of services with different requirements for QoS, security, robustness, etc.
複雑にもかかわらず、これらのサービス機能をすべて削除することは、現在の（そして変化する）インターネットによくある制約に対処するために使用されるため、オプションではありません。オペレーターは、グローバルIPv4アドレスの枯渇などの制約に対処し、QoS、セキュリティ、堅牢性などの要件が異なる多数のサービスをサポートする必要があります。
Although many middleboxes observe and manipulate application-layer content (e.g., session boarder controllers [RFC5853]), they are out of scope for this document, the aim being to describe middleboxes using transport-layer features. [RFC8404] describes the impact of pervasive encryption of application-layer data on network monitoring, protecting, and troubleshooting.
多くのミドルボックスは、アプリケーション層のコンテンツ（セッションボーダーコントローラー[RFC5853]など）を監視および操作しますが、このドキュメントの範囲外です。トランスポート層機能を使用してミドルボックスを説明することを目的としています。 [RFC8404]は、アプリケーション層データの広範な暗号化がネットワークの監視、保護、トラブルシューティングに及ぼす影響について説明しています。
The current document is not intended to recommend (or prohibit) middlebox deployment. Many operators have found the value provided by middleboxes to outweigh the added cost and complexity; this document attempts to provide that perspective as a reference in discussion of protocol design trade-offs.
現在のドキュメントは、ミドルボックスの展開を推奨（または禁止）することを目的としていません。多くのオペレーターは、追加のコストと複雑さを上回るためにミドルボックスによって提供される価値を見つけました。このドキュメントは、プロトコル設計のトレードオフの議論における参照としてその見方を提供することを試みます。
This document is not intended to discuss issues related to middleboxes. These issues are well known and are recorded in existing documents such as [RFC3234] and [RFC6269]. This document aims to elaborate on the motivations leading operators to enable such functions in spite of complications.
このドキュメントは、ミドルボックスに関連する問題について説明することを意図したものではありません。これらの問題はよく知られており、[RFC3234]や[RFC6269]などの既存のドキュメントに記録されています。このドキュメントは、複雑な状況にもかかわらず、オペレーターがそのような機能を有効にするための動機を詳しく説明することを目的としています。
This document takes an operator perspective that measurement and management of transport connections is of benefit to both parties: the end user receives a better quality of experience, and the network operator improves resource usage, the former being a consequence of the latter.
このドキュメントでは、トランスポート接続の測定と管理は双方にとってメリットがあるというオペレーターの視点を取り入れています。エンドユーザーはより優れたエクスペリエンスを体験でき、ネットワークオペレーターはリソースの使用を改善します。前者は後者の結果です。
This document does not discuss whether exposing some data to on-path devices for network-assistance purposes can be achieved by using in-band or out-of-band mechanisms.
このドキュメントでは、インバンドまたはアウトオブバンドのメカニズムを使用して、ネットワーク支援目的で一部のデータをパス上のデバイスに公開できるかどうかについては説明していません。
A number of measurements can be made by network devices that are either on-path or off-path. These measurements can be used either by automated systems or for manual network troubleshooting purposes (e.g., using packet-analysis tools). The automated systems can further be classified into two types: 1) monitoring systems that compute performance indicators for single connections or aggregates of connections and generate aggregated reports from them; and 2) active systems that make decisions also on how to handle packet flows based on these performance indicators.
オンパスまたはオフパスのネットワークデバイスによって、多くの測定を行うことができます。これらの測定は、自動システムまたは手動のネットワークトラブルシューティングの目的で使用できます（たとえば、パケット分析ツールを使用）。自動化システムはさらに2つのタイプに分類できます。1）単一接続または接続の集約のパフォーマンスインジケータを計算し、それらから集約レポートを生成する監視システム。および2）これらのパフォーマンスインジケータに基づいてパケットフローの処理方法についても決定するアクティブなシステム。
Long-term trends in these measurements can aid an operator in capacity planning.
これらの測定の長期的な傾向は、オペレーターが容量計画を立てるのに役立ちます。
Short-term anomalies revealed by these measurements can identify network breakages, attacks in progress, or misbehaving devices/ applications.
これらの測定によって明らかになった短期的な異常は、ネットワークの破損、進行中の攻撃、またはデバイス/アプリケーションの誤動作を識別することができます。
It is very useful for an operator to be able to detect and isolate packet loss in a network.
オペレーターがネットワーク内のパケット損失を検出して分離できることは非常に便利です。
Network problems and underprovisioning can be detected if packet loss is measurable. TCP packet loss can be detected by observing gaps in sequence numbers, retransmitted sequence numbers, and selective acknowledgement (SACK) options [RFC2018]. Packet loss can be detected per direction.
パケット損失が測定可能な場合、ネットワークの問題とプロビジョニング不足が検出されます。 TCPパケット損失は、シーケンス番号のギャップ、再送信されたシーケンス番号、および選択的確認応答（SACK）オプション[RFC2018]を監視することで検出できます。パケット損失は方向ごとに検出できます。
Gaps indicate loss upstream of the traffic observation point; retransmissions indicate loss downstream of the traffic observation point. SACKs can be used to detect either upstream or downstream packet loss (although some care needs to be taken to avoid misidentifying packet reordering as packet loss) and to distinguish between upstream versus downstream losses.
ギャップは、交通観測点の上流の損失を示します。再送信は、トラフィック監視ポイントの下流での損失を示します。 SACKを使用して、アップストリームまたはダウンストリームのパケット損失を検出し（パケットの再配列をパケット損失と誤認しないように注意する必要があります）、アップストリームとダウンストリームの損失を区別します。
Packet-loss measurements on both sides of the measurement point are an important component in precisely diagnosing insufficiently dimensioned devices or links in networks. Additionally, packet losses are one of the two main ways for congestion to manifest, the others being queuing delay or Explicit Congestion Notification (ECN) [RFC3168]; therefore, packet loss is an important measurement for any middlebox that needs to make traffic handling decisions based on observed levels of congestion.
測定ポイントの両側でのパケット損失測定は、ネットワーク内の不十分な寸法のデバイスまたはリンクを正確に診断する上で重要なコンポーネントです。さらに、パケット損失は、輻輳が発生する2つの主要な方法の1つであり、その他はキューイング遅延または明示的輻輳通知（ECN）[RFC3168]です。したがって、パケット損失は、観測された輻輳レベルに基づいてトラフィック処理を決定する必要があるミドルボックスの重要な測定値です。
The ability to measure partial-path round-trip times (RTTs) is valuable in diagnosing network issues (e.g., abnormal latency, abnormal packet loss). Knowing if latency is poor on one side of the observation point or the other provides more information than is available at either endpoint, which can only observe full RTTs.
部分パスラウンドトリップ時間（RTT）を測定する機能は、ネットワークの問題（異常な遅延、異常なパケット損失など）の診断に役立ちます。観測ポイントの一方または他方でレイテンシが悪いかどうかを知ることで、完全なRTTしか観測できない、どちらのエンドポイントで利用できるよりも多くの情報が提供されます。
For example, a TCP packet stream can be used to measure the RTT on each side of the measurement point. During the connection handshake, the SYN, SYN/ACK, and ACK timings can be used to establish a baseline RTT in each direction. Once the connection is established, the RTT between the server and the measurement point can only reliably be determined using TCP timestamps [RFC7323]. On the side between the measurement point and the client, the exact timing of data segments and ACKs can be used as an alternative. For this latter method to be accurate when packet loss is present, the connection must use selective acknowledgements.
たとえば、TCPパケットストリームを使用して、測定ポイントの両側でRTTを測定できます。接続ハンドシェイク中に、SYN、SYN / ACK、およびACKタイミングを使用して、各方向のベースラインRTTを確立できます。接続が確立されると、サーバーと測定ポイント間のRTTは、TCPタイムスタンプを使用してのみ確実に決定できます[RFC7323]。測定ポイントとクライアントの間の側では、データセグメントとACKの正確なタイミングを代替として使用できます。この後者の方法がパケット損失が存在するときに正確であるためには、接続は選択的な確認応答を使用する必要があります。
In many networks, congestion will show up as increasing packet queuing, and congestion-induced packet loss will only happen in extreme cases. RTTs will also show up as a much smoother signal than the discrete packet-loss events. This makes RTTs a good way to identify individual subscribers for whom the network is a bottleneck at a given time or geographical sites (such as cellular towers) that are experiencing large-scale congestion.
多くのネットワークでは、輻輳はパケットキューイングの増加として現れ、輻輳によって引き起こされるパケット損失は極端な場合にのみ発生します。 RTTは、個別のパケット損失イベントよりもはるかにスムーズな信号としても表示されます。これにより、RTTは、特定の時間にネットワークがボトルネックになっている個々のサブスクライバー、または大規模な輻輳が発生している地理的なサイト（セルラータワーなど）を識別するための優れた方法になります。
The main limit of RTT measurement as a congestion signal is the difficulty of reliably distinguishing between the data segments being queued versus the ACKs being queued.
輻輳信号としてのRTT測定の主な制限は、キューに入れられているデータセグメントとキューに入れられているACKを確実に区別することが難しいことです。
If a network is reordering packets of transport connections, caused perhaps by Equal-Cost Multipath (ECMP) misconfiguration (described in [RFC2991] and [RFC7690], for example), the endpoints may react as if packet loss is occurring and retransmit packets or reduce forwarding rates. Therefore, a network operator desires the ability to diagnose packet reordering.
ネットワークがトランスポート接続のパケットを並べ替えている場合は、（[RFC2991]や[RFC7690]で説明されているように）等コストマルチパス（ECMP）の誤設定が原因である可能性があります。転送速度を下げます。したがって、ネットワークオペレータは、パケットの並べ替えを診断する機能を望んでいます。
For TCP, packet reordering can be detected by observing TCP sequence numbers per direction. See, for example, a number of standard packet-reordering metrics in [RFC4737] and informational metrics in [RFC5236].
TCPの場合、パケットの並べ替えは、方向ごとのTCPシーケンス番号を監視することで検出できます。たとえば、[RFC4737]の多数の標準パケット並べ替えメトリックと[RFC5236]の情報メトリックを参照してください。
Although throughput to or from an IP address can be measured without transport-layer measurements, the transport layer provides clues about what the endpoints were attempting to do.
IPアドレスとの間のスループットは、トランスポート層の測定なしで測定できますが、トランスポート層は、エンドポイントが実行しようとしていたことについての手がかりを提供します。
One way of quickly excluding the network as the bottleneck during troubleshooting is to check whether the speed is limited by the endpoints. For example, the connection speed might instead be limited by suboptimal TCP options, the sender's congestion window, the sender temporarily running out of data to send, the sender waiting for the receiver to send another request, or the receiver closing the receive window.
トラブルシューティング中にボトルネックとしてネットワークをすばやく除外する1つの方法は、速度がエンドポイントによって制限されているかどうかを確認することです。たとえば、接続速度は、次善のTCPオプション、送信者の輻輳ウィンドウ、送信するデータが一時的に不足している送信者、受信者が別の要求を送信するのを待っている送信者、または受信者が受信ウィンドウを閉じることによって制限される場合があります。
This data is also useful for middleboxes used to measure network quality of service. Connections, or portions of connections, that are limited by the endpoints do not provide an accurate measure of the network's speed and can be discounted or completely excluded in such analyses.
このデータは、ネットワークのサービス品質を測定するために使用されるミドルボックスにも役立ちます。エンドポイントによって制限されている接続または接続の一部は、ネットワークの速度の正確な測定値を提供せず、そのような分析では割引または完全に除外できます。
Congestion control mechanisms continue to evolve. Tools exist that can interpret protocol sequence numbers (e.g., from TCP or RTP) to infer the congestion response of a flow. Such tools can be used by operators to help understand the impact of specific transport protocols on other traffic that shares their network. For example, packet sequence numbers can be analyzed to help understand whether an application flow backs off its load in the face of persistent congestion (as TCP does) and, hence, whether the behavior is appropriate for sharing limited network capacity.
輻輳制御メカニズムは進化し続けています。プロトコルシーケンス番号（TCPやRTPなど）を解釈してフローの輻輳応答を推測できるツールが存在します。オペレーターはこのようなツールを使用して、ネットワークを共有する他のトラフィックに対する特定のトランスポートプロトコルの影響を理解することができます。たとえば、パケットシーケンス番号を分析して、アプリケーションフローが（TCPのように）永続的な輻輳に直面してその負荷をバックオフするかどうか、したがって、動作が限られたネットワーク容量の共有に適切かどうかを理解するのに役立ちます。
These tools can also be used to determine whether mechanisms are needed in the network to prevent flows from acquiring excessive network capacity under severe congestion (e.g., by deploying rate limiters or network transport circuit breakers [RFC8084]).
これらのツールを使用して、深刻な輻輳下でフローが過剰なネットワーク容量を取得するのを防ぐために、ネットワークでメカニズムが必要かどうかを判断することもできます（たとえば、レートリミッターまたはネットワークトランスポート回路ブレーカー[RFC8084]を展開することにより）。
When an application or network resource is under attack, it is useful to identify this situation from the network perspective, upstream of the attacked resource.
アプリケーションまたはネットワークリソースが攻撃を受けている場合、攻撃されたリソースの上流にあるネットワークの観点からこの状況を特定すると役立ちます。
Although detection methods tend to be proprietary, attack detection from within the network may comprise:
検出方法は独自仕様である傾向がありますが、ネットワーク内からの攻撃検出には次のものが含まれます。
o Identifying uncharacteristic traffic volumes or sources;
o 特徴のないトラフィック量またはソースを特定する。
o Identifying congestion, possibly using techniques in Sections 2.1 and 2.2;
o おそらくセクション2.1および2.2の手法を使用して、輻輳を特定します。
o Identifying incomplete connections or transactions, from attacks that attempt to exhaust server resources;
o サーバーリソースを使い果たしようとする攻撃から、不完全な接続またはトランザクションを特定する。
o Fingerprinting based on whatever available fields are determined to be useful in discriminating an attack from desirable traffic.
o 利用可能なフィールドに基づくフィンガープリントは、攻撃を望ましいトラフィックから区別するのに役立つと判断されます。
Two trends in protocol design will make attack detection more difficult:
プロトコル設計の2つの傾向により、攻撃の検出がより困難になります。
o The desire to encrypt transport-layer fields;
o トランスポート層フィールドを暗号化したい;
o The desire to avoid statistical fingerprinting by adding entropy in various forms.
o さまざまな形でエントロピーを追加することにより、統計的フィンガープリントを回避したいという願望。
While improving privacy, those approaches may hinder attack detection.
プライバシーを改善する一方で、これらのアプローチは攻撃の検出を妨げる可能性があります。
One notable source of packet loss is packet corruption. This corruption will generally not be detected until the checksums are validated by the endpoint and the packet is dropped. This means that detecting the exact location where packets are lost is not sufficient when troubleshooting networks. An operator would like to find out where packets are being corrupted. IP and TCP checksum verification allows a measurement device to correctly distinguish between upstream packet corruption and normal downstream packet loss.
パケット損失の主な原因の1つは、パケットの破損です。この破損は通常、チェックサムがエンドポイントによって検証され、パケットがドロップされるまで検出されません。つまり、ネットワークのトラブルシューティングを行う場合、パケットが失われた正確な場所を検出するだけでは不十分です。オペレーターは、パケットが破損している場所を見つけたいと考えています。 IPおよびTCPチェックサム検証により、測定デバイスは、アップストリームパケットの破損と通常のダウンストリームパケット損失を正しく区別できます。
Transport protocol designers should consider whether a middlebox will be able to detect corrupted or tampered packets.
トランスポートプロトコルの設計者は、ミドルボックスが破損または改ざんされたパケットを検出できるかどうかを検討する必要があります。
Information about network health may also be gleaned from application-layer diagnosis, such as:
ネットワークの状態に関する情報は、次のようなアプリケーション層の診断から収集することもできます。
o DNS response times and retransmissions calculated by correlating answers to queries;
o クエリへの回答を相互に関連付けることによって計算されたDNS応答時間と再送信。
o Various protocol-aware voice and video quality analyses.
o さまざまなプロトコル対応の音声およびビデオ品質分析。
Could this type of information be provided in a transport layer?
この種の情報はトランスポート層で提供できますか？
This section describes features provided by on-path devices that go beyond measurement by modifying, discarding, delaying, or prioritizing traffic.
このセクションでは、トラフィックの変更、破棄、遅延、または優先順位付けによって測定を超える、オンパスデバイスによって提供される機能について説明します。
Network Address Translators (NATs) allow multiple devices to share a public address by dividing the transport-layer port space among the devices.
ネットワークアドレストランスレータ（NAT）を使用すると、トランスポート層のポートスペースをデバイス間で分割することにより、複数のデバイスでパブリックアドレスを共有できます。
NAT behavior recommendations are found for UDP in BCP 127 [RFC4787] and for TCP in BCP 142 [RFC7857].
NATの動作に関する推奨事項は、BCP 127のUDP [RFC4787]とBCP 142のTCP [RFC7857]にあります。
To support NAT, there must be transport-layer port numbers that can be modified by the NAT. Note that required fields (e.g., port numbers) are visible in all IETF-defined transport protocols.
NATをサポートするには、NATによって変更できるトランスポート層ポート番号が必要です。必須フィールド（ポート番号など）は、IETFで定義されたすべてのトランスポートプロトコルで表示されます。
The application layer must not assume the port number was left unchanged (e.g., by including it in a checksum or signing it).
アプリケーション層は、ポート番号が変更されていないことを前提としてはなりません（たとえば、チェックサムに含めるか、署名することにより）。
Address sharing is also used in the context of IPv6 transition. For example, DS-Lite Address Family Transition Router (AFTR) [RFC6333], NAT64 [RFC6146], or A+P [RFC7596][RFC7597] are features that are enabled in the network to allow for IPv4 service continuity over an IPv6 network.
アドレス共有は、IPv6移行のコンテキストでも使用されます。たとえば、DS-Liteアドレスファミリトランジションルーター（AFTR）[RFC6333]、NAT64 [RFC6146]、またはA + P [RFC7596] [RFC7597]は、IPv6ネットワーク上でIPv4サービスの継続性を可能にするネットワークで有効化されている機能です。 。
Further, because of some multihoming considerations, IPv6 prefix translation may be enabled by some enterprises by means of IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296].
さらに、一部のマルチホーミングの考慮事項のため、IPv6プレフィックス変換は、IPv6からIPv6へのネットワークプレフィックス変換（NPTv6）[RFC6296]を使用して、一部の企業によって有効にされる場合があります。
Firewalls are pervasive and essential components that inspect incoming and outgoing traffic. Firewalls are usually the cornerstone of a security policy that is enforced in end-user premises and other locations to provide strict guarantees about traffic that may be authorized to enter/leave the said premises, as well as end users who may be assigned different clearance levels regarding which networks and portions of the Internet they access.
ファイアウォールは、着信トラフィックと発信トラフィックを検査する広範囲にわたる不可欠なコンポーネントです。ファイアウォールは通常、エンドユーザーの敷地やその他の場所に適用されるセキュリティポリシーの土台であり、その敷地への出入りを許可されている可能性のあるトラフィックや、異なるクリアランスレベルが割り当てられている可能性のあるエンドユーザーに関する厳密な保証を提供します彼らがアクセスするインターネットとインターネットの一部に関して。
An important aspect of a firewall policy is differentiating internally initiated from externally initiated communications.
ファイアウォールポリシーの重要な側面は、内部で開始された通信と外部で開始された通信を区別することです。
For TCP, this is easily done by tracking the TCP state machine. Furthermore, the ending of a TCP connection is indicated by RST or FIN flags.
TCPの場合、これはTCPステートマシンを追跡することで簡単に実行できます。さらに、TCP接続の終了は、RSTまたはFINフラグによって示されます。
For UDP, the firewall can be opened if the first packet comes from an internal user, but the closing is generally done by an idle timer of arbitrary duration, which might not match the expectations of the application.
UDPの場合、最初のパケットが内部ユーザーからのものである場合、ファイアウォールを開くことができますが、通常は、任意の期間のアイドルタイマーによって閉じられます。これは、アプリケーションの期待と一致しない場合があります。
Simple IPv6 firewall capabilities for customer premises equipment (both stateless and stateful) are described in [RFC6092].
カスタマープレミス機器（ステートレスとステートフルの両方）のシンプルなIPv6ファイアウォール機能は、[RFC6092]で説明されています。
A firewall functions better when it can observe the protocol state machine, described generally by "Transport-Independent Path Layer State Management" [PATH-STATE].
ファイアウォールは、「トランスポートに依存しないパスレイヤーの状態管理」[PATH-STATE]で一般的に説明されているプロトコルステートマシンを監視できる場合に、より適切に機能します。
In the context of a DDoS attack, the purpose of a scrubber is to discard attack traffic while permitting useful traffic. Such a mitigator is described in [DOTS].
DDoS攻撃のコンテキストでは、スクラバーの目的は、有用なトラフィックを許可しながら攻撃トラフィックを破棄することです。そのような緩和策は[DOTS]で説明されています。
When attacks occur against constrained resources, some traffic will be discarded before reaching the intended destination. A user receives better experience and a server runs more efficiently if a scrubber can discard attack traffic, leaving room for legitimate traffic.
制約されたリソースに対して攻撃が発生すると、目的の宛先に到達する前に一部のトラフィックが破棄されます。スクラバーが攻撃トラフィックを破棄でき、正当なトラフィックの余地を残せば、ユーザーのエクスペリエンスが向上し、サーバーがより効率的に実行されます。
Scrubbing must be provided by an on-path network device, because neither endpoint of a legitimate connection has any control over the source of the attack traffic.
正当な接続のどちらのエンドポイントも攻撃トラフィックの送信元を制御できないため、スクラブはパス上のネットワークデバイスによって提供される必要があります。
Source-spoofed DDoS attacks can be mitigated at the source using BCP 38 [RFC2827], but it is more difficult if source address filtering cannot be applied.
送信元になりすましたDDoS攻撃は、BCP 38 [RFC2827]を使用して送信元で緩和できますが、送信元アドレスフィルタリングを適用できない場合はさらに困難になります。
In contrast to devices in the core of the Internet, middleboxes statefully observing bidirectional transport connections can reject source-spoofed TCP traffic based on the inability to provide sensible acknowledgement numbers to complete the three-way handshake. Obviously, this requires middlebox visibility into a transport-layer state machine.
インターネットのコアにあるデバイスとは対照的に、ミドルボックスは双方向トランスポート接続をステートフルに監視しており、3ウェイハンドシェイクを完了するための適切な確認応答番号を提供できないことに基づいて、送信元になりすましたTCPトラフィックを拒否できます。明らかに、これにはトランスポート層の状態マシンへのミドルボックスの可視性が必要です。
Middleboxes may also scrub on the basis of statistical classification: testing how likely a given packet is to be legitimate. As protocol designers add more entropy to headers and lengths, this test becomes less useful, and the best scrubbing strategy becomes random drop.
ミドルボックスは、統計的分類に基づいてスクラブする場合もあります。つまり、特定のパケットが正当である可能性をテストします。プロトコル設計者がヘッダーと長さにより多くのエントロピーを追加すると、このテストはあまり有用でなくなり、最良のスクラビング戦略はランダムドロップになります。
In order to enhance the end user's quality of experience, some operators deploy implicit identification features that rely upon the correlation of network-related information to access some local services. For example, service portals operated by some operators may be accessed immediately by end users without any explicit identification for the sake of improved service availability. This is doable thanks to on-path devices that inject appropriate metadata that can be used by the remote server to enforce per-subscriber policies. The information can be injected at the application layer or at the transport layer (when an address-sharing mechanism is in use).
エンドユーザーのエクスペリエンスの品質を向上させるために、一部のオペレーターは、ネットワーク関連情報の相関に依存してローカルサービスにアクセスする暗黙の識別機能を展開します。たとえば、一部の事業者が運営するサービスポータルには、サービスの可用性を向上させるために、明示的な識別なしにエンドユーザーがすぐにアクセスできます。これは、サブスクライバーごとのポリシーを適用するためにリモートサーバーが使用できる適切なメタデータを挿入するパス上のデバイスのおかげで実行可能です。情報は、アプリケーション層またはトランスポート層（アドレス共有メカニズムが使用されている場合）に挿入できます。
An experimental implementation using a TCP option is described in [RFC7974].
TCPオプションを使用した実験的な実装は、[RFC7974]で説明されています。
For the intended use of implicit identification, it is more secure to have a trusted middlebox mark this traffic than to trust end-user devices.
暗黙的な識別の使用目的では、エンドユーザーのデバイスを信頼するよりも、信頼できるミドルボックスでこのトラフィックをマークする方が安全です。
Performance-Enhancing Proxies (PEPs) can improve performance in some types of networks by improving packet spacing or generating local acknowledgements; they are most commonly used in satellite and cellular networks. Transport-Layer PEPs are described in Section 2.1.1 of [RFC3135].
パフォーマンス向上プロキシ（PEP）は、パケット間隔を改善したり、ローカルの確認応答を生成したりすることにより、一部のタイプのネットワークでパフォーマンスを改善できます。それらは衛星および携帯電話ネットワークで最も一般的に使用されます。 Transport-Layer PEPは、[RFC3135]のセクション2.1.1で説明されています。
PEPs allow central deployment of congestion control algorithms more suited to the specific network, most commonly for delay-based congestion control. More advanced TCP PEPs deploy congestion control systems that treat all of a single end user's TCP connections as a single unit, improving fairness and allowing faster reaction to changing network conditions. For example, it was reported that splitting the TCP connections in some network accesses can result in a halved page downloading time [ICCRG].
PEPにより、特定のネットワークにより適した、最も一般的には遅延ベースの輻輳制御に適した輻輳制御アルゴリズムを一元的に配備できます。より高度なTCP PEPは、単一のエンドユーザーのすべてのTCP接続を単一のユニットとして扱う輻輳制御システムを展開し、公平性を向上させ、変化するネットワーク条件へのより迅速な対応を可能にします。たとえば、一部のネットワークアクセスでTCP接続を分割すると、ページのダウンロード時間が半分になる[ICCRG]と報告されています。
Local acknowledgements generated by PEPs speed up TCP slow start by splitting the effective latency, and they allow for retransmissions to be done from the PEP rather than from the actual sender. Local acknowledgements will also allow a PEP to maintain a local buffer of data appropriate to the actual network conditions, whereas the actual endpoints would often send too much or too little.
PEPによって生成されたローカル確認応答は、実効待ち時間を分割することによりTCPスロースタートを高速化し、実際の送信者ではなくPEPから再送信を実行できるようにします。ローカルの確認応答により、PEPは実際のネットワーク状態に適したデータのローカルバッファーを維持することもできますが、実際のエンドポイントは送信する量が多すぎるか少なすぎることがよくあります。
A PEP function requires transport-layer fields that allow chunks of data to be identified (e.g., TCP sequence numbers), acknowledgements to be identified (e.g., TCP ACK numbers), and acknowledgements to be created from the PEP.
PEP機能には、データのチャンクの識別（TCPシーケンス番号など）、確認の識別（TCP ACK番号など）、およびPEPからの確認の作成を可能にするトランスポート層フィールドが必要です。
Note that PEPs are only useful in some types of networks. In particular, PEPs are very useful in contexts wherein the congestion control strategies of the endpoints are inappropriate for the network connecting them. That being said, poor design can result in degraded performances when PEPs are deployed.
PEPは一部のタイプのネットワークでのみ役立つことに注意してください。特に、PEPは、エンドポイントの輻輳制御戦略がそれらを接続するネットワークに不適切である状況で非常に役立ちます。そうは言っても、PEPが展開されている場合、設計が不十分だとパフォーマンスが低下する可能性があります。
Network Coding is a technique for improving transmission performance over low-bandwidth, long-latency links such as some satellite links. Coding may involve lossless compression and/or adding redundancy to headers and payload. A Network Coding Taxonomy is provided by [RFC8406]; an example of end-to-end coding is FECFRAME [RFC6363]. It is typically deployed with network-coding gateways at each end of those links, with a network-coding tunnel between them via the slow/lossy/long-latency links.
ネットワークコーディングは、一部の衛星リンクなど、低帯域幅で待ち時間の長いリンクでの伝送パフォーマンスを向上させるための手法です。コーディングには、ロスレス圧縮やヘッダーとペイロードへの冗長性の追加が含まれる場合があります。ネットワークコーディング分類法は[RFC8406]によって提供されます。エンドツーエンドのコーディングの例は、FECFRAME [RFC6363]です。通常、これらのリンクの両端にネットワークコーディングゲートウェイを配置し、低速/損失/長い遅延のリンクを介して、それらの間にネットワークコーディングトンネルを配置します。
Network-coding implementations may be specific to TCP, taking advantage of known properties of the protocol.
ネットワークコーディングの実装は、プロトコルの既知のプロパティを利用して、TCPに固有である場合があります。
The network-coding gateways may employ some techniques of PEPs, such as creating acknowledgements of queued data, removing retransmissions, and pacing data rates to reduce queue oscillation.
ネットワークコーディングゲートウェイは、キューに入れられたデータの確認応答の作成、再送信の削除、データレートのペーシングなどのPEPのいくつかの手法を使用して、キューの振動を減らすことができます。
The interest in more network coding in some specific networks is discussed in [SATELLITES].
いくつかの特定のネットワークにおけるより多くのネットワークコーディングへの関心は[衛星]で議論されています。
Note: This is not to be confused with transcoding, which performs lossy compression on transmitted media streams and is not in scope for this document.
注：これは、トランスコードされたメディアストリームに対して不可逆圧縮を実行するトランスコーディングと混同しないでください。このドキュメントの範囲外です。
The Hybrid Access Aggregation Point is a middlebox that allows customers to aggregate the bandwidth of multiple access technologies.
ハイブリッドアクセス集約ポイントは、顧客が複数のアクセステクノロジーの帯域幅を集約できるミドルボックスです。
One of the approaches uses Multipath TCP (MPTCP) proxies [TCP-CONVERT] to forward traffic along multiple paths. The MPTCP proxy operates at the transport layer while being located in the operator's network.
アプローチの1つは、マルチパスTCP（MPTCP）プロキシ[TCP-CONVERT]を使用して、複数のパスに沿ってトラフィックを転送します。 MPTCPプロキシは、通信事業者のネットワークに配置されている間、トランスポート層で動作します。
The support of multipath transport capabilities by communicating hosts remains a privileged target design so that such hosts can directly use the available resources provided by a variety of access networks they can connect to. Nevertheless, network operators do not control end hosts, whereas the support of MPTCP by content servers remains marginal.
通信ホストによるマルチパストランスポート機能のサポートは引き続き特権的なターゲット設計であるため、そのようなホストは、接続できるさまざまなアクセスネットワークによって提供される利用可能なリソースを直接使用できます。それでも、ネットワークオペレーターはエンドホストを制御しませんが、コンテンツサーバーによるMPTCPのサポートはわずかです。
Network-assisted MPTCP deployment models are designed to facilitate the adoption of MPTCP for the establishment of multipath communications without making any assumption about the support of MPTCP capabilities by communicating peers. Network-assisted MPTCP deployment models rely upon MPTCP Conversion Points (MCPs) that act on behalf of hosts so that they can take advantage of establishing communications over multiple paths [TCP-CONVERT].
ネットワーク支援MPTCP配置モデルは、通信するピアによるMPTCP機能のサポートについて何も想定せずに、マルチパス通信を確立するためのMPTCPの採用を容易にするように設計されています。ネットワーク支援MPTCP配置モデルは、ホストに代わって動作するMPTCP変換ポイント（MCP）に依存しているため、複数のパスを介した通信の確立を利用できます[TCP-CONVERT]。
Note there are cases when end-to-end MPTCP cannot be used even though both client and server are MPTCP-compliant. An MPTCP proxy can provide multipath utilization in these cases. Examples of such cases are listed below:
クライアントとサーバーの両方がMPTCPに準拠していても、エンドツーエンドのMPTCPを使用できない場合があることに注意してください。 MPTCPプロキシは、これらの場合にマルチパス使用率を提供できます。そのようなケースの例を以下に示します。
1. The use of private IPv4 addresses in some access networks. Typically, additional subflows cannot be added to the MPTCP connection without the help of an MCP.
1. 一部のアクセスネットワークでのプライベートIPv4アドレスの使用。通常、MCPを使用しないと、追加のサブフローをMPTCP接続に追加できません。
2. The assignment of IPv6 prefixes only by some networks. If the server is IPv4-only, IPv6 subflows cannot be added to an MPTCP connection established with that server, by definition.
2. 一部のネットワークのみによるIPv6プレフィックスの割り当て。サーバーがIPv4のみの場合、そのサーバーとのMPTCP接続にIPv6サブフローを追加することはできません。
3. Subscription to some service offerings is subject to volume quota.
3. 一部のサービスオファリングのサブスクリプションには、ボリュームクォータが適用されます。
Bulk traffic may be served with a higher latency than interactive traffic with no reduction in throughput. This fact allows a middlebox function to improve response times in interactive applications by prioritizing, policing, or remarking interactive transport connections differently from bulk-traffic transport connections. For example, gaming traffic may be prioritized over email or software updates. Configuration guidelines for Diffserv service classes are discussed in [RFC4594].
バルクトラフィックは、スループットを低下させることなく、インタラクティブトラフィックよりも高いレイテンシで処理できます。この事実により、ミドルボックス機能は、バルクトラフィックトランスポート接続とは異なる方法でインタラクティブトランスポート接続に優先順位を付ける、ポリシングする、または再マーキングすることにより、インタラクティブアプリケーションの応答時間を改善できます。たとえば、ゲームのトラフィックは、電子メールまたはソフトウェアの更新よりも優先される場合があります。 Diffservサービスクラスの構成ガイドラインは、[RFC4594]で説明されています。
Middleboxes may identify different classes of traffic by inspecting multiple layers of header and length of payload.
ミドルボックスは、ヘッダーの複数の層とペイロードの長さを検査することにより、トラフィックのさまざまなクラスを識別できます。
Basic traffic-shaping functionality requires no transport-layer information. All that is needed is a way of mapping each packet to a traffic shaper quota. For example, there may be a rate limit per 5-tuple or per subscriber IP address. However, such fixed traffic shaping rules are wasteful as they end up rate-limiting traffic even when the network has free resources available.
基本的なトラフィックシェーピング機能には、トランスポート層情報は必要ありません。必要なのは、各パケットをトラフィックシェーパークォータにマッピングする方法だけです。たとえば、5タプルまたはサブスクライバIPアドレスごとにレート制限がある場合があります。ただし、このような固定トラフィックシェーピングルールは、ネットワークに使用可能な空きリソースがある場合でも、最終的にレート制限トラフィックになるため、無駄が多くなります。
More advanced traffic-shaping devices use transport-layer metrics described in Section 2 to detect congestion on either a per-site or a per-user level and use different traffic-shaping rules when congestion is detected [RFC3272]. This type of device can overcome limitations of downstream devices that behave poorly (e.g., by excessive buffering or suboptimally dropping packets).
より高度なトラフィックシェーピングデバイスは、セクション2で説明されているトランスポートレイヤーメトリックを使用して、サイトごとまたはユーザーごとのレベルで輻輳を検出し、輻輳が検出されたときに異なるトラフィックシェーピングルールを使用します[RFC3272]。このタイプのデバイスは、動作が不十分なダウンストリームデバイスの制限を克服することができます（たとえば、過度のバッファリングまたは次善にパケットをドロップすることにより）
Several service offerings rely upon a volume-based charging model (e.g., volume-based data plans offered by cellular providers). Operators may assist end users in conserving their data quota by deploying on-path functions that shape traffic that would otherwise be aggressively transferred.
いくつかのサービスは、ボリュームベースの課金モデル（携帯電話プロバイダーによって提供されるボリュームベースのデータプランなど）に依存しています。オペレーターは、そうでなければ積極的に転送されるトラフィックを形成するオンパス機能を展開することにより、エンドユーザーがデータクォータを節約するのを支援できます。
For example, a fast download of a video that won't be viewed completely by the subscriber may lead to quick exhaustion of the data quota. Limiting the video download rate conserves quota for the benefit of the end user. Also, discarding unsolicited incoming traffic prevents the user's quota from being unfairly exhausted.
たとえば、サブスクライバーによって完全には表示されないビデオの高速ダウンロードは、データクォータをすぐに使い果たす可能性があります。ビデオのダウンロードレートを制限すると、エンドユーザーの利益のために割り当てが節約されます。また、一方的な着信トラフィックを破棄することで、ユーザーのクォータが不当に使い果たされることを防ぎます。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
This document intentionally excludes middleboxes that observe or manipulate application-layer data.
このドキュメントでは、アプリケーション層のデータを監視または操作するミドルボックスを意図的に除外しています。
The measurements and functions described in this document can all be implemented without violating confidentiality [RFC6973]. However, there is always the question of whether the fields and packet properties used to achieve operational benefits may also be used for harm.
このドキュメントで説明されている測定と機能はすべて、機密性を侵害することなく実装できます[RFC6973]。ただし、運用上のメリットを実現するために使用されるフィールドとパケットプロパティを害に使用できるかどうかは常に問題です。
In particular, the question is what confidentiality is lost by exposing transport-layer fields beyond what can be learned by observing IP-layer fields:
特に、問題は、トランスポート層フィールドをIP層フィールドを観察することによって学べることを超えて公開することによって、どのような機密性が失われるかです。
o Sequence numbers: an observer can learn how much data is transferred.
o シーケンス番号：オブザーバーは転送されるデータ量を知ることができます。
o Start/Stop indicators: an observer can count transactions for some applications.
o 開始/停止インジケーター：オブザーバーは一部のアプリケーションのトランザクションをカウントできます。
o Device fingerprinting: an observer may be more easily able to identify a device type when different devices use different default field values or options.
o デバイスのフィンガープリント：異なるデバイスが異なるデフォルトのフィールド値またはオプションを使用する場合、オブザーバーはデバイスタイプをより簡単に識別できる場合があります。
An on-path attacker being able to observe sequence numbers or session identifiers may make it easier to modify or terminate a transport connection. For example, observing TCP sequence numbers allows generation of a RST packet that terminates the connection. However, signing transport fields softens this attack. The attack and solution are described for the TCP authentication option [RFC5925]. Still, an on-path attacker can also drop the traffic flow.
パス上の攻撃者がシーケンス番号またはセッション識別子を監視できると、トランスポート接続の変更または終了が容易になる可能性があります。たとえば、TCPシーケンス番号を監視すると、接続を終了するRSTパケットを生成できます。ただし、トランスポートフィールドに署名すると、この攻撃が緩和されます。攻撃と解決策は、TCP認証オプション[RFC5925]について説明されています。それでも、パス上の攻撃者はトラフィックフローをドロップすることもできます。
Network maintainability and security can be improved by providing firewalls and DDoS mechanisms with some information about transport connections. In contrast, it would be very difficult to secure a network in which every packet appears unique and filled with random bits (from the perspective of an on-path device).
ファイアウォールとDDoSメカニズムにトランスポート接続に関するいくつかの情報を提供することにより、ネットワークの保守性とセキュリティを向上させることができます。対照的に、すべてのパケットが一意に見え、ランダムなビットで満たされたネットワークを保護することは非常に困難です（パス上のデバイスの観点から）。
Some features providing the ability to mitigate/filter attacks owing to a network-assisted mechanism will therefore improve security -- e.g., by means of Distributed-Denial-of-Service Open Threat Signaling (DOTS) [DOTS-SIGNAL].
したがって、ネットワーク支援メカニズムによる攻撃を緩和/フィルタリングする機能を提供するいくつかの機能は、セキュリティを向上させます-たとえば、サービス拒否分散型オープン脅威シグナリング（DOTS）[DOTS-SIGNAL]によって。
[DOTS] Mortensen, A., Andreasen, F., Reddy, T., Compton, R., and N. Teague, "Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture", Work in Progress, draft-ietf-dots-architecture-07, September 2018.
[DOTS] Mortensen、A.、Andreasen、F.、Reddy、T.、Compton、R。、およびN. Teague、「分散型サービス拒否（DOTS）アーキテクチャ」、作業中、ドラフト-ietf-dots-architecture-07、2018年9月。
[DOTS-SIGNAL] Reddy, T., Boucadair, M., Patil, P., Mortensen, A., and N. Teague, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", Work in Progress, draft-ietf-dots-signal-channel-25, September 2018.
[DOTS-SIGNAL] Reddy、T.、Boucadair、M.、Patil、P.、Mortensen、A。、およびN. Teague、「分散型サービス拒否のOpen Threat Signaling（DOTS）信号チャネル仕様」、進捗状況、draft-ietf-dots-signal-channel-25、2018年9月。
[ICCRG] Kuhn, N., "MPTCP and BBR performance over Internet satellite paths", IETF 100, 2017, <https://datatracker.ietf.org/meeting/100/materials/ slides-100-iccrg-mptcp-and-bbr-performance-over-satcom-links-00>.
[ICCRG]クーンN.、「インターネット衛星パスでのMPTCPおよびBBRパフォーマンス」、IETF 100、2017、<https://datatracker.ietf.org/meeting/100/materials/ slides-100-iccrg-mptcp-and -bbr-performance-over-satcom-links-00>。
[PATH-STATE] Kuehlewind, M., Trammell, B., and J. Hildebrand, "Transport-Independent Path Layer State Management", Work in Progress, draft-trammell-plus-statefulness-04, November 2017.
[PATH-STATE] Kuehlewind、M.、Trammell、B.、J。Hildebrand、「Transport-Independent Path Layer State Management」、Work in Progress、draft-trammell-plus-statefulness-04、2017年11月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, DOI 10.17487/RFC2018, October 1996, <https://www.rfc-editor.org/info/rfc2018>.
[RFC2018] Mathis、M.、Madhavi、J.、Floyd、S。、およびA. Romanow、「TCP選択的確認応答オプション」、RFC 2018、DOI 10.17487 / RFC2018、1996年10月、<https：//www.rfc- editor.org/info/rfc2018>。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IPソースアドレススプーフィングを使用するサービス拒否攻撃の阻止」、BCP 38、RFC 2827、DOI 10.17487 / RFC2827、2000年5月、<https：// www .rfc-editor.org / info / rfc2827>。
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, DOI 10.17487/RFC2991, November 2000, <https://www.rfc-editor.org/info/rfc2991>.
[RFC2991] Thaler、D。およびC. Hopps、「ユニキャストおよびマルチキャストネクストホップ選択におけるマルチパスの問題」、RFC 2991、DOI 10.17487 / RFC2991、2000年11月、<https://www.rfc-editor.org/info / rfc2991>。
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, DOI 10.17487/RFC3135, June 2001, <https://www.rfc-editor.org/info/rfc3135>.
[RFC3135] Border、J.、Kojo、M.、Griner、J。、モンテネグロ、G。、およびZ. Shelby、「リンク関連の低下を軽減するためのパフォーマンス強化プロキシ」、RFC 3135、DOI 10.17487 / RFC3135、6月2001、<https://www.rfc-editor.org/info/rfc3135>。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<https：// www。 rfc-editor.org/info/rfc3168>。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, <https://www.rfc-editor.org/info/rfc3234>.
[RFC3234] Carpenter、B。およびS. Brim、「Middleboxes：Taxonomy and Issues」、RFC 3234、DOI 10.17487 / RFC3234、2002年2月、<https://www.rfc-editor.org/info/rfc3234>。
[RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, <https://www.rfc-editor.org/info/rfc3272>.
[RFC3272] Awduche、D.、Chiu、A.、Elwalid、A.、Widjaja、I。、およびX. Xiao、「インターネットトラフィックエンジニアリングの概要と原則」、RFC 3272、DOI 10.17487 / RFC3272、2002年5月、< https://www.rfc-editor.org/info/rfc3272>。
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, <https://www.rfc-editor.org/info/rfc4594>.
[RFC4594] Babiarz、J.、Chan、K。、およびF. Baker、「DiffServサービスクラスの構成ガイドライン」、RFC 4594、DOI 10.17487 / RFC4594、2006年8月、<https://www.rfc-editor.org / info / rfc4594>。
[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, DOI 10.17487/RFC4737, November 2006, <https://www.rfc-editor.org/info/rfc4737>.
[RFC4737] Morton、A.、Ciavattone、L.、Ramachandran、G.、Shalunov、S。、およびJ. Perser、「Packet Reordering Metrics」、RFC 4737、DOI 10.17487 / RFC4737、2006年11月、<https：// www.rfc-editor.org/info/rfc4737>。
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, <https://www.rfc-editor.org/info/rfc4787>.
[RFC4787]オーデ、F、エド。およびC.ジェニングス、「ユニキャストUDPのネットワークアドレス変換（NAT）動作要件」、BCP 127、RFC 4787、DOI 10.17487 / RFC4787、2007年1月、<https://www.rfc-editor.org/info/rfc4787> 。
[RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A., and R. Whitner, "Improved Packet Reordering Metrics", RFC 5236, DOI 10.17487/RFC5236, June 2008, <https://www.rfc-editor.org/info/rfc5236>.
[RFC5236] Jayasumana、A.、Piratla、N.、Banka、T.、Bare、A。、およびR. Whitner、「Improved Packet Reordering Metrics」、RFC 5236、DOI 10.17487 / RFC5236、2008年6月、<https：/ /www.rfc-editor.org/info/rfc5236>。
[RFC5853] Hautakorpi, J., Ed., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, DOI 10.17487/RFC5853, April 2010, <https://www.rfc-editor.org/info/rfc5853>.
[RFC5853] Hautakorpi、J.、Ed。、Camarillo、G.、Penfield、R.、Hawrylyshen、A.、and M. Bhatia、 "Requirements from Session Initiation Protocol（SIP）Session Border Control（SBC）Deployments"、RFC 5853、DOI 10.17487 / RFC5853、2010年4月、<https://www.rfc-editor.org/info/rfc5853>。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、DOI 10.17487 / RFC5925、2010年6月、<https://www.rfc-editor.org/info / rfc5925>。
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, DOI 10.17487/RFC6092, January 2011, <https://www.rfc-editor.org/info/rfc6092>.
[RFC6092] Woodyatt、J.、Ed。、 "Recommended Simple Security Capability in Customer Premises Equipment（CPE）for Providing Residential IPv6 Internet Service"、RFC 6092、DOI 10.17487 / RFC6092、January 2011、<https：//www.rfc -editor.org/info/rfc6092>。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「Stateful NAT64：Network Address and Protocol Translation to IPv6 Clients to IPv4 Servers」、RFC 6146、DOI 10.17487 / RFC6146、2011年4月、<https： //www.rfc-editor.org/info/rfc6146>。
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, <https://www.rfc-editor.org/info/rfc6269>.
[RFC6269] Ford、M.、Ed。、Boucadair、M.、Durand、A.、Levis、P。、およびP. Roberts、「Issues with IP Address Sharing」、RFC 6269、DOI 10.17487 / RFC6269、2011年6月、 <https://www.rfc-editor.org/info/rfc6269>。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, <https://www.rfc-editor.org/info/rfc6296>.
[RFC6296] Wasserman、M。およびF. Baker、「IPv6-to-IPv6 Network Prefix Translation」、RFC 6296、DOI 10.17487 / RFC6296、2011年6月、<https://www.rfc-editor.org/info/rfc6296 >。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, <https://www.rfc-editor.org/info/rfc6333>.
[RFC6333] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4の枯渇に続くデュアルスタックLiteブロードバンドの展開」、RFC 6333、DOI 10.17487 / RFC6333、2011年8月、<https：/ /www.rfc-editor.org/info/rfc6333>。
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, DOI 10.17487/RFC6363, October 2011, <https://www.rfc-editor.org/info/rfc6363>.
[RFC6363] Watson、M.、Begen、A。、およびV. Roca、「Forward Error Correction（FEC）Framework」、RFC 6363、DOI 10.17487 / RFC6363、2011年10月、<https：//www.rfc-editor。 org / info / rfc6363>。
[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, DOI 10.17487/RFC6459, January 2012, <https://www.rfc-editor.org/info/rfc6459>.
[RFC6459] Korhonen、J.、Ed。、Soininen、J.、Patil、B.、Savolainen、T.、Bajko、G.、and K. Iisakkila、 "IPv6 in the 3rd Generation Partnership Project（3GPP）Evolved Packet System（ EPS） "、RFC 6459、DOI 10.17487 / RFC6459、2012年1月、<https://www.rfc-editor.org/info/rfc6459>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、DOI 10.17487 / RFC6973、2013年7月、<https://www.rfc-editor.org/info/rfc6973>。
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014, <https://www.rfc-editor.org/info/rfc7323>.
[RFC7323] Borman、D.、Braden、B.、Jacobson、V。、およびR. Scheffenegger、編、「高性能のTCP拡張機能」、RFC 7323、DOI 10.17487 / RFC7323、2014年9月、<https：// www.rfc-editor.org/info/rfc7323>。
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015, <https://www.rfc-editor.org/info/rfc7498>.
[RFC7498]クイン、P。、エド。 T.ナドー編、「サービス機能連鎖の問題ステートメント」、RFC 7498、DOI 10.17487 / RFC7498、2015年4月、<https://www.rfc-editor.org/info/rfc7498>。
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, July 2015, <https://www.rfc-editor.org/info/rfc7596>.
[RFC7596] Cui、Y.、Sun、Q.、Boucadair、M.、Tsou、T.、Lee、Y.、I。Farrer、「Lightweight 4over6：An Extension to the Dual-Stack Lite Architecture」、RFC 7596 、DOI 10.17487 / RFC7596、2015年7月、<https://www.rfc-editor.org/info/rfc7596>。
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015, <https://www.rfc-editor.org/info/rfc7597>.
[RFC7597] Troan、O.、Ed。、Dec、W.、Li、X.、Bao、C.、Matsushima、S.、Murakami、T.、and T. Taylor、Ed。、 "Mapping of Address and Port。カプセル化あり（MAP-E）」、RFC 7597、DOI 10.17487 / RFC7597、2015年7月、<https://www.rfc-editor.org/info/rfc7597>。
[RFC7690] Byerly, M., Hite, M., and J. Jaeggli, "Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB))", RFC 7690, DOI 10.17487/RFC7690, January 2016, <https://www.rfc-editor.org/info/rfc7690>.
[RFC7690] Byerly、M.、Hite、M.、and J. Jaeggli、 "Close Encounters of the ICMP Type 2 Kind（Near Miss with ICMPv6 Packet Too Big（PTB））"、RFC 7690、DOI 10.17487 / RFC7690、January 2016、<https://www.rfc-editor.org/info/rfc7690>。
[RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, S., and K. Naito, "Updates to Network Address Translation (NAT) Behavioral Requirements", BCP 127, RFC 7857, DOI 10.17487/RFC7857, April 2016, <https://www.rfc-editor.org/info/rfc7857>.
[RFC7857] Penno、R.、Perreault、S.、Boucadair、M.、Ed。、Sivakumar、S.、and K. Naito、 "Updates to Network Address Translation（NAT）Behavioral Requirements"、BCP 127、RFC 7857、 DOI 10.17487 / RFC7857、2016年4月、<https://www.rfc-editor.org/info/rfc7857>。
[RFC7974] Williams, B., Boucadair, M., and D. Wing, "An Experimental TCP Option for Host Identification", RFC 7974, DOI 10.17487/RFC7974, October 2016, <https://www.rfc-editor.org/info/rfc7974>.
[RFC7974]ウィリアムズ、B。、ブーカデア、M。、およびD.ウィング、「ホスト識別のための実験的TCPオプション」、RFC 7974、DOI 10.17487 / RFC7974、2016年10月、<https：//www.rfc-editor。 org / info / rfc7974>。
[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, <https://www.rfc-editor.org/info/rfc8084>.
[RFC8084] Fairhurst、G。、「Network Transport Circuit Breakers」、BCP 208、RFC 8084、DOI 10.17487 / RFC8084、2017年3月、<https://www.rfc-editor.org/info/rfc8084>。
[RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of Pervasive Encryption on Operators", RFC 8404, DOI 10.17487/RFC8404, July 2018, <https://www.rfc-editor.org/info/rfc8404>.
[RFC8404]モリアーティ、K。、エド。 A.モートン編、「オペレーターに対するパーベイシブ暗号化の影響」、RFC 8404、DOI 10.17487 / RFC8404、2018年7月、<https://www.rfc-editor.org/info/rfc8404>。
[RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and S. Sivakumar, "Taxonomy of Coding Techniques for Efficient Network Communications", RFC 8406, DOI 10.17487/RFC8406, June 2018, <https://www.rfc-editor.org/info/rfc8406>.
[RFC8406] Adamson、B.、Adjih、C.、Bilbao、J.、Firoiu、V.、Fitzek、F.、Ghanem、S.、Lochin、E.、Masucci、A.、Montpetit、MJ。、Pedersen、 M.、ペラルタ、G。、ロカ、V。、編、サクセナ、P。、およびS.シバクマー、「効率的なネットワーク通信のためのコーディング手法の分類法」、RFC 8406、DOI 10.17487 / RFC8406、2018年6月、<https ：//www.rfc-editor.org/info/rfc8406>。
[SATELLITES] Kuhn, N. and E. Lochin, "Network coding and satellites", Work in Progress, draft-irtf-nwcrg-network-coding-satellites-02, November 2018.
[衛星] Kuhn、N。およびE. Lochin、「ネットワークコーディングと衛星」、Work in Progress、draft-irtf-nwcrg-network-coding-satellites-02、2018年11月。
[TCP-CONVERT] Bonaventure, O., Boucadair, M., Gundavelli, S., and S. Seo, "0-RTT TCP Convert Protocol", Work in Progress, draft-ietf-tcpm-converters-04, October 2018.
[TCP-CONVERT] Bonaventure、O.、Boucadair、M.、Gundavelli、S。、およびS. Seo、「0-RTT TCP Convert Protocol」、作業中、draft-ietf-tcpm-converters-04、2018年10月。
[USE-CASE] Napper, J., Stiemerling, M., Lopez, D., and J. Uttaro, "Service Function Chaining Use Cases in Mobile Networks", Work in Progress, draft-ietf-sfc-use-case-mobility-08, May 2018.
[USE-CASE] Napper、J.、Stiemerling、M.、Lopez、D.、J。Uttaro、「モバイルネットワークでのサービス機能チェーンの使用例」、作業中、draft-ietf-sfc-use-case-モビリティ-08、2018年5月。
Acknowledgements
謝辞
The authors thank Brian Trammell, Brian Carpenter, Mirja Kuehlewind, Kathleen Moriarty, Gorry Fairhurst, Adrian Farrel, and Nicolas Kuhn for their review and suggestions.
著者は、レビューと提案をしてくれたBrian Trammell、Brian Carpenter、Mirja Kuehlewind、Kathleen Moriarty、Gorry Fairhurst、Adrian Farrel、Nicolas Kuhnに感謝します。
Authors' Addresses
著者のアドレス
David Dolson (editor)
デビッド・ドルソン（編集者）
Email: ddolson@acm.org
Juho Snellman
ジュホスネルマン
Email: jsnell@iki.fi
Mohamed Boucadair (editor) Orange 4 rue du Clos Courtel Rennes 35000 France
Mohamed Boucadair（編集者）Orange 4 rue du Clos Courtel Rennes 35000フランス
Email: mohamed.boucadair@orange.com
Christian Jacquenet Orange 4 rue du Clos Courtel Rennes 35000 France
クリスチャンジャケネオレンジ4 rue du Clos Courtel Rennes 35000フランス
Email: christian.jacquenet@orange.com