[要約] RFC 8462は、IABワークショップ「暗号化された世界での無線ネットワークの管理(MaRNEW)」の報告書です。このRFCの目的は、暗号化されたネットワーク環境における無線ネットワークの管理に関する課題と解決策を議論することです。

Internet Architecture Board (IAB)                              N. Rooney
Request for Comments: 8462                               S. Dawkins, Ed.
Category: Informational                                     October 2018
ISSN: 2070-1721
        

Report from the IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW)

暗号化された世界での無線ネットワークの管理に関するIABワークショップ(MaRNEW)からのレポート

Abstract

概要

The Internet Architecture Board (IAB) and GSM Association (GSMA) held a joint workshop on Managing Radio Networks in an Encrypted World (MaRNEW), on September 24-25, 2015. This workshop aimed to discuss solutions for bandwidth optimization on mobile networks for encrypted content, as current solutions rely on unencrypted content, which is not indicative of the security needs of today's Internet users. The workshop gathered IETF attendees, IAB members, and participants from various organizations involved in the telecommunications industry including original equipment manufacturers, content providers, and mobile network operators.

インターネットアーキテクチャボード(IAB)とGSMアソシエーション(GSMA)は、2015年9月24〜25日に、暗号化された世界での無線ネットワークの管理(MaRNEW)に関する共同ワークショップを開催しました。現在のソリューションは暗号化されていないコンテンツに依存しているため、暗号化されたコンテンツ。これは、今日のインターネットユーザーのセキュリティニーズを示すものではありません。ワークショップには、IETFの参加者、IABメンバー、および相手先ブランド供給業者、コンテンツプロバイダー、モバイルネットワークオペレーターなど、通信業界に関わるさまざまな組織の参加者が集まりました。

The group discussed Internet encryption trends and deployment issues identified within the IETF and the privacy needs of users that should be adhered to. Solutions designed around sharing data from the network to the endpoints and vice versa were then discussed; in addition, issues experienced when using current transport-layer protocols were also discussed. Content providers and Content Delivery Networks (CDNs) gave their own views of their experiences delivering their content with mobile network operators. Finally, technical responses to regulation were discussed to help the regulated industries relay the issues of impossible-to-implement or bad-for-privacy technologies back to regulators.

このグループは、IETF内で特定されたインターネット暗号化の傾向と展開の問題、および遵守する必要があるユーザーのプライバシーの必要性について議論しました。次に、ネットワークからエンドポイントへ、またはその逆にデータを共有するように設計されたソリューションについて説明しました。さらに、現在のトランスポート層プロトコルを使用するときに発生する問題についても説明しました。コンテンツプロバイダーとコンテンツ配信ネットワーク(CDN)は、モバイルネットワークオペレーターにコンテンツを配信する体験について、独自の見解を示しました。最後に、規制への技術的対応について話し合い、規制対象の業界が実装不可能またはプライバシーに不利な技術の問題を規制当局に伝えるのを支援しました。

A group of suggested solutions were devised, which will be discussed in various IETF groups moving forward.

提案されたソリューションのグループが考案されました。これについては、今後さまざまなIETFグループで議論されます。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

このドキュメントはインターネットアーキテクチャボード(IAB)の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。これは、インターネットアーキテクチャボード(IAB)のコンセンサスを表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8462.

このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc8462で入手できます。

Copyright Notice

著作権表示

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(c)2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。

Table of Contents

目次

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Understanding "Bandwidth Optimization"  . . . . . . . . .   4
     1.2.  Topics  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     1.3.  Organization of This Report . . . . . . . . . . . . . . .   5
     1.4.  Use of Note Well and the Chatham House Rule . . . . . . .   6
     1.5.  IETF and GSMA . . . . . . . . . . . . . . . . . . . . . .   6
   2.  Scene-Setting Sessions  . . . . . . . . . . . . . . . . . . .   7
     2.1.  Scene Setting . . . . . . . . . . . . . . . . . . . . . .   7
       2.1.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . .   8
       2.1.2.  Encryption Statistics and Radio Access Network
               Differences . . . . . . . . . . . . . . . . . . . . .   8
     2.2.  Encryption Deployment Considerations  . . . . . . . . . .   9
     2.3.  Awareness of User Choice (Privacy)  . . . . . . . . . . .  10
   3.  Network or Transport Solution Sessions  . . . . . . . . . . .  11
     3.1.  Sending Data Up/Down for Network Management Benefits  . .  11
       3.1.1.  Competition, Cooperation, and Mobile Network
               Complexities  . . . . . . . . . . . . . . . . . . . .  12
   4.  Transport Layer: Issues, Optimization, and Solutions  . . . .  13
   5.  Application-Layer Optimization, Caching, and CDNs . . . . . .  14
   6.  Technical Analysis and Response to Potential Regulatory
       Reaction  . . . . . . . . . . . . . . . . . . . . . . . . . .  15
   7.  Suggested Principles and Solutions  . . . . . . . . . . . . .  16
     7.1.  Better Collaboration  . . . . . . . . . . . . . . . . . .  19
   8.  Since MaRNEW  . . . . . . . . . . . . . . . . . . . . . . . .  19
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
   11. Informative References  . . . . . . . . . . . . . . . . . . .  20
   Appendix A.  Workshop Attendees . . . . . . . . . . . . . . . . .  24
   Appendix B.  Workshop Position Papers . . . . . . . . . . . . . .  26
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  28
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28
        
1. Introduction
1. はじめに

The Internet Architecture Board (IAB) and GSM Association (GSMA) held a joint workshop on Managing Radio Networks in an Encrypted World (MaRNEW), on September 24-25, 2015. This workshop aimed to discuss solutions for bandwidth optimization on mobile networks for encrypted content, as current solutions rely on unencrypted content, which is not indicative of the security needs of today's Internet users.

インターネットアーキテクチャボード(IAB)とGSMアソシエーション(GSMA)は、2015年9月24〜25日に、暗号化された世界での無線ネットワークの管理(MaRNEW)に関する共同ワークショップを開催しました。現在のソリューションは暗号化されていないコンテンツに依存しているため、暗号化されたコンテンツ。これは、今日のインターネットユーザーのセキュリティニーズを示すものではありません。

Mobile networks have a set of properties that place a large emphasis on sophisticated bandwidth optimization. The use of encryption is increasing on the Internet, which is positive for consumer and business privacy and security. Many existing solutions for mobile bandwidth optimization primarily operate on non-encrypted communications; this can lead to performance issues being amplified on mobile networks. The use of encryption on networks will continue to increase; with this understanding, the workshop aimed to understand how we can solve the issues of bandwidth optimization and performance on radio networks in this encrypted world.

モバイルネットワークには、高度な帯域幅の最適化に大きな重点を置く一連のプロパティがあります。暗号化の使用はインターネットで増加しており、これは消費者および企業のプライバシーとセキュリティにプラスです。モバイル帯域幅最適化のための多くの既存のソリューションは、主に非暗号化通信で動作します。これにより、モバイルネットワークでパフォーマンスの問題が増幅する可能性があります。ネットワークでの暗号化の使用は増加し続けます。この理解とともに、ワークショップは、この暗号化された世界の無線ネットワークにおける帯域幅の最適化とパフォーマンスの問題をどのように解決できるかを理解することを目的としています。

1.1. Understanding "Bandwidth Optimization"
1.1. 「帯域幅の最適化」について

For the purposes of this workshop, bandwidth optimization encompasses a variety of technical topics related to traffic engineering, prioritization, optimization, and efficiency enhancements. It also encompasses user-related topics such as specific subscription or billing models, and it may touch upon regulatory aspects or other issues relating to government-initiated regulatory concerns.

このワークショップでは、帯域幅の最適化には、トラフィックエンジニアリング、優先順位付け、最適化、および効率の向上に関連するさまざまな技術トピックが含まれます。また、特定のサブスクリプションや請求モデルなどのユーザー関連のトピックも含まれており、規制の側面や政府主導の規制の懸念に関連するその他の問題に触れる場合があります。

The first category of bandwidth optimization includes the following:

帯域幅最適化の最初のカテゴリには、次のものが含まれます。

o Caching

o キャッシング

o Prioritization of interactive traffic over background traffic

o バックグラウンドトラフィックに対するインタラクティブトラフィックの優先順位付け

o Per-user bandwidth limits

o ユーザーごとの帯域幅制限

The second category of bandwidth optimization may depend on one or more of the first category optimization strategies, but may, in particular, also encompass business-related topics such as content delivery arrangements with content providers.

帯域幅最適化の2番目のカテゴリは、1番目のカテゴリの最適化戦略の1つ以上に依存しますが、特に、コンテンツプロバイダーとのコンテンツ配信の取り決めなど、ビジネス関連のトピックも含まれます。

Finally, while not strictly speaking of traffic management, some networks employ policy-based filtering (e.g., requested parental controls), and many networks support some form of legal interception functionality per applicable laws.

最後に、トラフィック管理について厳密に述べていませんが、一部のネットワークはポリシーベースのフィルタリング(例:要求されたペアレンタルコントロール)を採用しており、多くのネットワークは適用される法律に従って何らかの形式の法的傍受機能をサポートしています。

Many of these functions can continue as they are performed today, even with increased use of encryption. Others are using methods that inspect parts of the communication that are not encrypted today, but will be encrypted, and these functions will have to be done differently in an increasingly encrypted Internet.

これらの機能の多くは、暗号化の使用が増加しても、現在実行されているまま続行できます。他の人は、今日暗号化されていないが暗号化される通信の一部を検査する方法を使用しており、これらの機能はますます暗号化されるインターネットで異なって行われる必要があります。

1.2. Topics
1.2. トピック

The workshop aimed to answer questions that focused on:

ワークショップは、以下に焦点を当てた質問に答えることを目的としました。

o understanding the bandwidth optimization use cases particular to radio networks;

o 無線ネットワークに固有の帯域幅最適化の使用例を理解する。

o understanding existing approaches and how these do not work with encrypted traffic;

o 既存のアプローチと、これらが暗号化されたトラフィックで機能しない方法を理解する。

o understanding reasons why the Internet has not standardized support for lawful intercept and why mobile networks have;

o インターネットが合法的傍受の標準化されたサポートを持たない理由、およびモバイルネットワークが持つ理由を理解する。

o determining how to match traffic types with bandwidth optimization methods

o トラフィックタイプを帯域幅最適化方法と照合する方法の決定

o discussing minimal information to be shared to manage networks but ensure user security and privacy;

o ネットワークを管理し、ユーザーのセキュリティとプライバシーを確​​保するために共有される最小限の情報について話し合う。

o developing new bandwidth optimization techniques and protocols within these new constraints;

o これらの新しい制約内で新しい帯域幅最適化技術とプロトコルを開発する。

o discussing the appropriate network layer(s) for each management function; and

o 各管理機能に適切なネットワーク層について話し合う。そして

o cooperative methods of bandwidth optimization and issues associated with these.

o 帯域幅の最適化の協力的な方法とこれらに関連する問題。

The further aim was to gather architectural and engineering guidance on future work in the bandwidth optimization area based on the discussions around the proposed approaches. The workshop also explored possible areas for standardization, e.g., new protocols that can aid bandwidth optimization whilst ensuring that user security is in line with new work in transport-layer protocols.

さらなる目的は、提案されたアプローチに関する議論に基づいて、帯域幅最適化分野での将来の作業に関するアーキテクチャとエンジニアリングのガイダンスを収集することでした。また、ワークショップでは、帯域幅の最適化を支援しながら、ユーザーのセキュリティがトランスポート層プロトコルの新しい作業と一致していることを確認しながら、標準化が可能な領域についても調査しました。

1.3. Organization of This Report
1.3. このレポートの構成

This workshop report summarizes the contributions to and discussions at the workshop, organized by topic. The workshop began with scene-setting topics that covered the issues around deploying encryption, the increased need for privacy on the Internet, and setting a clear understanding that ciphertext should remain unbroken. Later sessions focused on key solution areas; these included evolution on the transport layer and sending data up or down the path. A session on application layers and CDNs aimed to highlight both issues and solutions experienced on the application layer. The workshop ended with a session dedicated to discussing a technical response to regulation with regards to encryption. The contributing documents identified the issues experienced with encryption on radio networks and suggested solutions. Of the solutions suggested, some focused on transport evolution, some on trusted middleboxes, and others on collaborative data exchange. Solutions were discussed within the sessions. All accepted position papers and detailed transcripts of discussion are available at [MARNEW].

このワークショップレポートは、ワークショップへの貢献とディスカッションをトピック別にまとめたものです。ワークショップは、暗号化の導入、インターネット上でのプライバシーの必要性の増加、および暗号文をそのままにしておくべきであるという明確な理解を設定する問題をカバーするシーン設定トピックから始まりました。その後のセッションでは、主要なソリューション領域に焦点を当てました。これらには、トランスポート層での進化とパス上または下へのデータ送信が含まれます。アプリケーション層とCDNに関するセッションは、アプリケーション層で発生した問題と解決策の両方を強調することを目的としています。ワークショップは、暗号化に関する規制への技術的対応について議論するためのセッションで終了しました。寄稿文書では、無線ネットワークでの暗号化で発生した問題と推奨される解決策を特定しました。提案されたソリューションのうち、一部はトランスポートの進化に、一部は信頼できるミドルボックスに、その他は協調的データ交換に焦点を合わせました。解決策はセッション内で議論されました。承認されたすべてのポジションペーパーとディスカッションの詳細な筆記録は、[MARNEW]で入手できます。

The outcomes of the workshop are discussed in Sections 7 and 8; they discuss the progress made since the workshop toward each of the identified work items through the time this document was approved for publication.

ワークショップの結果については、セクション7および8で説明します。彼らは、ワークショップ以降、このドキュメントの公開が承認されるまでの、特定された各作業項目に向けた進捗状況について話し合っています。

Report readers should be reminded that this workshop did not aim to discuss regulation or legislation, although policy topics were mentioned in discussions from time to time.

報告書の読者は、このワークショップが規制や法律の議論を目的としたものではなかったことを思い出してください。

1.4. Use of Note Well and the Chatham House Rule
1.4. Note WellとChatham House Ruleの使用

The workshop was conducted under the IETF [NOTE_WELL] with the exception of the "Technical Analysis and Response to Potential Regulatory Reaction" session, which was conducted under the [CHATHAM_HOUSE_RULE].

このワークショップは、[CHATHAM_HOUSE_RULE]の下で行われた「潜在的な規制反応に対する技術分析と対応」セッションを除いて、IETF [NOTE_WELL]の下で行われました。

1.5. IETF and GSMA
1.5. IETFおよびGSMA

The IETF and GSMA [GSMA] have different working practices, standards, and processes. IETF is an open organization with community-driven standards, with the key aim of functionality and security for the Internet's users, while the GSMA is membership based and serves the needs of its membership base, most of whom are mobile network operators.

IETFとGSMA [GSMA]には、異なる作業慣行、標準、プロセスがあります。 IETFは、コミュニティ主導の標準を備えたオープンな組織であり、インターネットのユーザー向けの機能とセキュリティを主な目的としています。一方、GSMAはメンバーシップベースであり、そのほとんどがモバイルネットワークオペレーターであるメンバーシップベースのニーズに対応しています。

Unlike IETF, GSMA makes few standards. Within the telecommunications industry, standards are set in various divergent groups depending on their purpose. Perhaps of most relevance to the bandwidth optimization topic here is the work of the 3rd Generation Partnership Project (3GPP) [SDO_3GPP], which works on radio network and core network standards. 3GPP members include mobile operators and original equipment manufacturers.

IETFとは異なり、GSMAはいくつかの標準を作成します。電気通信業界では、目的に応じてさまざまなグループで標準が設定されています。おそらく、ここでの帯域幅最適化のトピックに最も関連するのは、無線ネットワークおよびコアネットワーク標準で機能する第3世代パートナーシッププロジェクト(3GPP)[SDO_3GPP]の作業です。 3GPPのメンバーには、携帯電話会社と相手先ブランド供給業者が含まれます。

One of the 3GPP standards relevant to this workshop is Policy and Charging Control QoS [PCC-QOS]. Traditionally, mobile networks have managed different applications and services based on the resources available and priorities given; for instance, emergency services have a top priority, data has a lower priority, and voice services are somewhere in-between. 3GPP defined the PCC-QoS mechanism to support this functionality, and this depends on unencrypted communications [EffectEncrypt].

このワークショップに関連する3GPP標準の1つは、ポリシーおよび課金制御QoS [PCC-QOS]です。従来、モバイルネットワークは、利用可能なリソースと与えられた優先順位に基づいて、さまざまなアプリケーションとサービスを管理してきました。たとえば、緊急サービスの優先順位が最も高く、データの優先順位が低く、音声サービスがその中間にあります。 3GPPは、この機能をサポートするPCC-QoSメカニズムを定義しました。これは、暗号化されていない通信[EffectEncrypt]に依存します。

2. Scene-Setting Sessions
2. シーン設定セッション

Scene-setting sessions aimed to bring all attendees up to a basic understanding of the problem and the scope of the workshop.

すべての参加者に問題とワークショップの範囲の基本的な理解を促すことを目的としたシーン設定セッション。

There were three scene-setting sessions:

3つのシーン設定セッションがありました。

o Section 2.1: Scene Setting

o セクション2.1:シーン設定

o Section 2.2: Encryption Deployment Considerations

o セクション2.2:暗号化の展開に関する考慮事項

o Section 2.3: Awareness of User Choice (Privacy)

o セクション2.3:ユーザー選択の認識(プライバシー)

2.1. Scene Setting
2.1. シーン設定

The telecommunications industry and Internet standards community are extremely different in terms of ethos and practices. Both groups drive technical standards in their domain and build technical solutions with some policy-driven use cases. These technologies, use cases, and technical implementations are different, and the motivators between the two industries are also diverse.

電気通信業界とインターネット標準化コミュニティは、精神と実践の点で非常に異なります。どちらのグループも、ドメイン内の技術標準を推進し、いくつかのポリシー主導のユースケースで技術ソリューションを構築します。これらのテクノロジー、ユースケース、および技術的な実装は異なり、2つの業界間の動機も多様です。

To ensure all attendees were aligned with contributing to discussions and driving solutions, this "Scene Setting" session worked on generating a clear scope with all attendees involved. In short, it was agreed that 1) ciphertext encrypted by one party and intended to be decrypted by a second party should not be decrypted by a third party in any solution, 2) the Radio Access Network (RAN) does experience issues with increased encrypted traffic, 3) the RAN issues need to be understood precisely, and 4) the goal is to improve user experience on the Internet. Proposing new technical solutions based on presumed future regulation was not in scope. The full scope is given below.

すべての参加者がディスカッションへの貢献とソリューションの推進に確実に対応できるように、この「シーン設定」セッションでは、すべての参加者が関与する明確なスコープの生成に取り組みました。要するに、1)ある当事者によって暗号化され、第2の当事者によって復号化されることを意図した暗号文は、いかなるソリューションにおいても第三者によって復号化されるべきではない、2)無線アクセスネットワーク(RAN)は暗号化の増加に関する問題を経験することで合意されましたトラフィック、3)RANの問題を正確に理解する必要があります。4)目標は、インターネット上のユーザーエクスペリエンスを向上させることです。推定される将来の規制に基づいて新しい技術ソリューションを提案することは範囲外でした。完全なスコープを以下に示します。

2.1.1. Scope
2.1.1. 範囲

The attendees identified and agreed to the scope described here.

出席者は、ここで説明されている範囲を特定して同意しました。

We should do the following:

次のことを行う必要があります。

o in discussion, assume that there is no broken crypto; ciphertext is increasingly common; congestion does need to be controlled (as do other transport issues); and network management, including efficient use of resources in RAN and elsewhere, has to work;

o 議論では、壊れた暗号がないと仮定します。暗号文はますます一般的になっています。混雑を制御する必要があります(他の輸送問題と同様に)。 RANや他の場所でのリソースの効率的な使用を含むネットワーク管理が機能する必要があります。

o identify how/why RAN is different for transport, and attempt to understand the complexities of RAN (i.e., how hard it is to manage) and why those complexities matter;

o RANがトランスポートでどのように/なぜ異なるのかを特定し、RANの複雑さ(つまり、管理がどれほど難しいか)とそれらの複雑さが重要である理由を理解しようとします。

o identify the precise problems caused by increased use of encryption;

o 暗号化の使用の増加によって引き起こされる正確な問題を特定します。

o identify players (in addition to end users), the resulting tensions, and how ciphertext changes those tensions;

o プレーヤー(エンドユーザーに加えて)、結果として生じる緊張、および暗号文がそれらの緊張をどのように変化させるかを特定します。

o discuss how some solutions will be radically changed by ciphertext (it's ok to talk about that)

o いくつかの解決策が暗号文によって根本的に変更される方法について話し合う(それについて話すことは問題ない)

o assume that the best possible quality of experience for the end user is a goal; and lastly,

o エンドユーザーにとって最高のエクスペリエンス品質が目標であると想定します。そして最後に、

o for the next two days, aim to analyze the situation and identify specific achievable tasks that could be tackled in the IETF or GSMA (or elsewhere) and that improve the Internet given the assumptions above.

o 次の2日間は、状況を分析し、IETFまたはGSMA(またはその他の場所)で取り組むことができる特定の達成可能なタスクを特定し、上記の前提でインターネットを改善することを目指します。

We should not delve into the following:

次のことは詳しく説明しないでください。

o ways of doing interception, legal or not, for the reasons described in [RFC2804]; and,

o [RFC2804]で説明されている理由により、合法的かどうかにかかわらず、傍受を行う方法そして、

o unpredictable political actions.

o 予測できない政治行動。

2.1.2. Encryption Statistics and Radio Access Network Differences
2.1.2. 暗号化統計と無線アクセスネットワークの違い

According to then-current statistics, attendees were shown that encrypted content reaches around 50% [STATE_BROWSER] [STATE_SERVER]. The IAB is encouraging all IETF working groups to consider the effect encryption being "on by default" will have on new protocol work. The IETF is also working on encryption at lower layers. One recent example of this work is opportunistic TCP encryption within the TCP Increased Security [TCPINC] Working Group. The aims of these work items are greater security and privacy for end users and their data.

当時の統計によると、参加者は暗号化されたコンテンツが約50%[STATE_BROWSER] [STATE_SERVER]に到達することを示しました。 IABは、すべてのIETFワーキンググループに対して、暗号化が「デフォルトでオン」であることによる新しいプロトコルの動作への影響を検討することを奨励しています。 IETFは、下位層での暗号化にも取り組んでいます。この作業の最近の1つの例は、TCPセキュリティ強化[TCPINC]ワーキンググループ内の便宜的なTCP暗号化です。これらの作業項目の目的は、エンドユーザーとそのデータのセキュリティとプライバシーを強化することです。

Telecommunications networks often contain middleboxes that operators have previously considered to be trusted, but qualifying trust is difficult and should not be assumed. Some interesting use cases exist with these middleboxes, such as anti-spam and malware detection, but these need to be balanced against their ability to open up cracks in the network for attacks such as pervasive monitoring.

通信ネットワークには、オペレーターが以前は信頼できると見なしていたミドルボックスが含まれていることがよくありますが、適格な信頼は困難であり、想定するべきではありません。これらのミドルボックスには、スパム対策やマルウェアの検出など、いくつかの興味深い使用例がありますが、これらは、広範な監視などの攻撃のためにネットワークの亀裂を広げる能力とのバランスを取る必要があります。

When operators increase the number of radio access network cells (base stations), this can improve the radio access network quality of service; however, it also adds to radio pollution. This is one example of the balancing act required when devising radio access network architecture.

事業者が無線アクセスネットワークセル(基地局)の数を増やすと、無線アクセスネットワークのサービス品質が向上します。しかし、それはまた、放射能汚染を増加させます。これは、無線アクセスネットワークアーキテクチャを考案する際に必要なバランシング動作の一例です。

2.2. Encryption Deployment Considerations
2.2. 暗号化の導入に関する考慮事項

Encryption across the Internet is on the rise. However, some organizations and individuals that are mainly driven by commercial perspectives come across a common set of operational issues when deploying encryption. [RFC8404] explains these network management function impacts, detailing areas around incident monitoring, access control management, and regulation on mobile networks. The data was collected from various Internet players, including system and network administrators across enterprise, governmental organizations, and personal use. The aim of the document is to gain an understanding of what is needed for technical solutions to these issues while maintaining security and privacy for users. Attendees commented that worthwhile additions would be different business environments (e.g., cloud environments) and service chaining. Incident monitoring in particular was noted as a difficult issue to solve given the use of URLs in today's incident monitoring middleware.

インターネットを介した暗号化が増加しています。ただし、主に商業的な視点から推進されている一部の組織や個人は、暗号化を展開するときに、運用上の共通の問題に遭遇します。 [RFC8404]は、これらのネットワーク管理機能の影響、インシデントモニタリング、アクセス制御管理、およびモバイルネットワークの規制に関する詳細を説明しています。データは、企業、政府機関、個人使用のシステム管理者やネットワーク管理者など、さまざまなインターネットプレーヤーから収集されました。このドキュメントの目的は、ユーザーのセキュリティとプライバシーを維持しながら、これらの問題の技術的なソリューションに必要なものを理解することです。出席者は、価値のある追加は異なるビジネス環境(クラウド環境など)とサービスチェーンになるとコメントしました。特にインシデントモニタリングは、今日のインシデントモニタリングミドルウェアでURLを使用する場合、解決が難しい問題として指摘されました。

Some of these impacts to mobile networks can be resolved using different methods, and the [NETWORK_MANAGEMENT] document details these methods. The document focuses heavily on methods to manage network traffic without breaching user privacy and security.

モバイルネットワークへのこれらの影響の一部は、さまざまな方法を使用して解決できます。[NETWORK_MANAGEMENT]ドキュメントでは、これらの方法について詳しく説明しています。このドキュメントは、ユーザーのプライバシーとセキュリティを侵害することなくネットワークトラフィックを管理する方法に重点を置いています。

By reviewing encryption deployment issues and the alternative methods of network management, MaRNEW attendees were made aware of the issues that affect radio networks, the deployment issues that are solvable and require no further action, and those issues that have not yet been solved but should be addressed within the workshop.

暗号化の展開の問題とネットワーク管理の代替方法を確認することにより、MaRNEWの参加者は、無線ネットワークに影響を与える問題、解決可能でそれ以上のアクションを必要としない展開の問題、およびまだ解決されていないが解決すべき問題を認識しました。ワークショップで取り上げられました。

2.3. Awareness of User Choice (Privacy)
2.3. ユーザー選択の認識(プライバシー)

Some solutions intended to improve delivery of encrypted content could affect some or all of the privacy benefits that encryption provides. Understanding user needs and desires for privacy is therefore important when designing these solutions.

暗号化されたコンテンツの配信を改善することを目的とした一部のソリューションは、暗号化によって提供されるプライバシー上の利点の一部またはすべてに影響を与える可能性があります。したがって、これらのソリューションを設計するときは、プライバシーに対するユーザーのニーズと要望を理解することが重要です。

From a then-current study [Pew2014], 64% of users said concerns over privacy have increased, and 67% of mobile Internet users would like to do more to protect their privacy. The World Wide Web Consortium (W3C) and IETF have both responded to user desires for better privacy by recommending encryption for new protocols and web technologies. Within the W3C, new security standards are emerging, and the design principles for HTML maintain that users are the stakeholders with the highest priority, followed by implementors and other stakeholders, which further enforces the "user first" principle. Users also have certain security expectations from particular contexts and sometimes use new technologies to further protect their privacy, even if those technologies weren't initially developed for that purpose.

当時最新の調査[Pew2014]から、64%のユーザーがプライバシーへの懸念が高まっていると述べ、67%のモバイルインターネットユーザーがプライバシーを保護するためにより多くのことを望んでいます。ワールドワイドウェブコンソーシアム(W3C)とIETFはどちらも、新しいプロトコルとウェブテクノロジーの暗号化を推奨することで、プライバシーの向上を求めるユーザーの要望に応えてきました。 W3C内では新しいセキュリティ標準が出現しており、HTMLの設計原則では、ユーザーが最優先の利害関係者であり、実装者やその他の利害関係者がそれに続き、「ユーザー優先」の原則がさらに実施されます。ユーザーは、特定のコンテキストから特定のセキュリティを期待しており、新しいテクノロジーを使用してプライバシーをさらに保護する場合があります。たとえそれらのテクノロジーが最初にその目的のために開発されていなかったとしてもです。

Operators may deploy technologies that can either impact user privacy without being aware of those privacy implications or incorrectly assume that the benefits users gain from the new technology outweigh the loss of privacy. If these technologies are necessary, they should be opt in.

オペレーターは、プライバシーの影響を認識せずにユーザーのプライバシーに影響を与える可能性のあるテクノロジーを展開するか、ユーザーが新しいテクノロジーから得られる利点がプライバシーの喪失を上回ると誤って想定する場合があります。これらのテクノロジーが必要な場合は、オプトインする必要があります。

Internet stakeholders should understand the priority of other stakeholders. Users should be considered the first priority. Other stakeholders include implementors, developers, advertisers, operators, and other ISPs. Some technologies, such as cookie use and JavaScript injection, have been abused by these parties. This has caused some developers to encrypt content to circumvent these technologies that are seen as intrusive or bad for user privacy.

インターネットの利害関係者は、他の利害関係者の優先順位を理解する必要があります。ユーザーを最優先する必要があります。その他の利害関係者には、実装者、開発者、広告主、事業者、およびその他のISPが含まれます。 Cookieの使用やJavaScriptインジェクションなどの一部のテクノロジーは、これらの関係者によって悪用されています。これにより、一部の開発者はコンテンツを暗号化して、ユーザーのプライバシーを侵害する、またはユーザーのプライバシーを害するこれらのテクノロジーを回避しています。

If users and content providers are to opt in to network management services with negative privacy impacts, they should see clear value from using these services and understand the impacts of using these services. Users should also have easy abilities to opt out. Some users will always automatically click through consent requests, so any model relying on explicit consent is flawed for these users. Understanding the extent of "auto click-through" may improve decisions about the use of consent requests in the future. One model (Cooperative Traffic Management) works as an agent of the user; by opting in, metadata can be shared. Issues with this involve trust only being applied at endpoints.

ユーザーとコンテンツプロバイダーがプライバシーに悪影響を与えるネットワーク管理サービスをオプトインする場合は、これらのサービスを使用することによる明確な価値を確認し、これらのサービスの使用による影響を理解する必要があります。また、ユーザーは簡単にオプトアウトできるようにする必要があります。一部のユーザーは常に自動的に同意リクエストをクリックするため、明示的な同意に依存するモデルには、これらのユーザーの欠陥があります。 「自動クリックスルー」の範囲を理解すると、将来の同意リクエストの使用に関する決定が改善される可能性があります。 1つのモデル(協調型トラフィック管理)は、ユーザーのエージェントとして機能します。オプトインすることで、メタデータを共有できます。この問題には、エンドポイントでのみ適用される信頼が含まれます。

3. Network or Transport Solution Sessions
3. ネットワークまたはトランスポートソリューションセッション

Network or Transport Solution Sessions discussed proposed solutions for managing encrypted traffic on radio access networks. Most solutions focus on metadata sharing, whether this sharing takes place from the endpoint to the network, from the network to the endpoint, or cooperatively in both directions. Transport-layer protocol evolution could be another approach to solve some of the issues radio access networks experience, which cause them to rely on network management middleboxes. By removing problems at the transport layer, reliance on expensive and complex middleboxes could decrease.

ネットワークまたはトランスポートソリューションセッションでは、無線アクセスネットワーク上の暗号化されたトラフィックを管理するための提案されたソリューションについて説明しました。ほとんどのソリューションは、メタデータの共有に焦点を当てています。この共有がエンドポイントからネットワークへ、ネットワークからエンドポイントへ、または両方向で協調して行われるかどうかにかかわらずです。トランスポート層プロトコルの進化は、無線アクセスネットワークがネットワーク管理ミドルボックスに依存する原因となる問題のいくつかを解決するための別のアプローチになる可能性があります。トランスポート層で問題を取り除くことにより、高価で複雑なミドルボックスへの依存を減らすことができます。

3.1. Sending Data Up/Down for Network Management Benefits
3.1. ネットワーク管理の利点のためのデータのアップ/ダウン送信

Collaboration between network elements and endpoints could bring about better content distribution. A number of suggestions were given; these included the following:

ネットワーク要素とエンドポイント間のコラボレーションにより、コンテンツ配信が改善される可能性があります。多くの提案がなされました。これらには以下が含まれます。

o Mobile Throughput Guidance [MTG]: exchanges metadata between network elements and endpoints via TCP options. It also allows for better understanding of how the transport protocol behaves and further improves the user experience, although additional work on MTG is still required.

o モバイルスループットガイダンス[MTG]:TCPオプションを介してネットワーク要素とエンドポイント間でメタデータを交換します。また、トランスポートプロトコルの動作の理解を深め、ユーザーエクスペリエンスをさらに向上させますが、MTGでの追加の作業は依然として必要です。

o Session Protocol for User Datagrams [SPUD]: a UDP-based encapsulation protocol to allow explicit cooperation with middleboxes while using, new encrypted transport protocols.

o ユーザーデータグラムのセッションプロトコル[SPUD]:UDPベースのカプセル化プロトコル。新しい暗号化されたトランスポートプロトコルを使用しながら、ミドルボックスと明示的に連携できます。

o Network Status API: an API for operators to share congestion status or the state of a cell before an application starts sending data that could allow applications to change their behavior.

o ネットワークステータスAPI:アプリケーションがデータの送信を開始する前にオペレーターが輻輳ステータスまたはセルの状態を共有するためのAPI。

o Traffic Classification: classifying traffic and adding these classifications as metadata for analysis throughout the network. This idea has trust and privacy implications.

o トラフィック分類:トラフィックを分類し、これらの分類をネットワーク全体で分析するためのメタデータとして追加します。このアイデアには、信頼とプライバシーの影響があります。

o Congestion Exposure [CONEX]: a mechanism where senders inform the network about the congestion encountered by previous packets on the same flow, in-band at the IP layer.

o Congestion Exposure [CONEX]:IP層の帯域内で同じフロー上の前のパケットが遭遇した輻輳について送信者がネットワークに通知するメカニズム。

o Latency versus Bandwidth: a bit that allows the content provider to indicate whether higher bandwidth or lower latency is of greater priority and allows the network to react based on that indication. Where this bit resides in the protocol stack and how it is authenticated would need to be decided.

o レイテンシと帯域幅:コンテンツプロバイダーがより高い帯域幅とより低いレイテンシのどちらを優先するかを示し、その指示に基づいてネットワークが反応できるようにするビット。このビットがプロトコルスタックのどこにあり、どのように認証されるかを決定する必要があります。

o No Network Management Tools: disabling all network management tools from the network and relying only on end-to-end protocols to manage congestion.

o ネットワーク管理ツールなし:ネットワークからすべてのネットワーク管理ツールを無効にし、輻輳を管理するためにエンドツーエンドプロトコルのみに依存します。

o Flow Queue Controlled Delay (FQ-CoDel) [FLOWQUEUE]: a hybrid packet scheduler / Active Queue Management (AQM) [RFC7567] algorithm aiming to reduce bufferbloat and latency. FQ-CoDel manages packets from multiple flows and reduces the impact of head-of-line blocking from bursty traffic.

o フローキュー制御遅延(FQ-CoDel)[FLOWQUEUE]:ハイブリッドパケットスケジューラ/アクティブキュー管理(AQM)[RFC7567]アルゴリズム。 FQ-CoDelは、複数のフローからのパケットを管理し、バースト性トラフィックによるヘッドオブラインブロッキングの影響を軽減します。

Some of these suggestions rely on signaling from network elements to endpoints. Others aim to create "hop-by-hop" solutions, which could be more aligned with how congestion is managed today but with greater privacy implications.

これらの提案の一部は、ネットワーク要素からエンドポイントへのシグナリングに依存しています。他の企業は、「ホップバイホップ」ソリューションを作成することを目指しています。これは、今日の輻輳の管理方法とより整合する可能性がありますが、プライバシーに大きな影響を与えます。

Still others rely on signaling from endpoints to network elements. Some of these rely on implicit signaling and others on explicit signaling. Some workshop attendees agreed that relying on applications to explicitly declare the quality of service they require was not a good path forward given the lack of success with this model in the past.

さらに、エンドポイントからネットワーク要素へのシグナリングに依存するものもあります。これらの一部は、暗黙的なシグナリングに依存し、その他は明示的なシグナリングに依存します。一部のワークショップ参加者は、必要なサービスの品質を明示的に宣言するためにアプリケーションに依存することは、過去のこのモデルでの成功の欠如を考えると、良い前進ではないことに同意しました。

3.1.1. Competition, Cooperation, and Mobile Network Complexities
3.1.1. 競争、協力、モバイルネットワークの複雑さ

One of the larger issues in sharing data about the problems encountered with encrypted traffic in wireless networks is the matter of competition; network operators are reluctant to relinquish data about their own networks because it contains information that is valuable to competitors, and application providers wish to protect their users and reveal as little information as possible to the network. Some people think that if middleboxes were authenticated and invoked explicitly, this would be an improvement over current transparent middleboxes that intercept traffic without endpoint consent. Some workshop attendees suggested any exchange of information should be bidirectional in an effort to improve cooperation between the elements. A robust incentive framework could provide a solution to these issues or at least help mitigate them.

ワイヤレスネットワークで暗号化されたトラフィックで発生する問題についてデータを共有する際の大きな問題の1つは、競争の問題です。ネットワークオペレーターは、自社のネットワークに関するデータを放棄することに消極的です。これは、競合他社にとって貴重な情報が含まれており、アプリケーションプロバイダーは、ユーザーを保護し、できるだけ少ない情報をネットワークに公開したいと考えているためです。一部の人々は、ミドルボックスが認証されて明示的に呼び出された場合、エンドポイントの同意なしにトラフィックを傍受する現在の透過的なミドルボックスよりも改善されると考えています。一部のワークショップ参加者は、要素間の協力を改善するために、情報の交換は双方向であるべきだと提案しました。強力なインセンティブフレームワークは、これらの問題の解決策を提供するか、少なくともそれらの緩和に役立ちます。

The radio access network is complex because it must deal with a number of conflicting demands. Base stations reflect this environment, and information within these base stations can be of value to other entities on the path. Some workshop participants thought solutions for managing congestion on radio networks should involve the base station if possible. For instance, understanding how the radio resource controller and AQM [RFC7567] interact (or don't interact) could provide valuable information for solving issues. Although many workshop attendees agreed that even though there is a need to understand the base station, not all agreed that the base station should be part of a future solution.

無線アクセスネットワークは、多くの相反する要求に対処する必要があるため、複雑です。基地局はこの環境を反映しており、これらの基地局内の情報は、パス上の他のエンティティにとって価値があります。一部のワークショップ参加者は、無線ネットワークの輻輳を管理するためのソリューションには、可能であれば基地局を含める必要があると考えていました。たとえば、無線リソースコントローラーとAQM [RFC7567]がどのように相互作用する(または相互作用しない)かを理解することで、問題を解決するための貴重な情報を得ることができます。多くのワークショップ参加者は、基地局を理解する必要があるとしても、基地局が将来のソリューションの一部であることに同意するわけではありませんでした。

Some suggested solutions were based on network categorization and on providing this information to the protocols or endpoints. Completely categorizing radio networks could be impossible due to their complexity, but categorizing essential network properties could be possible and valuable.

いくつかの提案されたソリューションは、ネットワークの分類と、この情報をプロトコルまたはエンドポイントに提供することに基づいていました。無線ネットワークは複雑なため、完全に分類することは不可能かもしれませんが、重要なネットワークプロパティを分類することは可能で価値があります。

4. Transport Layer: Issues, Optimization, and Solutions
4. トランスポート層:問題、最適化、およびソリューション

TCP has been the dominant transport protocol since TCP/IP replaced the Network Control Protocol (NCP) on the ARPANET in March 1983. TCP was originally devised to work on a specific network model that did not anticipate the high error rates and highly variable available bandwidth scenarios experienced on modern radio access networks.

TCPは、1983年3月にARPANETのネットワーク制御プロトコル(NCP)に取って代わって以来、主要なトランスポートプロトコルでした。TCPは、当初、高いエラー率と使用可能な帯域幅の変動が予想されない特定のネットワークモデルで動作するように考案されました最新の無線アクセスネットワークで経験したシナリオ。

Furthermore, new network elements have been introduced (NATs and network devices with large buffers creating bufferbloat), and considerable peer-to-peer traffic is competing with traditional client-server traffic. Consequently, the transport layer today has requirements beyond what TCP was designed to meet. TCP has other issues as well; too many services rely on TCP and only TCP, blocking deployment of new transport protocols like the Stream Control Transmission Protocol (SCTP) and Datagram Congestion Control Protocol (DCCP). This means that true innovation on the transport layer becomes difficult because deployment issues are more complicated than just building a new protocol.

さらに、新しいネットワーク要素が導入され(NATと大きなバッファを備えたネットワークデバイスがバッファブロートを作成する)、かなりのピアツーピアトラフィックが従来のクライアントサーバートラフィックと競合しています。その結果、今日のトランスポート層には、TCPが満たすように設計された以上の要件があります。 TCPには他の問題もあります。あまりにも多くのサービスがTCPとTCPのみに依存しており、ストリーム制御伝送プロトコル(SCTP)やデータグラム輻輳制御プロトコル(DCCP)などの新しいトランスポートプロトコルの展開をブロックしています。これは、トランスポート層の真の革新が困難になることを意味します。なぜなら、デプロイメントの問題は、単に新しいプロトコルを構築するよりも複雑だからです。

The IETF is trying to solve these issues through the IAB's IP Stack Evolution program, and the first step in this program is to collect data. Network and content providers can provide data including: the cost of encryption, the advantages of network management tools, the deployment of protocols, and the effects when network management tools are disabled. For mostly competitive reasons, network operators do not tend to reveal network information and so are unlikely to donate this information freely to the IETF. The GSMA is in a position to try to collect this data and anonymize it before bringing it to IETF, which should alleviate the network operator worries but still provide IETF with some usable data.

IETFはIABのIP Stack Evolutionプログラムを通じてこれらの問題を解決しようとしています。このプログラムの最初のステップはデータの収集です。ネットワークおよびコンテンツプロバイダーは、暗号化のコスト、ネットワーク管理ツールの利点、プロトコルの展開、ネットワーク管理ツールが無効になっている場合の影響などのデータを提供できます。主に競争上の理由から、ネットワークオペレーターはネットワーク情報を公開する傾向がないため、この情報をIETFに自由に寄付することはほとんどありません。 GSMAはこのデータを収集し、匿名化してからIETFに持ち込むことができます。これにより、ネットワークオペレーターの心配は軽減されますが、IETFに使用可能なデータが提供されます。

Although congestion is only detected when packet loss is encountered and better methods based on detecting congestion would be beneficial, a considerable amount of work has already been done on TCP, especially innovation in bandwidth management and congestion control.

輻輳はパケット損失が発生したときにのみ検出され、輻輳の検出に基づくより良い方法が有益ですが、TCPではかなりの量の作業、特に帯域幅管理と輻輳制御の革新がすでに行われています。

Furthermore, although the deficiencies of TCP are often considered key issues in the evolution of the Internet protocol stack, the main route to resolve these issues may not be a new TCP, but an evolved stack. Some workshop participants suggested that SPUD [SPUD] and Information-Centric Networking (ICN) [RFC7476] may help here. Quick UDP Internet Connection [QUIC] engineers stated that the problems solved by QUIC are general problems, rather than TCP issues. This view was not shared by all attendees of the workshop. Moreover, TCP has had some improvements in the last few years, which may mean some of the network lower layers should be investigated to see whether improvements can be made.

さらに、TCPの欠陥はインターネットプロトコルスタックの進化における主要な問題と見なされることがよくありますが、これらの問題を解決するための主なルートは新しいTCPではなく、進化したスタックである可能性があります。一部のワークショップ参加者は、SPUD [SPUD]および情報中心型ネットワーキング(ICN)[RFC7476]がここで役立つ可能性があることを示唆しました。クイックUDPインターネット接続[QUIC]のエンジニアは、QUICによって解決される問題は、TCPの問題ではなく、一般的な問題であると述べました。この見解は、ワークショップのすべての参加者によって共有されたわけではありません。さらに、TCPには過去数年間にいくつかの改善がありました。つまり、改善が可能かどうかを確認するために、ネットワークの下位層を調査する必要があるかもしれません。

5. Application-Layer Optimization, Caching, and CDNs
5. アプリケーション層の最適化、キャッシュ、およびCDN

Many discussions on the effects of encrypted traffic on radio access networks happen between implementers and the network operators. This session aimed to gather the opinions of the content and caching providers regarding their experiences running over mobile networks, the quality of experience their users expect, and the content and caching that providers would like to achieve by working with or using the mobile network.

無線アクセスネットワークへの暗号化されたトラフィックの影響に関する多くの議論は、実装者とネットワークオペレータの間で行われます。このセッションの目的は、モバイルネットワーク上で実行されているエクスペリエンス、ユーザーが期待するエクスペリエンスの品質、およびプロバイダーがモバイルネットワークを使用または使用することで実現したいコンテンツとキャッシュについて、コンテンツおよびキャッシュプロバイダーの意見を収集することでした。

Content providers explained how even though this workshop cited encrypted data over radio access networks as the main issue, the real issue is network management generally, and all actors (applications providers, networks, and devices) need to work together to overcome these general network management issues. Content providers explained how they assume the mobile networks are standards compliant. When the network is not standards compliant (e.g., using non-standards-compliant intermediaries), content providers can experience real costs as users contact their support centers to report issues that are difficult to test for and resolve.

コンテンツプロバイダーは、このワークショップが無線アクセスネットワーク上の暗号化されたデータを主要な問題として挙げているにもかかわらず、実際の問題は一般的にネットワーク管理であり、これらの一般的なネットワーク管理を克服するためにすべてのアクター(アプリケーションプロバイダー、ネットワーク、およびデバイス)が連携する必要があることを説明しました問題。コンテンツプロバイダーは、モバイルネットワークが標準に準拠していると想定する方法について説明しました。ネットワークが標準に準拠していない場合(たとえば、標準に準拠していない仲介者を使用している場合)、コンテンツプロバイダーは、ユーザーがサポートセンターに連絡してテストと解決が難しい問題を報告するときに、実際のコストを経験する可能性があります。

Content providers cited other common issues concerning data traffic over mobile networks. Data subscription limits (known as "caps") cause issues for users; users are confused about how data caps work or are unsure how expensive media is and how much data it consumes. Developers build products on networks not indicative of the networks their customers are using, and not every organization has the finances to build a caching infrastructure.

コンテンツプロバイダーは、モバイルネットワーク上のデータトラフィックに関するその他の一般的な問題を挙げています。データサブスクリプション制限(「キャップ」と呼ばれる)は、ユーザーに問題を引き起こします。ユーザーは、データキャップのしくみについて混乱している、またはメディアの価格とメディアが消費するデータ量がわからない。開発者は、顧客が使用しているネットワークを示すものではないネットワーク上に製品を構築し、すべての組織がキャッシングインフラストラクチャを構築するための資金を持っているわけではありません。

Strongly related to content providers, content owners consider CDNs to be trusted deliverers of content, and CDNs have shown great success in fixed networks. Now that more traffic is moving to mobile networks, there is a need to place caches near the user at the edge of the mobile network. Placing caches at the edge of the mobile network is a solution, but it requires standards developed by content providers and mobile network operators. The IETF's CDN Interconnection [CDNI] Working Group aims to allow global CDNs to interoperate with mobile CDNs, but this causes huge issues for the caching of encrypted data between these CDNs. Some CDNs are experimenting with approaches like "Keyless SSL" [KeylessSSL] to enable safer storage of content without passing private keys to the CDN. Blind Caching [BLIND_CACHING] is another proposal aimed at caching encrypted content closer to the user and managing the authentication at the original content provider servers.

コンテンツプロバイダーと強く関連しているコンテンツ所有者は、CDNをコンテンツの信頼できる配信者であると考えており、CDNは固定ネットワークで大きな成功を収めています。より多くのトラフィックがモバイルネットワークに移動している今、モバイルネットワークの端にあるユーザーの近くにキャッシュを配置する必要があります。キャッシュをモバイルネットワークのエッジに配置することはソリューションですが、コンテンツプロバイダーやモバイルネットワークオペレーターが開発した標準が必要です。 IETFのCDN相互接続[CDNI]ワーキンググループは、グローバルCDNがモバイルCDNと相互運用できるようにすることを目的としていますが、これにより、これらのCDN間の暗号化データのキャッシュに大きな問題が発生します。一部のCDNは、「キーレスSSL」[KeylessSSL]などのアプローチを試し、プライベートキーをCDNに渡さずにコンテンツをより安全に保存できるようにしています。ブラインドキャッシング[BLIND_CACHING]は、暗号化されたコンテンツをユーザーの近くにキャッシュし、元のコンテンツプロバイダーサーバーで認証を管理することを目的とした別の提案です。

At the end of the session, each panelist was asked to identify one key collaborative work item. Work items named were: evolving to cache encrypted content, using one bit for latency / bandwidth trade-off (explained below), better collaboration between the network and application, better metrics to aid troubleshooting and innovation, and indications from the network to allow the application to adapt.

セッションの最後に、各パネリストは1つの主要な共同作業項目を特定するよう求められました。名前付きの作業項目は、暗号化されたコンテンツをキャッシュするように進化する、レイテンシ/帯域幅のトレードオフに1ビットを使用する(以下で説明)、ネットワークとアプリケーション間のコラボレーションの改善、トラブルシューティングと革新を支援するメトリックの改善、およびネットワークからの指示によるものです。適応するアプリケーション。

6. Technical Analysis and Response to Potential Regulatory Reaction
6. 潜在的な規制反応に対するテクニカル分析と対応

This session was conducted under the Chatham House Rule. The session aimed to discuss regulatory and political issues, but not their worth or need, and to understand the laws that exist and how technologists can properly respond to them.

このセッションは、チャタムハウスルールの下で行われました。このセッションの目的は、規制や政治の問題について話し合うことであり、それらの価値や必要性については話し合わず、存在する法律と、技術者がそれらに適切に対応する方法を理解することでした。

Mobile networks are regulated; compliance is mandatory and can incur costs on the mobile network operator, while non-compliance can result in service license revocation in some nations. Regulation does vary geographically. Some regulations are court orders and others are self-imposed regulations, for example, "block lists" of websites such as the Internet Watch Foundation [IWF] list. Operators are not expected to decrypt sites, so those encrypted sites will not be blocked because of content.

モバイルネットワークは規制されています。コンプライアンスは必須であり、モバイルネットワークオペレータにコストが発生する可能性がありますが、一部の国では、コンプライアンスに違反するとサービスライセンスの取り消しが発生する可能性があります。規制は地理的に異なります。 Internet Watch Foundation [IWF]リストなどのWebサイトの「ブロックリスト」など、一部の規制は裁判所命令であり、その他は自主規制です。オペレーターはサイトを復号化することは想定されていないため、これらの暗号化されたサイトはコンテンツが原因でブロックされることはありません。

Parental-control-type filters also exist on the network and are easily bypassed today, vastly limiting their effectiveness. Better solutions would allow for users to easily set these restrictions themselves. Other regulations are also hard to meet, such as user data patterns, or will become harder to collect, such as Internet of Things (IoT) cases. Most attendees agreed that if a government cannot get information it needs (and is legally entitled to have) from network operators, they will approach content providers. Some governments are aware of the impact of encryption and are working with, or trying to work with, content providers. The IAB has concluded that blocking and filtering can be done at the endpoints of the communication.

ペアレンタルコントロールタイプのフィルターもネットワーク上に存在し、今日簡単にバイパスされ、その効果が大幅に制限されています。より良いソリューションでは、ユーザーがこれらの制限を自分で簡単に設定できるようになります。ユーザーデータパターンなどの他の規制も満たすのが難しいか、モノのインターネット(IoT)の場合など、収集が難しくなります。ほとんどの参加者は、政府がネットワーク事業者から必要な情報を入手できない場合(そして法的に入手する資格がある場合)、コンテンツプロバイダーにアプローチすることに同意しました。一部の政府は暗号化の影響を認識しており、コンテンツプロバイダーと連携しているか、または連携しようとしています。 IABは、通信のエンドポイントでブロッキングとフィルタリングを実行できると結論付けました。

Not all of these regulations apply to the Internet, and the Internet community is not always aware of their existence. Collectively, the Internet community can work with GSMA and 3GPP and act together to alleviate the risk imposed by encrypted traffic. Some participants expressed concern that governments might require operators to provide information that they no longer have the ability to provide because previously unencrypted traffic is now being encrypted, and this might expose operators to new liability, but no specific examples were given during the workshop. A suggestion from some attendees was that if any new technical solutions are necessary, they should easily be "switched off".

これらの規制のすべてがインターネットに適用されるわけではなく、インターネットコミュニティはその存在を常に認識しているわけではありません。集合的に、インターネットコミュニティはGSMAおよび3GPPと連携し、暗号化されたトラフィックによって課されるリスクを軽減するために一緒に行動することができます。一部の参加者は、以前は暗号化されていなかったトラフィックが現在暗号化されているため、政府が事業者に提供できなくなった情報を提供するよう要求する可能性があり、これにより事業者に新たな責任が課される可能性があるが、ワークショップ中に具体的な例は示されていないという懸念を表明しました。一部の参加者からの提案は、新しい技術的なソリューションが必要な場合は、簡単に「スイッチを切る」必要があるというものでした。

Some mobile network operators are producing transparency reports covering regulations including lawful intercept. Operators who have done this already are encouraging others to do the same.

一部のモバイルネットワークオペレーターは、合法的傍受を含む規制を網羅する透明性レポートを作成しています。すでにこれを行っているオペレーターは、他の人にも同じことをするように勧めています。

7. Suggested Principles and Solutions
7. 推奨される原則とソリューション

Based on the talks and discussions throughout the workshop, a set of suggested principles and solutions has been collected. This is not an exhaustive list, and no attempt was made to come to consensus during the workshop, so there are likely at least some participants who would not agree with any particular principle listed below. The list is a union of participant thinking, not an intersection.

ワークショップ全体での話し合いと議論に基づいて、一連の推奨される原則と解決策が収集されました。これは完全なリストではなく、ワークショップ中にコンセンサスを得るための試みは行われなかったため、少なくとも以下の特定の原則に同意しない参加者がいる可能性があります。リストは、参加者の考えの集合体であり、交差点ではありません。

o Encrypted Traffic: Any solution should encourage and support encrypted traffic.

o 暗号化されたトラフィック:どのソリューションでも、暗号化されたトラフィックを奨励およびサポートする必要があります。

o Flexibility: Radio access network qualities vary vastly, and the network needs of content can differ significantly, so any new solution should be flexible across either the network type, content type, or both.

o 柔軟性:無線アクセスネットワークの品質は大きく異なり、コンテンツのネットワークニーズは大幅に異なる可能性があるため、新しいソリューションは、ネットワークの種類、コンテンツの種類、またはその両方にわたって柔軟である必要があります。

o Privacy: New solutions should not introduce new ways for information to be discovered and attributed to individual users.

o プライバシー:新しいソリューションは、情報を発見して個々のユーザーに帰属させるための新しい方法を導入すべきではありません。

o Minimum data only for collaborative work: User data, application data, and network data all need protection, so new solutions should use minimal information to make a working solution.

o 共同作業のみの最小データ:ユーザーデータ、アプリケーションデータ、ネットワークデータはすべて保護が必要なので、新しいソリューションでは最小限の情報を使用して実用的なソリューションを作成する必要があります。

A collection of solutions suggested by various participants during the workshop is given below. Inclusion in this list does not imply that other workshop participants agreed. Again, the list is a union of proposed solutions, not an intersection.

ワークショップ中にさまざまな参加者が提案したソリューションのコレクションを以下に示します。このリストに含まれていても、他のワークショップ参加者が同意したことを意味するものではありません。繰り返しますが、リストは提案されたソリューションの集合であり、交差ではありません。

o Evolving TCP or evolution on the transport layer: This could take a number of forms, and some of this work is already underway within the IETF.

o 進化するTCPまたはトランスポート層での進化:これにはいくつかの形式があり、この作業の一部はIETF内ですでに進行中です。

o Congestion Control: Many attendees cited congestion control as a key issue. Further analysis, investigation, and work could be done in this space.

o 輻輳制御:多くの参加者が、輻輳制御を重要な問題として挙げました。このスペースでは、さらに分析、調査、および作業を行うことができます。

o Sprout [SPROUT]: Researched at MIT, Sprout is a transport protocol for applications that desire high throughput and low delay.

o Sprout [SPROUT]:MITで研究されたSproutは、高スループットと低遅延を望むアプリケーション向けのトランスポートプロトコルです。

o PCC [PCC]: Performance-oriented Congestion Control is a new architecture that aims for consistent high performance, even in challenging scenarios. PCC endpoints observe the connection between their actions and their known performance, which allows them to adapt their actions.

o PCC [PCC]:パフォーマンス指向の輻輳制御は、困難なシナリオでも一貫した高いパフォーマンスを目指す新しいアーキテクチャです。 PCCエンドポイントは、アクションと既知のパフォーマンスの間の接続を監視します。これにより、アクションを適応させることができます。

o CDNs and Caches: This suggests that placing caches closer to the edge of the radio network, as close as possible to the mobile user, or making more intelligent CDNs, would result in faster content delivery and less strain on the network.

o CDNとキャッシュ:これは、キャッシュを無線ネットワークのエッジにできるだけ近くに配置するか、モバイルユーザーにできるだけ近づけるか、よりインテリジェントなCDNを作成すると、コンテンツ配信が高速になり、ネットワークへの負担が少なくなることを示唆しています。

o Blind Caching [BLIND_CACHING]: This is a proposal for caching of encrypted content.

o ブラインドキャッシング[BLIND_CACHING]:これは、暗号化されたコンテンツのキャッシングの提案です。

o CDN Improvements: This includes Keyless SSL and better CDN placement.

o CDNの改善:これには、キーレスSSLとより良いCDN配置が含まれます。

o Mobile Throughput Guidance [MTG]: This is a mechanism and protocol elements that allow the cellular network to provide near real-time information on capacity available to the TCP server.

o モバイルスループットガイダンス[MTG]:これは、セルラーネットワークがTCPサーバーで利用可能な容量に関するほぼリアルタイムの情報を提供できるようにするメカニズムとプロトコル要素です。

o One Bit for Latency / Bandwidth Trade-Off: This suggests determining whether using a single bit in an unencrypted transport header to distinguish between traffic that the sender prefers to be queued and traffic that the sender would prefer to drop rather than delay provides additional benefits beyond what can be achieved without this signaling.

o 待ち時間/帯域幅のトレードオフに1ビット:これは、暗号化されていないトランスポートヘッダーの単一ビットを使用して、送信者がキューに入れることを好むトラフィックと遅延よりもドロップすることを好むトラフィックを区別するかどうかを決定することを提案します。このシグナリングなしで何が達成できるか。

o Base Station: Some suggestions involved using the base station, but this was not defined in detail. The base station holds the radio resource controller and scheduler, which could provide a place to host solutions, or data from the base station could help in devising new solutions.

o ベースステーション:ベースステーションの使用に関するいくつかの提案がありましたが、これは詳細には定義されていません。基地局は、ソリューションをホストする場所を提供できる無線リソースコントローラとスケジューラを保持します。または、基地局からのデータは、新しいソリューションを考案するのに役立ちます。

o Identify Traffic Types via 5-Tuple: Information from the 5-tuple could provide understanding of the traffic type, and network management appropriate for that traffic type could then be applied.

o 5タプルによるトラフィックタイプの識別:5タプルからの情報は、トラフィックタイプの理解を提供し、そのトラフィックタイプに適したネットワーク管理を適用できます。

o Heuristics: Networks can sometimes identify traffic types by observing characteristics, such as data flow rate, and then apply network management to these identified flows. This is not recommended, as categorizations can be incorrect.

o ヒューリスティック:ネットワークは、データフローレートなどの特性を監視してトラフィックタイプを識別し、これらの識別されたフローにネットワーク管理を適用することがあります。分類が正しくない可能性があるため、これはお勧めできません。

o APIs: An API for operators to share congestion status or the state of a cell before an application starts sending data could allow applications to change their behavior. Alternatively, an API could provide the network with information on the data type, allowing appropriate network management for that data type; however, this method exposes privacy issues.

o API:アプリケーションがデータの送信を開始する前に、オペレーターが輻輳状況またはセルの状態を共有するためのAPIにより、アプリケーションの動作を変更できる場合があります。または、APIはネットワークにデータタイプに関する情報を提供し、そのデータタイプに適切なネットワーク管理を許可することもできます。ただし、このメソッドはプライバシーの問題を公開します。

o Standard approach for the operator to offer services to Content Providers: Mobile network operators could provide caching services or other services for content providers to use for faster and smoother content delivery.

o 事業者がコンテンツプロバイダーにサービスを提供するための標準的なアプローチ:モバイルネットワークオペレーターは、コンテンツプロバイダーがより高速でスムーズなコンテンツ配信に使用するキャッシングサービスやその他のサービスを提供できます。

o AQM [RFC7567] and ECN [RFC3168] deployments: Queuing and congestion management methods have existed for some time in the form of AQM, ECN, and others, which can help the transport and Internet protocol layers adapt to congestion faster.

o AQM [RFC7567]とECN [RFC3168]の展開:キューイングと輻輳管理の方法は、以前からAQM、ECNなどの形式で存在しており、トランスポート層とインターネットプロトコル層が輻輳により速く適応するのに役立ちます。

o Trust Model or Trust Framework: Some solutions in this area (e.g., SPUD) have a reliance on trust when content providers or the network are being asked to add classifiers to their traffic.

o 信頼モデルまたは信頼フレームワーク:この領域の一部のソリューション(SPUDなど)は、コンテンツプロバイダーまたはネットワークがトラフィックに分類子を追加するように求められている場合、信頼に依存しています。

o Keyless SSL [KeylessSSL]: This allows content providers to maintain their private keys on a key server and host the content elsewhere (e.g., on a CDN). This could become standardized in the IETF. [LURK]

o キーレスSSL [KeylessSSL]:これにより、コンテンツプロバイダーは、秘密鍵をキーサーバーに保持し、コンテンツを他の場所(CDNなど)でホストできます。これはIETFで標準化される可能性があります。 [潜む]

o Meaningful capacity sharing: This includes the ConEx [CONEX] work, which exposes information about congestion to the network nodes.

o 意味のある容量共有:これには、輻輳に関する情報をネットワークノードに公開するConEx [CONEX]作業が含まれます。

o Hop-by-hop: Some suggestions offer hop-by-hop methods that allow nodes to adapt flow given the qualities of the networks around them and the congestion they are experiencing.

o ホップバイホップ:いくつかの提案は、ノードがそれらの周りのネットワークの品質とノードが経験している輻輳を考慮してフローを適応させるホップバイホップの方法を提供します。

o Metrics and metric standards: In order to evolve current protocols to be best suited to today's networks, data is needed about current network conditions, protocol deployments, packet traces, and middlebox behavior. Beyond this, proper testing and debugging on networks could provide great insight for stack evolution.

o メトリックとメトリック標準:現在のプロトコルを進化させて今日のネットワークに最適にするためには、現在のネットワーク状態、プロトコルの展開、パケットトレース、およびミドルボックスの動作に関するデータが必要です。これ以外にも、ネットワークで適切なテストとデバッグを行うことで、スタックの進化に関する優れた洞察を得ることができます。

o 5G: Mobile operator standards bodies are in the process of setting the requirements for 5G. Requirements for network management could be added.

o 5G:5Gの要件を設定中のモバイルオペレーター標準化団体。ネットワーク管理の要件を追加できます。

In the workshop, attendees identified other areas where greater understanding could help the standards process. These were identified as:

ワークショップでは、参加者は、理解を深めることで標準プロセスに役立つ他の領域を特定しました。これらは次のように識別されました。

o greater understanding of the RAN within the IETF;

o IETF内のRANの理解を深める。

o reviews and comments on 3GPP perspective; and,

o 3GPPの観点に関するレビューとコメント。そして、

o how to do congestion control in the RAN.

o RANで輻輳制御を行う方法。

7.1. Better Collaboration
7.1. より良いコラボレーション

Throughout the workshop, attendees placed emphasis on the need for better collaboration between the IETF and telecommunications bodies and organizations. The workshop was one such way to achieve this, but the good work and relationships built in the workshop should continue so the two groups can work on solutions that are better for both technologies and users.

ワークショップ全体を通じて、出席者は、IETFと電気通信機関および組織との間のより良いコラボレーションの必要性を強調しました。ワークショップはこれを達成するための1つの方法でしたが、2つのグループがテクノロジーとユーザーの両方にとってより良いソリューションに取り組むことができるように、ワークショップで構築された良好な作業と関係が続く必要があります。

8. Since MaRNEW
8. MaRNEW以来

Since MaRNEW, a number of activities have taken place in various IETF working groups and in groups external to IETF. The Alternatives to Content Classification for Operator Resource Deployment (ACCORD) BoF was held at IETF 95 in November 2015, which brought the workshop discussion to the wider IETF audiences by providing an account of the discussions that had taken place within the workshop and highlighting key areas to progress on. Key areas to progress on and an update on their current status are as follows:

MaRNEW以降、さまざまなIETFワーキンググループおよびIETFの外部のグループで多くの活動が行われています。オペレーターリソースデプロイメント(ACCORD)BoFのコンテンツ分類の代替案が2015年11月にIETF 95で開催され、ワー​​クショップ内で行われた議論の説明を提供し、主要な領域を強調することにより、ワークショップの議論をより幅広いIETF聴衆にもたらしました前進する。進行すべき主要な領域と現在のステータスの更新は次のとおりです。

o The collection of usable metrics and data were requested by a number of MaRNEW attendees, especially for use within the IRTF Measurement and Analysis for Protocols (MAP) Research Group; this data has been difficult to collect due to the closed nature of mobile network operators.

o 特にIRTF Measurement and Analysis for Protocols(MAP)Research Group内で使用するために、多くのMaRNEW参加者から、使用可能なメトリックとデータのコレクションが要求されました。このデータは、モバイルネットワークオペレーターの閉鎖的な性質のため、収集が困難でした。

o Understanding impediments to protocol stack evolution has continued within the IAB's IP Stack Evolution program and throughout transport-related IETF working groups such as the Transport Area Working Group (TSVWG).

o プロトコルスタックの進化に対する障害の理解は、IABのIPスタック進化プログラム内、およびトランスポートエリアワーキンググループ(TSVWG)などのトランスポート関連のIETFワーキンググループ全体で続きました。

o The Mobile Throughput Guidance document [MTG] has entered into a testing and data collection phase, although further advancements in transport technologies (QUIC, among others) may have stalled efforts in TCP-related proposals.

o モバイルスループットガイダンスドキュメント[MTG]はテストおよびデータ収集フェーズに入りましたが、トランスポートテクノロジー(特にQUIC)のさらなる進歩により、TCP関連の提案への取り組みが停滞する可能性があります。

o Work on proposals for caching encrypted content continue, albeit with some security flaws that proponents are working on further proposals to fix. Most often, these are discussed within the IETF HTTPbis Working Group.

o 暗号化されたコンテンツをキャッシュする提案への取り組みは継続していますが、支持者が修正するためのさらなる提案に取り組んでいるいくつかのセキュリティ上の欠陥はあります。ほとんどの場合、これらはIETF HTTPbisワーキンググループ内で議論されます。

o The Path Layer UDP Substrate (PLUS) BOF at IETF 96 in July 2016 did not result in the formation of a working group, as attendees expressed concern on the privacy issues associated with the proposed data-sharing possibilities of the shim layer.

o 2016年7月にIETF 96で開催されたパスレイヤーUDP基板(PLUS)BOFでは、シムレイヤーのデータ共有の可能性に関連するプライバシーの問題に懸念が表明されたため、ワーキンググループは結成されませんでした。

o The Limited Use of Remote Keys (LURK) BOF at IETF 96 in July 2016 did not result in the formation of a working group because the BOF identified more problems with the presumed approach than anticipated.

o 2016年7月のIETF 96でのリモートキーの限定使用(LURK)BOFは、BOFが想定されたアプローチで予想以上の問題を特定したため、ワーキンググループの結成にはなりませんでした。

The most rewarding output of MaRNEW is perhaps the most intangible. MaRNEW gave two rather divergent industry groups the opportunity to connect and discuss common technologies and issues affecting users and operations. Mobile network providers and key Internet engineers and experts have developed a greater collaborative relationship to aid development of further standards that work across networks in a secure manner.

MaRNEWの最もやりがいのある出力は、おそらく最も無形です。 MaRNEWは、2つのかなり異なる業界グループに、ユーザーと運用に影響を与える一般的な技術と問題を結び付けて議論する機会を与えました。モバイルネットワークプロバイダーと主要なインターネットエンジニアおよび専門家は、ネットワーク全体で安全な方法で機能するさらなる標準の開発を支援するために、より大きな協力関係を築きました。

9. Security Considerations
9. セキュリティに関する考慮事項

This document is an IAB report from a workshop on interactions between network security, especially privacy, and network performance.

このドキュメントは、ネットワークセキュリティ、特にプライバシーとネットワークパフォーマンスの間の相互作用に関するワークショップからのIABレポートです。

It does not affect the security of the Internet, taken on its own.

それ自体でとられたインターネットのセキュリティには影響しません。

10. IANA Considerations
10. IANAに関する考慮事項

This document has no IANA actions.

このドキュメントにはIANAアクションはありません。

11. Informative References
11. 参考引用

[BLIND_CACHING] Thomson, M., Eriksson, G., and C. Holmberg, "Caching Secure HTTP Content using Blind Caches", Work in Progress, draft-thomson-http-bc-01, October 2016.

[BLIND_CACHING] Thomson、M.、Eriksson、G。、およびC. Holmberg、「ブラインドキャッシュを使用した安全なHTTPコンテンツのキャッシング」、Work in Progress、draft-thomson-http-bc-01、2016年10月。

[CDNI] IETF, "Content Delivery Networks Interconnection (cdni)", <https://datatracker.ietf.org/wg/cdni/charter/>.

[CDNI] IETF、「コンテンツ配信ネットワーク相互接続(cdni)」、<https://datatracker.ietf.org/wg/cdni/charter/>。

[CHATHAM_HOUSE_RULE] Chatham House, "Chatham House Rule | Chatham House", <https://www.chathamhouse.org/about/chatham-house-rule>.

[CHATHAM_HOUSE_RULE]チャタムハウス、「チャタムハウスルール|チャタムハウス」、<https://www.chathamhouse.org/about/chatham-house-rule>。

[CONEX] IETF, "Congestion Exposure (conex) - Documents", <https://datatracker.ietf.org/wg/conex/documents/>.

[CONEX] IETF、「Congestion Exposure(conex)-Documents」、<https://datatracker.ietf.org/wg/conex/documents/>。

[EffectEncrypt] Xiong, C. and M. Patel, "The effect of encrypted traffic on the QoS mechanisms in cellular networks", August 2015, <https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_25.pdf>.

[EffectEncrypt] Xiong、C。およびM. Patel、「セルラーネットワークのQoSメカニズムに対する暗号化されたトラフィックの影響」、2015年8月、<https://www.iab.org/wp-content/IAB-uploads/2015 / 08 / MaRNEW_1_paper_25.pdf>。

[FLOWQUEUE] Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, J., and E. Dumazet, "FlowQueue-Codel", Work in Progress, draft-hoeiland-joergensen-aqm-fq-codel-01, November 2014.

[FLOWQUEUE] Hoeiland-Joergensen、T.、McKenney、P.、Taht、D.、Gettys、J。、およびE. Dumazet、「FlowQueue-Codel」、Work in Progress、draft-hoeiland-joergensen-aqm-fq- codel-01、2014年11月。

[GSMA] GSMA, "GSMA Homepage", <http://gsma.com>.

[GSMA] GSMA、「GSMAホームページ」、<http://gsma.com>。

[IWF] IWF, "Internet Watch Foundation Homepage", <https://www.iwf.org.uk/>.

[IWF] IWF、 "Internet Watch Foundation Homepage"、<https://www.iwf.org.uk/>。

[KeylessSSL] Sullivan, N., "Keyless SSL: The Nitty Gritty Technical Details", September 2014, <https://blog.cloudflare.com/ keyless-ssl-the-nitty-gritty-technical-details/>.

[KeylessSSL] Sullivan、N。、「Keyless SSL:The Nitty Gritty Technical Details」、2014年9月、<https://blog.cloudflare.com/ keyless-ssl-the-nitty-gritty-technical-details />。

[LURK] Migault, D., Ma, K., Salz, R., Mishra, S., and O. Dios, "LURK TLS/DTLS Use Cases", Work in Progress, draft-mglt-lurk-tls-use-cases-02, June 2016.

[LURK] Migault、D.、Ma、K.、Salz、R.、Mishra、S.、O。Dios、「LURK TLS / DTLSの使用例」、作業中、draft-mglt-lurk-tls-use -cases-02、2016年6月。

[MARNEW] IAB, "Managing Radio Networks in an Encrypted World (MaRNEW) Workshop 2015", <https://www.iab.org/activities/workshops/marnew/>.

[MARNEW] IAB、「Managing Radio Networks in a Encrypted World(MaRNEW)Workshop 2015」、<https://www.iab.org/activities/workshops/marnew/>。

[MTG] Jain, A., Terzis, A., Flinck, H., Sprecher, N., Arunachalam, S., Smith, K., Devarapalli, V., and R. Yanai, "Mobile Throughput Guidance Inband Signaling Protocol", Work in Progress, draft-flinck-mobile-throughput-guidance-04, March 2017.

[MTG] Jain、A.、Terzis、A.、Flinck、H.、Sprecher、N.、Arunachalam、S.、Smith、K.、Devarapalli、V。、およびR. Yanai、「モバイルスループットガイダンスインバンドシグナリングプロトコル"、Work in Progress、draft-flinck-mobile-throughput-guidance-04、2017年3月。

[NETWORK_MANAGEMENT] Smith, K., "Network management of encrypted traffic", Work in Progress, draft-smith-encrypted-traffic-management-05, May 2016.

[NETWORK_MANAGEMENT] Smith、K。、「暗号化されたトラフィックのネットワーク管理」、Work in Progress、draft-smith-encrypted-traffic-management-05、2016年5月。

[NOTE_WELL] IETF, "IETF Note Well", <https://www.ietf.org/about/note-well.html>.

[NOTE_WELL] IETF、「IETF Note Well」、<https://www.ietf.org/about/note-well.html>。

[PCC] Dong, M., Li, Q., Zarchy, D., Brighten Godfrey, P., and M. Schapira, "PCC: Re-architecting Congestion Control for Consistent High Performance", Proceedings of the 12th USENIX Symposium on Networked Systems Design and Implementation (NSDI '15), USENIX Association, May 2015, <https://www.usenix.org/system/files/conference/nsdi15/ nsdi15-paper-dong.pdf>.

[PCC] Dong、M.、Li、Q.、Zarchy、D.、Brighten Godfrey、P。、およびM. Schapira、「PCC:Re-architecting Congestion Control for Consistent High Performance」、Proceedings of the 12th USENIX Symposium on Networked Systems Design and Implementation(NSDI '15)、USENIX Association、May 2015、<https://www.usenix.org/system/files/conference/nsdi15/ nsdi15-paper-dong.pdf>。

[PCC-QOS] 3GPP, "Policy and charging control signalling flows and Quality of Service (QoS) parameter mapping", 3GPP TS 29.213, version 15.3.0, Release 15, June 2018, <http://www.3gpp.org/DynaReport/29213.htm>.

[PCC-QOS] 3GPP、「ポリシーおよび課金制御シグナリングフローとサービス品質(QoS)パラメータマッピング」、3GPP TS 29.213、バージョン15.3.0、リリース15、2018年6月、<http://www.3gpp.org /DynaReport/29213.htm>。

[Pew2014] Madden, M., "Public Perceptions of Privacy and Security in the Post-Snowden Era", November 2014, <http://www.pewinternet.org/2014/11/12/ public-privacy-perceptions/>.

[Pew2014] Madden、M.、「ポストスノーデン時代におけるプライバシーとセキュリティの公的認識」、2014年11月、<http://www.pewinternet.org/2014/11/12/ public-privacy-perceptions /> 。

[QUIC] Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2", Work in Progress, draft-tsvwg-quic-protocol-02, January 2016.

[QUIC]ハミルトン、R。、アイアンガー、J。、スウェット、I。、およびA.ウィルク、「QUIC:HTTP / 2用のUDPベースの安全で信頼性の高いトランスポート」、作業中、draft-tsvwg-quic- protocol-02、2016年1月。

[RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, DOI 10.17487/RFC2804, May 2000, <https://www.rfc-editor.org/info/rfc2804>.

[RFC2804] IABおよびIESG、「盗聴に関するIETFポリシー」、RFC 2804、DOI 10.17487 / RFC2804、2000年5月、<https://www.rfc-editor.org/info/rfc2804>。

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.

[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知(ECN)の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<https:// www。 rfc-editor.org/info/rfc3168>。

[RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., Tyson, G., Davies, E., Molinaro, A., and S. Eum, "Information-Centric Networking: Baseline Scenarios", RFC 7476, DOI 10.17487/RFC7476, March 2015, <https://www.rfc-editor.org/info/rfc7476>.

[RFC7476] Pentikousis、K.、Ed。、Ohlman、B.、Corujo、D.、Boggia、G.、Tyson、G.、Davies、E.、Molinaro、A.、and S. Eum、 "Information-Centricネットワーキング:ベースラインシナリオ」、RFC 7476、DOI 10.17487 / RFC7476、2015年3月、<https://www.rfc-editor.org/info/rfc7476>。

[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <https://www.rfc-editor.org/info/rfc7567>.

[RFC7567]ベイカー、F。、エド。およびG.フェアハースト編、「アクティブキュー管理に関するIETFの推奨事項」、BCP 197、RFC 7567、DOI 10.17487 / RFC7567、2015年7月、<https://www.rfc-editor.org/info/rfc7567>。

[RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of Pervasive Encryption on Operators", RFC 8404, DOI 10.17487/RFC8404, July 2018, <https://www.rfc-editor.org/info/rfc8404>.

[RFC8404]モリアーティ、K。、エド。 A.モートン編、「オペレーターに対するパーベイシブ暗号化の影響」、RFC 8404、DOI 10.17487 / RFC8404、2018年7月、<https://www.rfc-editor.org/info/rfc8404>。

[SDO_3GPP] 3GPP, "3GPP Homepage", <http://www.3gpp.org/>.

[SDO_3GPP] 3GPP、「3GPPホームページ」、<http://www.3gpp.org/>。

[SPROUT] Winstein, K., Sivaraman, A., and H. Balakrishnan, "Stochastic Forecasts Achieve High Throughput and Low Delay over Cellular Networks", 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI '13), USENIX Association, April 2013, <https://www.usenix.org/system/files/conference/nsdi13/ nsdi13-final113.pdf>.

[スプラウト] Winstein、K.、Sivaraman、A。、およびH. Balakrishnan、「確率的予測によりセルラーネットワーク上で高スループットと低遅延を実現」、第10回USENIXシンポジウム、ネットワークシステムの設計と実装(NSDI '13)、USENIX協会、 2013年4月、<https://www.usenix.org/system/files/conference/nsdi13/ nsdi13-final113.pdf>。

[SPUD] IETF, "Session Protocol for User Datagrams (spud)", <https://datatracker.ietf.org/wg/spud/about/>.

[SPUD] IETF、「ユーザーデータグラムのセッションプロトコル(spud)」、<https://datatracker.ietf.org/wg/spud/about/>。

[STATE_BROWSER] Barnes, R., "Some observations of TLS in the web", July 2015, <https://www.ietf.org/proceedings/93/slides/ slides-93-saag-3.pdf>.

[STATE_BROWSER] Barnes、R。、「ウェブでのTLSのいくつかの観察」、2015年7月、<https://www.ietf.org/proceedings/93/slides/ slides-93-saag-3.pdf>。

[STATE_SERVER] Salz, R., "Some observations of TLS in the web", July 2015, <https://www.ietf.org/proceedings/93/slides/ slides-93-saag-4.pdf>.

[STATE_SERVER] Salz、R。、「WebでのTLSの観察」、2015年7月、<https://www.ietf.org/proceedings/93/slides/ slides-93-saag-4.pdf>。

[TCPINC] "TCP Increased Security (tcpinc)", <https://datatracker.ietf.org/wg/tcpinc/charter/>.

[TCPINC]「TCPセキュリティ強化(tcpinc)」、<https://datatracker.ietf.org/wg/tcpinc/charter/>。

Appendix A. Workshop Attendees
付録A.ワークショップの参加者

o Rich Salz, Akamai

o 豊富な塩、アカマイ

o Aaron Falk, Akamai

o アーロンフォーク、アカマイ

o Vinay Kanitkar, Akamai

o Vinay Kanitkar、アカマイ

o Julien Maisonneuve, Alcatel Lucent

o ジュリアンメゾンヌーブ、アルカテルルーセント

o Dan Druta, AT&T

o Dan Druta、AT&T

o Humberto La Roche, Cisco

o Humberto La Roche、Cisco

o Thomas Anderson, Cisco

o シスコ、トーマスアンダーソン

o Paul Polakos, Cisco

o ポールポラコス、シスコ

o Marcus Ihlar, Ericsson

o マーカス・アイラー、エリクソン

o Szilveszter Nadas, Ericsson

o 新年ナダス、エリクソン

o John Mattsson, Ericsson

o ジョン・マットソン、エリクソン

o Salvatore Loreto, Ericsson

o サルヴァトーレロレート、エリクソン

o Blake Matheny, Facebook

o ブレイク・マセニー、フェイスブック

o Andreas Terzis, Google

o Andreas Terzis、Google

o Jana Iyengar, Google

o Jana IMinger、Google

o Natasha Rooney, GSMA

o ナターシャルーニー、GSMA

o Istvan Lajtos, GSMA

o Istvan Lajtos、GSMA

o Emma Wood, GSMA

o エマ・ウッド、GSMA

o Jianjie You, Huawei

o Jイアン姉妹、hu Aは

o Chunshan Xiong, Huawei

o CウェディングドレスNXイオンG、フーAは

o Russ Housley, IAB

o Russ Housley、IAB

o Mary Barnes, IAB

o メアリーバーンズ、IAB

o Joe Hildebrand, IAB / Cisco o Ted Hardie, IAB / Google

Joe Hildebrand、IAB / Cisco o Ted Hardie、IAB / Google

o Robert Sparks, IAB / Oracle

o ロバート・スパークス、IAB /オラクル

o Spencer Dawkins, IETF AD

o スペンサー・ドーキンス、IETF AD

o Benoit Claise, IETF AD / Cisco

o Benoit Claise、IETF AD / Cisco

o Kathleen Moriarty, IETF AD / EMC

o キャスリーン・モリアーティ、IETF AD / EMC

o Barry Leiba, IETF AD / Huawei

o バリー・レイバ、IETF AD / Huawei

o Ben Campbell, IETF AD / Oracle

o ベンキャンベル、IETF AD / Oracle

o Stephen Farrell, IETF AD / Trinity College Dublin

o Stephen Farrell、IETF AD / Trinity College Dublin

o Jari Arkko, IETF Chair / Ericsson

o アラコ、Aitf議長/エリクソン発行

o Karen O'Donoghue, ISOC

o かれん お’どのgふえ、 いそC

o Phil Roberts, ISOC

o Phil Roberts、ISOC

o Olaf Kolkman, ISOC

o ISOC、オラフ・コルクマン

o Christian Huitema, Microsoft

o クリスチャン・ウイテマ、マイクロソフト

o Patrick McManus, Mozilla

o Patrick McManus、Mozilla

o Dirk Kutscher, NEC Europe Network Laboratories

o NECヨーロッパネットワーク研究所、Dirk Kutscher

o Mark Watson, Netflix

o マークワトソン、Netflix

o Martin Peylo, Nokia

o マーティンベイロ、ノキア

o Mohammed Dadas, Orange

o モハメッド・ダダス、オレンジ

o Diego Lopez, Telefonica

o ディエゴ・ロペス、テレフォニカ

o Matteo Varvello, Telefonica

o テレフォニカ、マッテオバルヴェッロ

o Zubair Shafiq, The University of Iowa

o アイオワ大学ズバイル・シャフィク

o Vijay Devarapalli, Vasona Networks

o Vijay Devarapally、Vesina Networks

o Sanjay Mishra, Verizon

o Sanjay Mishra、Verizon

o Gianpaolo Scassellati, Vimplecom o Kevin Smith, Vodafone

お ぎあんぱおぉ Sかっせっぁち、 ゔぃmpぇこm お けゔぃん Sみth、 ゔぉだふぉね

o Wendy Seltzer, W3C

o ウェンディ・セルツァー、W3C

Appendix B. Workshop Position Papers
付録B.ワークショップのポジションペーパー

o Mohammed Dadas, Emile Stephan, Mathilde Cayla, Iuniana Oprescu, "Cooperation Framework between Application layer and Lower Layers" at <https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_33.pdf>

o Mohammed Dadas、Emile Stephan、Mathilde Cayla、Iuniana Oprescu、「https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_33.pdf>の「アプリケーション層と下位層の間の協調フレームワーク」

o Julien Maisonneuve, Vijay Gurbani, and Thomas Fossati, "The security pendulum" at <https://www.iab.org/wp-content/ IAB-uploads/2015/08/MaRNEW_1_paper_4.pdf>

o Julien Maisonneuve、Vijay Gurbani、およびThomas Fossati、「セキュリティの振り子」<https://www.iab.org/wp-content/ IAB-uploads / 2015/08 / MaRNEW_1_paper_4.pdf>

o Martin Peylo, "Enabling Secure QoE Measures for Internet Applications over Radio Networks is a MUST" at <https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_32.pdf>

o Martin Peylo、「無線ネットワークを介したインターネットアプリケーションの安全なQoE対策の有効化は必須」<https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_32.pdf>

o Vijay Devarapalli, "The Bandwidth Balancing Act: Managing QoE as encrypted services change the traffic optimization game" at <https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_10.pdf>

o Vijay Devarapalli、「帯域幅バランシング法:暗号化されたサービスがトラフィック最適化ゲームを変えるようにQoEを管理する」<https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_10.pdf>

o Humberto J. La Roche, "Use Cases for Communicating End-Points in Mobile Network Middleboxes" at <https://www.iab.org/wp-content/ IAB-uploads/2015/08/MaRNEW_1_paper_12.pdf>

o Humberto J. La Roche、「モバイルネットワークミドルボックスでエンドポイントを通信するための使用例」<https://www.iab.org/wp-content/ IAB-uploads / 2015/08 / MaRNEW_1_paper_12.pdf>

o Patrick McManus and Richard Barnes, "User Consent and Security as a Public Good" at <https://www.iab.org/wp-content/ IAB-uploads/2015/08/MaRNEW_1_paper_13.pdf>

o Patrick McManusとRichard Barnes、「https://www.iab.org/wp-content/ IAB-uploads / 2015/08 / MaRNEW_1_paper_13.pdf>の「公共財としてのユーザーの同意とセキュリティ」

o Iuniana Oprescu, Jon Peterson, and Natasha Rooney, "A Framework for Consent and Permissions in Mediating TLS" at <https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_31.pdf>

o Iuniana Oprescu、Jon Peterson、Natasha Rooney、「TLSの仲介における同意と許可のフレームワーク」<https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_31.pdf>

o Jari Arkko and Goran Eriksson, "Characteristics of Traffic Type Changes and Their Architectural Implications" at <https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_15.pdf>

o Jari ArkkoとGoran Eriksson、「トラフィックタイプの変更の特徴とそのアーキテクチャ上の影響」<https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_15.pdf>

o Szilveszter Nadas and Attila Mihaly, "Concept for Cooperative Traffic Management" at <https://www.iab.org/wp-content/ IAB-uploads/2015/08/MaRNEW_1_paper_16.pdf>

o 大晦日NadasとAttila Mihaly、<https://www.iab.org/wp-content/ IAB-uploads / 2015/08 / MaRNEW_1_paper_16.pdf>の「協調的トラフィ​​ック管理の概念」

o Gianpaolo Scassellati, "Vimpelcom Position paper for MaRNEW Workshop" at <https://www.iab.org/wp-content/IAB-uploads/2015/09/ MaRNEW_1_paper_17.pdf>

o Gianpaolo Scassellati、「https://www.iab.org/wp-content/IAB-uploads/2015/09/ MaRNEW_1_paper_17.pdf>の「MaRNEWワークショップのVimpelcomポジションペーパー」

o Mirja Kuhlewind, Dirk Kutscher, and Brian Trammell, "Enabling Traffic Management without DPI" at <https://www.iab.org/ wp-content/IAB-uploads/2015/08/MaRNEW_1_paper_18.pdf>

o Mirja Kuhlewind、Dirk Kutscher、Brian Trammell、「DPIを使用しないトラフィック管理の有効化」<https://www.iab.org/ wp-content / IAB-uploads / 2015/08 / MaRNEW_1_paper_18.pdf>

o Andreas Terzis and Chris Bentzel, "Sharing network state with application endpoints" at <https://www.iab.org/wp-content/ IAB-uploads/2015/08/MaRNEW_1_paper_19.pdf>

o Andreas TerzisとChris Bentzel、「https://www.iab.org/wp-content/ IAB-uploads / 2015/08 / MaRNEW_1_paper_19.pdf>の「アプリケーションエンドポイントとのネットワーク状態の共有」

o Marcus Ihlar, Salvatore Loreto, and Robert Skog, "The needed existence of PEP in an encrypted world" at <https://www.iab.org/ wp-content/IAB-uploads/2015/08/MaRNEW_1_paper_20.pdf>

o Marcus Ihlar、Salvatore Loreto、およびRobert Skog、「暗号化された世界におけるPEPの必要な存在」<https://www.iab.org/ wp-content / IAB-uploads / 2015/08 / MaRNEW_1_paper_20.pdf>

o John Mattsson, "Network Operation in an All-Encrypted World" at <https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_21.pdf>

o John Mattsson、「すべて暗号化された世界でのネットワーク運用」<https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_21.pdf>

o Dirk Kutscher, Giovanna Carofiglio, Luca Muscariello, and Paul Polakos, "Maintaining Efficiency and Privacy in Mobile Networks through Information-Centric Networking" at <https://www.iab.org/ wp-content/IAB-uploads/2015/08/MaRNEW_1_paper_23.pdf>

o Dirk Kutscher、Giovanna Carofiglio、Luca Muscariello、およびPaul Polakos、「https://www.iab.org/ wp-content / IAB-uploads / 2015/08の「情報中心のネットワーキングによるモバイルネットワークでの効率とプライバシーの維持」 /MaRNEW_1_paper_23.pdf>

o Chunshan Xiong and Milan Patel, "The effect of encrypted traffic on the QoS mechanisms in cellular networks" at <https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_25.pdf>

o Chunshan XiongとMilan Patel、「セルラーネットワークのQoSメカニズムに対する暗号化されたトラフィックの影響」<https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_25.pdf>

o Thomas Anderson, Peter Bosch, and Alessandro Duminuco, "Bandwidth Control and Regulation in Mobile Networks via SDN/NFV-Based Platforms" at <https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_26.pdf>

o Thomas Anderson、Peter Bosch、およびAlessandro Duminuco、「https://www.iab.org/wp-content/IAB-uploads/2015/08/にある「SDN / NFVベースのプラットフォームを介したモバイルネットワークにおける帯域幅制御と規制」 MaRNEW_1_paper_26.pdf>

o Karen O'Donoghue and Phil Roberts, "Barriers to Deployment: Probing the Potential Differences in Developed and Developing Infrastructure" at <https://www.iab.org/wp-content/ IAB-uploads/2015/08/MaRNEW_1_paper_27.pdf>

o Karen O'DonoghueとPhil Roberts、「https://www.iab.org/wp-content/ IAB-uploads / 2015/08 / MaRNEW_1_paper_27.pdfの「展開への障壁:開発済みインフラと開発中インフラの潜在的な違いの調査」 >

o Wendy Seltzer, "Security, Privacy, and Performance Considerations for the Mobile Web" at <https://www.iab.org/wp-content/ IAB-uploads/2015/08/MaRNEW_1_paper_28.pdf>

o Wendy Seltzer、「モバイルWebのセキュリティ、プライバシー、およびパフォーマンスに関する考慮事項」<https://www.iab.org/wp-content/ IAB-uploads / 2015/08 / MaRNEW_1_paper_28.pdf>

o Jianjie You, Hanyu Wei, and Huaru Yang, "Use Case Analysis and Potential Bandwidth Optimization Methods for Encrypted Traffic" at <https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_29.pdf>

o Jianjie You、Hanyu Wei、およびHuaru Yang、「https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_29.pdfの「暗号化されたトラフィックのユースケース分析と潜在的な帯域幅最適化手法」 >

o Mangesh Kasbekar and Vinay Kanitkar, "CDNs, Network Services and Encrypted Traffic" at <https://www.iab.org/wp-content/ IAB-uploads/2015/08/MaRNEW_1_paper_30.pdf>

o Mangesh KasbekarおよびVinay Kanitkar、「CDN、ネットワークサービスおよび暗号化トラフィック」(<https://www.iab.org/wp-content/ IAB-uploads / 2015/08 / MaRNEW_1_paper_30.pdf>)

o Yves Hupe, Claude Rocray, and Mark Santelli, "Providing Optimization of Encrypted HTTP Traffic" at <https://www.iab.org/ wp-content/IAB-uploads/2015/08/MaRNEW_1_paper_341.pdf>

o Yves Hupe、Claude Rocray、およびMark Santelli、「暗号化されたHTTPトラフィックの最適化の提供」<https://www.iab.org/ wp-content / IAB-uploads / 2015/08 / MaRNEW_1_paper_341.pdf>

o M. Zubair Shafiq, "Tracking Mobile Video QoE in the Encrypted Internet" at <https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_35.pdf>

o M. Zubair Shafiq、「https://www.iab.org/wp-content/IAB-uploads/2015/08/ MaRNEW_1_paper_35.pdf>の「暗号化インターネットでのモバイルビデオQoEの追跡」

o Kevin Smith, "Encryption and government regulation: what happens now?" at <https://www.iab.org/wp-content/IAB-uploads/2015/09/ MaRNEW_1_paper_1.pdf>

o ケビン・スミス、「暗号化と政府の規制:今何が起こるのか?」 <https://www.iab.org/wp-content/IAB-uploads/2015/09/ MaRNEW_1_paper_1.pdf>

Acknowledgements

謝辞

Stephen Farrell reviewed this report in draft form and provided copious comments and suggestions.

スティーブン・ファレルはこのレポートをドラフト形式でレビューし、豊富なコメントと提案を提供しました。

Barry Leiba provided some clarifications on specific discussions about Lawful Intercept that took place during the workshop.

バリーレイバは、ワークショップ中に行われた合法的傍受に関する特定の議論についていくつかの説明を提供しました。

Bob Hinden and Warren Kumari provided comments and suggestions during the IAB Call for Comments.

Bob HindenとWarren Kumariは、IABのコメント募集中にコメントと提案を行いました。

Amelia Andersdotter and Shivan Kaul Sahib provided comments from the Human Rights Review Team during the IAB Call for Comments.

Amelia AndersdotterとShivan Kaul Sahibは、IAB Call for Comments中に人権レビューチームからコメントを提供しました。

Authors' Addresses

著者のアドレス

Natasha Rooney GSMA

ナターシャルーニーGSMA

   Email: nrooney@gsma.com
   URI:   https://gsma.com
        

Spencer Dawkins (editor) Wonder Hamster

スペンサー・ドーキンス(編集者)ワンダーハムスター

   Email: spencerdawkins.ietf@gmail.com