[要約] RFC 9490 は、IABによって開催された「Management Techniques in Encrypted Networks (M-TEN)」ワークショップの議論を要約し、今後の取り組むべきテーマを特定する報告書です。このワークショップは、2022年10月17日から19日までの3日間にわたり、インターネット上での暗号化のさらなる普及を支援するために、ネットワーク管理技術の改善方法について議論するために開催されました。
Internet Architecture Board (IAB) M. Knodel
Request for Comments: 9490
Category: Informational W. Hardaker
ISSN: 2070-1721
T. Pauly
January 2024
The "Management Techniques in Encrypted Networks (M-TEN)" workshop was convened by the Internet Architecture Board (IAB) from 17 October 2022 to 19 October 2022 as a three-day online meeting. The workshop was organized in three parts to discuss ways to improve network management techniques in support of even broader adoption of encryption on the Internet. This report summarizes the workshop's discussion and identifies topics that warrant future work and consideration.
「暗号化されたネットワーク（M-TEN）の管理手法」ワークショップは、2022年10月17日から2022年10月19日まで、3日間のオンライン会議としてインターネットアーキテクチャボード（IAB）によって招集されました。このワークショップは、インターネット上のより広範な暗号化の採用をサポートするネットワーク管理手法を改善する方法を議論するために、3つの部分で開催されました。このレポートは、ワークショップの議論を要約し、将来の仕事と考慮を保証するトピックを特定します。
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the expressed during the workshop by participants and do not necessarily reflect IAB views and positions.
このドキュメントは、ワークショップの議事録に関するレポートであることに注意してください。このレポートに記録されている見解とポジションは、参加者によってワークショップ中に表明されたものであり、必ずしもIABのビューとポジションを反映しているわけではありません。
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/rfc9490.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9490で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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
1.1. About This Workshop Report Content
2. Workshop Scope and Discussion
2.1. "Where We Are" - Requirements and Passive Observations
2.1.1. Traffic Classification and Network Management
2.1.2. Preventing Traffic Analysis
2.1.3. Users and Privacy
2.1.4. Discussion
2.2. "Where We Want to Go" - Collaboration Principles
2.2.1. First-Party Collaboration for Network Management
2.2.2. Second- and Third-Party Collaboration for Network
Management
2.2.3. Visible, Optional Network Management
2.2.4. Discussion
2.3. "How We Get There" - Collaboration Use Cases
2.3.1. Establishing Expected Contracts to Enable Security
Management
2.3.2. Zero-Knowledge Middleboxes
2.3.3. Red Rover - a Collaborative Approach to Content
Filtering
3. Conclusions
4. Informative References
Appendix A. Position Papers
A.1. Motivations and Principles
A.2. Classification and Identification of Encrypted Traffic
A.3. Ideas for Collaboration and Coordination between Devices
and Networks
A.4. Other Background Material
Appendix B. Workshop Participants
Appendix C. Program Committee
IAB Members at the Time of Approval
Acknowledgments
Authors' Addresses
The Internet Architecture Board (IAB) holds occasional workshops designed to consider long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture. This long-term planning function of the IAB is complementary to the ongoing engineering efforts performed by working groups of the Internet Engineering Task Force (IETF).
インターネットアーキテクチャボード（IAB）は、インターネットの長期的な問題と戦略を検討し、インターネットアーキテクチャの将来の方向性を提案するように設計された時折のワークショップを開催しています。IABのこの長期計画機能は、インターネットエンジニアリングタスクフォース（IETF）のワーキンググループが実行する継続的なエンジニアリングの取り組みを補完します。
User privacy and security are constantly being improved by increasingly strong and more widely deployed encryption. This workshop aims to discuss ways to improve network management techniques in support of even broader adoption of encryption on the Internet.
ユーザーのプライバシーとセキュリティは、ますます強力で、より広く展開されている暗号化により、常に改善されています。このワークショップは、インターネット上のより広範な暗号化の採用をサポートするために、ネットワーク管理技術を改善する方法を議論することを目的としています。
Network management techniques need to evolve to work effectively and reliably in the presence of ubiquitous traffic encryption and to support user privacy. In an all-encrypted network, it is not viable to rely on unencrypted metadata for network monitoring and security functions, troubleshooting devices, and passive traffic measurements. New approaches are needed to track network behaviors, e.g., by directly cooperating with endpoints and applications, increasing use of in-band telemetry, increasing use of active measurement approaches, and privacy-preserving inference techniques.
ネットワーク管理手法は、ユビキタスなトラフィック暗号化の存在下で効果的かつ確実に機能し、ユーザーのプライバシーをサポートするために進化する必要があります。すべて暗号化されたネットワークでは、ネットワーク監視とセキュリティ機能、トラブルシューティングデバイス、パッシブトラフィック測定のために、暗号化されていないメタデータに依存することは実行できません。たとえば、エンドポイントとアプリケーションと直接協力し、帯域内のテレメトリの使用の増加、アクティブな測定アプローチの使用の増加、プライバシーを提供する推論技術により、ネットワークの動作を追跡するために新しいアプローチが必要です。
The aim of this IAB online workshop from October 17-19, 2022, has been to provide a platform to explore the interaction between network management and traffic encryption and to initiate work on collaborative approaches that promote security and user privacy while supporting operational requirements. As such, the workshop addressed the following questions:
2022年10月17〜19日のこのIABオンラインワークショップの目的は、ネットワーク管理とトラフィックの暗号化の間の相互作用を調査し、運用要件をサポートしながらセキュリティとユーザーのプライバシーを促進する共同アプローチの作業を開始することでした。そのため、ワークショップは次の質問に対処しました。
* What are actionable network management requirements?
* 実行可能なネットワーク管理要件とは何ですか？
* Who is willing to work on collaborative solutions?
* 誰が共同ソリューションに取り組むことをいとわないのですか？
* What are the starting points for collaborative solutions?
* 共同ソリューションの出発点は何ですか？
This document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.
このドキュメントは、ワークショップの議事録に関するレポートです。このレポートに記録されているビューとポジションは、ワークショップ参加者の見解であり、必ずしもIABのビューとポジションを反映しているわけではありません。
Furthermore, the content of the report comes from presentations given by workshop participants and notes taken during the discussions, without interpretation or validation. Thus, the content of this report follows the flow and dialog of the workshop but does not attempt to capture a consensus.
さらに、レポートの内容は、ワークショップの参加者によって与えられたプレゼンテーションと、解釈や検証なしで議論中に撮影されたメモから得られます。したがって、このレポートの内容は、ワークショップのフローとダイアログに従いますが、コンセンサスをキャプチャしようとはしません。
The workshop was held across three days with all-group discussion slots, one per day. The following topic areas were identified, and the program committee organized paper submissions into three main themes for each of the three discussion slots. During each discussion, those papers were presented sequentially with open discussion held at the end of each day.
ワークショップは、1日1つの全グループディスカッションスロットで3日間にわたって開催されました。次のトピック領域が特定され、プログラム委員会は、3つのディスカッションスロットのそれぞれについて、3つの主要なテーマに紙の提出を組織しました。各議論の中で、これらの論文は、毎日の終わりに開催されたオープンディスカッションと連続して提示されました。
The first day of the workshop focused on the existing state of the relationship between network management and encrypted traffic from various angles. Presentations ranged from discussing classifiers using machine learning to recognize traffic, to advanced techniques for evading traffic analysis, to user privacy considerations.
ワークショップの最初の日は、ネットワーク管理とさまざまな角度からの暗号化されたトラフィックとの関係の既存の状態に焦点を当てました。プレゼンテーションは、機械学習を使用してトラフィックを認識するための分類器の議論から、トラフィック分析を回避するための高度な手法、ユーザーのプライバシーに関する考慮事項にまで及びました。
After an introduction that covered the goals of the workshop and the starting questions (as described in Section 1), there were four presentations followed by open discussion.
ワークショップの目標と開始質問（セクション1で説明されているように）をカバーする紹介の後、4つのプレゼンテーションに続いてオープンディスカッションが行われました。
Many existing network management techniques are passive in nature: they don't rely on explicit signals from end hosts to negotiate with network middleboxes but instead rely on inspecting packets to recognize traffic and apply various policies. Traffic classification, as a passive technique, is being challenged by increasing encryption.
多くの既存のネットワーク管理手法は本質的に受動的です。エンドホストからの明示的な信号に依存してネットワークミドルボックスと交渉するのではなく、トラフィックを認識してさまざまなポリシーを適用するためにパケットの検査に依存しています。パッシブテクニックとしての交通分類は、暗号化を増やすことで挑戦されています。
Traffic classification is commonly performed by networks to infer what applications and services are being used. This information is in turn used for capacity and resource planning, Quality-of-Service (QoS) monitoring, traffic prioritization, network access control, identity management, and malware detection. However, since classification commonly relies on recognizing unencrypted properties of packets in a flow, increasing encryption of traffic can decrease the effectiveness of classification.
トラフィック分類は一般にネットワークによって実行され、どのアプリケーションとサービスが使用されているかを推測します。この情報は、容量とリソース計画、サービス品質（QOS）監視、トラフィックの優先順位付け、ネットワークアクセス制御、ID管理、およびマルウェア検出に使用されます。ただし、分類は一般に、流れのパケットの暗号化されていない特性を認識することに依存しているため、トラフィックの暗号化を増やすと分類の有効性が低下する可能性があります。
The amount of classification that can be performed on traffic also provides useful insight into how "leaky" the protocols used by applications are and points to areas where information is visible to any observer, who may or may not be malicious.
トラフィックで実行できる分類の量は、アプリケーションで使用されるプロトコルがどのように「漏れやす」」であるかについての有用な洞察を提供し、悪意があるかどうかの観察者に情報が表示される領域をポイントします。
Frequently, classification has been based on specific rules crafted by experts, but there is also a move toward using machine learning to recognize patterns. "Deep learning" machine-learning models generally rely on analyzing a large set of traffic over time and have trouble reacting quickly to changes in traffic patterns.
多くの場合、分類は専門家によって作成された特定のルールに基づいていますが、パターンを認識するために機械学習を使用することへの動きもあります。「ディープラーニング」マシンラーニングモデルは、一般に、時間の経過とともに大量のトラフィックセットの分析に依存しており、トラフィックパターンの変化に迅速に反応するのに苦労しています。
Models that are based on closed-world data sets also become less useful over time as traffic changes. [JIANG] describes experiments that show that a model that performed with high accuracy on an initial data set becomes severely degraded when running on a newer data set that contains traffic from the same applications. Even in as little time as one week, the traffic classification would become degraded. However, the set of features in packets and flows that were useful for models stayed mostly consistent, even if the models themselves needed to be updated. Models where the feature space is reduced to fewer features showed better resiliency and could be retrained more quickly. Based on this, [JIANG] recommends more work and research to determine which set of features in IP packets are most useful for focused machine-learning analysis. [WU] also recommends further research investment in Artificial Intelligence (AI) analysis for network management.
閉じた世界のデータセットに基づいたモデルは、トラフィックが変化するにつれて時間の経過とともに有用性が低くなります。[Jiang]は、同じアプリケーションからのトラフィックを含む新しいデータセットで実行すると、初期データセットで高精度で実行されるモデルが大幅に低下することを示す実験について説明しています。1週間ほどの時間でさえ、交通分類は劣化します。ただし、モデル自体を更新する必要がある場合でも、モデルに役立つパケットとフローの機能のセットとモデルに役立つフローのセットはほとんど一貫していました。機能空間が縮小されるモデルは、より良い復元力を示し、より迅速に再訓練することができます。これに基づいて、[Jiang]は、IPパケット内のどのセットセットが集中した機械学習分析に最も役立つかを決定するためのより多くの作業と研究を推奨しています。[WU]は、ネットワーク管理のための人工知能（AI）分析へのさらなる研究投資も推奨しています。
Just as traffic classification is continually adapting, techniques to prevent traffic analysis and to obfuscate application and user traffic are continually evolving. An invited talk from the authors of [DITTO] shared a novel approach with the workshop for how to build a very robust system to prevent unwanted traffic analysis.
トラフィック分類が継続的に適応しているように、トラフィック分析を防ぎ、アプリケーションとユーザートラフィックを難読化する手法が継続的に進化しています。[Ditto]の著者からの招待された講演は、不要なトラフィック分析を防ぐために非常に堅牢なシステムを構築する方法について、ワークショップで新しいアプローチを共有しました。
Usually traffic obfuscation is performed by changing the timing of packets or by adding padding to data. The practices can be costly and negatively impact performance. [DITTO] demonstrated the feasibility of applying traffic obfuscation on aggregated traffic in the network with minimal overhead and inline speed.
通常、トラフィックの難読化は、パケットのタイミングを変更するか、データにパディングを追加することによって実行されます。プラクティスは費用がかかり、パフォーマンスに悪影響を与える可能性があります。[Ditto]は、最小限のオーバーヘッドとインライン速度でネットワーク内の集約されたトラフィックにトラフィックの難読化を適用する可能性を実証しました。
While traffic obfuscation techniques are not widely deployed today, this study underlines the need for continuous effort to keep traffic models updated over time, the challenges of the classification of encrypted traffic, as well as the opportunities to further enhance user privacy.
トラフィックの難読化技術は今日広く展開されていませんが、この研究では、交通モデルを時間とともに更新するための継続的な努力、暗号化されたトラフィックの分類の課題、およびユーザーのプライバシーをさらに強化する機会が強調されています。
The Privacy Enhancements and Assessments Research Group (PEARG) is working on a document to discuss guidelines for measuring traffic on the Internet in a safe and privacy-friendly way [LEARMONTH]. These guidelines and principles provide another view on the discussion of passive classification and analysis of traffic.
プライバシーの強化と評価研究グループ（PEARG）は、安全でプライバシーに優しい方法でインターネット上のトラフィックを測定するためのガイドラインについて議論するために文書に取り組んでいます[Learmonth]。これらのガイドラインと原則は、トラフィックの受動的分類と分析の議論に関する別の見解を提供します。
Consent for collection and measurement of metadata is an important consideration in deploying network measurement techniques. This consent can be given explicitly as informed consent, given by proxy, or may be only implied. For example, a user of a network might need to consent to certain measurement and traffic treatment when joining a network.
メタデータの収集と測定の同意は、ネットワーク測定技術の展開における重要な考慮事項です。この同意は、プロキシによって与えられるインフォームドコンセントとして明示的に与えることができます。たとえば、ネットワークのユーザーは、ネットワークに参加する際に特定の測定とトラフィック治療に同意する必要がある場合があります。
Various techniques for data collection can also improve user privacy, such as discarding data after a short period of time, masking aspects of data that contain user-identifying information, reducing the accuracy of collected data, and aggregating data.
データ収集のさまざまな手法は、短期間後にデータを破棄したり、ユーザーを識別する情報を含むデータの側面をマスキングしたり、収集されたデータの精度を減らしたり、データを集めたりするなど、ユーザーのプライバシーを改善できます。
The intents and goals of users, application developers, and network operators align in some cases, but not in others. One of the recurring challenges that was discussed was the lack of a clear way to understand or to communicate intents and requirements. Both traffic classification and traffic obfuscation attempt to change the visibility of traffic without cooperation of other parties: traffic classification is an attempt by the network to inspect application traffic without coordination from applications, and traffic obfuscation is an attempt by the application to hide that same traffic as it transits a network.
ユーザー、アプリケーション開発者、およびネットワークオペレーターの意図と目標は、場合によっては整列していませんが、他の場合は目標を達成します。議論された繰り返しの課題の1つは、意図と要件を理解したり、伝えたりする明確な方法がないことでした。トラフィックの分類とトラフィックの難読化の両方の試み他の関係者の協力なしにトラフィックの可視性を変更しようとします。トラフィック分類は、アプリケーションからの調整なしにアプリケーショントラフィックを検査するためのネットワークによる試みであり、トラフィックの難読化は、同じトラフィックを非表示にするための試みですネットワークを通過するとき。
Traffic adaptation and prioritization is one dimension in which the incentives for cooperation seem most clear. Even if an application is trying to prevent the leaking of metadata, it could benefit from signals from the network about sudden capacity changes that can help it adapt its application quality, such as bitrates and codecs. Such signaling may not be appropriate for the most privacy-sensitive applications, like Tor, but could be applicable for many others. There are existing protocols that involve explicit signaling between applications and networks, such as Explicit Congestion Notification (ECN) [RFC3168], but that has yet to see wide adoption.
交通の適応と優先順位付けは、協力のインセンティブが最も明確に見える1つの次元です。アプリケーションがメタデータの漏れを防止しようとしている場合でも、ビットレートやコーデックなどのアプリケーションの品質を適応させるのに役立つ突然の容量の変化に関するネットワークからの信号から利益を得ることができます。このようなシグナル伝達は、TORのような最もプライバシーに敏感なアプリケーションには適していない場合がありますが、他の多くのアプリケーションに適用できます。明示的な輻輳通知（ECN）[RFC3168]など、アプリケーションとネットワーク間の明示的なシグナル伝達を含む既存のプロトコルがありますが、それはまだ広範囲に採用されていません。
Managed networks (such as private corporate networks) were brought up in several comments as particularly challenging for meeting management requirements while maintaining encryption and privacy. These networks can have legal and regulated requirements for detection of specific fraudulent or malicious traffic.
マネージドネットワーク（プライベートコーポレートネットワークなど）は、暗号化とプライバシーを維持しながら、管理要件を満たすために特に困難なものとして、いくつかのコメントで提起されました。これらのネットワークには、特定の不正または悪意のあるトラフィックを検出するための法的および規制された要件があります。
Personal networks that enable managed parental controls have similar complications with encrypted traffic and user privacy. In these scenarios, the parental controls that are operated by the network may be as simple as a DNS filter, which can be made ineffective by a device routing traffic to an alternate DNS resolver.
管理された親のコントロールを可能にするパーソナルネットワークは、暗号化されたトラフィックとユーザープライバシーと同様の合併症を抱えています。これらのシナリオでは、ネットワークによって動作する親のコントロールは、DNSフィルターと同じくらい単純である可能性があります。これは、トラフィックを代替DNSリゾルバーにルーティングするデバイスが効果的ではありません。
The second day of the workshop focused on the emerging techniques for analyzing, managing, or monitoring encrypted traffic. Presentations covered advanced classification and identification, including machine-learning techniques, for the purposes of managing network flows or monitoring or monetizing usage.
ワークショップの2日目は、暗号化されたトラフィックを分析、管理、または監視するための新しいテクニックに焦点を当てました。プレゼンテーションは、ネットワークフローの管理または監視または収益化の使用を目的として、機械学習手法を含む高度な分類と識別をカバーしました。
After an introduction that covered the goals of the workshop and the starting questions (as described in Section 1), there were three presentations, followed by open discussion.
ワークショップの目標と開始質問（セクション1で説明されているように）をカバーする紹介の後、3つのプレゼンテーションがあり、その後に開かれたディスカッションが行われました。
It is the intent of end-to-end encryption of traffic to create a barrier between entities inside the communication channel and everyone else, including network operators. Therefore, any attempt to overcome that intentional barrier requires collaboration between the inside and outside entities. At a minimum, those entities must agree on the benefits of overcoming the barrier (or solving the problem), agree that costs are proportional to the benefits, and agree to additional limitations or safeguards against bad behavior by collaborators including other non-insiders [BARNES].
これは、通信チャネル内のエンティティとネットワークオペレーターを含む他のすべてのエンティティ間の障壁を作成するためのトラフィックのエンドツーエンドの暗号化の意図です。したがって、その意図的な障壁を克服しようとすると、内部と外部のエンティティ間のコラボレーションが必要です。少なくとも、これらのエンティティは、障壁を克服する（または問題を解決する）ことの利点に同意し、コストが利益に比例することに同意し、他の非インサイダーを含む協力者による悪い行動に対する追加の制限または保護に同意する必要があります[Barnes]。
The Internet is designed interoperably, which means an outside entity wishing to collaborate with the inside might be any number of intermediaries and not, say, a specific person that can be trusted in the human sense. Additionally, the use of encryption, especially network-layer or transport-layer encryption, introduces dynamic or opportunistic or perfunctory discoverability. These realities point to a need to ask why an outside entity might make an engineering case to collaborate with the user of a network with encrypted traffic and to ask whether the trade-offs and potential risks are worth it to the user.
インターネットは相互作用できるように設計されています。つまり、内部と協力したい外部のエンティティは、人間の意味で信頼できる特定の人ではなく、どの仲介者も数多くの仲介者である可能性があります。さらに、暗号化、特にネットワーク層または輸送層暗号化の使用は、動的または日和見的またはおかしな発見可能性を導入します。これらの現実は、暗号化されたトラフィックとネットワークのユーザーと協力するために、外部エンティティがエンジニアリングケースを作成する理由を尋ねる必要性を尋ね、トレードオフと潜在的なリスクがユーザーにとって価値があるかどうかを尋ねる必要があることを尋ねる必要があります。
However, the answers cannot be specific, and the determinations or guidance need to be general as the encryption boundary is inevitably an application used by many people. Trade-offs must make sense to users who are unlikely to be thinking about network management considerations. Harms need to be preemptively reduced because, in general terms, few users would choose network management benefits over their own privacy if given the choice.
ただし、回答は具体的ではなく、暗号化の境界は必然的に多くの人々が使用するアプリケーションであるため、決定またはガイダンスは一般的である必要があります。トレードオフは、ネットワーク管理の考慮事項について考えていないユーザーには意味があります。一般的には、選択肢が与えられた場合、自分のプライバシーよりもネットワーク管理の利点を選択するユーザーはほとんどいないため、害を先取りする必要があります。
Some have found that there appears to be little, if any, evidence that encryption causes network problems that are meaningful to the user. Since alignment on problem solving is a prerequisite to collaboration on a solution, it does not seem that collaboration across the encryption boundary is called for.
暗号化がユーザーにとって意味のあるネットワークの問題を引き起こすという証拠があったとしても、あったとしてもほとんどないように見えることを発見した人もいます。問題解決の調整はソリューションでのコラボレーションの前提条件であるため、暗号化境界全体のコラボレーションが求められているとは思われません。
Even with the wide-scale deployment of encryption in new protocols and of techniques that prevent passive observers of network traffic from knowing the content of exchanged communications, important information, such as which parties communicate and sometimes even which services have been requested, may still be able to be deduced. The future is to conceal more data and metadata from passive observers and also to minimize information exposure to second parties (where the user is the first party) by, maybe counterintuitively, introducing third-party relay services to intermediate communications. As discussed in [KUEHLEWIND], the relay is a mechanism that uses additional levels of encryption to separate two important pieces of information: knowledge of the identity of the person accessing a service is separated from knowledge about the service being accessed. By contrast, a VPN uses only one level of encryption and does not separate identity (first party) and service (second party) metadata.
新しいプロトコルでの暗号化と、ネットワークトラフィックの受動的な観察者が交換された通信の内容を把握できないようにする手法、どの関係者が通信し、時にはどのサービスが要求されているかなどの重要な情報を知ることを妨げる技術の幅広い規模の展開があっても、まだ推定できる。将来は、受動的なオブザーバーからより多くのデータとメタデータを隠し、また、おそらく直観的に反対的に、中間通信にサードパーティのリレーサービスを導入することにより、第二当事者（ユーザーが第一党）への情報の露出を最小限に抑えることです。[Kuehlewind]で説明したように、リレーは、追加の暗号化レベルを使用して2つの重要な情報を分離するメカニズムです。サービスにアクセスする人の身元に関する知識は、アクセスされているサービスに関する知識から分離されています。対照的に、VPNは1つのレベルの暗号化のみを使用し、ID（第一党）とサービス（第四党）メタデータを分離しません。
Relay mechanisms are termed "oblivious", there is a future for specifications in privacy-preserving measurement (PPM), and protocols like Multiplexed Application Substrate over QUIC Encryption (MASQUE) are discussed in the IETF. In various schemes, users are ideally able to share their identity only with the entity they have identified as a trusted one. That data is not shared with the service provider. However, this is more complicated for network management, but there may be opportunities for better collaboration between the network and, say, the application or service at the endpoint.
リレーメカニズムは「忘れられない」と呼ばれ、プライバシーを提供する測定（PPM）の仕様の将来があり、QUIC暗号化（マスク）を介した多重化アプリケーション基板などのプロトコルがIETFで説明されています。さまざまなスキームでは、ユーザーは理想的には、信頼できるものとして特定したエンティティとのみアイデンティティを共有できます。そのデータはサービスプロバイダーと共有されていません。ただし、これはネットワーク管理にとってより複雑ですが、ネットワークと、たとえばエンドポイントでのアプリケーションまたはサービスとの間でより良いコラボレーションの機会があるかもしれません。
A queriable relay mechanism could preserve network management functions that are disrupted by encryption, such as TCP optimization, quality of service, zero-rating, parental controls, access control, redirection, content enhancement, analytics, and fraud prevention. Instead of encrypting communication between only two ends with passive observation by all on-path elements, intermediate relays could be introduced as trusted parties that get to see limited information for the purpose of collaboration between in-network intermediary services.
クエリ性リレーメカニズムは、TCP最適化、サービス品質、ゼロレーティング、親制御、アクセス制御、リダイレクト、コンテンツの強化、分析、詐欺防止など、暗号化によって破壊されるネットワーク管理機能を保持できます。すべてのオンパス要素によるパッシブ観測で2つのエンド間の通信を暗号化する代わりに、ネットワーク内の仲介サービス間のコラボレーションを目的として限られた情報を見ることができる信頼できるパーティーとして中間リレーを導入できます。
Out of all of the possible network management functions that might be ameliorated by proxying, the ability to control congestion in encrypted communications has been researched in depth. These techniques are realized based on TCP performance-enhancing proxies (PEPs) that either entirely intercept a TCP connection or interfere with the transport information in the TCP header. However, despite the challenge that the new encrypted protocol will limit any such in-network interference, these techniques can also have a negative impact on the evolvability of these protocols. Therefore, a new approach was presented where, instead of manipulating existing information, additional information is sent using a so-called sidecar protocol independent of the main transport protocol that is used end to end [WELZL]. For example, sidecar information can contain additional acknowledgments to enable in-network local retransmission or faster end-to-end retransmission by reducing the signaling round-trip time.
プロキシによって改善される可能性のあるネットワーク管理機能のすべてのうち、暗号化された通信の輻輳を制御する能力が深く研究されています。これらの手法は、TCP接続を完全に傍受するか、TCPヘッダーの輸送情報を妨害するTCPパフォーマンス向上プロキシ（PEP）に基づいて実現されます。ただし、新しい暗号化されたプロトコルがこのようなネットワーク内干渉を制限するという課題にもかかわらず、これらの手法はこれらのプロトコルの進化性にマイナスの影響を与える可能性があります。したがって、既存の情報を操作する代わりに、使用されるメイントランスポートプロトコルとは無関係に[WELZL]を使用して追加情報が送信される新しいアプローチが提示されました。たとえば、SIDECAR情報には、シグナリングラウンドトリップ時間を短縮することにより、ネットワーク内のローカル再送信またはより速いエンドツーエンドの再送信を可能にするための追加の承認を含めることができます。
Taking user privacy benefits for granted, there is a need to investigate the comparable performance outputs of various encrypted traffic configurations such as the use of an additional sidecar protocol, or explicit encrypted and trusted network communication using MASQUE in relation to existing techniques such as TCP PEPs, etc.
ユーザーのプライバシーの利点を当たり前にすると、追加のサイドカープロトコルの使用など、さまざまな暗号化されたトラフィック構成の同等のパフォーマンス出力、またはTCP PEPSなどの既存の技術に関連してマスクを使用した明示的な暗号化および信頼できるネットワーク通信を調査する必要があります。、など
One size fits all? On the issue of trust, different networks or devices will have different trust requirements for devices, users, or each other, and vice versa. For example, imagine two networks with really different security requirements, like a home network with a requirement to protect its child users versus a national security institution's network. How could one network architecture solve the needs of all use cases?
1つのサイズがすべてフィットしますか？信頼の問題については、さまざまなネットワークまたはデバイスには、デバイス、ユーザー、または互いの信頼要件が異なり、その逆も同様です。たとえば、子どものユーザーと国家安全保障機関のネットワークを保護する要件を持つホームネットワークのように、非常に異なるセキュリティ要件を持つ2つのネットワークを想像してください。1つのネットワークアーキテクチャは、すべてのユースケースのニーズをどのように解決できますか？
Does our destination have consequences? It seems sometimes that there may be future consequences caused by the ubiquitous, strong encryption of network traffic because it will cause intermediaries to poke holes in what are supposed to be long-term solutions for user privacy and security.
目的地には結果がありますか？ネットワークトラフィックのユビキタスで強力な暗号化によって引き起こされる将来の結果があるかもしれないように思われます。なぜなら、それにより、仲介者はユーザーのプライバシーとセキュリティのための長期的なソリューションと思われるものに穴を突いているからです。
Can we bring the user along? While there has been a focus on the good reasons why people might collaborate across the encryption barrier, there will always be others who want to disrupt that in order to exploit the data for their own gain, and sometimes exploitation is called innovation. High-level policy mitigations have exposed how powerless end users are against corporate practices of data harvesting. And yet interfaces to help users understand these lower-layer traffic flows to protect their financial transactions or privacy haven't been achieved yet. That means that engineers must make inferences about user wants. Instead, we should make these relationships and trade-offs more visible.
ユーザーを連れて行くことはできますか？人々が暗号化の障壁を越えて協力する正当な理由に焦点を合わせてきましたが、自分の利益のためにデータを悪用するためにそれを混乱させたい他の人が常に存在し、時には搾取はイノベーションと呼ばれます。高レベルのポリシー緩和により、データ収穫の企業慣行に無力なエンドユーザーがどれほど無力であるかが明らかになりました。それでも、ユーザーが金融取引やプライバシーを保護するためにこれらの低層トラフィックフローを理解するのに役立つインターフェイスはまだ達成されていません。つまり、エンジニアはユーザーの要望について推論する必要があります。代わりに、これらの関係とトレードオフをより目立たせる必要があります。
The third day focused on techniques that could be used to improve the management of encrypted networks. The potential paths forward described in the presentations included some element of collaboration between the networks and the subscribing clients that simultaneously want both privacy and protection. Thus, the central theme of the third day became negotiation and collaboration.
3日目は、暗号化されたネットワークの管理を改善するために使用できる技術に焦点を当てました。プレゼンテーションで説明されている潜在的なパスには、ネットワークとサブスクライティングクライアントの間のコラボレーションの要素が含まれ、同時にプライバシーと保護の両方を必要とします。したがって、3日目の中心的なテーマは、交渉とコラボレーションになりました。
For enterprise networks where client behavior is potentially managed, [COLLINS] proposes "Improving network monitoring through contracts", where contracts describe different states of network behavior.
クライアントの動作が潜在的に管理されるエンタープライズネットワークの場合、[Collins]は「契約によるネットワーク監視の改善」を提案します。
Because network operators have a limited amount of time to focus on problems and process alerts, contracts and states let the operator focus on a particular aspect of a current situation or problem. The current estimate for the number of events a Security Operations Center (SOC) operator can handle is about 10 per hour. Operators must work within the limits imposed by their organization and must pick among options that frequently only frustrate attackers -- preventing attacks entirely is potentially impossible. Finally, operators must prioritize and manage the most events possible.
ネットワークオペレーターは、問題に焦点を合わせ、プロセスアラート、契約、および州が現在の状況または問題の特定の側面に集中できるようにするための時間が限られているためです。セキュリティオペレーションセンター（SOC）オペレーターが処理できるイベントの数の現在の見積もりは、1時間あたり約10件です。オペレーターは、組織によって課せられた制限内で作業する必要があり、攻撃者を頻繁に苛立たせるオプションの中から選択する必要があります。攻撃を完全に防ぐことは潜在的に不可能です。最後に、オペレーターは可能な限り最もイベントを優先して管理する必要があります。
Validating which alerts are true positives is challenging because lots of weird traffic creates many anomalies, and not all anomalies are malicious events. Identifying which anomalous traffic is rooted in malicious activity with any level of certainty is extremely challenging. Unfortunately, applying the latest machine-learning techniques has produced mixed results. To make matters worse, the large amounts of Internet-wide scanning has resulted in endless traffic that is technically malicious but only creates an information overload and challenges event prioritization. Any path forward must free up analyst time to concentrate on the more challenging events.
多くの奇妙なトラフィックが多くの異常を生み出し、すべての異常が悪意のあるイベントではないため、どのアラートが真のポジティブであるかを検証することは困難です。どの異常なトラフィックがあらゆるレベルの確実性を持つ悪意のある活動に根ざしているかを特定することは非常に困難です。残念ながら、最新の機械学習技術を適用することで、さまざまな結果が得られました。さらに悪いことに、大量のインターネット全体のスキャンにより、技術的に悪意がありますが、情報の過負荷のみを作成し、イベントの優先順位付けに挑戦する無限のトラフィックが発生しました。前進するパスは、より挑戦的なイベントに集中するために、アナリストの時間を解放する必要があります。
The proposed contract solution is to define a collection of acceptable behaviors that comprises different states that might include IP addresses, domain names, and indicators of compromise. Deviation from a contract might indicate that a system is acting outside a normal mode of behavior or even that a normal mode of behavior is suddenly missing. An example contract might be "this system is expected to update its base OS once a day". If this doesn't occur, then this expectation has not been met, and the system should be checked as it failed to call home to look for (potentially security-related) updates.
提案された契約ソリューションは、IPアドレス、ドメイン名、および妥協の指標を含む可能性のあるさまざまな状態を含む許容可能な行動のコレクションを定義することです。契約からの逸脱は、システムが通常の動作モードの外で作用していること、または通常の動作モードが突然欠落していることを示している可能性があります。例の契約は、「このシステムは1日1回ベースOSを更新することが期待される」ことです。これが発生しない場合、この期待は満たされておらず、システムをチェックする必要があります。
Within the IETF, the Manufacturer Usage Description Specification (MUD) [RFC8520] is one subset of contracts. Note that contracts are likely to succeed only in a constrained, expected environment maintained by operational staff and may not work in an open Internet environment where end users drive all network connections.
IETF内では、メーカーの使用法の説明仕様（MUD）[RFC8520]は、契約のサブセットの1つです。契約は、運用スタッフが維持する制約された予想される環境でのみ成功する可能性が高く、エンドユーザーがすべてのネットワーク接続を駆動するオープンなインターネット環境では機能しない可能性があることに注意してください。
The world is not only shifting to increased encrypted traffic but is also encrypting more and more of the metadata (e.g., DNS queries and responses). This makes network policy enforcement by middleboxes significantly more challenging. The result is a significant tension between security enforcement and privacy protection.
世界は、暗号化されたトラフィックの増加にシフトするだけでなく、ますます多くのメタデータ（DNSクエリや応答など）を暗号化しています。これにより、ミドルボックスによるネットワークポリシー施行により、大幅に困難になります。その結果、セキュリティ執行とプライバシー保護の間に大きな緊張があります。
Goals for solving this problem should include enabling networks to enforce their policies, but should not include the weakening of encryption nor the deployment of new server software. Existing solutions fail to meet at least one of these points.
この問題を解決するための目標には、ネットワークがポリシーを実施できるようにすることを含める必要がありますが、暗号化の弱体化や新しいサーバーソフトウェアの展開を含めるべきではありません。既存のソリューションは、これらのポイントの少なくとも1つを満たすことができません。
A cryptographic principle of a "zero-knowledge proof" (ZKP) [GRUBBS] may be one path forward to consider. A ZKP allows a third party to verify that a statement is true without revealing what the statement actually is. Applying this to network traffic has been shown to allow a middlebox to verify that traffic to a web server is compliant with a policy without revealing the actual contents. This solution meets the three criteria listed above. Using ZKP within TLS 1.3 traffic turns out to be plausible.
「ゼロ知識証明」（ZKP）[grubbs]の暗号化の原則は、考慮すべき1つのパスかもしれません。ZKPにより、第三者は、声明が実際に何であるかを明らかにせずに、声明が真であることを確認することができます。これをネットワークトラフィックに適用することで、ミドルボックスがWebサーバーへのトラフィックが実際のコンテンツを明らかにすることなくポリシーに準拠していることを確認できるようになりました。このソリューションは、上記の3つの基準を満たしています。TLS 1.3トラフィック内でZKPを使用することはもっともらしいことが判明しました。
An example engine using encrypted DNS was built to test ZKP. Clients were able to create DNS requests that were not listed within a DNS block list. Middleboxes could verify, without knowing the exact request, that the client's DNS request was not on the prohibited list. Although the result was functional, the computational overhead was still too slow, and future work will be needed to decrease the ZKP-imposed latencies.
暗号化されたDNSを使用した例のエンジンがZKPをテストするために構築されました。クライアントは、DNSブロックリスト内にリストされていないDNSリクエストを作成できました。ミドルボックスは、正確な要求を知らずに、クライアントのDNS要求が禁止リストに載っていないことを確認できます。結果は機能的でしたが、計算オーバーヘッドはまだ遅すぎ、ZKPが課したレイテンシを減らすには将来の作業が必要になります。
The principle challenge being studied is how to handle the inherent conflict between filtering and privacy. Network operators need to implement policies and regulations that can originate from many locations (e.g., security, governmental, parental, etc.). Conversely, clients need to protect their users' privacy and security.
研究されている主要な課題は、フィルタリングとプライバシーの固有の対立をどのように処理するかです。ネットワークオペレーターは、多くの場所（セキュリティ、政府、保護者など）に由来する可能性のあるポリシーと規制を実装する必要があります。逆に、クライアントはユーザーのプライバシーとセキュリティを保護する必要があります。
Safe browsing, originally created by Google, is one example of a mechanism that tries to meet both sides of this conflict. It would be beneficial to standardize this and other similar mechanisms. Operating systems could continually protect their users by ensuring that malicious destinations are not being reached. This would require some coordination between cooperating clients and servers offering protection services. These collaborative solutions may be the best compromise to resolve the tension between privacy services and protection services [PAULY].
もともとGoogleが作成した安全なブラウジングは、この紛争の両側に対応しようとするメカニズムの一例です。これや他の同様のメカニズムを標準化することは有益です。オペレーティングシステムは、悪意のある目的地に到達しないようにすることで、ユーザーを継続的に保護できます。これには、協力するクライアントと保護サービスを提供するサーバーの間の調整が必要です。これらの共同ソリューションは、プライバシーサービスと保護サービスの間の緊張を解決するための最良の妥協である可能性があります[Pauly]。
Looking forward, the workshop participants identified that solving the entire problem space with a single approach will be challenging for several reasons:
ワークショップの参加者は、1つのアプローチで問題スペース全体を解決することは、いくつかの理由で挑戦的であると特定しました。
* The scalability of many solutions will likely be an issue as some solutions are complex or expensive to implement.
* 一部のソリューションは実装するのに複雑または高価であるため、多くのソリューションのスケーラビリティが問題になる可能性があります。
* Collaboration between multiple parties will be required for many mechanisms to function, and the sets of parties required for different use cases might be disjoint.
* 多くのメカニズムが機能するには、複数の当事者間のコラボレーションが必要であり、異なるユースケースに必要な当事者のセットは矛盾する可能性があります。
* There is an unanswered question of whether or not network operators are willing to participate by allowing new encryption technologies into their environment in exchange for technologies that prove their clients are being good net-citizens. If so, some of these solutions might be required to exist before networks allow a certain type of increased encryption; consider the example of TLS Encrypted Client Hello being blocked by some network operators.
* ネットワークオペレーターが、クライアントが優れたネット市民であることを証明するテクノロジーと引き換えに、新しい暗号化テクノロジーを環境に入れることにより、参加する意思があるかどうかについての未回答の質問があります。もしそうなら、これらのソリューションのいくつかは、ネットワークが特定のタイプの暗号化を増やす前に存在する必要があるかもしれません。一部のネットワーク演算子によってブロックされているTLS暗号化されたクライアントの例を考えてみましょう。
The breadth of the problem space itself is another complicating factor. There is a wide variety of network architectures, and each has different requirements for both data encryption and network management. Each problem space will have multiple, different encumbrances: for example, technical, legal, data ownership, and regulatory concerns. New network architectures might be needed to solve this problem at a larger scope, which would in turn require interoperability support from network product vendors. Education about various solutions will be required in order to ensure regulation and policy organizations can understand and thus support the deployment of developed solutions.
問題空間自体の幅は、別の複雑な要因です。さまざまなネットワークアーキテクチャがあり、それぞれがデータ暗号化とネットワーク管理の両方に異なる要件があります。それぞれの問題スペースには、複数の異なる負担があります。たとえば、技術、法的、データ所有権、規制上の懸念などです。この問題をより大きな範囲で解決するには、新しいネットワークアーキテクチャが必要になる場合があります。これにより、ネットワーク製品ベンダーからの相互運用性サポートが必要になります。規制および政策機関が開発されたソリューションの展開を理解し、サポートできるようにするために、さまざまなソリューションに関する教育が必要です。
After new technologies and related standards are developed and deployed, unintended consequences can emerge. These lead to effects in multiple directions: on one hand, exposed protocol values not intended for network management might be used by networks to differentiate traffic; on the other hand, changes to a protocol that break existing use cases might have an impact on private network deployments. While making decisions on technology direction and protocol design, it is important to consider the impact on various kinds of network deployments and their unique requirements. When protocols change to make different network management functions easier or harder, the impact on various deployment models ought to be considered and documented.
新しいテクノロジーと関連標準が開発され、展開された後、意図しない結果が現れる可能性があります。これらは複数の方向の影響につながります。一方では、ネットワーク管理を目的としていない露出したプロトコル値をネットワークで使用してトラフィックを区別することができます。一方、既存のユースケースを破るプロトコルの変更は、プライベートネットワークの展開に影響を与える可能性があります。テクノロジーの方向性とプロトコル設計を決定しながら、さまざまな種類のネットワーク展開とその独自の要件への影響を考慮することが重要です。プロトコルが変更されてさまざまなネットワーク管理機能を容易にする場合、またはさまざまな展開モデルへの影響を考慮して文書化する必要があります。
[BARNES] Barnes, R., "What's In It For Me? Revisiting the reasons
people collaborate", August 2022, <https://www.iab.org/wp-
content/IAB-uploads/2023/11/Barnes-Whats-In-It-For-Me-
Revisiting-the-reasons-people-collaborate.pdf>.
[CASAS] Casas, P., "Monitoring User-Perceived Quality in an
Encrypted Internet - AI to the Rescue", August 2022,
<https://www.iab.org/wp-content/IAB-uploads/2023/11/Casas-
AI-driven-real-time-QoE-monitoring-encrypted-traffic.pdf>.
[COLLINS] Collins, M., "Improving Network Monitoring Through
Contracts", August 2022, <https://www.iab.org/wp-content/
IAB-uploads/2023/11/Collins-Improving-Network-Monitoring-
Through-Contracts.pdf>.
[DERI] Deri, L., "nDPI Research Proposal", August 2022,
<https://www.iab.org/wp-content/IAB-uploads/2023/11/Deri-
nDPI-Research-Proposal.pdf>.
[DITTO] Meier, R., Lenders, V., and L. Vanbever, "ditto: WAN
Traffic Obfuscation at Line Rate", Network and Distributed
Systems Security (NDSS) Symposium,
DOI 10.14722/ndss.2022.24056, April 2022,
<https://doi.org/10.14722/ndss.2022.24056>.
[ELKINS] Elkins, N., Ackermann, M., Tahiliani, M., Dhody, D., and
T. Pecorella, "Performance Monitoring in Encrypted
Networks: PDMv2", August 2022, <https://www.iab.org/wp-
content/IAB-uploads/2023/11/Elkins-Performance-Monitoring-
in-Encrypted-Networks-PDMv2.pdf>.
[GRUBBS] Grubbs, P., Arun, A., Zhang, Y., Bonneau, J., and M.
Walfish, "Zero-Knowledge Middleboxes", 31st USENIX
Security Symposium (USENIX Security 22), August 2022,
<https://www.usenix.org/conference/usenixsecurity22/
presentation/grubbs>.
[HARDAKER] Hardaker, W., "Network Flow Management by Probability",
August 2022, <https://www.iab.org/wp-content/IAB-
uploads/2023/11/Hardaker-Encrypted-Traffic-
Estimation.pdf>.
[JIANG] Jiang, X., Liu, S., Naama, S., Bronzino, F., Schmitt, P.,
and N. Feamster, "Towards Designing Robust and Efficient
Classifiers for Encrypted Traffic in the Modern Internet",
August 2022, <https://www.iab.org/wp-content/IAB-
uploads/2023/11/Jiang-Towards-Designing-Robust-and-
Efficient-Classifiers-for-Encrypted-Traffic-in-the-Modern-
Internet.pdf>.
[KNODEL] Knodel, M., "(Introduction) 'Guidelines for Performing
Safe Measurement on the Internet'", August 2022,
<https://www.iab.org/wp-content/IAB-uploads/2023/11/
Knodel-Guidelines-for-Performing-Safe-Measurement-on-the-
Internet.pdf>.
[KUEHLEWIND]
Kuehlewind, M., Westerlund, M., Sarker, Z., and M. Ihlar,
"Relying on Relays: The future of secure communication",
June 2022, <https://www.ericsson.com/en/blog/2022/6/
relays-and-online-user-privacy>.
[LEARMONTH]
Learmonth, I. R., Grover, G., and M. Knodel, "Guidelines
for Performing Safe Measurement on the Internet", Work in
Progress, Internet-Draft, draft-irtf-pearg-safe-internet-
measurement-09, 12 January 2024,
<https://datatracker.ietf.org/doc/html/draft-irtf-pearg-
safe-internet-measurement-09>.
[LEI] Lei, Y., Wu, J., Sun, X., Zhang, L., and Q. Wu, "Encrypted
Traffic Classification Through Deep Learning", August
2022, <https://www.iab.org/wp-content/IAB-uploads/2023/11/
Lei-Encrypted-Traffic-Classification-Through-Deep-
Learning.pdf>.
[PAULY] Pauly, T. and R. Barnes, "Red Rover: A collaborative
approach to content filtering", August 2022,
<https://www.iab.org/wp-content/IAB-uploads/2023/11/Pauly-
Red-Rover-A-collaborative-approach-to-content-
filtering.pdf>.
[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>.
[RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
Description Specification", RFC 8520,
DOI 10.17487/RFC8520, March 2019,
<https://www.rfc-editor.org/info/rfc8520>.
[WELZL] Welzl, M., "The Sidecar: 'Opting in' to PEP Functions",
August 2022, <https://www.iab.org/wp-content/IAB-
uploads/2023/11/Welzl-The-Sidecar-Opting-in-to-PEP-
Functions.pdf>.
[WU] Wu, Q., Wu, J., and Q. Ma, "Network Management of
Encrypted Traffic: Detect it don't decrypt it", August
2022, <https://www.iab.org/wp-content/IAB-uploads/2023/11/
Wu-mten-taxonomy.pdf>.
Interested participants were openly invited to submit position papers on the workshop topics, including Internet-Drafts, relevant academic papers, or short abstracts explaining their interest. The papers below constitute the inputs that were considered relevant for workshop attendees and that focused the discussions themselves. The program committee grouped the papers by theme.
興味のある参加者は、インターネットドラフト、関連するアカデミックペーパー、または彼らの関心を説明する短い要約など、ワークショップのトピックに関するポジションペーパーを提出するように公然と招待されました。以下の論文は、ワークショップの参加者に関連すると見なされ、それ自体で議論に焦点を合わせた入力を構成しています。プログラム委員会は、テーマごとに論文をグループ化しました。
Richard Barnes. "What's In It For Me? Revisiting the reasons people collaborate." [BARNES]
リチャード・バーンズ。「私にとって何が入っているのか？人々が協力する理由を再訪してください。」[バーンズ]
Mallory Knodel. "(Introduction) 'Guidelines for Performing Safe Measurement on the Internet'." (Additional rationale) [KNODEL]
マロリーノーデル。「（はじめに）「インターネット上で安全な測定を実行するためのガイドライン」。」（追加の根拠）[Knodel]
Qin Wu, Jun Wu, Qiufang Ma. "Network Management of Encrypted Traffic: Detect it don't decrypt it." [WU]
Qin Wu、Jun Wu、Qiufang Ma。「暗号化されたトラフィックのネットワーク管理：それを検出しないでください。」[wu]
Luca Deri. "nDPI Research Proposal." [DERI]
ルカ・デリ。「NDPI研究提案。」[deri]
Wes Hardaker. "Network Flow Management by Probability." [HARDAKER]
ウェス・ハーダーカー。「確率によるネットワークフロー管理。」[ハードカー]
Xi Jiang, Shinan Liu, Saloua Naama, Francesco Bronzino, Paul Schmitt, Nick Feamster. "Towards Designing Robust and Efficient Classifiers for Encrypted Traffic in the Modern Internet." [JIANG]
Xi Jiang、Shinan Liu、Saloua Naama、Francesco Bronzino、Paul Schmitt、Nick Feamster。「現代のインターネットで暗号化されたトラフィック用の堅牢で効率的な分類器の設計に向けて」[江師]
Yupeng Lei, Jun Wu, Xudong Sun, Liang Zhang, Qin Wu. "Encrypted Traffic Classification Through Deep Learning." [LEI]
Yupeng Lei、Jun Wu、Xudong Sun、Liang Zhang、Qin Wu。「深い学習による暗号化された交通分類。」[レイ]
Michael Collins. "Improving Network Monitoring Through Contracts." [COLLINS]
マイケル・コリンズ。「契約によるネットワーク監視の改善。」[コリンズ]
Paul Grubbs, Arasu Arun, Ye Zhang, Joseph Bonneau, Michael Walfish. "Zero-Knowledge Middleboxes." [GRUBBS]
Paul Grubbs、Arasu Arun、Ye Zhang、Joseph Bonneau、Michael Walfish。「ゼロ認識中間ボックス。」[グラブス]
Mirja Kuehlewind, Magnus Westerlund, Zaheduzzaman Sarker, Marcus Ihlar. "Relying on Relays: The future of secure communication." [KUEHLEWIND]
Mirja Kuehlewind、Magnus Westerlund、Zaheduzzaman Sarker、Marcus Ihlar。「リレーに依存する：安全なコミュニケーションの未来。」[Kuehlewind]
Tommy Pauly, Richard Barnes. "Red Rover: A collaborative approach to content filtering." [PAULY]
トミー・ポーリー、リチャード・バーンズ。「レッドローバー：コンテンツフィルタリングへの共同アプローチ。」[ポーリー]
Michael Welzl. "The Sidecar: 'Opting in' to PEP Functions." [WELZL]
マイケル・ウェルツル。「サイドカー：「 "pep functionsをオプトします。」[welzl]
Pedro Casas. "Monitoring User-Perceived Quality in an Encrypted Internet - AI to the Rescue." [CASAS]
ペドロカサス。「暗号化されたインターネットでユーザーが認識している品質を監視 - 救助へのAI。」[カサス]
Nalini Elkins, Mike Ackermann, Mohit P. Tahiliani, Dhruv Dhody, Prof. Tommaso Pecorella. "Performance Monitoring in Encrypted Networks: PDMv2." [ELKINS]
Nalini Elkins、Mike Ackermann、Mohit P. Tahiliani、Dhruv Dhody、Tommaso Pecorella教授。「暗号化されたネットワークのパフォーマンス監視：PDMV2。」[エルキンズ]
The workshop participants were Cindy Morgan, Colin Perkins, Cullen Jennings, Deborah Brungard, Dhruv Dhody, Éric Vyncke, Georg Carle, Ivan Nardi, Jari Arkko, Jason Livingood, Jiankang Yao, Karen O'Donoghue, Keith Winstein, Lars Eggert, Laurent Vanbever, Luca Deri, Mallory Knodel, Marcus Ihlar, Matteo, Michael Collins, Michael Richardson, Michael Welzl, Mike Ackermann, Mirja Kühlewind, Mohit P. Tahiliani, Nalini Elkins, Patrick Tarpey, Paul Grubbs, Pedro Casas, Qin Wu, Qiufang Ma, Richard Barnes, Rob Wilton, Russ White, Saloua Naama, Shinan Liu, Srinivas C, Toerless Eckert, Tommy Pauly, Wes Hardaker, Xi Chase Jiang, Zaheduzzaman Sarker, and Zhenbin Li.
ワークショップの参加者は、シンディ・モーガン、コリン・パーキンス、カレン・ジェニングス、デボラ・ブルンガード、ドルフ・ドディ、エリック・ヴィンケ、ジョージ・カール、イヴァン・ナルディ、ジャリ・アークコ、ジェイソン・リビングウッド、ジアンカン・ヤオ、カレン・オウアンヴァンシュタイン、キース・ウィンスタイン、ラース、ルカ・デリ、マロリー・ノーデル、マーカス・イーラー、マッテオ、マイケル・コリンズ、マイケル・リチャードソン、マイケル・ウェルツル、マイク・アッカーマン、ミルジャ・キュルウィンド、モヒット・P・タヒリアーニ、ナリーニ・エルキンス、パトリック・ターピー、ポール・グラブス、ペドロ・カサス、キン・ワウ、キューファン・マリチャード・バーンズ、ロブ・ウィルトン、ラス・ホワイト、サロウア・ナマ、シナン・リュー、スリニバスC、Toerless Eckert、Tommy Pauly、Wes Hardaker、Xi Chase Jiang、Zaheduzzaman Sarker、およびZhenbin Li。
The workshop program committee members were Wes Hardaker (IAB, USC/ ISI), Mallory Knodel (IAB, Center for Democracy and Technology), Mirja Kühlewind (IAB, Ericsson), Tommy Pauly (IAB, Apple), Russ White (IAB, Juniper), Qin Wu (IAB, Huawei).
ワークショッププログラム委員会のメンバーは、Wes Hardaker（IAB、USC/ ISI）、Mallory Knodel（IAB、Center for Democracy and Technology）、MirjaKühlewind（IAB、Ericsson）、Tommy Pauly（IAB、Apple）、Russ White（IAB、Joniperer）、Qin Wu（IAB、Huawei）。
Internet Architecture Board members at the time this document was approved for publication were:
インターネットアーキテクチャ委員会メンバーこの文書が公開されたときに承認された時点は次のとおりです。
Dhruv Dhody
dhruv dhody
Lars Eggert
ラース・エガート
Wes Hardaker
ウェス・ハーダーカー
Cullen Jennings
カレン・ジェニングス
Mallory Knodel
マロリーノーデル
Suresh Krishnan
Suresh Krishnan
Mirja Kühlewind
MirjaKühlewind
Tommy Pauly
トミーポーリー
Alvaro Retana
Alvaro Retana
David Schinazi
デビッド・シナジ
Christopher Wood
クリストファー・ウッド
Qin Wu
Qin Wu
Jiankang Yao
Jiankang Yao
We wish to acknowledge the comments and suggestions from Elliot Lear and Arnaud Taddei for their comments and improvements to this document.
この文書へのコメントと改善について、エリオット・リアとアルノー・タデイからのコメントと提案を認めたいと思います。
Mallory Knodel
Email: mknodel@cdt.org
Wes Hardaker
Email: ietf@hardakers.net
Tommy Pauly
Email: tpauly@apple.com