[要約] RFC 8558は、トランスポートプロトコルパスシグナルに関する標準化された仕様であり、ネットワークパス上の信号の制御と通信を目的としています。このRFCは、ネットワークの信号制御に関する一貫性と互換性を提供するために作成されました。
Internet Architecture Board (IAB) T. Hardie, Ed.
Request for Comments: 8558 April 2019
Category: Informational
ISSN: 2070-1721
Transport Protocol Path Signals
トランスポートプロトコルパス信号
Abstract
概要
This document discusses the nature of signals seen by on-path elements examining transport protocols, contrasting implicit and explicit signals. For example, TCP's state machine uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on-path network elements lack those signals. Often, the removal of those signals is intended by those moving the messages to confidential channels. Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used.
このドキュメントでは、転送プロトコルを調べて、暗黙的信号と明示的信号を対比して、経路上の要素によって見られる信号の性質について説明します。たとえば、TCPのステートマシンは、平文で交換される一連の既知のメッセージを使用します。これらは、トランスポート接続を設定する2つのノード間のパス上のネットワーク要素から見えるため、これらのネットワーク要素によって信号としてよく使用されます。これらのメッセージを平文で交換しないトランスポートでは、パス上のネットワーク要素にはこれらの信号がありません。多くの場合、これらの信号の削除は、メッセージを機密チャネルに移動することを目的としています。エンドポイントがパスに沿ったネットワーク要素がこれらの信号を受信することを望む場合、このドキュメントでは明示的な信号を使用することを推奨しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。これは、インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc8558.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8558で入手できます。
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
2. Signal Types Inferred ...........................................4
2.1. Session Establishment ......................................4
2.1.1. Session Identity ....................................4
2.1.2. Routability and Intent ..............................4
2.1.3. Flow Stability ......................................5
2.1.4. Resource Requirements ...............................5
2.2. Network Measurement ........................................5
2.2.1. Path Latency ........................................5
2.2.2. Path Reliability and Consistency ....................5
3. Options .........................................................5
3.1. Do Not Restore These Signals ...............................6
3.2. Replace These with Network-Layer Signals ...................6
3.3. Replace These with Per-Transport Signals ...................6
3.4. Create a Set of Signals Common to Multiple Transports ......6
4. Recommendation ..................................................7
5. IANA Considerations .............................................8
6. Security Considerations .........................................8
7. Informative References ..........................................9
IAB Members at the Time of Approval ...............................10
Acknowledgements ..................................................10
Author's Address ..................................................10
This document discusses the nature of signals seen by on-path elements examining transport protocols, contrasting implicit and explicit signals. For example, TCP's state machine uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. While the architecture of the Internet may be best realized by end-to-end protocols [RFC1958], there are cases such as the use of Network Address Translators [RFC3234] where some functions are commonly provided by on-path network elements. In transports that do not exchange these messages in the clear, on-path network elements lack those signals. Often, the removal of those signals is intended by those moving the messages to confidential channels. Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used.
このドキュメントでは、転送プロトコルを調べて、暗黙的信号と明示的信号を対比して、経路上の要素によって見られる信号の性質について説明します。たとえば、TCPのステートマシンは、平文で交換される一連の既知のメッセージを使用します。これらは、トランスポート接続を設定する2つのノード間のパス上のネットワーク要素に表示されるため、これらのネットワーク要素によって信号としてよく使用されます。インターネットのアーキテクチャはエンドツーエンドプロトコル[RFC1958]で最もよく実現できるかもしれませんが、ネットワークアドレストランスレータ[RFC3234]を使用する場合など、一部の機能は通常、パス上のネットワーク要素によって提供されます。これらのメッセージを平文で交換しないトランスポートでは、パス上のネットワーク要素にはこれらの信号がありません。多くの場合、これらの信号の削除は、メッセージを機密チャネルに移動することを目的としています。エンドポイントがパスに沿ったネットワーク要素がこれらの信号を受信することを望む場合、このドキュメントでは明示的な信号を使用することを推奨しています。
The interpretation of TCP [RFC0793] by on-path elements is an example of implicit signal usage. It uses cleartext handshake messages to establish, maintain, and close connections. While these are primarily intended to create state between two communicating nodes, these handshake messages are visible to network elements along the path between them. It is common for certain network elements to treat the exchanged messages as signals that relate to their own functions.
経路上の要素によるTCP [RFC0793]の解釈は、暗黙的な信号の使用例です。クリアテキストハンドシェイクメッセージを使用して、接続を確立、維持、および閉じます。これらは主に2つの通信ノード間に状態を作成することを目的としていますが、これらのハンドシェイクメッセージは、ノード間のパスに沿ったネットワーク要素に表示されます。特定のネットワーク要素が、交換されたメッセージを、独自の機能に関連する信号として扱うことはよくあります。
A firewall may, for example, create a rule that allows traffic from a specific host and port to enter its network when the connection was initiated by a host already within the network. It may subsequently remove that rule when the communication has ceased. In the context of TCP handshake, it sets up the pinhole rule on seeing the initial TCP SYN acknowledgement and then removes it upon seeing a RST or FIN and ACK exchange. Note that in this case, it does nothing to rewrite any portion of the TCP packet; it simply enables a return path that would otherwise have been blocked.
たとえば、ファイアウォールは、接続がすでにネットワーク内にあるホストによって開始されたときに、特定のホストとポートからのトラフィックがそのネットワークに入ることを許可するルールを作成する場合があります。その後、通信が停止したときにそのルールを削除する場合があります。 TCPハンドシェイクのコンテキストでは、最初のTCP SYN確認を確認する際にピンホールルールを設定し、RSTまたはFINとACKの交換を確認するとそれを削除します。この場合、TCPパケットのどの部分も書き換えることはありません。それ以外の場合はブロックされていたはずのリターンパスを有効にするだけです。
When a transport encrypts the fields it uses for state mechanics, these signals are no longer accessible to path elements. The behavior of path elements will then depend on which signal is not available, on the default behavior configured by the path element administrator, and by the security posture of the network as a whole.
トランスポートが状態機構に使用するフィールドを暗号化すると、これらの信号はパス要素にアクセスできなくなります。その場合、パス要素の動作は、利用できない信号、パス要素管理者によって構成されたデフォルトの動作、およびネットワーク全体のセキュリティ状態によって異なります。
The following list of signals that may be inferred from transport state messages includes those that may be exchanged during session establishment and those that derive from the ongoing flow.
トランスポート状態メッセージから推測できる信号の次のリストには、セッションの確立中に交換される可能性のある信号と、進行中のフローから派生する信号が含まれます。
Some of these signals are derived from the direct examination of packet sequences, such as using a sequence number gap pattern to infer network reliability; others are derived from association, such as inferring network latency by timing a flow's packet inter-arrival times.
これらの信号の一部は、シーケンス番号のギャップパターンを使用してネットワークの信頼性を推測するなど、パケットシーケンスの直接的な検査から得られます。その他は、フローのパケットの到着間時間を計ることによってネットワーク遅延を推測するなど、関連付けから導出されます。
This list is not exhaustive, and it is not the full set of effects due to encrypting data and metadata in flight. Note as well that because these are derived from inference, they do not include any path signals that would not be relevant to the endpoint state machines; indeed, an inference-based system cannot send such signals.
このリストは完全なものではなく、進行中のデータとメタデータの暗号化による影響の完全なセットではありません。また、これらは推論から導出されているため、エンドポイントステートマシンに関連しないパス信号は含まれていません。実際、推論ベースのシステムはそのような信号を送信できません。
One of the most basic inferences made by examination of transport state is that a packet will be part of an ongoing flow; that is, an established session will continue until messages are received that terminate it. Path elements may then make subsidiary inferences related to the session.
トランスポート状態の調査によって行われる最も基本的な推論の1つは、パケットが進行中のフローの一部になることです。つまり、確立されたセッションは、それを終了するメッセージが受信されるまで続きます。次に、パス要素はセッションに関連する補助的な推論を行う場合があります。
Path elements that track session establishment will typically create a session identity for the flow, commonly using a tuple of the visible information in the packet headers. This is then used to associate other information with the flow.
セッションの確立を追跡するパス要素は、通常、フローのセッションIDを作成します。通常、パケットヘッダーの可視情報のタプルを使用します。次に、これを使用して他の情報をフローに関連付けます。
A second common inference that session establishment provides is that the communicating pair of hosts can each reach each other and are interested in continuing communication. The firewall example given above is a consequence of that inference; because the internal host initiates the connection, it is presumed to want to receive return traffic. That, in turn, justifies the pinhole.
セッションの確立が提供する2番目の一般的な推論は、通信しているホストのペアがそれぞれお互いに到達でき、通信の継続に関心があるということです。上記のファイアウォールの例は、その推論の結果です。内部ホストが接続を開始するため、リターントラフィックを受信したいと考えられます。それが今度はピンホールを正当化します。
Some other on-path elements assume that a host that asked to communicate with a remote address has authorized receiving incoming communications from any other host (e.g., Endpoint-Independent Mapping or Endpoint-Independent Filtering [RFC7857]). This is, for example, the default behavior in Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64).
他のいくつかのパス上の要素は、リモートアドレスとの通信を要求したホストが、他のホストからの着信通信の受信を承認していることを前提としています（たとえば、エンドポイントに依存しないマッピングまたはエンドポイントに依存しないフィルタリング[RFC7857]）。これは、たとえば、IPv6クライアントからIPv4サーバー（NAT64）へのネットワークアドレスおよびプロトコル変換のデフォルトの動作です。
Some on-path devices that are responsible for load-sharing or load-balancing may be instructed to preserve the same path for a given flow rather than dispatching packets belonging to the same flow on multiple paths as this may cause packets in the flow to be delivered out of order.
ロードシェアリングまたはロードバランシングを担当する一部のパス上デバイスは、フロー内のパケットが原因となる可能性があるため、複数のパスで同じフローに属するパケットをディスパッチするのではなく、特定のフローに対して同じパスを保持するように指示される場合があります。順不同で配送されます。
An additional common inference is that network resources will be required for the session. These may be requirements within the network element itself, such as table entry space for a firewall or NAT; they may also be communicated by the network element to other systems. For networks that use resource reservations, this might result in reservation of radio air time, energy, or network capacity.
さらに一般的な推論は、セッションにはネットワークリソースが必要になるということです。これらは、ファイアウォールやNATのテーブルエントリスペースなど、ネットワーク要素自体の要件である場合があります。また、ネットワーク要素によって他のシステムと通信することもできます。リソース予約を使用するネットワークの場合、これにより、無線通信時間、エネルギー、またはネットワーク容量が予約される可能性があります。
Some network elements will also observe transport messages to engage in measurement of the paths that are used by flows on their network. The list of measurements below is illustrative, not exhaustive.
一部のネットワーク要素は、トランスポートメッセージを監視して、ネットワーク上のフローによって使用されるパスの測定に従事します。以下の測定値のリストは例示であり、網羅的ではありません。
There are several ways in which a network element may measure path latency using transport messages, but two common ones are examining exposed timestamps and associating sequence numbers with a local timer. These measurements are necessarily limited to measuring only the portion of the path between the system that assigned the timestamp or sequence number and the network element.
ネットワーク要素がトランスポートメッセージを使用してパスレイテンシを測定する方法はいくつかありますが、一般的な2つの方法は、公開されたタイムスタンプを調べ、シーケンス番号をローカルタイマーに関連付けることです。これらの測定は、タイムスタンプまたはシーケンス番号を割り当てたシステムとネットワーク要素の間のパスの一部のみを測定することに限定されます。
A network element may also measure the reliability of a particular path by examining sessions that expose sequence numbers; retransmissions and gaps are then associated with the path segments on which they might have occurred.
ネットワーク要素は、シーケンス番号を公開するセッションを調べることにより、特定のパスの信頼性も測定できます。次に、再送信とギャップが発生した可能性のあるパスセグメントに関連付けられます。
The set of options below are alternatives that optimize very different things. Though it comes to a preliminary conclusion, this document intends to foster a discussion of those trade-offs, and any discussion of them must be understood as preliminary.
以下のオプションのセットは、非常に異なるものを最適化する代替手段です。暫定的な結論に至りますが、このドキュメントはそれらのトレードオフについての議論を促進することを目的としており、それらの議論はすべて予備的なものとして理解されなければなりません。
It is possible, of course, to do nothing. The transport messages were not necessarily intended for consumption by on-path network elements, and encrypting them so they are not visible may be taken by some as a benefit. Each network element would then treat packets without these visible elements according to its own defaults. While our experience of that is not extensive, one consequence has been that state tables for flows of this type are generally not kept as long as those for which sessions are identifiable. The result is that heartbeat traffic must be maintained to keep any bindings (e.g., NAT or firewall) from early expiry. When those bindings are not kept, methods like a QUIC connection-id [QUIC] may be necessary to allow load balancers or other systems to continue to maintain a flow's path to the appropriate peer.
もちろん、何もすることはできません。トランスポートメッセージは、必ずしもパス上のネットワーク要素による消費を目的としたものではなく、それらを暗号化して見えないようにすることは、一部の人にとっては利点となる場合があります。次に、各ネットワーク要素は、これらの可視要素のないパケットを独自のデフォルトに従って処理します。これまでの経験は広範囲ではありませんが、1つの結果として、このタイプのフローのステートテーブルは、セッションが識別可能なものである限り、通常は保持されません。その結果、バインディング（NATやファイアウォールなど）が早期に期限切れにならないように、ハートビートトラフィックを維持する必要があります。これらのバインディングが維持されない場合、ロードバランサーまたは他のシステムが適切なピアへのフローのパスを維持し続けるために、QUIC connection-id [QUIC]などのメソッドが必要になる場合があります。
It would be possible to replace these implicit signals with explicit signals at the network layer. Though IPv4 has relatively few facilities for this, IPv6 hop-by-hop headers [RFC7045] might suit this purpose. Further examination of the deployability of these headers may be required.
これらの暗黙的な信号をネットワーク層で明示的な信号に置き換えることが可能です。 IPv4にはこのための機能は比較的少ないですが、IPv6ホップバイホップヘッダー[RFC7045]はこの目的に適している可能性があります。これらのヘッダーの展開可能性をさらに検討する必要がある場合があります。
It is possible to replace these implicit signals with signals that are tailored to specific transports, just as the initial signals are derived primarily from TCP. There is a risk here that the first transport that develops these will be reused for many purposes outside its stated purpose, simply because it traverses NATs and firewalls better than other traffic. If done with an explicit intent to reuse the elements of the solution in other transports, the risk of ossification might be slightly lower.
最初の信号が主にTCPから派生するのと同じように、これらの暗黙的な信号を特定のトランスポートに合わせて調整された信号に置き換えることができます。これらを開発する最初のトランスポートが、NATやファイアウォールを他のトラフィックよりも効率的に通過するという理由だけで、規定された目的以外の多くの目的で再利用されるリスクがあります。ソリューションの要素を他のトランスポートで再利用する明示的な目的で行われた場合、骨化のリスクはわずかに低くなる可能性があります。
Several proposals use UDP [RFC0768] as a demux layer, onto which new transport semantics are layered. For those transports, it may be possible to build a common signaling mechanism and set of signals, such as that proposed in "Transport-Independent Path Layer State Management" [PLUS].
いくつかの提案では、UDP [RFC0768]をdemux層として使用しており、その上に新しいトランスポートセマンティクスが階層化されています。これらのトランスポートについては、「トランスポートに依存しないパスレイヤーの状態管理」[PLUS]で提案されているような、共通のシグナリングメカニズムとシグナルのセットを構築することが可能な場合があります。
This may be taken as a variant of the reuse of common elements mentioned in the section above, but it has a greater chance of avoiding the ossification of the solution into the first moving protocol.
これは、上記のセクションで述べた一般的な要素の再利用の変形と見なすことができますが、最初の移動プロトコルへのソリューションの骨化を回避する可能性が高くなります。
The IAB urges protocol designers to design for confidential operation by default. We strongly encourage developers to include encryption in their implementations and to make them encrypted by default. We similarly encourage network and service operators to deploy encryption where it is not yet deployed, and we urge firewall policy administrators to permit encrypted traffic. One of the consequences of the change will be the loss of implicit signals.
IABは、プロトコル設計者がデフォルトで機密操作を行うように設計することを求めています。開発者には、実装に暗号化を組み込み、デフォルトで暗号化することを強くお勧めします。同様に、ネットワークおよびサービスオペレーターには暗号化がまだ配備されていない場所に暗号化を配備することを推奨し、ファイアウォールポリシー管理者には暗号化されたトラフィックを許可するように要請します。変更の結果の1つは、暗黙のシグナルの損失です。
Fundamentally, this document recommends that implicit signals should be avoided and that an implicit signal should be replaced with an explicit signal only when the signal's originator intends that it be used by the network elements on the path. For many flows, this may result in the signal being absent but allows it to be present when needed.
基本的に、このドキュメントでは、暗黙的な信号を回避し、暗黙的な信号を明示的な信号に置き換える必要があるのは、信号の発信者がパス上のネットワーク要素によって使用されることを意図している場合のみにしてください。多くのフローでは、これにより信号が存在しなくなる可能性がありますが、必要なときに存在することができます。
Discussion of the appropriate mechanism(s) for these signals is continuing, but at a minimum, any method should aim to adhere to these basic principles:
これらの信号の適切なメカニズムについての議論は続いていますが、少なくとも、どの方法でもこれらの基本原則を遵守することを目的とする必要があります。
o The portion of protocol signaling that is intended for end-system state machines should be protected by confidentiality and integrity protection such that it is only available to those end systems.
o エンドシステムステートマシンを対象とするプロトコルシグナリングの部分は、これらのエンドシステムでのみ使用できるように、機密性と整合性の保護によって保護する必要があります。
o Anything exposed to the path should be done with the intent that it be used by the network elements on the path. This information should be integrity protected, so that end systems can detect if path elements have made changes in flight.
o パスに公開されているものはすべて、パス上のネットワーク要素によって使用されることを意図して実行する必要があります。この情報は完全性を保護する必要があります。これにより、パス要素が処理中に変更を加えたかどうかをエンドシステムが検出できるようになります。
o Signals exposed to the path should be decoupled from signals that drive the protocol state machines in endpoints. This avoids creating opportunities for additional inference.
o パスに公開される信号は、エンドポイントのプロトコルステートマシンを駆動する信号から分離する必要があります。これにより、追加の推論の機会が作成されなくなります。
o Intermediate path elements should not add visible signals that identify the user, origin node, or origin network [RFC8164]. Note that if integrity protection is provided as suggested above, any signals added by intermediate path elements will be clearly distinguishable from those added by endpoints, as they will not be within the integrity-protected portion of the packet.
o 中間パス要素は、ユーザー、起点ノード、または起点ネットワーク[RFC8164]を識別する可視信号を追加してはなりません。上記のように完全性保護が提供されている場合、中間パス要素によって追加された信号は、パケットの完全性保護部分内にないため、エンドポイントによって追加された信号とは明確に区別されます。
The IAB notes that methods for allowing on-path actors to verify integrity protection are not available unless those actors have shared keys with the end systems or share a common set of trust points. As a result, integrity protection can generally be reliably applied by and verified only by endpoints.
IABは、パス上のアクターが整合性保護を検証できるようにする方法は、それらのアクターがエンドシステムと共有キーを持っているか、共通のトラストポイントのセットを共有していない限り利用できないと述べています。その結果、完全性保護は一般にエンドポイントによってのみ確実に適用および検証できます。
Verifying the authenticity of signals generated by on-path actors is similarly difficult. Endpoints that consume signals generated by on-path actors, particularly where those signals are unauthenticated, need to fully consider the implications of doing so. Managing the authentication of on-path signals is an area of active research, and defining or recommending methods for it is outside the scope of this document.
パス上のアクターによって生成された信号の信憑性を検証することも同様に困難です。パス上のアクターによって生成された信号を消費するエンドポイントは、特にそれらの信号が認証されていない場合、そうすることの影響を十分に考慮する必要があります。経路上の信号の認証の管理は活発な研究の領域であり、そのための方法の定義または推奨はこのドキュメントの範囲外です。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
Path-visible signals allow network elements along the path to act based on the signaled information, whether the signal is implicit or explicit. If the network element is controlled by an attacker, those actions can include dropping, delaying, or mishandling the constituent packets of a flow. An attacker may also characterize the flow or attempt to fingerprint the communicating nodes based on the pattern of signals.
パス可視信号は、信号が暗黙的であるか明示的であるかに関係なく、パスに沿ったネットワーク要素が信号情報に基づいて動作することを可能にします。ネットワーク要素が攻撃者によって制御されている場合、それらのアクションには、フローの構成パケットのドロップ、遅延、または誤った処理が含まれます。攻撃者はまた、フローを特徴付けるか、信号のパターンに基づいて通信ノードのフィンガープリントを試みる可能性があります。
Note that actions that do not benefit the flow or the network may be perceived as an attack even if they are conducted by a responsible network element. Designing a system that minimizes the ability to act on signals at all by removing as many signals as possible may reduce this possibility. This approach also comes with risks, principally that the actions will continue to take place on an arbitrary set of flows.
フローまたはネットワークに利益をもたらさないアクションは、責任のあるネットワーク要素によって実行されたとしても、攻撃として認識される可能性があることに注意してください。できるだけ多くの信号を削除することにより、信号に作用する能力を最小限に抑えるシステムを設計すると、この可能性を減らすことができます。このアプローチにはリスクも伴います。主に、アクションは任意のフローセットで引き続き発生します。
Addition of visible signals to the path also increases the information available to an observer and may, when the information can be linked to a node or user, reduce the privacy of the user.
パスに可視信号を追加すると、オブザーバーが利用できる情報も増え、情報をノードまたはユーザーにリンクできる場合、ユーザーのプライバシーが低下する可能性があります。
When signals from endpoints to the path are independent from the signals used by endpoints to manage the flow's state mechanics, they may be falsified by an endpoint without affecting the peer's understanding of the flow's state. For encrypted flows, this divergence is not detectable by on-path devices. The intent of this practice may be to garner improved treatment from the network or to avoid strictures. Protocol designers should be cautious when introducing explicit signals to consider how falsified signals would impact protocol operation and deployment. Similarly, operators should be cautious in deployments to be sure that default operation without these signals does not encourage gaming the system by providing false signals.
エンドポイントからパスへの信号が、フローの状態メカニズムを管理するためにエンドポイントで使用される信号から独立している場合、ピアがフローの状態を理解することに影響を与えることなく、エンドポイントによって信号が改ざんされる可能性があります。暗号化されたフローの場合、この分岐はパス上のデバイスでは検出できません。この実践の目的は、ネットワークからの改善された治療を獲得すること、または狭窄を回避することであるかもしれません。明示的な信号を導入する場合、プロトコルの設計者は、改ざんされた信号がプロトコルの動作と展開にどのように影響するかを検討する場合は注意が必要です。同様に、オペレーターは、これらの信号のないデフォルトの動作が誤った信号を提供することによってシステムのゲームを促進しないことを確認するために、デプロイメントで注意する必要があります。
[PLUS] Kuehlewind, M., Trammell, B., and J. Hildebrand, "Transport-Independent Path Layer State Management", Work in Progress, draft-trammell-plus-statefulness-04, November 2017.
[PLUS] Kuehlewind、M.、Trammell、B.、J。Hildebrand、「Transport-Independent Path Layer State Management」、Work in Progress、draft-trammell-plus-statefulness-04、2017年11月。
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", Work in Progress, draft-ietf-quic-transport-19, March 2019.
[QUIC]アイアンガー、J。、エド。 M.トムソン編、「QUIC：A UDPベースの多重化されたセキュアなトランスポート」、Work in Progress、draft-ietf-quic-transport-19、2019年3月。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.
[RFC0768] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<https://www.rfc-editor.org/info/rfc768>。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<https://www.rfc-editor.org/info/rfc793>。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, <https://www.rfc-editor.org/info/rfc1958>.
[RFC1958] Carpenter、B。、編、「インターネットのアーキテクチャ原則」、RFC 1958、DOI 10.17487 / RFC1958、1996年6月、<https://www.rfc-editor.org/info/rfc1958>。
[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>。
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, DOI 10.17487/RFC7045, December 2013, <https://www.rfc-editor.org/info/rfc7045>.
[RFC7045] Carpenter、B。およびS. Jiang、「IPv6拡張ヘッダーの送信と処理」、RFC 7045、DOI 10.17487 / RFC7045、2013年12月、<https://www.rfc-editor.org/info/rfc7045> 。
[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>。
[RFC8164] Nottingham, M. and M. Thomson, "Opportunistic Security for HTTP/2", RFC 8164, DOI 10.17487/RFC8164, May 2017, <https://www.rfc-editor.org/info/rfc8164>.
[RFC8164]ノッティンガム、M。およびM.トムソン、「HTTP / 2の日和見セキュリティ」、RFC 8164、DOI 10.17487 / RFC8164、2017年5月、<https://www.rfc-editor.org/info/rfc8164>。
IAB Members at the Time of Approval
承認時のIABメンバー
Jari Arkko Alissa Cooper Ted Hardie Christian Huitema Gabriel Montenegro Erik Nordmark Mark Nottingham Melinda Shore Robert Sparks Jeff Tantsura Martin Thomson Brian Trammell Suzanne Woolf
ジャリアルコアリッサクーパーテッドハーディクリスチャンウイテマガブリエルモンテネグロエリックノードマークマークノッティンガムメリンダショアロバートスパークスジェフタンツラマーティントムソンブライアントラメルスザンヌウルフ
Acknowledgements
謝辞
In addition to the editor listed in the header, this document incorporates contributions from Brian Trammell, Mirja Kuehlewind, Martin Thomson, Aaron Falk, Mohamed Boucadair, and Joe Hildebrand. These ideas were also discussed at the PLUS BoF, sponsored by Spencer Dawkins. The ideas around the use of IPv6 hop-by-hop headers as a network-layer signal benefited from discussions with Tom Herbert. The description of UDP as a demuxing protocol comes from Stuart Cheshire. Mark Smith, Kazuho Oku, Stephen Farrell, and Eliot Lear provided valuable comments on earlier draft versions of this document.
ヘッダーにリストされているエディターに加えて、このドキュメントには、Brian Trammell、Mirja Kuehlewind、Martin Thomson、Aaron Falk、Mohamed Boucadair、およびJoe Hildebrandからの寄稿が組み込まれています。これらのアイデアは、Spencer Dawkinsが後援するPLUS BoFでも議論されました。 IPv6ホップバイホップヘッダーをネットワーク層信号として使用することに関するアイデアは、トムハーバートとの議論から得られました。分離プロトコルとしてのUDPの説明は、Stuart Cheshireによるものです。 Mark Smith、Okazuho Oku、Stephen Farrell、およびEliot Learは、このドキュメントの以前のドラフトバージョンについて貴重なコメントを提供しました。
All errors are those of the editor.
すべてのエラーはエディターのエラーです。
Author's Address
著者のアドレス
Ted Hardie (editor)
テッド・ハーディ（編集者）
Email: ted.ietf@gmail.com