[要約] RFC 9419は、明示的なパスシグナルの設計原則について議論し、特定の有益なケースで標準化活動を求めています。このドキュメントの目的は、情報共有を最小限に抑えるために認証されたパスシグナルの設計を指針とすることです。
Internet Architecture Board (IAB) J. Arkko
Request for Comments: 9419 Ericsson
Category: Informational T. Hardie
ISSN: 2070-1721 Cisco
T. Pauly
Apple
M. Kühlewind
Ericsson
July 2023
This document discusses principles for designing mechanisms that use or provide path signals and calls for standards action in specific valuable cases. RFC 8558 describes path signals as messages to or from on-path elements and points out that visible information will be used whether or not it is intended as a signal. The principles in this document are intended as guidance for the design of explicit path signals, which are encouraged to be authenticated and include a minimal set of parties to minimize information sharing. These principles can be achieved through mechanisms like encryption of information and establishing trust relationships between entities on a path.
このドキュメントでは、特定の貴重なケースでパス信号を使用または提供するメカニズムを設計または提供する原則について説明します。RFC 8558は、パスシグナルをパスオンパス要素との間でのメッセージとして説明し、信号として意図されているかどうかにかかわらず、目に見える情報が使用されることを指摘します。このドキュメントの原則は、明示的なパス信号の設計のガイダンスとして意図されています。これは、情報共有を最小限に抑えるために、認証され、最小限のパーティーセットを含めることが奨励されています。これらの原則は、情報の暗号化や、パス上のエンティティ間の信頼関係を確立するなどのメカニズムを通じて達成できます。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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/rfc9419.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9419で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 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ドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
1. Introduction
2. Principles
2.1. Intentional Distribution
2.2. Control of the Distribution of Information
2.3. Protecting Information and Authentication
2.4. Minimize Information
2.5. Limiting Impact of Information
2.6. Minimum Set of Entities
2.7. Carrying Information
3. Further Work
4. IANA Considerations
5. Security Considerations
6. Informative References
IAB Members at the Time of Approval
Acknowledgments
Authors' Addresses
[RFC8558] defines the term "path signals" as signals to or from on-path elements. Today, path signals are often implicit; for example, they are derived from cleartext end-to-end information by, e.g., examining transport protocols. For instance, on-path elements use various fields of the TCP header [RFC9293] to derive information about end-to-end latency as well as congestion. These techniques have evolved because the information was available and its use required no coordination with anyone. This made such techniques more easily deployable than alternative, potentially more explicit or cooperative, approaches.
[RFC8558]は、「パス信号」という用語を、パス上の要素に対する信号として定義します。今日、パス信号はしばしば暗黙的です。たとえば、これらは、たとえば、輸送プロトコルを調べることにより、クリアテキストエンドツーエンド情報から派生しています。たとえば、オンパス要素は、TCPヘッダー[RFC9293]のさまざまなフィールドを使用して、エンドツーエンドのレイテンシと混雑に関する情報を導き出します。これらの手法は、情報が利用可能であり、その使用には誰とも調整を必要としないため、進化しました。これにより、このような技術は、代替、潜在的に明示的または協力的なアプローチよりも簡単に展開できました。
However, this also means that applications and networks have often evolved their interaction without comprehensive design for how this interaction should happen or which (minimal) information would be needed for a certain function. This has led to a situation where information that happens to be easily available is used instead of the information that is actually needed. As such, that information may be incomplete, incorrect, or only indirectly representative of the information that is actually needed. In addition, dependencies on information and mechanisms that were designed for a different function limit the evolvability of the protocols in question.
ただし、これはまた、アプリケーションとネットワークが、この相互作用がどのように発生するか、または特定の機能にどの（最小限の）情報が必要になるかについての包括的な設計なしに、相互作用を進化させることが多いことを意味します。これにより、実際に必要な情報の代わりに、たまたま簡単に利用できる情報が使用される状況につながりました。そのため、情報は不完全、間違っている、または実際に必要な情報を間接的に代表する場合があります。さらに、異なる関数のために設計された情報とメカニズムへの依存関係は、問題のプロトコルの進化性を制限します。
In summary, such unplanned interactions end up having several negative effects:
要約すると、このような計画外の相互作用は、いくつかのマイナス効果をもたらすことになります。
* Ossifying protocols by introducing dependencies to unintended parties that may not be updating, such as how middleboxes have limited the use of TCP options
* MiddleboxがTCPオプションの使用を制限した方法など、更新されない可能性のある意図しないパーティーに依存関係を導入することにより、プロトコルを閉鎖します
* Creating systemic incentives against deploying more secure or otherwise updated versions of protocols
* より安全なまたはその他の更新されたプロトコルの展開に対する全身的インセンティブの作成
* Basing network behavior on information that may be incomplete or incorrect
* 不完全または間違っている可能性のある情報に基づくネットワーク動作
* Creating a model where network entities expect to be able to use rich information about sessions passing through
* ネットワークエンティティが通過するセッションに関する豊富な情報を使用できることを期待するモデルを作成する
For instance, features such as DNS resolution or TLS setup have been used beyond their original intent, such as in name-based filtering. Media Access Control (MAC) addresses have been used for access control, captive portals have been used to take over cleartext HTTP sessions, and so on. (This document is not about whether those practices are good or bad; it is simply stating a fact that the features were used beyond their original intent.)
たとえば、DNS解像度やTLSセットアップなどの機能は、名前ベースのフィルタリングなど、元の意図を超えて使用されています。Media Access Control（MAC）アドレスは、アクセス制御に使用され、Captive PortalsはClearText HTTPセッションを引き継ぐために使用されています。（このドキュメントは、これらのプラクティスが良いか悪いかについてではありません。機能が元の意図を超えて使用されているという事実を単に述べています。）
Many protocol mechanisms throughout the stack fall into one of two categories: authenticated private communication that is only visible to a very limited set of parties, often one on each "end", and unauthenticated public communication that is visible to all network elements on a path.
スタック全体の多くのプロトコルメカニズムは、2つのカテゴリのいずれかに分類されます。非常に限られたパーティーのセットにのみ見える認証されたプライベートコミュニケーション、多くの場合、それぞれの「終了」と、パス上のすべてのネットワーク要素に表示される認識されていないパブリックコミュニケーション。
Exposed information encourages pervasive monitoring, which is described in [RFC7258]. It may also be used for commercial purposes or to form a basis for filtering that the applications or users do not desire. However, a lack of all path signaling, on the other hand, may limit network management, debugging, or the ability for networks to optimize their services. There are many cases where elements on the network path can provide beneficial services, but only if they can coordinate with the endpoints. It also affects the ability of service providers and others to observe why problems occur [RFC9075].
露出した情報は、[RFC7258]で説明されている広範な監視を促進します。また、商業目的で使用されたり、アプリケーションやユーザーが望んでいないフィルタリングの基礎を形成するために使用される場合があります。ただし、一方、すべてのパスシグナル伝達の欠如は、ネットワーク管理、デバッグ、またはネットワークがサービスを最適化する能力を制限する場合があります。ネットワークパス上の要素が有益なサービスを提供できる場合には、エンドポイントと調整できる場合のみがあります。また、問題が発生する理由を観察するサービスプロバイダーやその他の能力にも影響します[RFC9075]。
As such, this situation is sometimes cast as an adversarial trade-off between privacy and the ability for the network path to provide intended functions. However, this is perhaps an unnecessarily polarized characterization as a zero-sum situation. Not all information passing implies loss of privacy. For instance, performance information or preferences do not require disclosing the content being accessed, the user identity, or the application in use. Similarly, network congestion status information does not have to reveal network topology, the status of other users, and so on.
そのため、この状況は、プライバシーとネットワークパスが意図した機能を提供する能力との敵対的なトレードオフとしてキャストされることがあります。しかし、これはおそらくゼロサムの状況として不必要に偏光された特性評価です。すべての情報が合格することがプライバシーの損失を意味するわけではありません。たとえば、パフォーマンス情報や設定では、アクセスするコンテンツ、ユーザーID、または使用中のアプリケーションを開示する必要はありません。同様に、ネットワークの混雑ステータス情報は、ネットワークトポロジ、他のユーザーのステータスなどを明らかにする必要はありません。
Increased deployment of encryption is changing this situation. Encryption provides tools for controlling information access and protects against ossification by avoiding unintended dependencies and requiring active maintenance. The increased deployment of encryption provides an opportunity to reconsider parts of Internet architecture that have used implicit derivation of input signals for on-path functions rather than explicit signaling, as recommended by [RFC8558].
暗号化の展開の増加は、この状況を変えています。暗号化は、情報アクセスを制御するためのツールを提供し、意図しない依存関係を回避し、積極的なメンテナンスを必要とすることにより、骨化から保護します。暗号化の展開の増加は、[RFC8558]で推奨されるように、明示的なシグナリングではなく、パス上の関数の入力信号の暗黙的な導出を使用したインターネットアーキテクチャの一部を再考する機会を提供します。
For instance, QUIC replaces TCP for various applications and protects end-to-end signals so that they are only accessible by the endpoints, ensuring evolvability [RFC9000]. QUIC does expose information dedicated for on-path elements to consume by using explicit signals for specific use cases, such as the Spin Bit for latency measurements or connection ID that can be used by load balancers [RFC9312]. This information is accessible by all on-path devices, but information is limited to only those use cases. Each new use case requires additional action. This points to one way to resolve the adversity: the careful design of what information is passed.
たとえば、QUICはさまざまなアプリケーションにTCPを置き換え、エンドツーエンド信号を保護して、エンドポイントでのみアクセスできるようにし、進化性[RFC9000]を確保します。QUICは、パスオン要素が専用の情報を公開し、特定のユースケースに明示的な信号を使用して、ロードバランサー[RFC9312]が使用できるレイテンシ測定や接続IDなどのスピンビットなどです。この情報はすべてのオンパスデバイスでアクセスできますが、情報はそれらのユースケースのみに限定されます。新しいユースケースごとに追加のアクションが必要です。これは、逆境を解決する1つの方法、つまりどの情報が渡されるかの慎重な設計を示しています。
Another extreme is to employ explicit trust and coordination between specific entities, endpoints, and network path elements. VPNs are a good example of a case where there is an explicit authentication and negotiation with a network path element that is used to gain access to specific resources. Authentication and trust must be considered in both directions: how endpoints trust and authenticate signals from network path elements and how network path elements trust and authenticate signals from endpoints.
もう1つの極端なのは、特定のエンティティ、エンドポイント、およびネットワークパス要素間の明示的な信頼と調整を採用することです。VPNは、特定のリソースへのアクセスを得るために使用されるネットワークパス要素との明示的な認証とネゴシエーションがある場合の良い例です。認証と信頼は両方向に考慮する必要があります。エンドポイントがネットワークパス要素から信頼と認証方法、およびネットワークパス要素がエンドポイントから信号を信頼し、認証する方法。
The goal of improving privacy and trust on the Internet does not necessarily need to remove the ability for network elements to perform beneficial functions. We should instead improve the way that these functions are achieved and design new ways to support explicit collaboration where it is seen as beneficial. As such, our goals should be to:
インターネット上のプライバシーと信頼を改善するという目標は、必ずしもネットワーク要素が有益な機能を実行する能力を削除する必要はありません。代わりに、これらの機能が達成される方法を改善し、それが有益であると見なされる明示的なコラボレーションをサポートする新しい方法を設計する必要があります。そのため、私たちの目標は次のとおりです。
* ensure that information is distributed intentionally, not accidentally;
* 偶然ではなく、情報が意図的に配布されていることを確認してください。
* understand the privacy and other implications of any distributed information;
* 分散情報のプライバシーとその他の意味を理解する。
* ensure that the information distribution is limited to the intended parties; and
* 情報の分布が目的の当事者に限定されていることを確認します。そして
* gate the distribution of information on the participation of the relevant parties.
* 関連当事者の参加に関する情報の配布にゲートをかけます。
These goals for exposure and distribution apply equally to senders, receivers, and path elements.
露出と流通に関するこれらの目標は、送信者、レシーバー、パス要素に等しく適用されます。
Going forward, new standards work in the IETF needs to focus on addressing this gap by providing better alternatives and mechanisms for building functions that require some collaboration between endpoints and path elements.
今後、IETFでの新しい標準は、エンドポイントとパス要素の間のコラボレーションを必要とする機能を構築するためのより良い代替案とメカニズムを提供することにより、このギャップへの対処に焦点を合わせる必要があります。
We can establish some basic questions that any new network function should consider:
新しいネットワーク機能が考慮すべきいくつかの基本的な質問を確立できます。
* Which entities must consent to the information exchange?
* 情報交換に同意しなければならないエンティティはどれですか？
* What is the minimum information each entity in this set needs?
* このセットの各エンティティが必要とする最小情報は何ですか？
* What is the effect that new signals should have?
* 新しい信号が持つべき効果は何ですか？
* What is the minimum set of entities that need to be involved?
* 関与する必要があるエンティティの最小セットは何ですか？
* What are the right mechanism and needed level of trust to convey this kind of information?
* この種の情報を伝えるために正しいメカニズムと必要な信頼レベルは何ですか？
If we look at ways network functions are achieved today, we find that many, if not most of them, fall short of the standard set up by the questions above. Too often, they send unnecessary information, fail to limit the scope of distribution, or fail to provide any negotiation or consent.
ネットワーク関数が今日達成される方法を見ると、それらのほとんどではないにしても、上記の質問によって設定された標準に達していないことがわかります。多くの場合、不要な情報を送信したり、配布の範囲を制限したり、交渉や同意を提供したりできません。
Designing explicit signals between applications and network elements, and ensuring that all information is appropriately protected, enables information exchange in both directions that is important for improving the quality of experience and network management. The clean separation provided by explicit signals is also more conducive to protocol evolvability.
アプリケーションとネットワーク要素の間に明示的な信号を設計し、すべての情報が適切に保護されていることを確認することで、エクスペリエンスの質とネットワーク管理の質を向上させるために重要な両方向で情報交換が可能になります。明示的な信号によって提供されるクリーンな分離も、プロトコルの進化性をより助長します。
Beyond the recommendation in [RFC8558], the IAB has provided further guidance on protocol design. Among other documents, [RFC5218] provides general advice on incremental deployability based on an analysis of successes and failures, and [RFC6709] discusses protocol extensibility. The Internet Technology Adoption and Transition (ITAT) workshop report [RFC7305] is also a recommended reading on this same general topic. [RFC9049], an IRTF document, provides a catalog of past issues to avoid and discusses incentives for adoption of path signals such as the need for outperforming end-to-end mechanisms or considering per-connection state.
[RFC8558]の推奨事項を超えて、IABはプロトコル設計に関するさらなるガイダンスを提供しました。他のドキュメントの中でも、[RFC5218]は、成功と障害の分析に基づいた増分展開性に関する一般的なアドバイスを提供し、[RFC6709]はプロトコルの拡張性について説明します。インターネットテクノロジーの採用および移行（ITAT）ワークショップレポート[RFC7305]も、この同じ一般的なトピックについて推奨される読み物です。[RFC9049]は、IRTFドキュメントであり、エンドツーエンドのメカニズムをアウトパフォーマンスする必要性や接続ごとの状態を考慮するなど、パス信号の採用のインセンティブを回避および議論する過去の問題のカタログを提供します。
This document discusses different approaches for explicit collaboration and provides guidance on architectural principles to design new mechanisms. Section 2 discusses principles that good design can follow. This section also provides examples and explores the consequences of not following these principles in those examples. Section 3 points to topics that need to be looked at more carefully before any guidance can be given.
このドキュメントは、明示的なコラボレーションのためのさまざまなアプローチについて説明し、新しいメカニズムを設計するための建築原則に関するガイダンスを提供します。セクション2では、優れたデザインが従うことができる原則について説明します。また、このセクションでは、これらの例ではこれらの原則に従わないことの結果を調査し、調査します。セクション3では、ガイダンスを提供する前に、より慎重に検討する必要があるトピックを指します。
This section provides architecture-level principles for protocol designers and recommends models to apply for network collaboration and signaling.
このセクションでは、プロトコル設計者のアーキテクチャレベルの原則を提供し、ネットワークコラボレーションとシグナリングを申請するモデルを推奨しています。
While [RFC8558] focuses specifically on communication to "on-path elements", the principles described in this document apply potentially to:
[RFC8558]は特に「パスオン要素」へのコミュニケーションに焦点を当てていますが、このドキュメントに記載されている原則は次のように適用される可能性があります。
* on-path signaling (in either direction) and
* オンパス信号（どちらの方向）と
* signaling with other elements in the network that are not directly on-path but still influence end-to-end connections.
* ネットワーク内の他の要素とのシグナル伝達は、直接パスではなく、エンドツーエンドの接続に影響を与えます。
An example of on-path signaling is communication between an endpoint and a router on a network path. An example of signaling with another network element is communication between an endpoint and a network-assigned DNS server, firewall controller, or captive portal API server. Note that these communications are conceptually independent of the base flow, even if they share a packet; they are coming from and going to other parties, rather than creating a multiparty communication.
オンパスシグナル伝達の例は、エンドポイントとネットワークパス上のルーターとの間の通信です。別のネットワーク要素を使用したシグナリングの例は、エンドポイントとネットワークが割り当てられたDNSサーバー、ファイアウォールコントローラー、またはキャプティブポータルAPIサーバーの間の通信です。これらの通信は、パケットを共有していても、ベースフローから概念的に独立していることに注意してください。彼らは、マルチパーティコミュニケーションを作成するのではなく、他の関係者から来て行きます。
Taken together, these principles focus on the inherent privacy and security concerns of sharing information between endpoints and network elements, emphasizing that careful scrutiny and a high bar of consent and trust need to be applied. Given the known threat of pervasive monitoring, the application of these principles is critical to ensuring that the use of path signals does not create a disproportionate opportunity for observers to extract new data from flows.
まとめると、これらの原則は、エンドポイントとネットワーク要素間で情報を共有するという固有のプライバシーとセキュリティの懸念に焦点を当てており、慎重な精査と高い同意と信頼の基準を適用する必要があることを強調しています。普及している監視の既知の脅威を考えると、これらの原則の適用は、パス信号の使用が、観察者がフローから新しいデータを抽出する不均衡な機会を生み出さないことを保証するために重要です。
The following guideline is best expressed in [RFC8558]:
次のガイドラインは[RFC8558]で最もよく表現されています。
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.
基本的に、このドキュメントは、暗黙の信号を避ける必要があり、信号のオリジネーターがパス上のネットワーク要素によって使用されることを意図している場合にのみ、暗黙の信号を明示的な信号に置き換える必要があることを推奨しています。多くのフローでは、これにより信号が不在になる可能性がありますが、必要に応じて存在することができます。
The goal is that any information should be provided knowingly, for a specific purpose, sent in signals designed for that purpose, and that any use of information should be done within that purpose. In addition, an analysis of the security and privacy implications of the specific purpose and associated information is needed.
目標は、特定の目的のために、その目的のために設計された信号で送信される情報を故意に提供する必要があり、情報の使用はその目的の範囲内で行う必要があることです。さらに、特定の目的と関連情報のセキュリティとプライバシーへの影響の分析が必要です。
This guideline applies in the network element to application direction as well: a network element should not unintentionally leak information. While this document makes recommendations that are applicable to many different situations, it is important to note that the above call for careful analysis is key. Different types of information, applications, and directions of communication influence the analysis and can lead to very different conclusions about what information can be shared and with whom. For instance, it is easy to find examples of information that applications should not share with network elements (e.g., content of communications) or that network elements should not share with applications (e.g., detailed user location in a wireless network). But, equally, information about other things, such as the onset of congestion, should be possible to share and can be beneficial information to all parties.
このガイドラインは、ネットワーク要素にアプリケーションの方向にも適用されます。ネットワーク要素は、意図せずに漏れてはいけません。このドキュメントは、さまざまな状況に適用できる推奨事項を作成しますが、慎重な分析を求める上記の呼び出しが重要であることに注意することが重要です。さまざまな種類の情報、アプリケーション、およびコミュニケーションの方向は、分析に影響を与え、どの情報を共有できるかについて非常に異なる結論につながる可能性があります。たとえば、アプリケーションがネットワーク要素（通信のコンテンツなど）と共有すべきではない情報の例や、ネットワーク要素がアプリケーション（例えば、ワイヤレスネットワークの詳細なユーザーの場所）と共有すべきではないという情報の例を簡単に見つけることができます。しかし、同様に、混雑の発症など、他の事柄に関する情報は、共有できる必要があり、すべての関係者にとって有益な情報になることができます。
Intentional distribution is a precondition for explicit collaboration that enables each entity to have the highest possible level of control about what information to share.
意図的な分布は、各エンティティが共有する情報について可能な限り最高レベルの制御を持つことを可能にする明示的なコラボレーションの前提条件です。
Explicit signals are not enough. The entities also need to agree to exchange the information. Trust and mutual agreement between the involved entities must determine the distribution of information in order to give each entity adequate control over the collaboration or information sharing. This can be achieved as discussed below.
明示的な信号では十分ではありません。エンティティはまた、情報を交換することに同意する必要があります。関係するエンティティ間の信頼と相互合意は、各エンティティにコラボレーションまたは情報共有を適切に制御できるようにするために、情報の分布を決定する必要があります。これは、以下で説明するように達成できます。
The sender needs to decide that it is willing to send information to a specific entity or set of entities. Any passing of information or request for an action needs to be explicit and use signaling mechanisms that are designed for the purpose. Merely sending a particular kind of packet to a destination should not be interpreted as an implicit agreement.
送信者は、特定のエンティティまたはエンティティセットに情報を送信する意思があると判断する必要があります。情報の合格またはアクションの要求は、目的のために設計されたシグナル伝達メカニズムを明示的に使用する必要があります。特定の種類のパケットを宛先に送信するだけで、暗黙の合意として解釈されるべきではありません。
At the same time, the recipient of information or the target of a request should have the option to agree or deny to receiving the information. It should not be burdened with extra processing if it does not have willingness or a need to do so. This happens naturally in most protocol designs, but it has been a problem for some cases where "slow path" packet processing is required or implied, and the recipient or router is not willing to handle it. Performance impacts like this are best avoided, however.
同時に、情報の受信者またはリクエストのターゲットには、情報の受信を同意または拒否するオプションが必要です。意欲やそうする必要性がない場合、追加の処理に負担をかけるべきではありません。これは、ほとんどのプロトコル設計で自然に発生しますが、「遅いパス」パケット処理が必要または暗示されており、レシピエントまたはルーターがそれを処理する意思がない場合には問題となっています。ただし、このようなパフォーマンスの影響は回避するのが最善です。
In any case, all involved entities must be identified and potentially authenticated if trust is required as a prerequisite to share certain information.
いずれにせよ、特定の情報を共有するための前提条件として信頼が必要である場合、関係するすべてのエンティティを特定し、潜在的に認証する必要があります。
Many Internet communications are not performed on behalf of the applications but are ultimately made on behalf of users. However, not all information that may be shared directly relates to user actions or other sensitive data. All shared information must be evaluated carefully to identify potential privacy implications for users. Information that directly relates to the user should not be shared without the user's consent. It should be noted that the interests of the user and other parties, such as the application developer, may not always coincide; some applications may wish to collect more information about the user than the user would like. As discussed in [RFC8890], from an IETF point of view, the interests of the user should be prioritized over those of the application developer. The general issue of how to achieve a balance of control between the actual user and an application representing a user's interest is out of scope for this document.
多くのインターネット通信は、アプリケーションに代わって実行されませんが、最終的にはユーザーに代わって行われます。ただし、直接共有される可能性のあるすべての情報がユーザーアクションまたは他の機密データに関連するわけではありません。すべての共有情報は、ユーザーのプライバシーへの潜在的な影響を特定するために慎重に評価する必要があります。ユーザーに直接関係する情報は、ユーザーの同意なしに共有されるべきではありません。アプリケーション開発者などのユーザーや他の当事者の関心は、常に一致するとは限らないことに注意する必要があります。一部のアプリケーションでは、ユーザーが望むよりも多くの情報をユーザーに関する情報を収集したい場合があります。[RFC8890]で説明したように、IETFの観点から、ユーザーの関心はアプリケーション開発者の利益よりも優先されるべきです。実際のユーザーとユーザーの関心を表すアプリケーションとの間の制御のバランスを達成する方法の一般的な問題は、このドキュメントの範囲外です。
Some simple forms of information often exist in cleartext form, e.g., Explicit Congestion Notification (ECN) bits from routers are generally not authenticated or integrity protected. This is possible when the information exchanges do not carry any significantly sensitive information from the parties. Often, these kinds of interactions are also advisory in their nature (see Section 2.5).
いくつかの単純な形式の情報は、多くの場合、クリアテキスト形式で存在します。たとえば、ルーターからの明示的な輻輳通知（ECN）ビットは、一般に認証されていないか、整合性保護されていません。これは、情報交換が当事者からの重要な機密情報を持ち込んでいない場合に可能です。多くの場合、これらの種類の相互作用は、その性質上のアドバイザリーでもあります（セクション2.5を参照）。
In other cases, it may be necessary to establish a secure signaling channel for communication with a specific other party, e.g., between a network element and an application. This channel may need to be authenticated, integrity protected, and confidential. This is necessary, for instance, if the particular information or request needs to be shared in confidence only with a particular, trusted network element or endpoint or if there is danger of an attack where someone else may forge messages that could endanger the communication.
それ以外の場合は、特定の他者との通信、たとえばネットワーク要素とアプリケーションの間の安全なシグナリングチャネルを確立する必要がある場合があります。このチャネルは、認証され、整合性保護され、機密が必要な場合があります。これは、特定の情報またはリクエストを特定の信頼できるネットワーク要素またはエンドポイントとのみ自信を持って共有する必要がある場合、または他の誰かがコミュニケーションを危険にさらす可能性のあるメッセージを偽造する可能性のある攻撃の危険がある場合に必要です。
Authenticated integrity protections on signaled data can help ensure that data received in a signal has not been modified by other parties. Still, both network elements and endpoints need to be careful in processing or responding to any signal. Whether through bugs or attacks, the content of path signals can lead to unexpected behaviors or security vulnerabilities if not properly handled. As a result, the advice in Section 2.5 still applies even in situations where there's a secure channel for sending information.
信号データの認証された整合性保護は、信号で受信されたデータが他の当事者によって変更されていないことを保証するのに役立ちます。それでも、ネットワーク要素とエンドポイントの両方が、どの信号の処理または応答に注意する必要があります。バグを介して攻撃を通じて、パス信号の内容は、適切に処理されないと、予期しない動作やセキュリティの脆弱性につながる可能性があります。その結果、セクション2.5のアドバイスは、情報を送信するための安全なチャネルがある状況でも適用されます。
However, it is important to note that authentication does not equal trust. Whether a communication is with an application server or network element that can be shown to be associated with a particular domain name, it does not follow that information about the user can be safely sent to it.
ただし、認証は信頼に匹敵しないことに注意することが重要です。通信が特定のドメイン名に関連付けられていることが示されるアプリケーションサーバーまたはネットワーク要素を使用しているかどうかにかかわらず、ユーザーに関する情報を安全に送信できることは従いません。
In some cases, the ability of a party to show that it is on the path can be beneficial. For instance, an ICMP error that refers to a valid flow may be more trustworthy than any ICMP error claiming to come from an address.
場合によっては、それが道にいることを示す当事者の能力が有益である可能性があります。たとえば、有効なフローを指すICMPエラーは、アドレスから来ると主張するICMPエラーよりも信頼できる場合があります。
Other cases may require more substantial assurances. For instance, a specific trust arrangement may be established between a particular network and application. Or technologies, such as confidential computing, can be applied to provide an assurance that information processed by a party is handled in an appropriate manner.
他のケースでは、より大きな保証が必要になる場合があります。たとえば、特定のネットワークとアプリケーションの間に特定の信頼の取り決めが確立される場合があります。または、機密コンピューティングなどのテクノロジーを適用して、当事者によって処理された情報が適切な方法で処理されるという保証を提供することができます。
Each party should provide only the information that is needed for the other parties to perform the task for which collaboration is desired and no more. This applies to information sent by an application about itself, sent about users, or sent by the network. This also applies to any information related to flow identification.
各当事者は、他の当事者がコラボレーションが望まれていないタスクを実行するために必要な情報のみを提供する必要があります。これは、アプリケーションから送信された情報、ユーザーに関するもの、またはネットワークによって送信された情報に適用されます。これは、フロー識別に関連する情報にも適用されます。
An architecture can follow the guideline from [RFC8558] in using explicit signals but still fail to differentiate properly between information that should be kept private and information that should be shared. [RFC6973] also outlines this principle of data minimization as a mitigation technique to protect privacy and provides further guidance.
アーキテクチャは、[RFC8558]のガイドラインに従って、明示的な信号を使用していますが、プライベートに保つべき情報と共有すべき情報を適切に区別できません。[RFC6973]は、プライバシーを保護するための緩和手法としてのデータ最小化の原則を概説し、さらなるガイダンスを提供します。
In looking at what information can or cannot be easily passed, we need to consider both information from the network to the application and from the application to the network.
情報を簡単に渡すことができる、または簡単に渡すことができるかどうかを見ると、ネットワークからアプリケーション、およびアプリケーションからネットワークへの両方の情報を考慮する必要があります。
For the application-to-network direction, user-identifying information can be problematic for privacy and tracking reasons. Similarly, application identity can be problematic if it might form the basis for prioritization or discrimination that the application provider may not wish to happen.
アプリケーションからネットワークへの方向性については、ユーザーを特定する情報は、プライバシーと追跡上の理由に問題がある可能性があります。同様に、アプリケーションプロバイダーが発生したくない可能性のある優先順位付けまたは差別の基礎を形成する可能性がある場合、アプリケーションのIDは問題になる可能性があります。
On the other hand, as noted above, information about general classes of applications may be desirable to be given by application providers if it enables prioritization that would improve service, e.g., differentiation between interactive and non-interactive services.
一方、上記のように、アプリケーションの一般的なクラスに関する情報は、サービスを改善する優先順位付けを可能にする場合、アプリケーションプロバイダーが提供することが望ましい場合があります。
For the network-to-application direction, there is similarly sensitive information, such as the precise location of the user. On the other hand, various generic network conditions, predictive bandwidth and latency capabilities, and so on might be attractive information that applications can use to determine, for instance, optimal strategies for changing codecs. However, information given by the network about load conditions and so on should not form a mechanism to provide a side channel into what other users are doing.
ネットワーク間の方向には、ユーザーの正確な場所など、同様に機密情報があります。一方、さまざまな一般的なネットワーク条件、予測帯域幅、潜伏能力など、アプリケーションがコーデックを変更するための最適な戦略を決定するために使用できる魅力的な情報かもしれません。ただし、負荷条件などについてネットワークから提供された情報は、他のユーザーが行っていることにサイドチャネルを提供するメカニズムを形成すべきではありません。
While information needs to be specific and provided on a per-need basis, it is often beneficial to provide declarative information that, for instance, expresses application needs and then makes specific requests for action.
情報は具体的であり、必要に応じて提供される必要がありますが、たとえばアプリケーションのニーズを表現し、具体的なアクションの要求を行う宣言的な情報を提供することが有益であることがよくあります。
Information shared between a network element and an endpoint of a connection needs to have a limited impact on the behavior of both endpoints and network elements. Any action that an endpoint or network element takes based on a path signal needs to be considered appropriately based on the level of authentication and trust that has been established, and it needs to be scoped to a specific network path.
ネットワーク要素と接続のエンドポイントとの間で共有される情報は、エンドポイントとネットワーク要素の両方の動作に制限された影響を与える必要があります。パス信号に基づいてエンドポイントまたはネットワーク要素がとるアクションは、確立された認証と信頼のレベルに基づいて適切に考慮する必要があり、特定のネットワークパスにスコープする必要があります。
For example, an ICMP signal from a network element to an endpoint can be used to influence future behavior on that particular network path (such as changing the effective packet size or closing a path-specific connection) but should not be able to cause a multipath or migration-capable transport connection to close.
たとえば、ネットワーク要素からエンドポイントへのICMP信号を使用して、その特定のネットワークパス（効果的なパケットサイズの変更やパス固有の接続の閉鎖など）で将来の動作に影響を与えることができますが、マルチパスを引き起こすことはできませんまたは、閉鎖への移行対応輸送接続。
In many cases, path signals can be considered advisory information, with the effect of optimizing or adjusting the behavior of connections on a specific path. In the case of a firewall blocking connectivity to a given host, endpoints should only interpret that as the host being unavailable on that particular path; this is in contrast to an end-to-end authenticated signal, such as a DNSSEC-authenticated denial of existence [RFC7129].
多くの場合、特定のパスでの接続の動作を最適化または調整する効果とともに、パス信号をアドバイザリー情報と見なすことができます。特定のホストへの接続をブロックするファイアウォールの場合、エンドポイントは、その特定のパスでホストが利用できないと解釈する必要があります。これは、DNSSECの認識存在の拒否[RFC7129]など、エンドツーエンドの認証された信号とは対照的です。
It is recommended that a design identifies the minimum number of entities needed to share a specific signal required for an identified function.
設計では、特定された関数に必要な特定の信号を共有するために必要なエンティティの最小数を識別することをお勧めします。
Often, this will be a very limited set, such as when an application only needs to provide a signal to its peer at the other end of the connection or a host needs to contact a specific VPN gateway. In other cases, a broader set is needed, such as when explicit or implicit signals from a potentially unknown set of multiple routers along the path inform the endpoints about congestion.
多くの場合、これは非常に限られたセットになります。たとえば、アプリケーションが接続のもう一方の端でピアに信号を提供する必要がある場合、または特定のVPNゲートウェイに連絡する必要がある場合などです。他の場合には、パスに沿った潜在的に未知の複数のルーターのセットからの明示的または暗黙的な信号が、輻輳についてエンドポイントに通知する場合など、より広いセットが必要です。
While it is tempting to consider removing these limitations in the context of closed, private networks, each interaction is still best considered separately, rather than simply allowing all information exchanges within the closed network. Even in a closed network with carefully managed elements, there may be compromised components, as evidenced in the most extreme way by the Stuxnet worm that operated in an air-gapped network. Most "closed" networks have at least some needs and means to access the rest of the Internet and should not be modeled as if they had an impenetrable security barrier.
閉じたプライベートネットワークのコンテキストでこれらの制限を削除することを検討するのは魅力的ですが、閉じたネットワーク内のすべての情報交換を単純に許可するのではなく、それぞれの相互作用が個別に考慮されるのが最適です。慎重に管理された要素を備えた閉じたネットワークでさえ、エアギャップされたネットワークで動作したStuxNetワームによって最も極端な方法で証明されるように、妥協したコンポーネントが存在する可能性があります。ほとんどの「クローズド」ネットワークには、少なくともインターネットの残りの部分にアクセスするためのいくつかのニーズと手段があり、不可解なセキュリティ障壁があるかのようにモデル化されるべきではありません。
There is a distinction between what information is sent and how it is sent. The information that is actually sent may be limited, while the mechanisms for sending or requesting information can be capable of sharing much more.
送信される情報と送信方法との間には区別があります。実際に送信される情報は制限される場合がありますが、情報を送信または要求するメカニズムは、より多くの共有を可能にすることができます。
There is a trade-off here between flexibility and ensuring that the information is minimal in the future. The concern is that a fully generic data-sharing approach between different layers and parties could potentially be misused, e.g., by making the availability of some information a requirement for passing through a network, such as making it mandatory to identify specific applications or users. This is undesirable.
ここでは、柔軟性と将来情報が最小限に抑えられるようにすることとの間にトレードオフがあります。懸念は、たとえば、特定のアプリケーションまたはユーザーを特定するために必須にするなど、ネットワークを通過するための要件をいくつかの情報に入手できるようにすることにより、異なるレイヤーとパーティーの間の完全な一般的なデータ共有アプローチが潜在的に誤用される可能性があることです。これは望ましくありません。
This document recommends that signaling mechanisms that send information be built to specifically support sending the necessary, minimal set of information (see Section 2.4) and no more. As previously noted, flow-identifying information is a path signal in itself, and as such, provisioning of flow identifiers also requires protocol-specific analysis.
このドキュメントでは、情報を送信するシグナリングメカニズムを構築するために、必要な最小限の情報セットを送信することを具体的にサポートするように構築されることを推奨しています（セクション2.4を参照）。前述のように、フロー識別情報はそれ自体がパス信号であるため、フロー識別子のプロビジョニングにはプロトコル固有の分析も必要です。
Further, such mechanisms also need to have the ability to establish an agreement (see Section 2.2) and sufficient trust to pass the information (see Section 2.3).
さらに、このようなメカニズムは、合意を確立する能力（セクション2.2を参照）と情報を渡すのに十分な信頼を持つ必要があります（セクション2.3を参照）。
This is a developing field, and it is expected that our understanding of it will continue to grow. One recent change is much higher use of encryption at different protocol layers. This obviously impacts the field greatly, by removing the ability to use most implicit signals. However, it may also provide new tools for secure collaboration and force a rethinking of how collaboration should be performed.
これは発展途上の分野であり、私たちの理解が成長し続けることが期待されています。最近の1つの変更は、異なるプロトコル層での暗号化のはるかに高い使用です。これは、最も暗黙の信号を使用する能力を削除することにより、明らかにフィールドに大きな影響を与えます。ただし、安全なコラボレーションのための新しいツールを提供し、コラボレーションの実行方法を再考することもできます。
While there are some examples of modern, well-designed collaboration mechanisms, the list of examples is not long. Clearly, more work is needed if we wish to realize the potential benefits of collaboration in further cases. This requires a mindset change, a migration away from using implicit signals. And of course we need to choose such cases where the collaboration can be performed safely, where it is not a privacy concern, and where the incentives of the relevant parties are aligned. It should also be noted that many complex cases would require significant developments in order to become feasible.
近代的で適切に設計されたコラボレーションメカニズムの例がいくつかありますが、例のリストは長くありません。明らかに、さらなるケースでコラボレーションの潜在的な利点を実現したい場合は、より多くの作業が必要です。これには、考え方の変更、暗黙の信号の使用からの移行が必要です。そしてもちろん、コラボレーションを安全に実行できる、それがプライバシーの懸念ではない場合、および関連当事者のインセンティブが一致する場合、そのようなケースを選択する必要があります。また、多くの複雑なケースが実行可能になるためには重要な開発が必要になることに注意する必要があります。
Some of the most difficult areas are listed below. Research on these topics would be welcome. Note that the topics include both those dealing directly with on-path network element collaboration and some adjacent issues that would influence such collaboration.
最も難しい領域のいくつかを以下に示します。これらのトピックに関する研究は大歓迎です。このトピックには、オンパスネットワーク要素のコラボレーションを直接扱うものと、そのようなコラボレーションに影響を与える隣接する問題の両方が含まれていることに注意してください。
* Some forms of collaboration may depend on business arrangements, which may or may not be easy to put in place. For instance, some quality-of-service mechanisms involve an expectation of paying for a service. This is possible and has been successful within individual domains, e.g., users can pay for higher data rates or data caps in their ISP networks. However, it is a business-wise proposition that is much harder for end-to-end connections across multiple administrative domains [Claffy2015] [RFC9049].
* いくつかの形式のコラボレーションは、ビジネスの取り決めに依存する場合があります。たとえば、一部のサービス品質メカニズムには、サービスの支払いが期待されることが含まれます。これは可能であり、個々のドメイン内で成功しています。たとえば、ユーザーはISPネットワークのより高いデータレートまたはデータキャップに対して支払うことができます。ただし、複数の管理ドメイン[Claffy2015] [RFC9049]にわたるエンドツーエンドの接続にとってはるかに困難なのは、ビジネス上の提案です。
* Secure communication with path elements is needed as discussed in Section 2.3. Finding practical ways for this has been difficult, both from the mechanics and scalability point of view, partially because there is no easy way to find out which parties to trust or what trust roots would be appropriate. Some application-network element interaction designs have focused on information (such as ECN bits) that is distributed openly within a path, but there are limited examples of designs with secure information exchange with specific network elements or endpoints.
* セクション2.3で説明したように、パス要素との安全な通信が必要です。これのための実用的な方法を見つけることは、メカニズムとスケーラビリティの観点からの両方から困難でした。これは、どの関係者を信頼するか、どのようなルーツが適切かを見つける簡単な方法がないためです。いくつかのアプリケーションネットワークの相互作用設計は、パス内に公然と配布される情報（ECNビットなど）に焦点を当てていますが、特定のネットワーク要素またはエンドポイントを使用した安全な情報交換を備えたデザインの例は限られています。
* The use of path signals to reduce the effects of denial-of-service attacks, e.g., perhaps modern forms of "source quench" designs, could be developed. The difficulty is finding a solution that would be both effective against attacks and would not enable third parties from slowing down or censoring someone else's communication.
* パス信号を使用して、サービス拒否攻撃の影響を軽減すること、たとえば、おそらく「ソースクエンチ」デザインの現代形式を開発することができます。難しさは、攻撃に対して効果的であり、第三者が他の誰かのコミュニケーションを減速または検閲することを可能にしないソリューションを見つけることです。
* Work has begun on mechanisms that dissociate the information held by servers from knowledge of the user's network location and behavior. Among the solutions that exist for this but are not widely deployed are [Oblivious] [PDoT] [DNS-CONFIDENTIAL] [HTTP-OBLIVIOUS]. These solutions address specific parts of the issue, and more work remains to find ways to limit the spread of information about the user's actions. Host applications currently share sensitive information about the user's action with a variety of infrastructure and path elements, starting from basic data, such as domain names, source and destination addresses, and protocol header information. This can expand to detailed end-user identity and other information learned by the servers. Work to protect all of this information is needed.
* ユーザーのネットワークの位置と動作の知識からサーバーが保持している情報を分離するメカニズムに関する作業が開始されました。このために存在するが広く展開されていないソリューションの中には、[忘れられない] [pdot] [dns-confidential] [http-oblivious]があります。これらのソリューションは、問題の特定の部分に対処しており、ユーザーのアクションに関する情報の拡散を制限する方法を見つけるためにより多くの作業が残っています。ホストアプリケーションは現在、ドメイン名、ソースおよび宛先アドレス、プロトコルヘッダー情報などの基本データから始まるさまざまなインフラストラクチャおよびパス要素と、ユーザーのアクションに関する機密情報を共有しています。これにより、詳細なエンドユーザーIDや、サーバーが学習したその他の情報に拡張できます。このすべての情報を保護するための作業が必要です。
* Work is needed to explore how to increase the deployment of mechanisms for sharing information from networks to applications. There are some working examples of this, e.g., ECN. A few other proposals have been made (see, e.g., [MOBILE-THROUGHPUT-GUIDANCE]), but very few of those have seen deployment.
* ネットワークからアプリケーションまで情報を共有するためのメカニズムの展開を増やす方法を探るために作業が必要です。これのいくつかの実用的な例、例えばECN。他のいくつかの提案がなされています（[モバイルスループット誘導]を参照）が、展開を見たものはほとんどありません。
* Additional work on sharing information from applications to networks would also be valuable. There are a few working examples of this (see Section 1). Numerous proposals have been made in this space, but most of them have not progressed through standards or been deployed for a variety of reasons [RFC9049]. However, several current or recent proposals exist, such as [NETWORK-TOKENS].
* アプリケーションからネットワークへの情報を共有するための追加作業も価値があります。これにはいくつかの作業例があります（セクション1を参照）。この分野では多くの提案がなされていますが、それらのほとんどは標準を経て進歩していないか、さまざまな理由で展開されていません[RFC9049]。ただし、[ネットワークトケン]など、いくつかの現在または最近の提案が存在します。
* Data privacy regimes generally deal with multiple issues, not just whether or not some information is shared with another party. For instance, there may be rules regarding how long information can be stored or what purpose that information may be used for. Similar issues may also be applicable to the kind of information sharing discussed in this document.
* データプライバシー体制は一般に、一部の情報が他の当事者と共有されるかどうかだけでなく、複数の問題を扱っています。たとえば、情報を保存できる期間、またはその情報を使用できる目的に関するルールがある場合があります。同様の問題は、このドキュメントで議論されている情報共有の種類にも適用される場合があります。
* The present work has focused on the technical aspects of making collaboration safe and mutually beneficial, but of course, deployments need to take into account various regulatory and other policy matters. These include privacy regulation, competitive issues, network neutrality aspects, and so on.
* 現在の研究は、コラボレーションを安全で相互に有益にするための技術的側面に焦点を当てていますが、もちろん、展開はさまざまな規制およびその他の政策問題を考慮に入れる必要があります。これらには、プライバシー規制、競争上の問題、ネットワーク中立性の側面などが含まれます。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
This document has no security considerations.
このドキュメントにはセキュリティ上の考慮事項はありません。
[Claffy2015]
Claffy, KC. and D. Clark, "Adding Enhanced Services to the
Internet: Lessons from History", TPRC 43: The 43rd
Research Conference on Communication, Information and
Internet Policy Paper, DOI 10.2139/ssrn.2587262, November
2015, <https://papers.ssrn.com/sol3/
papers.cfm?abstract_id=2587262>.
[DNS-CONFIDENTIAL]
Arkko, J. and J. Novotny, "Privacy Improvements for DNS
Resolution with Confidential Computing", Work in Progress,
Internet-Draft, draft-arkko-dns-confidential-02, 2 July
2021, <https://datatracker.ietf.org/doc/html/draft-arkko-
dns-confidential-02>.
[EXPLICIT-COOP]
Trammell, B., Ed., "Architectural Considerations for
Transport Evolution with Explicit Path Cooperation", Work
in Progress, Internet-Draft, draft-trammell-stackevo-
explicit-coop-00, 23 September 2015,
<https://datatracker.ietf.org/doc/html/draft-trammell-
stackevo-explicit-coop-00>.
[HTTP-OBLIVIOUS]
Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in
Progress, Internet-Draft, draft-thomson-http-oblivious-02,
24 August 2021, <https://datatracker.ietf.org/doc/html/
draft-thomson-http-oblivious-02>.
[MOBILE-THROUGHPUT-GUIDANCE]
Jain, A., Terzis, A., Flinck, H., Sprecher, N.,
Arunachalam, S., Smith, K., Devarapalli, V., and R. Bar
Yanai, "Mobile Throughput Guidance Inband Signaling
Protocol", Work in Progress, Internet-Draft, draft-flinck-
mobile-throughput-guidance-04, 13 March 2017,
<https://datatracker.ietf.org/doc/html/draft-flinck-
mobile-throughput-guidance-04>.
[NETWORK-TOKENS]
Yiakoumis, Y., McKeown, N., and F. Sorensen, "Network
Tokens", Work in Progress, Internet-Draft, draft-
yiakoumis-network-tokens-02, 21 December 2020,
<https://datatracker.ietf.org/doc/html/draft-yiakoumis-
network-tokens-02>.
[Oblivious]
Schmitt, P., Edmundson, A., Mankin, A., and N. Feamster,
"Oblivious DNS: Practical Privacy for DNS Queries",
Proceedings on Privacy Enhancing Technologies, Volume
2019, Issue 2, pp. 228-244, DOI 10.2478/popets-2019-0028,
December 2018, <https://doi.org/10.2478/popets-2019-0028>.
[PATH-SIGNALS-INFO]
Arkko, J., "Considerations on Information Passed between
Networks and Applications", Work in Progress, Internet-
Draft, draft-arkko-path-signals-information-00, 22
February 2021, <https://datatracker.ietf.org/doc/html/
draft-arkko-path-signals-information-00>.
[PDoT] Nakatsuka, Y., Paverd, A., and G. Tsudik, "PDoT: Private
DNS-over-TLS with TEE Support", Digital Threats: Research
and Practice, Volume 2, Issue 1, Article No. 3, pp. 1-22,
DOI 10.1145/3431171, February 2021,
<https://doi.org/10.1145/3431171>.
[PER-APP-NETWORKING]
Colitti, L. and T. Pauly, "Per-Application Networking
Considerations", Work in Progress, Internet-Draft, draft-
per-app-networking-considerations-00, 15 November 2020,
<https://datatracker.ietf.org/doc/html/draft-per-app-
networking-considerations-00>.
[RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful
Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
<https://www.rfc-editor.org/info/rfc5218>.
[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
Considerations for Protocol Extensions", RFC 6709,
DOI 10.17487/RFC6709, September 2012,
<https://www.rfc-editor.org/info/rfc6709>.
[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>.
[RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of
Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129,
February 2014, <https://www.rfc-editor.org/info/rfc7129>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet
Technology Adoption and Transition (ITAT)", RFC 7305,
DOI 10.17487/RFC7305, July 2014,
<https://www.rfc-editor.org/info/rfc7305>.
[RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals",
RFC 8558, DOI 10.17487/RFC8558, April 2019,
<https://www.rfc-editor.org/info/rfc8558>.
[RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890,
DOI 10.17487/RFC8890, August 2020,
<https://www.rfc-editor.org/info/rfc8890>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to
Deployment (A Bestiary of Roads Not Taken)", RFC 9049,
DOI 10.17487/RFC9049, June 2021,
<https://www.rfc-editor.org/info/rfc9049>.
[RFC9075] Arkko, J., Farrell, S., Kühlewind, M., and C. Perkins,
"Report from the IAB COVID-19 Network Impacts Workshop
2020", RFC 9075, DOI 10.17487/RFC9075, July 2021,
<https://www.rfc-editor.org/info/rfc9075>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
[RFC9312] Kühlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", RFC 9312, DOI 10.17487/RFC9312,
September 2022, <https://www.rfc-editor.org/info/rfc9312>.
Internet Architecture Board members at the time this document was approved for publication were:
インターネットアーキテクチャ委員会メンバーこの文書が公開されたときに承認された時点は次のとおりです。
Jari Arkko
ジャリ・アークコ
Deborah Brungard
デボラ・ブランガード
Lars Eggert
ラース・エガート
Wes Hardaker
ウェス・ハーダーカー
Cullen Jennings
カレン・ジェニングス
Mallory Knodel
マロリーノーデル
Mirja Kühlewind
MirjaKühlewind
Zhenbin Li
Zhenbin Li
Tommy Pauly
トミーポーリー
David Schinazi
デビッド・シナジ
Russ White
ラス・ホワイト
Qin Wu
Qin Wu
Jiankang Yao
Jiankang Yao
The authors would like to thank everyone at the IETF, the IAB, and our day jobs for interesting thoughts and proposals in this space. Fragments of this document were also in [PER-APP-NETWORKING] and [PATH-SIGNALS-INFO]. We would also like to acknowledge that similar thoughts are presented in [EXPLICIT-COOP]. Finally, the authors would like to thank Adrian Farrell, Toerless Eckert, Martin Thomson, Mark Nottingham, Luis M. Contreras, Watson Ladd, Vittorio Bertola, Andrew Campling, Eliot Lear, Spencer Dawkins, Christian Huitema, David Schinazi, Cullen Jennings, Mallory Knodel, Zhenbin Li, Chris Box, and Jeffrey Haas for useful feedback on this topic and document.
著者は、この分野での興味深い考えや提案について、IETF、IAB、そして私たちの日の仕事のすべての人に感謝したいと思います。このドキュメントのフラグメントは、[APP-ネットワークごと]および[Path-Signals-info]にもありました。また、同様の考えが[expricit-coop]に提示されていることも認めたいと思います。最後に、著者は、エイドリアン・ファレル、トーアレス・エッカート、マーティン・トムソン、マーク・ノッティンガム、ルイス・M・コントレラス、ワトソン・ラッド、ヴィットリオ・ベルトラ、エリオット・リア、スペンサー・ドーキンス、クリスチャン・フイテマ、デイビッド・シナジ、クレン・ジェニングス、マラこのトピックと文書に関する有用なフィードバックについては、Knodel、Zhenbin Li、Chris Box、およびJeffrey Haas。
Jari Arkko
Ericsson
Email: jari.arkko@ericsson.com
Ted Hardie
Cisco
Email: ted.ietf@gmail.com
Tommy Pauly
Apple
Email: tpauly@apple.com
Mirja Kühlewind
Ericsson
Email: mirja.kuehlewind@ericsson.com