[要約] RFC 8404は、インターネット上での広範な暗号化の使用がネットワークオペレーターに与える影響について説明しています。この文書の目的は、暗号化がトラフィック管理、セキュリティ対策、法的な監視活動にどのように影響を及ぼすかを理解し、議論することにあります。利用場面としては、ネットワークの設計、運用、ポリシー策定の際に、暗号化技術の導入がもたらす潜在的な課題を考慮する際に参照されます。関連するRFCには、暗号化技術の標準を定めるRFC 8446（TLS 1.3）や、インターネットプライバシーに関するRFC 6973などがあります。
Internet Engineering Task Force (IETF) K. Moriarty, Ed.
Request for Comments: 8404 Dell EMC
Category: Informational A. Morton, Ed.
ISSN: 2070-1721 AT&T Labs
July 2018
Effects of Pervasive Encryption on Operators
広範囲での暗号化がネットワークオペレータに与える影響
Abstract
概要
Pervasive monitoring attacks on the privacy of Internet users are of serious concern to both user and operator communities. RFC 7258 discusses the critical need to protect users' privacy when developing IETF specifications and also recognizes that making networks unmanageable to mitigate pervasive monitoring is not an acceptable outcome: an appropriate balance is needed. This document discusses current security and network operations as well as management practices that may be impacted by the shift to increased use of encryption to help guide protocol development in support of manageable and secure networks.
インターネットユーザーのプライバシーに対する広範な監視攻撃は、ユーザーとオペレーターの両方のコミュニティにとって深刻な懸念事項です。 RFC 7258は、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 Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。 Internet Engineering Steering Group（IESG）による公開が承認されています。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 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/rfc8404.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8404で入手できます。
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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Additional Background on Encryption Changes . . . . . . . 5
1.2. Examples of Attempts to Preserve Functions . . . . . . . 7
2. Network Service Provider Monitoring Practices . . . . . . . . 8
2.1. Passive Monitoring . . . . . . . . . . . . . . . . . . . 8
2.1.1. Traffic Surveys . . . . . . . . . . . . . . . . . . . 8
2.1.2. Troubleshooting . . . . . . . . . . . . . . . . . . . 9
2.1.3. Traffic-Analysis Fingerprinting . . . . . . . . . . . 11
2.2. Traffic Optimization and Management . . . . . . . . . . . 12
2.2.1. Load Balancers . . . . . . . . . . . . . . . . . . . 12
2.2.2. Differential Treatment Based on Deep Packet
Inspection (DPI) . . . . . . . . . . . . . . . . . . 14
2.2.3. Network-Congestion Management . . . . . . . . . . . . 16
2.2.4. Performance-Enhancing Proxies . . . . . . . . . . . . 16
2.2.5. Caching and Content Replication near the Network Edge 17
2.2.6. Content Compression . . . . . . . . . . . . . . . . . 18
2.2.7. Service Function Chaining . . . . . . . . . . . . . . 18
2.3. Content Filtering, Network Access, and Accounting . . . . 19
2.3.1. Content Filtering . . . . . . . . . . . . . . . . . . 19
2.3.2. Network Access and Data Usage . . . . . . . . . . . . 20
2.3.3. Application Layer Gateways (ALGs) . . . . . . . . . . 21
2.3.4. HTTP Header Insertion . . . . . . . . . . . . . . . . 22
3. Encryption in Hosting and Application SP Environments . . . . 23
3.1. Management-Access Security . . . . . . . . . . . . . . . 23
3.1.1. Monitoring Customer Access . . . . . . . . . . . . . 24
3.1.2. SP Content Monitoring of Applications . . . . . . . . 24
3.2. Hosted Applications . . . . . . . . . . . . . . . . . . . 26
3.2.1. Monitoring Managed Applications . . . . . . . . . . . 27
3.2.2. Mail Service Providers . . . . . . . . . . . . . . . 27
3.3. Data Storage . . . . . . . . . . . . . . . . . . . . . . 28
3.3.1. Object-Level Encryption . . . . . . . . . . . . . . . 28
3.3.2. Disk Encryption, Data at Rest (DAR) . . . . . . . . . 29
3.3.3. Cross-Data-Center Replication Services . . . . . . . 29
4. Encryption for Enterprises . . . . . . . . . . . . . . . . . 30
4.1. Monitoring Practices of the Enterprise . . . . . . . . . 30
4.1.1. Security Monitoring in the Enterprise . . . . . . . . 31
4.1.2. Monitoring Application Performance in the Enterprise 32
4.1.3. Diagnostics and Troubleshooting for Enterprise
Networks . . . . . . . . . . . . . . . . . . . . . . 33
4.2. Techniques for Monitoring Internet-Session Traffic . . . 34
5. Security Monitoring for Specific Attack Types . . . . . . . . 36
5.1. Mail Abuse and Spam . . . . . . . . . . . . . . . . . . . 37
5.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 37
5.3. Phishing . . . . . . . . . . . . . . . . . . . . . . . . 38
5.4. Botnets . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.5. Malware . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.6. Spoofed-Source IP Address Protection . . . . . . . . . . 39
5.7. Further Work . . . . . . . . . . . . . . . . . . . . . . 39
6. Application-Based Flow Information Visible to a Network . . . 40
6.1. IP Flow Information Export . . . . . . . . . . . . . . . 40
6.2. TLS Server Name Indication . . . . . . . . . . . . . . . 40
6.3. Application-Layer Protocol Negotiation (ALPN) . . . . . . 41
6.4. Content Length, Bitrate, and Pacing . . . . . . . . . . . 42
7. Effect of Encryption on the Evolution of Mobile Networks . . 42
8. Response to Increased Encryption and Looking Forward . . . . 43
9. Security Considerations . . . . . . . . . . . . . . . . . . . 43
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
11. Informative References . . . . . . . . . . . . . . . . . . . 44
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
In response to pervasive monitoring revelations and the IETF consensus that pervasive monitoring is an attack [RFC7258], efforts are underway to increase encryption of Internet traffic. Pervasive monitoring is of serious concern to users, operators, and application providers. RFC 7258 discusses the critical need to protect users' privacy when developing IETF specifications and also recognizes that making networks unmanageable to mitigate pervasive monitoring is not an acceptable outcome; rather, an appropriate balance would emerge over time.
広範な監視の啓示と、広範な監視が攻撃であるというIETFのコンセンサス[RFC7258]に対応して、インターネットトラフィックの暗号化を高める取り組みが進行中です。広範囲にわたる監視は、ユーザー、オペレーター、およびアプリケーションプロバイダーにとって深刻な問題です。 RFC 7258は、IETF仕様を開発する際にユーザーのプライバシーを保護するという重要な必要性を論じており、ネットワークを管理不能にして広範囲にわたる監視を緩和することは許容できる結果ではないことも認識しています。むしろ、時間の経過とともに適切なバランスが生まれます。
This document describes practices currently used by network operators to manage, operate, and secure their networks and how those practices may be impacted by a shift to increased use of encryption. It provides network operators' perspectives about the motivations and objectives of those practices as well as effects anticipated by operators as use of encryption increases. It is a summary of concerns of the operational community as they transition to managing networks with less visibility. This document does not endorse the use of the practices described herein, nor does it aim to provide a comprehensive treatment of the effects of current practices, some of which have been considered controversial from a technical or business perspectives or contradictory to previous IETF statements (e.g., [RFC1958], [RFC1984], and [RFC2804]). The following RFCs consider the end-to-end (e2e) architectural principle to be a guiding principle for the development of Internet protocols [RFC2775] [RFC3724] [RFC7754].
このドキュメントでは、ネットワークオペレーターがネットワークを管理、運用、および保護するために現在使用しているプラクティスと、暗号化の使用の増加への移行がこれらのプラクティスに与える影響について説明します。それは、それらの実践の動機と目的についてのネットワークオペレーターの見方と、暗号化の使用が増加するにつれてオペレーターによって予想される影響を提供します。可視性の低いネットワーク管理に移行する際の運用コミュニティの懸念の要約です。このドキュメントは、本書に記載されている慣行の使用を推奨するものではなく、現在の慣行の影響を包括的に扱うことを目的としていません。その一部は、技術的またはビジネスの観点から議論の余地があると見なされているか、以前のIETFステートメント（たとえば、[RFC1958]、[RFC1984]、および[RFC2804]）。以下のRFCは、エンドツーエンド（e2e）のアーキテクチャの原則を、インターネットプロトコル[RFC2775] [RFC3724] [RFC7754]の開発の指針となるものと見なしています。
This document aims to help IETF participants understand network operators' perspectives about the impact of pervasive encryption, both opportunistic and strong end-to-end encryption, on operational practices. The goal is to help inform future protocol development to ensure that operational impact is part of the conversation. Perhaps new methods could be developed to accomplish some of the goals of current practices despite changes in the extent to which cleartext will be available to network operators (including methods that rely on network endpoints where applicable). Discussion of current practices and the potential future changes is provided as a prerequisite to potential future cross-industry and cross-layer work to support the ongoing evolution towards a functional Internet with pervasive encryption.
このドキュメントは、IETFの参加者が、運用慣行に及ぼす日和見的および強力なエンドツーエンド暗号化の両方の普及暗号化の影響に関するネットワークオペレーターの見解を理解するのに役立つことを目的としています。目標は、将来のプロトコル開発に情報を提供して、運用上の影響が会話の一部であることを確認することです。おそらく、新しい方法を開発して、ネットワークオペレーターが利用できるクリアテキストの範囲が変更されても、現在のプラクティスの目標のいくつかを達成することができます（該当する場合、ネットワークエンドポイントに依存する方法を含む）。現在の慣行と潜在的な将来の変化についての議論は、普及している暗号化を備えた機能的なインターネットに向けて進行中の進化をサポートするための潜在的な将来の業界横断および層横断的な作業の前提条件として提供されています。
Traditional network management, planning, security operations, and performance optimization have been developed on the Internet where a large majority of data traffic flows without encryption. While unencrypted traffic has made information that aids operations and troubleshooting at all layers accessible, it has also made pervasive monitoring by unseen parties possible. With broad support and increased awareness of the need to consider privacy in all aspects across the Internet, it is important to catalog existing management, operational, and security practices that have depended upon the availability of cleartext to function and to explore if critical operational practices can be met by less-invasive means.
従来のネットワーク管理、計画、セキュリティ運用、およびパフォーマンス最適化は、データトラフィックの大部分が暗号化されずに流れるインターネット上で開発されてきました。暗号化されていないトラフィックにより、すべてのレイヤーでの操作とトラブルシューティングに役立つ情報にアクセスできるようになりましたが、目に見えない関係者による広範な監視も可能になりました。幅広いサポートと、インターネット全体のあらゆる面でプライバシーを考慮する必要性の認識の高まりにより、機能するクリアテキストの可用性に依存している既存の管理、運用、およびセキュリティの実践をカタログ化し、重要な運用が可能かどうかを調査することが重要ですより侵襲性の低い手段で満たされる。
This document refers to several different forms of Service Providers (SPs). For example, network service providers (or network operators) provide IP-packet transport primarily, though they may bundle other services with packet transport. Alternatively, application service providers primarily offer systems that participate as an endpoint in communications with the application user and hosting service providers lease computing, storage, and communications systems in data centers. In practice, many companies perform two or more service provider roles but may be historically associated with one.
このドキュメントでは、いくつかの異なる形式のサービスプロバイダー（SP）について説明します。たとえば、ネットワークサービスプロバイダー（またはネットワークオペレーター）は、主にIPパケットトランスポートを提供しますが、他のサービスをパケットトランスポートにバンドルする場合もあります。または、アプリケーションサービスプロバイダーは、主にアプリケーションユーザーとの通信のエンドポイントとして参加するシステムを提供し、ホスティングサービスプロバイダーは、データセンターのコンピューティング、ストレージ、および通信システムをリースします。実際には、多くの企業が2つ以上のサービスプロバイダーの役割を果たしていますが、歴史的には1つに関連付けられている場合があります。
This document includes a sampling of current practices and does not attempt to describe every nuance. Some sections cover technologies used over a broad spectrum of devices and use cases.
このドキュメントには、現在のプラクティスのサンプルが含まれており、すべてのニュアンスを説明しようとするものではありません。一部のセクションでは、幅広いデバイスとユースケースで使用されるテクノロジーについて説明します。
Pervasive encryption in this document refers to all types of session encryption including Transport Layer Security (TLS), IP Security (IPsec), TCPcrypt [TCPcrypt], QUIC [QUIC] (IETF's specification of Google's QUIC), and others that are increasingly deployed. It is well understood that session encryption helps to prevent both passive and active attacks on transport protocols; more on pervasive monitoring can be found in "Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement" [RFC7624]. Active attacks have long been a motivation for increased encryption, and preventing pervasive monitoring became a focus just a few years ago. As such, the Internet Architecture Board (IAB) released a statement advocating for increased use of encryption in November 2014 (see <https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/>). Perspectives on encryption paradigms have shifted over time to make ease of deployment a high priority and to balance that against providing the maximum possible level of security, regardless of deployment considerations.
このドキュメントで広く使用されている暗号化とは、トランスポート層セキュリティ（TLS）、IPセキュリティ（IPsec）、TCPcrypt [TCPcrypt]、QUIC [QUIC]（IETFのGoogle QUICの仕様）、およびますます導入されているその他のすべてのタイプのセッション暗号化を指します。セッション暗号化は、トランスポートプロトコルに対するパッシブ攻撃とアクティブ攻撃の両方を防ぐのに役立つことはよく理解されています。浸透監視の詳細については、「浸透監視に直面する機密性：脅威モデルと問題の説明」[RFC7624]を参照してください。アクティブな攻撃は、長い間暗号化を強化する動機であり、広範に及ぶ監視の防止が数年前に焦点になりました。そのため、インターネットアーキテクチャボード（IAB）は、2014年11月に暗号化の使用の増加を支持する声明を発表しました（<https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentialityを参照） />）。暗号化パラダイムの見方は、展開の容易さを優先度の高いものにし、展開の考慮事項に関係なく、可能な最大レベルのセキュリティを提供することとバランスをとるために、時間とともに変化しました。
One such shift is documented in Opportunistic Security (OS) [RFC7435], which suggests that when use of authenticated encryption is not possible, cleartext sessions should be upgraded to unauthenticated session encryption, rather than no encryption. OS encourages upgrading from cleartext but cannot require or guarantee such upgrades. Once OS is used, it allows for an evolution to authenticated encryption. These efforts are necessary to improve an end user's expectation of privacy, making pervasive monitoring cost prohibitive. With OS in use, active attacks are still possible on unauthenticated sessions. OS has been implemented as NULL Authentication with IPsec [RFC7619], and there are a number of infrastructure use cases such as server-to-server encryption where this mode is deployed. While OS is helpful in reducing pervasive monitoring by increasing the cost to monitor, it is recognized that risk profiles for some applications require authenticated and secure session encryption as well prevention of active attacks. IPsec, and other session encryption protocols, with authentication has many useful applications, and usage has increased for infrastructure applications such as for virtual private networks between data centers. OS, as well as other protocol developments like the Automated Certificate Management Environment (ACME), have increased the usage of session encryption on the Internet.
そのようなシフトの1つはOpportunistic Security（OS）[RFC7435]に文書化されており、認証された暗号化を使用できない場合は、クリアテキストセッションを暗号化せずに非認証セッション暗号化にアップグレードする必要があることを示唆しています。 OSはクリアテキストからのアップグレードを推奨しますが、そのようなアップグレードを要求または保証することはできません。 OSを使用すると、認証された暗号化への進化が可能になります。これらの取り組みは、エンドユーザーのプライバシーに対する期待を向上させ、広範囲にわたる監視コストを法外に高くするために必要です。 OSを使用している場合でも、認証されていないセッションでアクティブな攻撃が可能です。 OSはIPsecを使用したNULL認証として実装されており[RFC7619]、このモードが導入されているサーバー間暗号化など、多くのインフラストラクチャの使用例があります。 OSは監視のコストを増加させることで広範囲の監視を減らすのに役立ちますが、一部のアプリケーションのリスクプロファイルには、認証された安全なセッション暗号化とアクティブな攻撃の防止が必要であることが認識されています。認証を伴うIPsecおよびその他のセッション暗号化プロトコルには、多くの有用なアプリケーションがあり、データセンター間の仮想プライベートネットワークなどのインフラストラクチャアプリケーションの使用が増加しています。 OS、および自動証明書管理環境（ACME）などの他のプロトコル開発により、インターネットでのセッション暗号化の使用が増加しています。
Risk profiles vary and so do the types of session encryption deployed. To understand the scope of changes in visibility, a few examples are highlighted. Work continues to improve the implementation, development, and configuration of TLS and DTLS sessions to prevent active attacks used to monitor or intercept session data. The changes from TLS 1.2 to 1.3 enhance the security of TLS, while hiding more of the session negotiation and providing less visibility on the wire. The Using TLS in Applications (UTA) Working Group has been publishing documentation to improve the security of TLS and DTLS sessions. They have documented the known attack vectors in [RFC7457], have documented best practices for TLS and DTLS in [RFC7525], and have other documents in development. The recommendations from these documents were built upon for TLS 1.3 to provide a more inherently secure end-to-end protocol.
リスクプロファイルはさまざまであり、展開されるセッション暗号化のタイプも異なります。可視性の変更の範囲を理解するために、いくつかの例が強調表示されています。 TLSおよびDTLSセッションの実装、開発、および構成を引き続き改善する作業により、セッションデータの監視または傍受に使用されるアクティブな攻撃を防止しています。 TLS 1.2から1.3への変更により、TLSのセキュリティが強化され、セッションネゴシエーションの多くが隠され、ネットワーク上での可視性が低下します。アプリケーションでのTLSの使用（UTA）ワーキンググループは、TLSおよびDTLSセッションのセキュリティを向上させるためのドキュメントを公開しています。彼らは[RFC7457]で既知の攻撃ベクトルを文書化し、[RFC7525]でTLSとDTLSのベストプラクティスを文書化し、その他の文書を開発中です。これらのドキュメントの推奨事項は、TLS 1.3に基づいて構築され、より本質的に安全なエンドツーエンドプロトコルを提供します。
In addition to encrypted website access (HTTP over TLS), there are other well-deployed application-level transport encryption efforts such as MTA-to-MTA (mail transfer agent) session encryption transport for email (SMTP over TLS) and gateway-to-gateway for instant messaging (the Extensible Messaging and Presence Protocol (XMPP) over TLS). Although this does provide protection from transport-layer attacks, the servers could be a point of vulnerability if user-to-user encryption is not provided for these messaging protocols. User-to-user content encryption schemes, such as S/MIME and Pretty Good Privacy (PGP) for email and Off-the-Record (OTR) encryption for XMPP are used by those interested in protecting their data as it crosses intermediary servers, preventing transport-layer attacks by providing an end-to-end solution. User-to-user schemes are under review, and additional options will emerge to ease the configuration requirements, making this type of option more accessible to non-technical users interested in protecting their privacy.
暗号化されたWebサイトアクセス（HTTP over TLS）に加えて、MTA（MTA）へのMTA（メール転送エージェント）セッション暗号化トランスポート（SMTP over TLS）やゲートウェイから-インスタントメッセージングのゲートウェイ（TLSを介した拡張メッセージングおよびプレゼンスプロトコル（XMPP））。これはトランスポート層攻撃からの保護を提供しますが、これらのメッセージングプロトコルにユーザー間の暗号化が提供されていない場合、サーバーは脆弱性のポイントになる可能性があります。電子メールのS / MIMEやPretty Good Privacy（PGP）やXMPPのオフレコ（OTR）暗号化などのユーザー間コンテンツ暗号化スキームは、データが中間サーバーを通過するときにデータを保護することに関心を持つ人々によって使用されます。エンドツーエンドのソリューションを提供することにより、トランスポート層攻撃を防止します。ユーザー間のスキームが検討されており、構成要件を緩和する追加オプションが登場し、このタイプのオプションは、プライバシーの保護に関心のある非技術系ユーザーがよりアクセスしやすくなります。
Increased use of encryption, either opportunistic or authenticated, at the transport, network, or application layer, impacts how networks are operated, managed, and secured. In some cases, new methods to operate, manage, and secure networks will evolve in response. In other cases, currently available capabilities for monitoring or troubleshooting networks could become unavailable. This document lists a collection of functions currently employed by network operators that may be impacted by the shift to increased use of encryption. This document does not attempt to specify responses or solutions to these impacts; it documents the current state.
トランスポート層、ネットワーク層、またはアプリケーション層での便宜的または認証済みの暗号化の使用の増加は、ネットワークの運用、管理、および保護の方法に影響を与えます。場合によっては、ネットワークを操作、管理、保護する新しい方法がそれに応じて進化します。他の場合では、ネットワークの監視またはトラブルシューティングに現在利用可能な機能が利用できなくなる可能性があります。このドキュメントでは、暗号化の使用の増加への移行によって影響を受ける可能性のある、ネットワークオペレーターが現在採用している機能のコレクションを示します。このドキュメントでは、これらの影響に対する対応や解決策を指定することは試みません。現在の状態を文書化します。
Following the Snowden [Snowden] revelations, application service providers (Yahoo, Google, etc.) responded by encrypting traffic between their data centers (IPsec) to prevent passive monitoring from taking place unbeknownst to them. Infrastructure traffic carried over the public Internet has been encrypted for some time; this change for universal encryption was specific to their private backbones. Large mail service providers also began to encrypt session transport (TLS) to hosted mail services. This and other increases in the use of encryption had the immediate effect of providing confidentiality and integrity for protected data, but it created a problem for some network-management functions. Operators could no longer gain access to some session streams resulting in actions by several to regain their operational practices that previously depended on cleartext data sessions.
Snowden [Snowden]の暴露を受けて、アプリケーションサービスプロバイダー（Yahoo、Googleなど）は、データセンター間のトラフィックを暗号化（IPsec）して対応し、知らないうちに受動的な監視が行われないようにしました。公共のインターネットを介して伝送されるインフラストラクチャトラフィックは、しばらくの間暗号化されています。ユニバーサル暗号化のこの変更は、プライベートバックボーンに固有のものでした。大規模なメールサービスプロバイダーも、ホストされたメールサービスへのセッショントランスポート（TLS）を暗号化し始めました。暗号化の使用におけるこの増加およびその他の増加は、保護されたデータに機密性と完全性を提供するという即時の効果をもたらしましたが、一部のネットワーク管理機能に問題を引き起こしました。オペレーターは、一部のセッションストリームにアクセスできなくなり、以前はクリアテキストデータセッションに依存していた運用慣行を取り戻すためのアクションがいくつか発生しました。
The Electronic Frontier Foundation (EFF) reported [EFF2014] several network service providers using a downgrade attack to prevent the use of SMTP over TLS by breaking STARTTLS (Section 3.2 of [RFC7525]), essentially preventing the negotiation process resulting in fallback to the use of cleartext. There have already been documented cases of service providers preventing STARTTLS to avoid session encryption negotiation on some sessions. Doing so allows them to inject a super cookie that enables advertisers to track users; these actions are also considered an attack. These serve as examples of undesirable behavior that could be prevented through upfront discussions in protocol work for operators and protocol designers to understand the implications of such actions. In other cases, some service providers and enterprises have relied on middleboxes having access to cleartext for load-balancing, monitoring for attack traffic, meeting regulatory requirements, or other purposes. The implications for enterprises that own the data on their networks or that have explicit agreements that permit the monitoring of user traffic are very different from those for service providers who may be accessing content in a way that violates privacy considerations. Additionally, service provider equipment is designed for accessing only the headers exposed for the data-link, network, and transport layers. Delving deeper into packets is possible, but there is typically a high degree of accuracy from the header information and packet sizes when limited to header information from these three layers. Service providers also have the option of adding routing overlay protocols to traffic. These middlebox implementations, performing functions either considered legitimate by the IETF or not, have been impacted by increases in encrypted traffic. Only methods keeping with the goal of balancing network management and pervasive monitoring mitigation as discussed in [RFC7258] should be considered in work toward a solution resulting from this document.
Electronic Frontier Foundation（EFF）は、[EFF2014]ダウングレード攻撃を使用してSTARTTLS（[RFC7525]のセクション3.2）を破壊することにより、SMTP over TLSの使用を防止し、基本的にネゴシエーションプロセスを阻止して使用にフォールバックすることを報告しました。クリアテキストの。一部のセッションでのセッション暗号化ネゴシエーションを回避するためにサービスプロバイダーがSTARTTLSを妨害するケースはすでに文書化されています。そうすることで、広告主がユーザーを追跡できるようにするスーパーCookieを挿入できます。これらのアクションも攻撃と見なされます。これらは、オペレーターとプロトコル設計者がそのようなアクションの影響を理解するためのプロトコル作業における事前の議論を通じて防止できる望ましくない動作の例として役立ちます。他のケースでは、一部のサービスプロバイダーや企業は、ロードバランシング、攻撃トラフィックの監視、規制要件への適合などの目的でクリアテキストにアクセスできるミドルボックスに依存しています。ネットワーク上のデータを所有している、またはユーザートラフィックの監視を許可する明示的な合意を持っている企業への影響は、プライバシーに関する考慮事項に違反する方法でコンテンツにアクセスしているサービスプロバイダーへの影響とは大きく異なります。さらに、サービスプロバイダーの機器は、データリンク、ネットワーク、およびトランスポート層に公開されたヘッダーのみにアクセスするように設計されています。パケットをより深く掘り下げることは可能ですが、これらの3つの層からのヘッダー情報に限定すると、通常はヘッダー情報とパケットサイズからの精度が高くなります。サービスプロバイダーには、ルーティングオーバーレイプロトコルをトラフィックに追加するオプションもあります。これらのミドルボックスの実装は、IETFによって正当と見なされるかどうかに関係なく機能を実行し、暗号化されたトラフィックの増加による影響を受けています。 [RFC7258]で説明されているように、ネットワーク管理と広範囲にわたる監視の軽減のバランスを保つという目標に沿った方法のみが、このドキュメントから生じるソリューションに向けた作業で検討されるべきです。
It is well known that national surveillance programs monitor traffic for criminal activities [JNSLP] [RFC2804] [RFC7258]. Governments vary on their balance between monitoring versus the protection of user privacy, data, and assets. Those that favor unencrypted access to data ignore the real need to protect users' identities, financial transactions, and intellectual property (which require security and encryption to prevent crime). A clear understanding of technology, encryption, and monitoring goals will aid in the development of solutions as work continues towards finding an appropriate balance that allows for management while protecting user privacy with strong encryption solutions.
国の監視プログラムが犯罪行為のトラフィックを監視することはよく知られています[JNSLP] [RFC2804] [RFC7258]。政府は、監視とユーザーのプライバシー、データ、および資産の保護との間のバランスが異なります。データへの暗号化されていないアクセスを好むユーザーは、ユーザーのID、金融取引、および知的財産（犯罪を防ぐためにセキュリティと暗号化が必要）を保護するという本当の必要性を無視します。テクノロジー、暗号化、およびモニタリングの目標を明確に理解することで、強力な暗号化ソリューションでユーザーのプライバシーを保護しながら管理を可能にする適切なバランスを見つけるための作業が続けられるため、ソリューションの開発に役立ちます。
Service providers, for this definition, include the backbone ISPs as well as those providing infrastructure at scale for core Internet use (hosted infrastructure and services such as email).
この定義のサービスプロバイダーには、バックボーンISP、およびコアインターネット使用のための大規模なインフラストラクチャ（ホストされているインフラストラクチャと電子メールなどのサービス）を提供するプロバイダーが含まれます。
Network service providers use various techniques to operate, manage, and secure their networks. The following subsections detail the purpose of several techniques as well as which protocol fields are used to accomplish each task. In response to increased encryption of these fields, some network service providers may be tempted to undertake undesirable security practices in order to gain access to the fields in unencrypted data flows. To avoid this situation, new methods could be developed to accomplish the same goals without service providers having the ability to see session data.
ネットワークサービスプロバイダーは、さまざまな手法を使用してネットワークを運用、管理、および保護します。次のサブセクションでは、いくつかの手法の目的と、各タスクを実行するために使用されるプロトコルフィールドについて詳しく説明します。これらのフィールドの暗号化の増加に対応して、一部のネットワークサービスプロバイダーは、暗号化されていないデータフローのフィールドにアクセスするために、望ましくないセキュリティ対策を講じようとする場合があります。この状況を回避するために、サービスプロバイダーがセッションデータを表示する機能を持たなくても、同じ目標を達成する新しい方法を開発できます。
Internet traffic surveys are useful in many pursuits, such as input for studies of the Center for Applied Internet Data Analysis (CAIDA) [CAIDA], network planning, and optimization. Tracking the trends in Internet traffic growth, from earlier peer-to-peer communication to the extensive adoption of unicast video streaming applications, has relied on a view of traffic composition with a particular level of assumed accuracy, based on access to cleartext by those conducting the surveys.
インターネットトラフィック調査は、応用インターネットデータ分析センター（CAIDA）[CAIDA]の研究への入力、ネットワーク計画、最適化など、多くの目的で役立ちます。以前のピアツーピア通信からユニキャストビデオストリーミングアプリケーションの広範な採用まで、インターネットトラフィックの増加傾向を追跡することは、実施者によるクリアテキストへのアクセスに基づいて、想定される特定のレベルの精度でトラフィック構成のビューに依存してきました調査。
Passive monitoring makes inferences about observed traffic using the maximal information available and is subject to inaccuracies stemming from incomplete sampling (of packets in a stream) or loss due to monitoring-system overload. When encryption conceals more layers in each packet, reliance on pattern inferences and other heuristics grows and accuracy suffers. For example, the traffic patterns between server and browser are dependent on browser supplier and version, even when the sessions use the same server application (e.g., web email access). It remains to be seen whether more complex inferences can be mastered to produce the same monitoring accuracy.
パッシブモニタリングは、利用可能な最大の情報を使用して、観測されたトラフィックを推測し、（ストリーム内のパケットの）不完全なサンプリングまたはモニタリングシステムの過負荷による損失に起因する不正確さの影響を受けます。暗号化により各パケットでより多くの層が隠されると、パターン推論およびその他のヒューリスティックへの依存が高まり、精度が低下します。たとえば、セッションが同じサーバーアプリケーション（Webメールアクセスなど）を使用している場合でも、サーバーとブラウザー間のトラフィックパターンはブラウザーのサプライヤーとバージョンに依存します。同じ監視精度を生成するために、より複雑な推論を習得できるかどうかは、今後の課題です。
Network operators use protocol-dissecting analyzers when responding to customer problems, to identify the presence of attack traffic, and to identify root causes of the problem such as misconfiguration. In limited cases, packet captures may also be used when a customer approves of access to their packets or provides packet captures close to the endpoint. The protocol dissection is generally limited to supporting protocols (e.g., DNS and DHCP), network and transport (e.g., IP and TCP), and some higher-layer protocols (e.g., RTP and the RTP Control Protocol (RTCP)). Troubleshooting will move closer to the endpoint with increased encryption and adjustments in practices to effectively troubleshoot using a 5-tuple may require education. Packet-loss investigations, and those where access is limited to a 2-tuple (IPsec tunnel mode), rely on network and transport-layer headers taken at the endpoint. In this case, captures on intermediate nodes are not reliable as there are far too many cases of aggregate interfaces and alternate paths in service provider networks.
ネットワークオペレータは、顧客の問題に対応するときにプロトコル分析アナライザを使用して、攻撃トラフィックの存在を識別し、設定ミスなどの問題の根本原因を識別します。限られたケースでは、パケットキャプチャは、顧客がパケットへのアクセスを承認したり、エンドポイントの近くでパケットキャプチャを提供したりするときにも使用できます。プロトコルの解剖は一般的に、サポートするプロトコル（DNSやDHCPなど）、ネットワークとトランスポート（IPやTCPなど）、一部の上位層プロトコル（RTPやRTP制御プロトコル（RTCP）など）に限定されます。トラブルシューティングは、暗号化を強化し、5タプルを使用して効果的にトラブルシューティングを行うためのプラクティスの調整により、エンドポイントに近づきます。教育が必要になる場合があります。パケット損失調査、およびアクセスが2タプル（IPsecトンネルモード）に制限されている調査は、エンドポイントで取得されたネットワークおよびトランスポート層ヘッダーに依存します。この場合、中間ノードでのキャプチャは、サービスプロバイダーネットワーク内の集約インターフェイスと代替パスのケースが多すぎるため、信頼できません。
Network operators are often the first ones called upon to investigate application problems (e.g., "my HD video is choppy"), to first rule out network and network services as a cause for the underlying issue. When diagnosing a customer problem, the starting point may be a particular application that isn't working. The ability to identify the problem application's traffic is important, and packet capture provided from the customer close to the edge may be used for this purpose; IP address filtering is not useful for applications using Content Delivery Networks (CDNs) or cloud providers. After identifying the traffic, an operator may analyze the traffic characteristics and routing of the traffic. This diagnostic step is important to help determine the root cause before exploring if the issue is directly with the application.
多くの場合、ネットワークオペレーターは、アプリケーションの問題（「HDビデオが途切れる」など）を調査し、根本的な問題の原因として最初にネットワークとネットワークサービスを除外することを求められる最初のオペレーターです。顧客の問題を診断する場合、開始点は、機能していない特定のアプリケーションである可能性があります。問題のあるアプリケーションのトラフィックを識別する機能は重要であり、エッジの近くの顧客から提供されたパケットキャプチャをこの目的に使用できます。 IPアドレスフィルタリングは、コンテンツ配信ネットワーク（CDN）またはクラウドプロバイダーを使用するアプリケーションには役立ちません。トラフィックを識別した後、オペレーターはトラフィックの特性とトラフィックのルーティングを分析できます。この診断手順は、問題がアプリケーションに直接あるかどうかを調べる前に、根本的な原因を特定するのに重要です。
For example, by investigating packet loss (from TCP sequence and acknowledgement numbers), Round-Trip Time (RTT) (from TCP timestamp options or application-layer transactions, e.g., DNS or HTTP response time), TCP receive-window size, packet corruption (from checksum verification), inefficient fragmentation, or application-layer problems, the operator can narrow the problem to a portion of the network, server overload, client or server misconfiguration, etc. Network operators may also be able to identify the presence of attack traffic as not conforming to the application the user claims to be using. In many instances, the exposed packet header is sufficient for this type of troubleshooting.
たとえば、（TCPシーケンスおよび確認番号からの）パケット損失、（TCPタイムスタンプオプションまたはアプリケーション層トランザクション（DNSまたはHTTP応答時間など）からの）ラウンドトリップ時間（RTT）、TCP受信ウィンドウサイズ、パケットを調査することによって破損（チェックサム検証による）、非効率的な断片化、またはアプリケーション層の問題の場合、オペレーターは問題をネットワークの一部、サーバーの過負荷、クライアントまたはサーバーの構成ミスなどに絞り込むことができます。ネットワークオペレーターは、ユーザーが使用していると主張するアプリケーションに準拠していないとしてトラフィックを攻撃します。多くの場合、このタイプのトラブルシューティングには、公開されたパケットヘッダーで十分です。
One way of quickly excluding the network as the bottleneck during troubleshooting is to check whether the speed is limited by the endpoints. For example, the connection speed might instead be limited by suboptimal TCP options, the sender's congestion window, the sender temporarily running out of data to send, the sender waiting for the receiver to send another request, or the receiver closing the receive window. All this information can be derived from the cleartext TCP header.
トラブルシューティング中にボトルネックとしてネットワークをすばやく除外する1つの方法は、速度がエンドポイントによって制限されているかどうかを確認することです。たとえば、接続速度は、次善のTCPオプション、送信者の輻輳ウィンドウ、送信するデータが一時的に不足している送信者、受信者が別の要求を送信するのを待っている送信者、または受信者が受信ウィンドウを閉じることによって制限される場合があります。この情報はすべて、クリアテキストのTCPヘッダーから取得できます。
Packet captures and protocol-dissecting analyzers have been important tools. Automated monitoring has also been used to proactively identify poor network conditions, leading to maintenance and network upgrades before user experience declines. For example, findings of loss and jitter in Voice over IP (VoIP) traffic can be a predictor of future customer dissatisfaction (supported by metadata from RTP/RTCP) [RFC3550], or increases in DNS response time can generally make interactive web browsing appear sluggish. But, to detect such problems, the application or service stream must first be distinguished from others.
パケットキャプチャとプロトコル分析アナライザは重要なツールです。また、自動監視機能を使用して、ネットワークの不良状態を事前に特定し、ユーザーエクスペリエンスが低下する前にメンテナンスやネットワークのアップグレードを行っています。たとえば、Voice over IP（VoIP）トラフィックの損失とジッタの発見は、将来の顧客の不満（RTP / RTCPからのメタデータによってサポートされる）[RFC3550]の予測因子になる可能性があります。鈍い。ただし、このような問題を検出するには、まずアプリケーションまたはサービスストリームを他のストリームと区別する必要があります。
When increased encryption is used, operators lose a source of data that may be used to debug user issues. For example, IPsec obscures TCP and RTP header information, while TLS and the Secure Real-time Transport Protocol (SRTP) do not. Because of this, application-server operators using increased encryption might be called upon more frequently to assist with debugging and troubleshooting; thus, they may want to consider what tools can be put in the hands of their clients or network operators.
暗号化を強化すると、オペレーターはユーザーの問題のデバッグに使用できるデータのソースを失います。たとえば、IPsecはTCPおよびRTPヘッダー情報を覆い隠しますが、TLSおよびSecure Real-time Transport Protocol（SRTP）は覆い隠しません。このため、暗号化を強化したアプリケーションサーバーオペレーターは、デバッグとトラブルシューティングを支援するために、より頻繁に要求される場合があります。したがって、クライアントやネットワークオペレーターが手に入れることができるツールを検討する必要があります。
Further, the performance of some services can be more efficiently managed and repaired when information on user transactions is available to the service provider. It may be possible to continue transaction-monitoring activities without cleartext access to the application layers of interest; however, inaccuracy will increase and efficiency of repair activities will decrease. For example, an application-protocol error or failure would be opaque to network troubleshooters when transport encryption is applied, making root cause location more difficult and, therefore, increasing the time to repair. Repair time directly reduces the availability of the service, and most network operators have made availability a key metric in their Service Level Agreements (SLAs) and/or subscription rebates. Also, there may be more cases of user-communication failures when the additional encryption processes are introduced (e.g., key management at large scale), leading to more customer service contacts and (at the same time) less information available to network-operation repair teams.
さらに、サービスプロバイダーがユーザートランザクションに関する情報を利用できる場合、一部のサービスのパフォーマンスをより効率的に管理および修復できます。対象のアプリケーション層へのクリアテキストアクセスなしでトランザクション監視アクティビティを続行できる可能性があります。ただし、不正確さが増し、修理作業の効率が低下します。たとえば、トランスポート暗号化が適用されている場合、アプリケーションプロトコルのエラーや障害はネットワークのトラブルシューティングでわかりにくくなり、根本原因の特定がより困難になり、修復にかかる時間が長くなります。修理時間はサービスの可用性を直接低下させ、ほとんどのネットワークオペレーターは可用性をサービスレベルアグリーメント（SLA）および/またはサブスクリプションリベートの主要なメトリックにしています。また、追加の暗号化プロセスが導入されると（たとえば、大規模なキー管理）、より多くの顧客サービス連絡先につながり、（同時に）ネットワーク操作の修復に利用できる情報が少なくなるため、ユーザー通信障害のケースが増える可能性があります。チーム。
In mobile networks, knowledge about TCP's stream transfer progress (by observing ACKs, retransmissions, packet drops, and the Sector Utilization Level, etc.) is further used to measure the performance of network segments (sector, eNodeB (eNB), etc.). This information is used as key performance indicators (KPIs) and for the estimation of user/service key quality indicators at network edges for circuit emulation (CEM) as well as input for mitigation methods. If the makeup of active services per user and per sector are not visible to a server that provides Internet Access Point Names (APNs), it cannot perform mitigation functions based on network segment view.
モバイルネットワークでは、ネットワークセグメント（セクター、eNodeB（eNB）など）のパフォーマンスを測定するために、TCPのストリーム転送の進行状況（ACK、再送信、パケットドロップ、およびセクター使用率レベルなどを監視することによる）に関する知識がさらに使用されます。 。この情報は、主要なパフォーマンスインジケーター（KPI）として、および回線エミュレーション（CEM）のネットワークエッジでのユーザー/サービスの主要な品質インジケーターの推定と軽減方法の入力に使用されます。ユーザーごとおよびセクターごとのアクティブなサービスの構成が、インターネットアクセスポイント名（APN）を提供するサーバーに表示されない場合、ネットワークセグメントビューに基づく軽減機能を実行できません。
It is important to note that the push for encryption by application providers has been motivated by the application of the described techniques. Although network operators have noted performance improvements with network-based optimization or enhancement of user traffic (otherwise, deployment would not have occurred), application providers have likewise noted some degraded performance and/or user experience, and such cases may result in additional operator troubleshooting. Further, encrypted application streams might avoid outdated optimization or enhancement techniques, where they exist.
アプリケーションプロバイダーによる暗号化の推進は、説明されている手法のアプリケーションによって動機付けられていることに注意することが重要です。ネットワークオペレーターは、ネットワークベースの最適化またはユーザートラフィックの強化によるパフォーマンスの向上に言及しています（そうでない場合、展開は行われませんでした）。同様に、アプリケーションプロバイダーは、パフォーマンスやユーザーエクスペリエンスの低下を指摘しており、そのような場合、オペレーターのトラブルシューティングが増える可能性があります。 。さらに、暗号化されたアプリケーションストリームは、それらが存在する場合、古い最適化または拡張技術を回避する可能性があります。
A gap exists for vendors where built-in diagnostics and serviceability are not adequate to provide detailed logging and debugging capabilities that, when possible, could be accessed with cleartext network parameters. In addition to traditional logging and debugging methods, packet tracing and inspection along the service path provides operators the visibility to continue to diagnose problems reported both internally and by their customers. Logging of service path upon exit for routing overlay protocols will assist with policy management and troubleshooting capabilities for traffic flows on encrypted networks. Protocol trace logging and protocol data unit (PDU) logging should also be considered to improve visibility to monitor and troubleshoot application-level traffic. Additional work on this gap would assist network operators to better troubleshoot and manage networks with increasing amounts of encrypted traffic.
組み込みの診断機能と保守性では、可能な場合はクリアテキストのネットワークパラメータでアクセスできる詳細なロギング機能とデバッグ機能を提供するのに十分ではないベンダーにはギャップがあります。従来のロギングとデバッグの方法に加えて、サービスパスに沿ったパケットトレースと検査により、オペレーターは内部と顧客の両方から報告された問題を診断し続けることができます。ルーティングオーバーレイプロトコルの出口でのサービスパスのロギングは、暗号化されたネットワーク上のトラフィックフローのポリシー管理およびトラブルシューティング機能に役立ちます。アプリケーションレベルのトラフィックを監視およびトラブルシューティングするための可視性を向上させるには、プロトコルトレースログとプロトコルデータユニット（PDU）ログも考慮する必要があります。このギャップに関する追加の作業は、ネットワークオペレーターが暗号化されたトラフィックの量が増加するネットワークのトラブルシューティングと管理を改善するのに役立ちます。
Fingerprinting is used in traffic analysis and monitoring to identify traffic streams that match certain patterns. This technique can be used with both cleartext and encrypted sessions. Some Distributed Denial-of-Service (DDoS) prevention techniques at the network-provider level rely on the ability to fingerprint traffic in order to mitigate the effect of this type of attack. Thus, fingerprinting may be an aspect of an attack or part of attack countermeasures.
フィンガープリンティングは、特定のパターンに一致するトラフィックストリームを識別するために、トラフィック分析とモニタリングで使用されます。この手法は、クリアテキストセッションと暗号化セッションの両方で使用できます。ネットワークプロバイダーレベルの一部の分散サービス拒否（DDoS）防止技術は、このタイプの攻撃の影響を軽減するためにトラフィックをフィンガープリントする機能に依存しています。したがって、フィンガープリントは、攻撃の一部または攻撃対策の一部である可能性があります。
A common, early trigger for DDoS mitigation includes observing uncharacteristic traffic volumes or sources, congestion, or degradation of a given network or service. One approach to mitigate such an attack involves distinguishing attacker traffic from legitimate user traffic. The ability to examine layers and payloads above transport provides an increased range of filtering opportunities at each layer in the clear. If fewer layers are in the clear, this means that there are reduced filtering opportunities available to mitigate attacks. However, fingerprinting is still possible.
DDoS緩和の一般的な初期トリガーには、特定のネットワークまたはサービスの特徴のないトラフィック量またはソース、輻輳、または劣化の観察が含まれます。このような攻撃を軽減する1つの方法は、攻撃者のトラフィックを正当なユーザートラフィックから区別することです。トランスポートより上のレイヤーとペイロードを検査する機能により、クリアな各レイヤーでのフィルタリングの機会の範囲が広がります。クリアになっているレイヤーの数が少ない場合、これは、攻撃を緩和するために利用できるフィルタリングの機会が少ないことを意味します。ただし、フィンガープリントは引き続き可能です。
Passive monitoring of network traffic can lead to invasion of privacy by external actors at the endpoints of the monitored traffic. Encryption of traffic end to end is one method to obfuscate some of the potentially identifying information. For example, browser fingerprints are comprised of many characteristics, including User Agents, HTTP Accept headers, browser plug-in details, screen size and color details, system fonts, and time zones. A monitoring system could easily identify a specific browser, and by correlating other information, identify a specific user.
ネットワークトラフィックのパッシブモニタリングは、モニタリングされたトラフィックのエンドポイントで外部のアクターによるプライバシーの侵害につながる可能性があります。エンドツーエンドのトラフィックの暗号化は、潜在的に識別できる情報の一部を難読化する1つの方法です。たとえば、ブラウザフィンガープリントは、ユーザーエージェント、HTTP Acceptヘッダー、ブラウザプラグインの詳細、画面サイズと色の詳細、システムフォント、タイムゾーンなど、多くの特性で構成されています。監視システムは、特定のブラウザを簡単に識別でき、他の情報を関連付けることにより、特定のユーザーを識別できます。
A standalone load balancer is a function one can take off the shelf, place in front of a pool of servers, and configure appropriately, and it will balance the traffic load among servers in the pool. This is a typical setup for load balancers. Standalone load balancers rely on the plainly observable information in the packets they are forwarding and industry-accepted standards in interpreting the plainly observable information. Typically, this is a 5-tuple of the connection. This type of configuration terminates TLS sessions at the load balancer, making it the endpoint instead of the server. Standalone load balancers are considered middleboxes, but they are an integral part of server infrastructure that scales.
スタンドアロンロードバランサーは、棚から外してサーバーのプールの前に配置し、適切に構成できる機能であり、プール内のサーバー間でトラフィックの負荷を分散します。これはロードバランサーの一般的なセットアップです。スタンドアロンロードバランサーは、転送しているパケット内の明白に観察可能な情報と、明白に観察可能な情報を解釈する際に業界で受け入れられている標準に依存しています。通常、これは接続の5タプルです。このタイプの構成は、ロードバランサーでTLSセッションを終了し、サーバーではなくエンドポイントにします。スタンドアロンロードバランサーはミドルボックスと見なされますが、拡張性のあるサーバーインフラストラクチャの不可欠な部分です。
In contrast, an integrated load balancer is developed to be an integral part of the service provided by the server pool behind that load balancer. These load balancers can communicate state with their pool of servers to better route flows to the appropriate servers. They rely on non-standard, system-specific information and operational knowledge shared between the load balancer and its servers.
対照的に、統合ロードバランサーは、そのロードバランサーの背後にあるサーバープールによって提供されるサービスの不可欠な部分になるように開発されています。これらのロードバランサーは、サーバーのプールと状態を通信して、適切なサーバーにフローをより適切にルーティングできます。それらは、ロードバランサーとそのサーバー間で共有される非標準のシステム固有の情報と運用知識に依存しています。
Both standalone and integrated load balancers can be deployed in pools for redundancy and load sharing. For high availability, it is important that when packets belonging to a flow start to arrive at a different load balancer in the load-balancer pool, the packets continue to be forwarded to the original server in the server pool. The importance of this requirement increases as the chance of such a load balancer change event increases.
スタンドアロンと統合ロードバランサーの両方をプールにデプロイして、冗長性と負荷分散を実現できます。高可用性を実現するには、フローに属するパケットがロードバランサープール内の別のロードバランサーに到着し始めると、パケットがサーバープール内の元のサーバーに転送され続けることが重要です。この要件の重要性は、そのようなロードバランサーの変更イベントが発生する可能性が高まるにつれて高まります。
Mobile operators deploy integrated load balancers to assist with maintaining connection state as devices migrate. With the proliferation of mobile connected devices, there is an acute need for connection-oriented protocols that maintain connections after a network migration by an endpoint. This connection persistence provides an additional challenge for multihomed anycast-based services typically employed by large content owners and CDNs. The challenge is that a migration to a different network in the middle of the connection greatly increases the chances of the packets routed to a different anycast point of presence (POP) due to the new network's different connectivity and Internet peering arrangements. The load balancer in the new POP, potentially thousands of miles away, will not have information about the new flow and would not be able to route it back to the original POP.
モバイルオペレーターは、統合されたロードバランサーを展開して、デバイスの移行時に接続状態を維持できるようにします。モバイル接続デバイスの急増に伴い、エンドポイントによるネットワーク移行後も接続を維持する接続指向のプロトコルが急務となっています。この接続の永続性は、大規模なコンテンツ所有者やCDNで一般的に採用されているマルチホームエニーキャストベースのサービスに追加の課題を提供します。課題は、接続の途中で別のネットワークに移行すると、新しいネットワークの接続性とインターネットピアリングの配置が異なるため、パケットが別のエニーキャストポイントオブプレゼンス（POP）にルーティングされる可能性が大幅に増えることです。新しいPOPのロードバランサーは、数千マイル離れている可能性があり、新しいフローに関する情報がなく、元のPOPにルーティングできません。
To help with the endpoint network migration challenges, anycast service operations are likely to employ integrated load balancers that, in cooperation with their pool servers, are able to ensure that client-to-server packets contain some additional identification in plainly observable parts of the packets (in addition to the 5-tuple). As noted in Section 2 of [RFC7258], careful consideration in protocol design to mitigate pervasive monitoring is important, while ensuring manageability of the network.
エンドポイントネットワークの移行の課題を支援するために、エニーキャストサービスの運用では、プールサーバーと連携して、クライアントからサーバーへのパケットがパケットの明白に観察可能な部分に追加の識別情報を確実に含むことができる統合ロードバランサーを採用する可能性があります（5タプルに加えて）。 [RFC7258]のセクション2で述べたように、ネットワークの管理性を確保しながら、広範囲にわたる監視を軽減するためのプロトコル設計における注意深い検討が重要です。
An area for further research includes end-to-end solutions that would provide a simpler architecture and that may solve the issue with CDN anycast. In this case, connections would be migrated to a CDN unicast address.
さらなる研究の領域には、より単純なアーキテクチャを提供し、CDNエニーキャストの問題を解決する可能性のあるエンドツーエンドのソリューションが含まれます。この場合、接続はCDNユニキャストアドレスに移行されます。
Current protocols, such as TCP, allow the development of stateless integrated load balancers by availing such load balancers of additional plaintext information in client-to-server packets. In case of TCP, such information can be encoded by having server-generated sequence numbers (that are ACKed by the client), segment values, lengths of the packet sent, etc. The use of some of these mechanisms for load balancing negates some of the security assumptions associated with those primitives (e.g., that an off-path attacker guessing valid sequence numbers for a flow is hard). Another possibility is a dedicated mechanism for storing load-balancer state, such as QUIC's proposed connection ID to provide visibility to the load balancer. An identifier could be used for tracking purposes, but this may provide an option that is an improvement from bolting it on to an unrelated transport signal.
TCPなどの現在のプロトコルでは、クライアントからサーバーへのパケットで追加の平文情報のロードバランサーを利用することにより、ステートレスな統合ロードバランサーを開発できます。 TCPの場合、そのような情報は、サーバーが生成したシーケンス番号（クライアントがACKする）、セグメント値、送信されたパケットの長さなどを使用してエンコードできます。これらのメカニズムの一部をロードバランシングに使用すると、それらのプリミティブに関連付けられたセキュリティの仮定（たとえば、パスのオフの攻撃者がフローの有効なシーケンス番号を推測するのは難しい）。もう1つの可能性は、ロードバランサーに可視性を提供するQUICの提案された接続IDなど、ロードバランサーの状態を保存するための専用メカニズムです。識別子は追跡の目的で使用できますが、これにより、無関係なトランスポート信号にそれを追加することから改善されるオプションが提供される場合があります。
This method allows for tight control by one of the endpoints and can be rotated to avoid roving client linkability: in other words, being a specific, separate signal, it can be governed in a way that is finely targeted at that specific use case.
このメソッドは、エンドポイントの1つによる厳密な制御を可能にし、ローテーションしてクライアントのリンク可能性のロービングを回避できます。つまり、特定の個別の信号であるため、その特定のユースケースを細かく対象とする方法で管理できます。
Some integrated load balancers have the ability to use additional plainly observable information even for today's protocols that are not network-migration tolerant. This additional information allows for improved availability and scalability of the load-balancing operation. For example, BGP reconvergence can cause a flow to switch anycast POPs, even without a network change by any endpoint. Additionally, a system that is able to encode the identity of the pool server in plaintext information available in each incoming packet is able to provide stateless load balancing. This ability confers great reliability and scalability advantages, even if the flow remains in a single POP, because the load-balancing system is not required to keep state of each flow. Even more importantly, there's no requirement to continuously synchronize such state among the pool of load balancers. An integrated load balancer repurposing limited existing bits in transport-flow state must maintain and synchronize per-flow state occasionally: using the sequence number as a cookie only works for so long given that there aren't that many bits available to divide across a pool of machines.
一部の統合ロードバランサーは、ネットワーク移行に対応していない今日のプロトコルでも、明白に観察可能な追加情報を使用する機能を備えています。この追加情報により、負荷分散操作の可用性とスケーラビリティが向上します。たとえば、BGPの再収束により、エンドポイントによるネットワークの変更がなくても、フローがエニーキャストPOPを切り替えることがあります。さらに、各着信パケットで利用可能なプレーンテキスト情報でプールサーバーのIDをエンコードできるシステムは、ステートレスロードバランシングを提供できます。負荷分散システムは各フローの状態を維持する必要がないため、この機能は、フローが単一のPOPに残っている場合でも、信頼性とスケーラビリティに大きな利点をもたらします。さらに重要なことに、ロードバランサーのプール間でこのような状態を継続的に同期する必要はありません。トランスポートフロー状態の限られた既存のビットを転用する統合ロードバランサーは、フローごとの状態を時々維持および同期化する必要があります。シーケンス番号をCookieとして使用すると、プール全体で分割できるビットがそれほど多くないため、Cookieとしてのみ機能します。マシンの。
Mobile operators apply 3GPP Self-Organizing Networks (SONs) for intelligent workflows such as content-aware Mobility Load Balancing (MLB). Where network load balancers have been configured to route according to application-layer semantics, an encrypted payload is effectively invisible. This has resulted in practices of intercepting TLS in front of load balancers to regain that visibility, but at a cost to security and privacy.
モバイルオペレーターは、コンテンツ対応のモビリティロードバランシング（MLB）などのインテリジェントワークフローに3GPP自己組織化ネットワーク（SON）を適用します。アプリケーション層のセマンティクスに従ってルーティングするようにネットワークロードバランサーが構成されている場合、暗号化されたペイロードは事実上見えません。これにより、ロードバランサーの前でTLSをインターセプトしてその可視性を取り戻す習慣が生まれましたが、セキュリティとプライバシーが犠牲になります。
In future Network Function Virtualization (NFV) architectures, load-balancing functions are likely to be more prevalent (deployed at locations throughout operators' networks). NFV environments will require some type of identifier (IPv6 flow identifiers, the proposed QUIC connection ID, etc.) for managing traffic using encrypted tunnels. The shift to increased encryption will have an impact on visibility of flow information and will require adjustments to perform similar load-balancing functions within an NFV.
将来のネットワーク機能仮想化（NFV）アーキテクチャでは、負荷分散機能がより一般的になる可能性があります（オペレーターのネットワーク全体の場所に展開されます）。 NFV環境では、暗号化されたトンネルを使用してトラフィックを管理するために、あるタイプの識別子（IPv6フロー識別子、提案されたQUIC接続IDなど）が必要になります。暗号化の強化への移行は、フロー情報の可視性に影響を与え、NFV内で同様のロードバランシング機能を実行するための調整が必要になります。
Data transfer capacity resources in cellular radio networks tend to be more constrained than in fixed networks. This is a result of variance in radio signal strength as a user moves around a cell, the rapid ingress and egress of connections as users hand off between adjacent cells, and temporary congestion at a cell. Mobile networks alleviate this by queuing traffic according to its required bandwidth and acceptable latency: for example, a user is unlikely to notice a 20 ms delay when receiving a simple web page or email, or an instant message response, but will very likely notice a rebuffering pause in a video playback or a VoIP call de-jitter buffer. Ideally, the scheduler manages the queue so that each user has an acceptable experience as conditions vary, but inferences of the traffic type have been used to make bearer assignments and set scheduler priority.
セルラー無線ネットワークのデータ転送容量リソースは、固定ネットワークよりも制約を受ける傾向があります。これは、ユーザーがセル内を移動する際の無線信号強度の変動、ユーザーが隣接するセル間でハンドオフする際の接続の急速な出入り、およびセルでの一時的な輻輳の結果です。モバイルネットワークは、必要な帯域幅と許容可能なレイテンシに従ってトラフィックをキューイングすることでこれを軽減します。たとえば、ユーザーは単純なWebページや電子メール、またはインスタントメッセージの応答を受信するときに20ミリ秒の遅延に気付くことはほとんどありませんが、ビデオ再生またはVoIPコールのデジッタバッファでの一時停止の再バッファリング。理想的には、スケジューラはキューを管理して、条件が変化しても各ユーザーが許容できるエクスペリエンスを提供できるようにしますが、ベアラの割り当てとスケジューラの優先順位の設定にはトラフィックタイプの推論が使用されています。
Deep Packet Inspection (DPI) allows identification of applications based on payload signatures, in contrast to trusting well-known port numbers. Application- and transport-layer encryption make the traffic type estimation more complex and less accurate; therefore, it may not be effectual to use this information as input for queue management. With the use of WebSockets [RFC6455], for example, many forms of communications (from isochronous/real-time to bulk/elastic file transfer) will take place over HTTP port 80 or port 443, so only the messages and higher-layer data will make application differentiation possible. If the monitoring system sees only "HTTP port 443", it cannot distinguish application streams that would benefit from priority queuing from others that would not.
ディープパケットインスペクション（DPI）では、既知のポート番号を信頼するのとは対照的に、ペイロードシグネチャに基づいてアプリケーションを識別できます。アプリケーション層およびトランスポート層の暗号化により、トラフィックタイプの推定がより複雑になり、精度が低下します。したがって、この情報をキュー管理の入力として使用しても効果的ではない場合があります。たとえば、WebSockets [RFC6455]を使用すると、多くの形式の通信（アイソクロナス/リアルタイムからバルク/エラスティックファイル転送まで）がHTTPポート80またはポート443を介して行われるため、メッセージと上位層のデータのみアプリケーションの差別化が可能になります。監視システムが「HTTPポート443」のみを認識している場合、優先キューイングの恩恵を受けるアプリケーションストリームとそうでないアプリケーションストリームを区別できません。
Mobile networks especially rely on content-/application-based prioritization of Over-the-Top (OTT) services -- each application type or service has different delay/loss/throughput expectations, and each type of stream will be unknown to an edge device if encrypted. This impedes dynamic QoS adaptation. An alternate way to achieve encrypted application separation is possible when the User Equipment (UE) requests a dedicated bearer for the specific application stream (known by the UE), using a mechanism such as the one described in Section 6.5 of 3GPP TS 24.301 [TS3GPP]. The UE's request includes the Quality Class Indicator (QCI) appropriate for each application, based on their different delay/loss/throughput expectations. However, UE requests for dedicated bearers and QCI may not be supported at the subscriber's service level, or in all mobile networks.
モバイルネットワークは、Over-the-Top（OTT）サービスのコンテンツ/アプリケーションベースの優先順位付けに特に依存しています-各アプリケーションタイプまたはサービスには異なる遅延/損失/スループットの期待値があり、ストリームの各タイプはエッジデバイスに認識されません。暗号化されている場合。これは動的QoSの適応を妨げます。 3GPP TS 24.301 [TS3GPP]のセクション6.5で説明されているようなメカニズムを使用して、ユーザー機器（UE）が特定のアプリケーションストリーム（UEが知っている）の専用ベアラを要求する場合、暗号化されたアプリケーション分離を実現する別の方法が可能です。 ]。 UEの要求には、さまざまな遅延/損失/スループットの期待値に基づいて、各アプリケーションに適した品質クラスインジケータ（QCI）が含まれています。ただし、専用ベアラおよびQCIに対するUE要求は、加入者のサービスレベルまたはすべてのモバイルネットワークでサポートされているとは限りません。
These effects and potential alternative solutions have been discussed at the accord BoF [ACCORD] at IETF 95.
これらの影響と潜在的な代替ソリューションは、IETF 95の合意BoF [ACCORD]で議論されています。
This section does not consider traffic discrimination by service providers related to Net Neutrality, where traffic may be favored according to the service provider's preference as opposed to the user's preference. These use cases are considered out of scope for this document as controversial practices.
このセクションでは、トラフィックがユーザーの設定ではなくサービスプロバイダーの設定に従って優先される場合がある、ネットニュートラルに関連するサービスプロバイダーによるトラフィックの差別については考慮しません。これらのユースケースは、このドキュメントの範囲外と見なされており、物議を醸しています。
For 3GPP User Plane Congestion Management (UPCON) [UPCON], the ability to understand content and manage networks during periods of congestion is the focus. Mitigating techniques such as deferred download, off-peak acceleration, and outbound roamers are a few examples of the areas explored in the associated 3GPP documents. The documents describe the issues, describe the data utilized in managing congestion, and make policy recommendations.
3GPPユーザープレーン輻輳管理（UPCON）[UPCON]の場合、輻輳の期間中にコンテンツを理解し、ネットワークを管理する機能が中心です。遅延ダウンロード、オフピークアクセラレーション、アウトバウンドローマーなどの軽減技術は、関連する3GPPドキュメントで検討されている領域のいくつかの例です。ドキュメントは問題を記述し、混雑の管理に利用されるデータを記述し、そして政策提言を行います。
Performance-enhancing TCP proxies may perform local retransmission at the network edge; this also applies to mobile networks. In TCP, duplicated ACKs are detected and potentially concealed when the proxy retransmits a segment that was lost on the mobile link without involvement of the far end (see Section 2.1.1 of [RFC3135] and Section 3.5 of [MIDDLEBOXES]).
パフォーマンスを向上させるTCPプロキシは、ネットワークエッジでローカル再送信を実行する場合があります。これはモバイルネットワークにも適用されます。 TCPでは、プロキシが遠端の関与なしにモバイルリンクで失われたセグメントを再送信すると、重複したACKが検出され、潜在的に隠されます（[RFC3135]のセクション2.1.1および[MIDDLEBOXES]のセクション3.5を参照）。
Operators report that this optimization at network edges improves real-time transmission over long-delay Internet paths or networks with large capacity variation (such as mobile/cellular networks). However, such optimizations can also cause problems with performance, for example, if the characteristics of some packet streams begin to vary significantly from those considered in the proxy design.
事業者は、ネットワークエッジでのこの最適化により、遅延の長いインターネットパスまたは容量の変動が大きいネットワーク（モバイル/セルラーネットワークなど）でのリアルタイム伝送が改善されると報告しています。ただし、このような最適化は、たとえば、一部のパケットストリームの特性がプロキシ設計で考慮されたものと大幅に異なる場合、パフォーマンスの問題を引き起こす可能性もあります。
In general, some operators have stated that performance-enhancing proxies have a lower RTT to the client; therefore, they determine the responsiveness of flow control. A lower RTT makes the flow-control loop more responsive to changes in the mobile-network conditions and enables faster adaptation in a delay- and capacity-varying network due to user mobility.
一般に、一部のオペレーターは、パフォーマンス向上プロキシはクライアントへのRTTが低いと述べています。したがって、フロー制御の応答性を決定します。 RTTが低いほど、フロー制御ループはモバイルネットワークの状態の変化に応答しやすくなり、ユーザーの移動性により、遅延や容量が変化するネットワークでより迅速に適応できます。
Further, some use service-provider-operated proxies to reduce the control delay between the sender and a receiver on a mobile network where resources are limited. The RTT determines how quickly a user's attempt to cancel a video is recognized and, therefore, how quickly the traffic is stopped, thus keeping unwanted video packets from entering the radio-scheduler queue. If impacted by encryption, performance-enhancing proxies could make use of routing overlay protocols to accomplish the same task, but this results in additional overhead.
さらに、一部は、リソースが制限されているモバイルネットワーク上の送信者と受信者の間の制御遅延を減らすために、サービスプロバイダーが操作するプロキシを使用します。 RTTは、ユーザーがビデオをキャンセルしようとする試みが認識される速さ、したがってトラフィックが停止される速さを決定し、不要なビデオパケットがラジオスケジューラキューに入らないようにします。暗号化の影響を受ける場合、パフォーマンス向上プロキシはルーティングオーバーレイプロトコルを利用して同じタスクを実行できますが、これによりオーバーヘッドが増加します。
An application-type-aware network edge (middlebox) can further control pacing, limit simultaneous HD videos, or prioritize active videos against new videos, etc. Services at this more granular level are limited with the use of encryption.
アプリケーションタイプを認識するネットワークエッジ（ミドルボックス）は、ペーシングをさらに制御したり、同時HDビデオを制限したり、新しいビデオに対してアクティブビデオを優先したりすることができます。このより細かいレベルのサービスは、暗号化の使用により制限されます。
Performance-enhancing proxies are primarily used on long-delay links (satellite) with access to the TCP header to provide an early ACK and make the long-delay link of the path seem shorter. With some specific forms of flow control, TCP can be more efficient than alternatives such as proxies. The editors cannot cite research on this point specific to the performance-enhancing proxies described, but they agree this area could be explored to determine if flow-control modifications could preserve the end-to-end performance on long-delay path sessions where the TCP header is exposed.
パフォーマンス向上プロキシは、TCPヘッダーにアクセスできる長い遅延リンク（衛星）で主に使用され、早期のACKを提供し、パスの長い遅延リンクを短く見せます。フロー制御の特定の形式では、TCPはプロキシなどの代替手段よりも効率的です。編集者は、説明されているパフォーマンス向上プロキシに固有のこの点についての研究を引用することはできませんが、TCPが存在する長い遅延パスセッションでフロー制御の変更がエンドツーエンドのパフォーマンスを維持できるかどうかを判断するためにこの領域を調査できることに同意しますヘッダーが公開されています。
The features and efficiency of some Internet services can be augmented through analysis of user flows and the applications they provide. For example, network caching of popular content at a location close to the requesting user can improve delivery efficiency (both in terms of lower request response times and reduced use of links on the international Internet when content is remotely located), and service providers through an authorized agreement acting on their behalf use DPI in combination with content-distribution networks to determine if they can intervene effectively. Encryption of packet contents at a given protocol layer usually makes DPI processing of that layer and higher layers impossible. That being said, it should be noted that some content providers prevent caching to control content delivery through the use of encrypted end-to-end sessions. CDNs vary in their deployment options of end-to-end encryption. The business risk of losing control of content is a motivation outside of privacy and pervasive monitoring that is driving end-to-end encryption for these content providers.
一部のインターネットサービスの機能と効率は、ユーザーフローとそれらが提供するアプリケーションを分析することで強化できます。たとえば、要求しているユーザーに近い場所で人気のあるコンテンツのネットワークキャッシュを使用すると、配信の効率が向上し（要求の応答時間が短くなり、コンテンツが離れた場所にある場合の国際インターネット上のリンクの使用が減ります）、サービスプロバイダーが彼らに代わって承認された契約では、コンテンツ配信ネットワークと組み合わせてDPIを使用して、効果的に介入できるかどうかを判断します。特定のプロトコルレイヤーでのパケットコンテンツの暗号化は、通常、そのレイヤー以上のレイヤーのDPI処理を不可能にします。とはいえ、一部のコンテンツプロバイダーは、暗号化されたエンドツーエンドセッションを使用してコンテンツ配信を制御するためのキャッシュを防止していることに注意してください。 CDNは、エンドツーエンドの暗号化の展開オプションが異なります。コンテンツの制御を失うことのビジネスリスクは、これらのコンテンツプロバイダーのエンドツーエンドの暗号化を推進しているプライバシーと広範囲にわたる監視以外の動機です。
It should be noted that caching was first supported in [RFC1945] and continued in the recent update of "Hypertext Transfer Protocol (HTTP/1.1): Caching" [RFC7234]. Some operators also operate transparent caches that neither the user nor the origin opt-in. The use of these caches is controversial within the IETF and is generally precluded by the use of HTTPS.
キャッシングは最初に[RFC1945]でサポートされ、「ハイパーテキスト転送プロトコル（HTTP / 1.1）：キャッシング」[RFC7234]の最近のアップデートで継続されたことに注意してください。一部のオペレーターは、ユーザーもオリジンもオプトインしない透過キャッシュを操作します。これらのキャッシュの使用は、IETF内で議論の余地があり、一般的にHTTPSの使用によって妨げられています。
Content replication in caches (for example, live video and content protected by Digital Rights Management (DRM)) is used to most efficiently utilize the available limited bandwidth and thereby maximize the user's Quality of Experience (QoE). Especially in mobile networks, duplicating every stream through the transit network increases backhaul cost for live TV. 3GPP Enhanced Multimedia Broadcast/Multicast Services (eMBMS) utilize trusted edge proxies to facilitate delivering the same stream to different users, using either unicast or multicast depending on channel conditions to the user. There are ongoing efforts to support multicast inside carrier networks while preserving end-to-end security: Automatic Multicast Tunneling (AMT), for instance, allows CDNs to deliver a single (potentially encrypted) copy of a live stream to a carrier network over the public Internet and for the carrier to then distribute that live stream as efficiently as possible within its own network using multicast.
キャッシュ内のコンテンツレプリケーション（たとえば、ライブビデオやデジタル著作権管理（DRM）で保護されたコンテンツ）は、利用可能な限られた帯域幅を最も効率的に利用し、それによってユーザーのエクスペリエンスの品質（QoE）を最大化するために使用されます。特にモバイルネットワークでは、トランジットネットワークを介してすべてのストリームを複製すると、ライブTVのバックホールコストが増加します。 3GPP拡張マルチメディアブロードキャスト/マルチキャストサービス（eMBMS）は、信頼できるエッジプロキシを利用して、ユーザーへのチャネル条件に応じてユニキャストまたはマルチキャストを使用して、同じストリームをさまざまなユーザーに配信しやすくします。エンドツーエンドのセキュリティを維持しながらキャリアネットワーク内のマルチキャストをサポートするための継続的な取り組みがあります。たとえば、自動マルチキャストトンネリング（AMT）を使用すると、CDNはライブストリームの単一の（暗号化されている可能性がある）コピーを、公衆インターネット、およびキャリアがマルチキャストを使用して、自社のネットワーク内で可能な限り効率的にそのライブストリームを配信するため。
Alternate approaches are in the early phase of being explored to allow caching of encrypted content. These solutions require cooperation from content owners and fall outside the scope of what is covered in this document. Content delegation allows for replication with possible benefits, but any form of delegation has the potential to affect the expectation of client-server confidentiality.
代替アプローチは、暗号化されたコンテンツのキャッシュを可能にするために検討されている初期段階にあります。これらのソリューションにはコンテンツ所有者の協力が必要であり、このドキュメントの対象範囲外です。コンテンツの委任は、可能な利点を備えた複製を可能にしますが、どのような形式の委任でも、クライアントサーバーの機密性の期待に影響を与える可能性があります。
In addition to caching, various applications exist to provide data compression in order to conserve the life of the user's mobile data plan or make delivery over the mobile link more efficient. The compression proxy access can be built into a specific user-level application, such as a browser, or it can be available to all applications using a system-level application. The primary method is for the mobile application to connect to a centralized server as a transparent proxy (user does not opt-in), with the data channel between the client application and the server using compression to minimize bandwidth utilization. The effectiveness of such systems depends on the server having access to unencrypted data flows.
キャッシングに加えて、ユーザーのモバイルデータプランの寿命を節約するため、またはモバイルリンクを介した配信をより効率的にするために、データ圧縮を提供するさまざまなアプリケーションが存在します。圧縮プロキシアクセスは、ブラウザなどの特定のユーザーレベルのアプリケーションに組み込むことも、システムレベルのアプリケーションを使用するすべてのアプリケーションで利用できるようにすることもできます。主な方法は、モバイルアプリケーションが集中型サーバーに透過プロキシ（ユーザーはオプトインしない）として接続し、クライアントアプリケーションとサーバー間のデータチャネルが圧縮を使用して帯域幅の使用率を最小限に抑えることです。このようなシステムの効果は、暗号化されていないデータフローにアクセスできるサーバーに依存します。
Aggregated data stream content compression that spans objects and data sources that can be treated as part of a unified compression scheme (e.g., through the use of a shared segment store) is often effective at providing data offload when there is a network element close to the receiver that has access to see all the content.
統合された圧縮スキームの一部として（たとえば、共有セグメントストアを使用して）処理できるオブジェクトとデータソースにまたがる集約データストリームコンテンツ圧縮は、ネットワーク要素が近くにある場合にデータオフロードを提供するのに効果的ですすべてのコンテンツを表示するアクセス権を持つレシーバー。
Service Function Chaining (SFC) is defined in RFC 7665 [RFC7665] and RFC 8300 [RFC8300]. As discussed in RFC 7498 [RFC7498], common SFC deployments may use classifiers to direct traffic into VLANs instead of using a Network Service Header (NSH), as defined in RFC 8300 [RFC8300]. As described in RFC 7665 [RFC7665], the ordered steering of traffic to support specific optimizations depends upon the ability of a classifier to determine the microflows. RFC 2474 [RFC2474] defines the following:
サービス機能チェーン（SFC）は、RFC 7665 [RFC7665]およびRFC 8300 [RFC8300]で定義されています。 RFC 7498 [RFC7498]で説明されているように、一般的なSFC配備では、RFC 8300 [RFC8300]で定義されているように、ネットワークサービスヘッダー（NSH）を使用する代わりに、分類子を使用してトラフィックをVLANに転送できます。 RFC 7665 [RFC7665]で説明されているように、特定の最適化をサポートするためのトラフィックの順序付けされたステアリングは、マイクロフローを決定する分類子の能力に依存します。 RFC 2474 [RFC2474]は以下を定義しています。
Microflow: a single instance of an application-to-application flow of packets which is identified by source address, destination address, protocol id, and source port, destination port (where applicable).
Microflow：送信元アドレス、宛先アドレス、プロトコルID、および送信元ポート、宛先ポート（該当する場合）によって識別される、アプリケーション間のパケットフローの単一インスタンス。
SFC currently depends upon a classifier to at least identify the microflow. As the classifier's visibility is reduced from a 5-tuple to a 2-tuple, or if information above the transport layer becomes inaccessible, then the SFC classifier is not able to perform its job, and the service functions of the path may be adversely affected.
SFCは現在、少なくともマイクロフローを識別するために分類子に依存しています。分類子の可視性が5タプルから2タプルに減少するか、トランスポート層より上の情報にアクセスできなくなると、SFC分類子はそのジョブを実行できなくなり、パスのサービス機能に悪影響が及ぶ可能性があります。 。
There are also mechanisms provided to protect security and privacy. In the SFC case, the layer below a network service header can be protected with session encryption. A goal is protecting end-user data, while retaining the intended functions of RFC 7665 [RFC7665] at the same time.
セキュリティとプライバシーを保護するために提供されるメカニズムもあります。 SFCの場合、ネットワークサービスヘッダーの下のレイヤーはセッション暗号化で保護できます。目標は、RFC 7665 [RFC7665]の目的の機能を同時に維持しながら、エンドユーザーデータを保護することです。
Mobile networks and many ISPs operate under the regulations of their licensing government authority. These regulations include Lawful Intercept, adherence to Codes of Practice on content filtering, and application of court order filters. Such regulations assume network access to provide content filtering and accounting, as discussed below. As previously stated, the intent of this document is to document existing practices; the development of IETF protocols follows the guiding principles of [RFC1984] and [RFC2804] and explicitly does not support tools and methods that could be used for wiretapping and censorship.
モバイルネットワークと多くのISPは、ライセンスを付与する政府機関の規制の下で運用されています。これらの規制には、合法的傍受、コンテンツフィルタリングに関する行動規範の遵守、裁判所命令フィルターの適用が含まれます。このような規制では、以下で説明するように、コンテンツのフィルタリングとアカウンティングを提供するためにネットワークアクセスを想定しています。前述のように、このドキュメントの目的は既存のプラクティスを文書化することです。 IETFプロトコルの開発は、[RFC1984]および[RFC2804]の基本原則に従い、盗聴や検閲に使用できるツールや方法を明示的にサポートしていません。
There are numerous reasons why service providers might block content: to comply with requests from law enforcement or regulatory authorities, to effectuate parental controls, to enforce content-based billing, or for other reasons, possibly considered inappropriate by some. See RFC 7754 [RFC7754] for a survey of Internet filtering techniques and motivations and the IAB consensus on those mechanisms. This section is intended to document a selection of current content-blocking practices by operators and the effects of encryption on those practices. Content blocking may also happen at endpoints or at the edge of enterprise networks, but those scenarios are not addressed in this section.
サービスプロバイダーがコンテンツをブロックする理由は多数あります。法執行機関または規制当局からの要求に準拠するため、ペアレンタルコントロールを有効にするため、コンテンツベースの請求を実行するため、または他の理由で、おそらく不適切であると見なされている人がいます。インターネットフィルタリングの手法と動機の調査、およびそれらのメカニズムに関するIABの合意については、RFC 7754 [RFC7754]を参照してください。このセクションは、オペレーターによる現在のコンテンツブロッキングプラクティスの選択とそれらのプラクティスに対する暗号化の影響を文書化することを目的としています。コンテンツのブロックは、エンドポイントまたはエンタープライズネットワークのエッジでも発生する可能性がありますが、このセクションではそれらのシナリオについては扱いません。
In a mobile network, content filtering usually occurs in the core network. With other networks, content filtering could occur in the core network or at the edge. A proxy is installed that analyzes the transport metadata of the content users are viewing and filters content based on either a blacklist of sites or the user's predefined profile (e.g., for age-sensitive content). Although filtering can be done by many methods, one commonly used method involves a trigger based on the proxy identifying a DNS lookup of a host name in a URL that appears on a blacklist being used by the operator. The subsequent requests to that domain will be rerouted to a proxy that checks whether the full URL matches a blocked URL on the list, and it will return a 404 if a match is found. All other requests should complete. This technique does not work in situations where DNS traffic is encrypted (e.g., by employing [RFC7858]). This method is also used by other types of network providers enabling traffic inspection, but not modification.
モバイルネットワークでは、コンテンツフィルタリングは通常、コアネットワークで行われます。他のネットワークでは、コンテンツフィルタリングはコアネットワークまたはエッジで発生する可能性があります。ユーザーが表示しているコンテンツのトランスポートメタデータを分析し、サイトのブラックリストまたはユーザーの事前定義されたプロファイル（年齢に敏感なコンテンツなど）に基づいてコンテンツをフィルターするプロキシがインストールされています。フィルタリングは多くの方法で実行できますが、一般的に使用される1つの方法は、オペレーターが使用しているブラックリストに表示されるURL内のホスト名のDNSルックアップを識別するプロキシに基づくトリガーです。そのドメインへの後続のリクエストは、完全なURLがリスト上のブロックされたURLと一致するかどうかをチェックするプロキシに再ルーティングされ、一致が見つかった場合は404を返します。他のすべての要求は完了する必要があります。この手法は、DNSトラフィックが暗号化されている状況では機能しません（たとえば、[RFC7858]を使用して）。この方法は、トラフィック検査を可能にする他のタイプのネットワークプロバイダーでも使用されますが、変更はできません。
Content filtering via a proxy can also utilize an intercepting certificate where the client's session is terminated at the proxy enabling for cleartext inspection of the traffic. A new session is created from the intercepting device to the client's destination; this is an opt-in strategy for the client, where the endpoint is configured to trust the intercepting certificate. Changes to TLS 1.3 do not impact this more invasive method of interception, which has the potential to expose every HTTPS session to an active man in the middle (MITM).
プロキシ経由のコンテンツフィルタリングでは、インターセプト証明書を利用することもできます。この場合、クライアントのセッションはプロキシで終了し、トラフィックのクリアテキスト検査が可能になります。インターセプトデバイスからクライアントの宛先への新しいセッションが作成されます。これは、エンドポイントがインターセプトする証明書を信頼するように構成されている、クライアントのオプトイン戦略です。 TLS 1.3への変更は、このより侵襲的な傍受方法に影響を与えません。これは、すべてのHTTPSセッションをアクティブな中間者（MITM）に公開する可能性があります。
Another form of content filtering is called parental control, where some users are deliberately denied access to age-sensitive content as a feature to the service subscriber. Some sites involve a mixture of universal and age-sensitive content and filtering software. In these cases, more-granular (application-layer) metadata may be used to analyze and block traffic. Methods that accessed cleartext application-layer metadata no longer work when sessions are encrypted. This type of granular filtering could occur at the endpoint or as a proxy service. However, the lack of ability to efficiently manage endpoints as a service reduces network service providers' ability to offer parental control.
コンテンツフィルタリングの別の形式はペアレンタルコントロールと呼ばれ、一部のユーザーはサービス加入者への機能として、年齢に敏感なコンテンツへのアクセスを意図的に拒否されます。一部のサイトでは、ユニバーサルで年齢に敏感なコンテンツとフィルタリングソフトウェアが混在しています。これらの場合、より詳細な（アプリケーション層）メタデータを使用してトラフィックを分析およびブロックできます。クリアテキストのアプリケーション層メタデータにアクセスしたメソッドは、セッションが暗号化されていると機能しなくなりました。このタイプの詳細なフィルタリングは、エンドポイントで、またはプロキシサービスとして発生する可能性があります。ただし、エンドポイントをサービスとして効率的に管理する機能がないため、ペアレンタルコントロールを提供するネットワークサービスプロバイダーの機能が低下します。
Approved access to a network is a prerequisite to requests for Internet traffic.
ネットワークへの承認されたアクセスは、インターネットトラフィックの要求の前提条件です。
However, there are cases (beyond parental control) when a network service provider currently redirects customer requests for content (affecting content accessibility):
ただし、ネットワークサービスプロバイダーがコンテンツに対する顧客の要求を現在リダイレクトしている場合（ペアレンタルコントロール以外）があります（コンテンツのアクセシビリティに影響します）。
1. The network service provider is performing the accounting and billing for the content provider, and the customer has not (yet) purchased the requested content.
1. ネットワークサービスプロバイダーはコンテンツプロバイダーのアカウンティングと請求を実行しており、顧客は要求されたコンテンツを（まだ）購入していません。
2. Further content may not be allowed as the customer has reached their usage limit and needs to purchase additional data service, which is the usual billing approach in mobile networks.
2. 顧客が使用制限に達し、追加のデータサービスを購入する必要があるため、これ以上のコンテンツは許可されない場合があります。これは、モバイルネットワークでの通常の課金方法です。
Currently, some network service providers redirect the customer using HTTP redirect to a captive portal page that explains to those customers the reason for the blockage and the steps to proceed. [RFC6108] describes one viable web notification system. When the HTTP headers and content are encrypted, this appropriately prevents mobile carriers from intercepting the traffic and performing an HTTP redirect. As a result, some mobile carriers block customer's encrypted requests, which impacts customer experience because the blocking reason must be conveyed by some other means. The customer may need to call customer care to find out the reason and/or resolve the issue, possibly extending the time needed to restore their network access. While there are well-deployed alternate SMS-based solutions that do not involve out-of-specification protocol interception, this is still an unsolved problem for non-SMS users.
現在、一部のネットワークサービスプロバイダーは、HTTPリダイレクトを使用して、ブロックの理由と続行する手順を説明するキャプティブポータルページに顧客をリダイレクトしています。 [RFC6108]は、1つの実行可能なWeb通知システムについて説明しています。 HTTPヘッダーとコンテンツが暗号化されると、モバイルキャリアがトラフィックを傍受してHTTPリダイレクトを実行することが適切に防止されます。その結果、一部のモバイルキャリアは顧客の暗号化された要求をブロックします。これは、他の手段でブロック理由を伝える必要があるため、顧客のエクスペリエンスに影響を与えます。お客様は、カスタマーケアに電話して理由を調べたり、問題を解決したりする必要がある場合があります。ネットワークアクセスの復元に必要な時間が長くなる可能性があります。仕様外のプロトコルインターセプトを含まない、適切に展開された代替のSMSベースのソリューションがありますが、これは非SMSユーザーにとって未解決の問題です。
Further, when the requested service is about to consume the remainder of the user's plan limits, the transmission could be terminated and advance notifications may be sent to the user by their service provider to warn the user ahead of the exhausted plan. If web content is encrypted, the network provider cannot know the data transfer size at request time. Lacking this visibility of the application type and content size, the network would continue the transmission and stop the transfer when the limit was reached. A partial transfer may not be usable by the client wasting both network and user resources, possibly leading to customer complaints. The content provider does not know a user's service plans or current usage and cannot warn the user of plan exhaustion.
さらに、要求されたサービスがユーザーのプラン制限の残りを消費しようとすると、送信が終了し、サービスプロバイダーが事前通知をユーザーに送信して、使い果たされたプランの前にユーザーに警告することができます。 Webコンテンツが暗号化されている場合、ネットワークプロバイダーはリクエスト時にデータ転送サイズを知ることができません。このアプリケーションタイプとコンテンツサイズの可視性がないと、ネットワークは送信を続行し、制限に達したときに転送を停止します。クライアントがネットワークとユーザーの両方のリソースを浪費することにより、部分的な転送が使用できなくなり、顧客の不満を招く可能性があります。コンテンツプロバイダーは、ユーザーのサービスプランや現在の使用状況を認識していないため、プランの枯渇についてユーザーに警告することはできません。
In addition, some mobile network operators sell tariffs that allow free-data access to certain sites, known as 'zero rating'. A session to visit such a site incurs no additional cost or data usage to the user. For some implementations, zero rating is impacted if encryption hides the details of the content domain from the network.
さらに、一部のモバイルネットワークオペレーターは、「ゼロレーティング」と呼ばれる特定のサイトへの無料データアクセスを許可する料金を販売しています。このようなサイトにアクセスするためのセッションでは、ユーザーに追加のコストやデータ使用は発生しません。一部の実装では、暗号化によってネットワークからコンテンツドメインの詳細が隠される場合、ゼロレーティングが影響を受けます。
Application Layer Gateways (ALGs) assist applications to set connectivity across Network Address Translators (NATs), firewalls, and/or load balancers for specific applications running across mobile networks. Section 2.9 of [RFC2663] describes the role of ALGs and their interaction with NAT and/or application payloads. ALGs are deployed with an aim to improve connectivity. However, it is an IETF best common practice recommendation that ALGs for UDP-based protocols be turned off [RFC4787].
アプリケーションレイヤーゲートウェイ（ALG）は、アプリケーションがネットワークアドレス変換（NAT）、ファイアウォール、および/またはモバイルネットワークで実行されている特定のアプリケーションのロードバランサーに接続を設定するのを支援します。 [RFC2663]のセクション2.9は、ALGの役割と、NATやアプリケーションペイロードとの相互作用について説明しています。 ALGは、接続性の向上を目的として展開されます。ただし、UDPベースのプロトコルのALGをオフにすることは、IETFのベストプラクティスの推奨事項です[RFC4787]。
One example of an ALG in current use is aimed at video applications that use the Real-Time Streaming Protocol (RTSP) [RFC7826] primary stream as a means to identify related RTP/RTCP [RFC3550] flows at setup. The ALG in this case relies on the 5-tuple flow information derived from RTSP to provision NAT or other middleboxes and provide connectivity. Implementations vary, and two examples follow:
現在使用されているALGの一例は、セットアップ時に関連するRTP / RTCP [RFC3550]フローを識別する手段としてリアルタイムストリーミングプロトコル（RTSP）[RFC7826]プライマリストリームを使用するビデオアプリケーションを対象としています。この場合のALGは、RTSPから導出された5タプルフロー情報に依存して、NATまたは他のミドルボックスをプロビジョニングし、接続を提供します。実装はさまざまで、次の2つの例があります。
1. Parse the content of the RTSP stream and identify the 5-tuple of the supporting streams as they are being negotiated.
1. RTSPストリームのコンテンツを解析し、ネゴシエーション中のサポートストリームの5タプルを識別します。
2. Intercept and modify the 5-tuple information of the supporting media streams as they are being negotiated on the RTSP stream, which is more intrusive to the media streams.
2. サポートされているメディアストリームの5タプル情報を傍受し、RTSPストリームでネゴシエートされているときに変更します。RTSPストリームは、メディアストリームに侵入しやすくなります。
When RTSP-stream content is encrypted, the 5-tuple information within the payload is not visible to these ALG implementations; therefore, they cannot provision their associated middleboxes with that information.
RTSPストリームコンテンツが暗号化されている場合、ペイロード内の5タプル情報はこれらのALG実装からは見えません。したがって、関連するミドルボックスにその情報をプロビジョニングすることはできません。
The deployment of IPv6 may well reduce the need for NAT and the corresponding requirement for ALGs.
IPv6の導入により、NATの必要性とそれに対応するALGの要件が大幅に削減される可能性があります。
Some mobile carriers use HTTP header insertion (see Section 3.2.1 of [RFC7230]) to provide information about their customers to third parties or to their own internal systems [Enrich]. Third parties use the inserted information for analytics, customization, advertising, cross-site tracking of users, customer billing, or selectively allowing or blocking content. HTTP header insertion is also used to pass information internally between a mobile service provider's sub-systems, thus keeping the internal systems loosely coupled. When HTTP connections are encrypted to protect user privacy, mobile network service providers cannot insert headers to accomplish the, sometimes considered controversial, functions above.
一部の携帯通信会社は、HTTPヘッダー挿入（[RFC7230]のセクション3.2.1を参照）を使用して、顧客に関する情報をサードパーティまたは自社の内部システム[Enrich]に提供しています。サードパーティは、挿入された情報を分析、カスタマイズ、広告、ユーザーのクロスサイト追跡、顧客への請求、またはコンテンツの選択的な許可またはブロックに使用します。 HTTPヘッダー挿入は、モバイルサービスプロバイダーのサブシステム間で内部的に情報を渡すためにも使用されるため、内部システムの疎結合が維持されます。 HTTP接続がユーザーのプライバシーを保護するために暗号化されている場合、モバイルネットワークサービスプロバイダーは、ヘッダーを挿入して、上記の論争と見なされることもある機能を実行できません。
Guidance from the Internet Architecture Board has been provided in "Design Considerations for Metadata Insertion" [RFC8165]. The guidance asserts that designs that share metadata only by explicit actions at the host are preferable to designs in which middleboxes insert metadata. Alternate notification methods that follow this and other guidance would be helpful to mobile carriers.
インターネットアーキテクチャボードからのガイダンスは、「メタデータ挿入の設計上の考慮事項」[RFC8165]で提供されています。ガイダンスでは、ホストでの明示的なアクションによってのみメタデータを共有する設計は、ミドルボックスがメタデータを挿入する設計よりも望ましいと主張しています。これや他のガイダンスに従う代替通知方法は、携帯電話会社に役立ちます。
Hosted environments have had varied requirements in the past for encryption, with many businesses choosing to use these services primarily for data and applications that are not business or privacy sensitive. A shift prior to the revelations on surveillance/passive monitoring began where businesses were asking for hosted environments to provide higher levels of security so that additional applications and service could be hosted externally. Businesses understanding the threats of monitoring in hosted environments increased that pressure to provide more secure access and session encryption to protect the management of hosted environments as well as the data and applications.
ホスト環境には、暗号化に関するさまざまな要件がありました。多くの企業は、これらのサービスを、ビジネスやプライバシーに敏感ではないデータとアプリケーションに主に使用することを選択しています。追加のアプリケーションやサービスを外部でホストできるように、より高いレベルのセキュリティを提供するために企業がホスト環境を要求するところから、監視/パッシブモニタリングの啓示の前にシフトが始まりました。ホスト環境での監視の脅威を理解する企業は、より安全なアクセスとセッション暗号化を提供して、ホスト環境とデータおよびアプリケーションの管理を保護するというプレッシャーを増大させました。
Hosted environments may have multiple levels of management access, where some may be strictly for the Hosting service provider (infrastructure that may be shared among customers), and some may be accessed by a specific customer for application management. In some cases, there are multiple levels of hosting service providers, further complicating the security of management infrastructure and the associated requirements.
ホスティングされた環境には複数のレベルの管理アクセスがあり、ホスティングサービスプロバイダー（顧客間で共有される可能性のあるインフラストラクチャ）に厳密に当てはまるものもあれば、アプリケーション管理のために特定の顧客がアクセスするものもあります。場合によっては、ホスティングサービスプロバイダーのレベルが複数あり、管理インフラストラクチャのセキュリティと関連する要件がさらに複雑になります。
Hosting service provider management access is typically segregated from other traffic with a control channel and may or may not be encrypted depending upon the isolation characteristics of the management session. Customer access may be through a dedicated connection, but discussion for that connection method is out of scope for this document.
ホスティングサービスプロバイダーの管理アクセスは、通常、制御チャネルによって他のトラフィックから分離されており、管理セッションの分離特性に応じて暗号化される場合とされない場合があります。お客様のアクセスは専用の接続を介する場合がありますが、その接続方法の説明はこのドキュメントの範囲外です。
In overlay networks (e.g., Virtual eXtensible Local Area Network (VXLAN), Geneve, etc.) that are used to provide hosted services, management access for a customer to support application management may depend upon the security mechanisms available as part of that overlay network. While overlay-network data encapsulations may be used to indicate the desired isolation, this is not sufficient to prevent deliberate attacks that are aware of the use of the overlay network. [GENEVE-REQS] describes requirements to handle attacks. It is possible to use an overlay header in combination with IPsec or other encrypted traffic sessions, but this adds the requirement for authentication infrastructure and may reduce packet transfer performance. The use of an overlay header may also be deployed as a mechanism to manage encrypted traffic streams on the network-by-network service providers. Additional extension mechanisms to provide integrity and/or privacy protections are being investigated for overlay encapsulations. Section 7 of [RFC7348] describes some of the security issues possible when deploying VXLAN on Layer 2 networks. Rogue endpoints can join the multicast groups that carry broadcast traffic, for example.
ホストされたサービスを提供するために使用されるオーバーレイネットワーク（Virtual eXtensible Local Area Network（VXLAN）、Geneveなど）では、アプリケーション管理をサポートするための顧客の管理アクセスは、そのオーバーレイネットワークの一部として利用可能なセキュリティメカニズムに依存する場合があります。必要な分離を示すためにオーバーレイネットワークのデータカプセル化を使用できますが、これは、オーバーレイネットワークの使用を知っている意図的な攻撃を防ぐには不十分です。 [GENEVE-REQS]は、攻撃を処理するための要件を示しています。オーバーレイヘッダーをIPsecまたは他の暗号化されたトラフィックセッションと組み合わせて使用することは可能ですが、これにより認証インフラストラクチャの要件が追加され、パケット転送パフォーマンスが低下する可能性があります。オーバーレイヘッダーの使用は、ネットワークごとのサービスプロバイダーで暗号化されたトラフィックストリームを管理するメカニズムとして展開することもできます。完全性および/またはプライバシー保護を提供するための追加の拡張メカニズムは、オーバーレイのカプセル化について調査されています。 [RFC7348]のセクション7では、レイヤ2ネットワークにVXLANをデプロイするときに起こり得るセキュリティの問題について説明しています。たとえば、不正なエンドポイントは、ブロードキャストトラフィックを伝送するマルチキャストグループに参加できます。
Hosted applications that allow some level of customer-management access may also require monitoring by the hosting service provider. Monitoring could include access-control restrictions such as authentication, authorization, and accounting for filtering and firewall rules to ensure they are continuously met. Customer access may occur on multiple levels, including user-level and administrative access. The hosting service provider may need to monitor access through either session monitoring or log evaluation to ensure security SLAs for access management are met. The use of session encryption to access hosted environments limits access restrictions to the metadata described below. Monitoring and filtering may occur at a:
一定レベルの顧客管理アクセスを許可するホストアプリケーションも、ホスティングサービスプロバイダーによる監視が必要になる場合があります。監視には、認証、承認、フィルタリングのアカウンティング、ファイアウォールルールなどのアクセス制御制限を含めて、それらが継続的に満たされるようにすることができます。顧客アクセスは、ユーザーレベルのアクセスと管理アクセスを含む複数のレベルで発生する場合があります。ホスティングサービスプロバイダーは、セッション管理またはログ評価のいずれかを介してアクセスを監視し、アクセス管理のセキュリティSLAが満たされていることを確認する必要がある場合があります。ホスト環境にアクセスするためにセッション暗号化を使用すると、以下で説明するメタデータへのアクセス制限が制限されます。監視とフィルタリングは次の場所で行われます。
2-tuple: IP level with source and destination IP addresses alone, or
2タプル：送信元と宛先のIPアドレスのみのIPレベル、または
5-tuple: IP and protocol level with a source IP address, destination IP address, protocol number, source port number, and destination port number.
5タプル：送信元IPアドレス、宛先IPアドレス、プロトコル番号、送信元ポート番号、および宛先ポート番号を含むIPおよびプロトコルレベル。
Session encryption at the application level, for example, TLS, currently allows access to the 5-tuple. IP-level encryption, such as IPsec in tunnel mode, prevents access to the original 5-tuple and may limit the ability to restrict traffic via filtering techniques. This shift may not impact all hosting service provider solutions as alternate controls may be used to authenticate sessions, or access may require that clients access such services by first connecting to the organization before accessing the hosted application. Shifts in access may be required to maintain equivalent access-control management. Logs may also be used for monitoring that access-control restrictions are met, but would be limited to the data that could be observed due to encryption at the point of log generation. Log analysis is out of scope for this document.
TLSなどのアプリケーションレベルでのセッション暗号化では、現在5タプルへのアクセスが許可されています。トンネルモードのIPsecなどのIPレベルの暗号化は、元の5タプルへのアクセスを妨げ、フィルタリング技術を介してトラフィックを制限する機能を制限する場合があります。代替制御を使用してセッションを認証する場合があるため、このシフトはすべてのホスティングサービスプロバイダーソリューションに影響を与えることはありません。同等のアクセス制御管理を維持するために、アクセスのシフトが必要になる場合があります。ログは、アクセス制御の制限が満たされていることを監視するためにも使用できますが、ログ生成の時点での暗号化が原因で監視できるデータに限定されます。ログ分析はこのドキュメントの範囲外です。
The following observations apply to any IT organization that is responsible for delivering services, whether to third parties, for example, as a web-based service, or to internal customers in an enterprise, e.g., a data-processing system that forms a part of the enterprise's business.
次の観察は、サービスの提供を担当するすべてのIT組織に適用されます。たとえば、Webベースのサービスとしてサードパーティに、または企業の一部であるデータ処理システムなどの企業の内部顧客に企業のビジネス。
Organizations responsible for the operation of a data center have many processes that access the contents of IP packets (passive methods of measurement, as defined in [RFC7799]). These processes are typically for service assurance or security purposes as part of their data-center operations.
データセンターの運用を担当する組織には、IPパケットのコンテンツにアクセスする多くのプロセスがあります（[RFC7799]で定義されている受動測定方法）。これらのプロセスは、通常、データセンターの運用の一環として、サービスの保証またはセキュリティを目的としています。
Examples include:
例は次のとおりです。
- Network-Performance Monitoring / Application-Performance Monitoring
- ネットワークパフォーマンス監視/アプリケーションパフォーマンス監視
- Intrusion defense/prevention systems
- 侵入防御/防止システム
- Malware detection
- マルウェアの検出
- Fraud monitoring
- 不正監視
- Application DDOS protection
- アプリケーションDDOS保護
- Cyber-attack investigation
- サイバー攻撃調査
- Proof of regulatory compliance
- 規制遵守の証明
- Data leakage prevention
- データ漏洩防止
Many application service providers simply terminate sessions to/from the Internet at the edge of the data center in the form of SSL/TLS offload in the load balancer. Not only does this reduce the load on application servers, it simplifies the processes to enable monitoring of the session content.
多くのアプリケーションサービスプロバイダーは、ロードバランサーでのSSL / TLSオフロードの形式で、データセンターのエッジでインターネットとの間のセッションを終了するだけです。これにより、アプリケーションサーバーの負荷が軽減されるだけでなく、プロセスが簡素化され、セッションコンテンツの監視が可能になります。
However, in some situations, encryption deeper in the data center may be necessary to protect personal information or in order to meet industry regulations, e.g., those set out by the Payment Card Industry (PCI). In such situations, various methods have been used to allow service assurance and security processes to access unencrypted data. These include SSL/TLS decryption in dedicated units, which then forward packets to SP-controlled tools, or real-time or post-capture decryption in the tools themselves. A number of these tools provide passive decryption by providing the monitoring device with the server's private key. The move to increased use of the forward-secret key exchange mechanism impacts the use of these techniques.
ただし、状況によっては、個人情報を保護したり、業界の規制（Payment Card Industry（PCI）など）に準拠したりするために、データセンターでより深い暗号化が必要になる場合があります。このような状況では、サービス保証およびセキュリティプロセスが暗号化されていないデータにアクセスできるようにするために、さまざまな方法が使用されてきました。これらには、専用ユニットでのSSL / TLS復号化が含まれます。これにより、パケットがSP制御のツールに転送されたり、ツール自体でリアルタイムまたはキャプチャ後の復号化が行われます。これらのツールの多くは、監視デバイスにサーバーの秘密キーを提供することにより、パッシブな復号化を提供します。前方秘密鍵交換メカニズムの使用の増加への移行は、これらの技術の使用に影響を与えます。
Operators of data centers may also maintain packet recordings in order to be able to investigate attacks, breaches of internal processes, etc. In some industries, organizations may be legally required to maintain such information for compliance purposes.
データセンターのオペレーターは、攻撃や内部プロセスの違反などを調査できるように、パケットの記録を維持することもできます。一部の業界では、組織がコンプライアンスの目的でそのような情報を維持することを法的に要求される場合があります。
Investigations of this nature have used access to the unencrypted contents of the packet. Alternate methods to investigate attacks or breaches of process will rely on endpoint information, such as logs. As previously noted, logs often lack complete information, and this is seen as a concern resulting in some relying on session access for additional information.
この性質の調査では、パケットの暗号化されていないコンテンツへのアクセスが使用されています。攻撃またはプロセスの違反を調査する別の方法は、ログなどのエンドポイント情報に依存します。前述のように、ログには完全な情報が欠落していることが多く、これは懸念事項として見なされ、追加情報をセッションアクセスに依存する人がいます。
Application service providers may offer content-level monitoring options to detect intellectual property leakage or other attacks. In service provider environments where Data Loss Prevention (DLP) has been implemented on the basis of the service provider having cleartext access to session streams, the use of encrypted streams prevents these implementations from conducting content searches for the keywords or phrases configured in the DLP system. DLP is often used to prevent the leakage of Personally Identifiable Information (PII) as well as financial account information, Personal Health Information (PHI), and PCI. If session encryption is terminated at a gateway prior to accessing these services, DLP on session data can still be performed. The decision of where to terminate encryption to hosted environments will be a risk decision made between the application service provider and customer organization according to their priorities. DLP can be performed at the server for the hosted application and on an end user's system in an organization as alternate or additional monitoring points of content; however, this is not frequently done in a service provider environment.
アプリケーションサービスプロバイダーは、コンテンツレベルの監視オプションを提供して、知的財産の漏洩やその他の攻撃を検出する場合があります。セッションストリームへのクリアテキストアクセスを持つサービスプロバイダーに基づいてデータ損失防止（DLP）が実装されているサービスプロバイダー環境では、暗号化されたストリームを使用すると、DLPシステムで構成されたキーワードまたはフレーズのコンテンツ検索を実行できなくなります。 DLPは、個人識別情報（PII）、金融口座情報、個人の健康情報（PHI）、PCIの漏洩を防ぐためによく使用されます。これらのサービスにアクセスする前にセッション暗号化がゲートウェイで終了した場合でも、セッションデータのDLPを実行できます。ホスト環境への暗号化をどこで終了するかの決定は、アプリケーションサービスプロバイダーと顧客組織の間で優先順位に従って行われるリスク決定です。 DLPは、ホストされているアプリケーションのサーバーと、組織内のエンドユーザーのシステムで、コンテンツの代替または追加の監視ポイントとして実行できます。ただし、これはサービスプロバイダー環境では頻繁に行われません。
Application service providers, by their very nature, control the application endpoint. As such, much of the information gleaned from sessions is still available on that endpoint. However, when a gap exists in the application's logging and debugging capabilities, it has led the application service provider to access data in transport for monitoring and debugging.
アプリケーションサービスプロバイダーは、その性質上、アプリケーションエンドポイントを制御します。そのため、セッションから収集した情報の多くは、そのエンドポイントで引き続き利用できます。ただし、アプリケーションのロギング機能とデバッグ機能にギャップがある場合、アプリケーションサービスプロバイダーは監視とデバッグのためにトランスポート内のデータにアクセスするようになりました。
Organizations are increasingly using hosted applications rather than in-house solutions that require maintenance of equipment and software. Examples include Enterprise Resource Planning (ERP) solutions, payroll service, time and attendance, travel and expense reporting, among others. Organizations may require some level of management access to these hosted applications and will typically require session encryption or a dedicated channel for this activity.
組織は、機器やソフトウェアのメンテナンスを必要とする社内ソリューションではなく、ホストされたアプリケーションをますます使用しています。例としては、エンタープライズリソースプランニング（ERP）ソリューション、給与計算サービス、時間と出勤、出張および経費の報告などがあります。組織は、これらのホストされたアプリケーションへのある程度の管理アクセスを必要とする場合があり、通常、このアクティビティにはセッションの暗号化または専用チャネルが必要です。
In other cases, hosted applications may be fully managed by a hosting service provider with SLA expectations for availability and performance as well as for security functions including malware detection. Due to the sensitive nature of these hosted environments, the use of encryption is already prevalent. Any impact may be similar to an enterprise with tools being used inside of the hosted environment to monitor traffic. Additional concerns were not reported in the call for contributions.
他の場合では、ホスティングされたアプリケーションは、可用性とパフォーマンス、およびマルウェア検出を含むセキュリティ機能に対するSLAの期待値を持つホスティングサービスプロバイダーによって完全に管理されます。これらのホスト環境の機密性が高いため、暗号化の使用はすでに普及しています。影響は、ホストされた環境内でトラフィックを監視するためにツールが使用されている企業に似ています。追加の懸念は寄付の要請で報告されなかった。
Performance, availability, and other aspects of an SLA are often collected through passive monitoring. For example:
SLAのパフォーマンス、可用性、およびその他の側面は、多くの場合、パッシブモニタリングを通じて収集されます。例えば：
o Availability: ability to establish connections with hosts to access applications and to discern the difference between network-or host-related causes of unavailability.
o 可用性：ホストとの接続を確立してアプリケーションにアクセスし、ネットワークまたはホストに関連する利用不能の原因の違いを識別する能力。
o Performance: ability to complete transactions within a target response time and to discern the difference between network- or host-related causes of excess response time.
o パフォーマンス：目標の応答時間内にトランザクションを完了し、過剰な応答時間のネットワークまたはホスト関連の原因の違いを識別する能力。
Here, as with all passive monitoring, the accuracy of inferences is dependent on the cleartext information available, and encryption would tend to reduce the information and, therefore, the accuracy of each inference. Passive measurement of some metrics will be impossible with encryption that prevents inferring-packet correspondence across multiple observation points, such as for packet-loss metrics.
ここでは、すべてのパッシブモニタリングと同様に、推論の精度は利用可能なクリアテキスト情報に依存しており、暗号化によって情報が減少し、したがって各推論の精度が低下する傾向があります。一部のメトリックのパッシブ測定は、パケット損失メトリックなどの複数の観測ポイント間でパケットの対応を推測することを防ぐ暗号化では不可能になります。
Application logging currently lacks detail sufficient to make accurate inferences in an environment with increased encryption, and so this constitutes a gap for passive performance monitoring (which could be closed if log details are enhanced in the future).
現在、アプリケーションロギングには、暗号化が強化された環境で正確な推論を行うのに十分な詳細がありません。そのため、これはパッシブパフォーマンスモニタリングのギャップになります（将来、ログの詳細が強化された場合は閉じられる可能性があります）。
Mail (application) service providers vary in what services they offer. Options may include a fully hosted solution where mail is stored external to an organization's environment on mail service provider equipment or the service offering may be limited to monitor incoming mail to remove spam (Section 5.1), phishing attacks (Section 5.3), and malware (Section 5.6) before mail is directed to the organization's equipment. In both of these cases, content of the messages and headers is monitored to detect and remove messages that are undesirable or that may be considered an attack.
メール（アプリケーション）サービスプロバイダーは、提供するサービスが異なります。オプションには、メールが組織の環境の外部にあるメールサービスプロバイダーの機器に保存される完全にホストされたソリューションが含まれる場合や、サービスの提供が受信メールの監視に制限され、スパム（セクション5.1）、フィッシング攻撃（セクション5.3）、およびマルウェア（セクション5.6）メールが組織の機器に送られる前。これらのどちらの場合でも、メッセージとヘッダーの内容が監視され、望ましくないメッセージや攻撃と見なされる可能性のあるメッセージが検出されて削除されます。
STARTTLS should have zero effect on anti-spam efforts for SMTP traffic. Anti-spam services could easily be performed on an SMTP gateway, eliminating the need for TLS decryption services. The impact to anti-spam service providers should be limited to a change in tools, where middleboxes were deployed to perform these functions.
STARTTLSは、SMTPトラフィックのスパム対策への影響はありません。スパム対策サービスはSMTPゲートウェイで簡単に実行でき、TLS復号化サービスの必要性を排除します。スパム対策サービスプロバイダーへの影響は、これらの機能を実行するためにミドルボックスが展開されているツールの変更に限定する必要があります。
Many efforts are emerging to improve user-to-user encryption, including promotion of PGP and newer efforts such as Dark Mail [DarkMail]. Of course, content-based spam filtering will not be possible on encrypted content.
PGPの推進やダークメール[DarkMail]などの新しい取り組みを含む、ユーザー間の暗号化を改善するための多くの取り組みが浮上しています。もちろん、コンテンツベースのスパムフィルタリングは暗号化されたコンテンツでは不可能です。
Numerous service offerings exist that provide hosted storage solutions. This section describes the various offerings and details the monitoring for each type of service and how encryption may impact the operational and security monitoring performed.
ホスト型ストレージソリューションを提供する多数のサービスが存在します。このセクションでは、さまざまなサービスについて説明し、各タイプのサービスの監視の詳細と、暗号化が実行される運用監視とセキュリティ監視にどのように影響するかを説明します。
Trends in data storage encryption for hosted environments include a range of options. The following list is intentionally high-level to describe the types of encryption used in coordination with data storage that may be hosted remotely, meaning the storage is physically located in an external data center requiring transport over the Internet. Options for monitoring will vary with each encryption approach described below. In most cases, solutions have been identified to provide encryption while ensuring management capabilities were maintained through logging or other means.
ホスト環境のデータストレージ暗号化のトレンドには、さまざまなオプションが含まれます。次のリストは、リモートでホストされる可能性があるデータストレージと連携して使用される暗号化のタイプを説明するために意図的に高レベルになっています。つまり、ストレージはインターネット経由のトランスポートを必要とする外部データセンターに物理的に配置されます。監視のオプションは、以下で説明する各暗号化アプローチによって異なります。ほとんどの場合、ログやその他の手段を通じて管理機能を維持しながら、暗号化を提供するソリューションが特定されています。
For higher security and/or privacy of data and applications, options that provide end-to-end encryption of the data from the user's desktop or server to the storage platform may be preferred. This description includes any solution that encrypts data at the object level, not the transport level. Encryption of data may be performed with libraries on the system or at the application level, which includes file-encryption services via a file manager. Object-level encryption is useful when data storage is hosted or scenarios when the storage location is determined based on capacity or based on a set of parameters to automate decisions. This could mean that large datasets accessed infrequently could be sent to an off-site storage platform at an external hosting service, data accessed frequently may be stored locally, or the decision of where to store datasets could be based on the transaction type. Object-level encryption is grouped separately for the purpose of this document since data may be stored in multiple locations including off-site remote storage platforms. If session encryption is also used, the protocol is likely to be TLS.
データとアプリケーションのセキュリティやプライバシーを高めるために、ユーザーのデスクトップまたはサーバーからストレージプラットフォームへのデータのエンドツーエンドの暗号化を提供するオプションが推奨されます。この説明には、トランスポートレベルではなく、オブジェクトレベルでデータを暗号化するソリューションが含まれます。データの暗号化は、システム上のライブラリまたはアプリケーションレベルで実行できます。これには、ファイルマネージャーを介したファイル暗号化サービスが含まれます。オブジェクトレベルの暗号化は、データストレージがホストされている場合や、ストレージの場所が容量または一連のパラメータに基づいて決定され、決定を自動化する場合に役立ちます。これは、アクセス頻度の低い大きなデータセットを外部ホスティングサービスのオフサイトストレージプラットフォームに送信したり、アクセス頻度の高いデータをローカルに保存したり、トランザクションタイプに基づいてデータセットを保存する場所を決定したりすることを意味します。データはオフサイトのリモートストレージプラットフォームを含む複数の場所に保存される可能性があるため、このドキュメントでは、オブジェクトレベルの暗号化を個別にグループ化しています。セッション暗号化も使用されている場合、プロトコルはTLSである可能性があります。
Impacts to monitoring may include access to content inspection for data-leakage prevention and similar technologies, depending on their placement in the network.
監視への影響には、ネットワーク内での配置に応じて、データ漏えい防止および同様のテクノロジーのコンテンツ検査へのアクセスが含まれる場合があります。
Monitoring of hosted storage solutions that use host-level (object) encryption is described in this subsection. Host-level encryption can be employed for backup services and occasionally for external storage services (operated by a third party) when internal storage limits are exceeded.
このサブセクションでは、ホストレベル（オブジェクト）の暗号化を使用するホスト型ストレージソリューションの監視について説明します。ホストレベルの暗号化は、内部ストレージの制限を超えたときに、バックアップサービスや、場合によっては外部ストレージサービス（サードパーティが運営）に使用できます。
Monitoring of data flows to hosted storage solutions is performed for security and operational purposes. The security monitoring may be to detect anomalies in the data flows that could include changes to destination, the amount of data transferred, or alterations in the size and frequency of flows. Operational considerations include capacity and availability monitoring.
ホストされたストレージソリューションへのデータフローの監視は、セキュリティと運用の目的で実行されます。セキュリティモニタリングは、宛先への変更、転送されたデータの量、またはフローのサイズと頻度の変更を含む可能性のあるデータフローの異常を検出することです。運用上の考慮事項には、容量と可用性の監視が含まれます。
There are multiple ways to achieve full disk encryption for stored data. Encryption may be performed on data to be stored while in transit close to the storage media with solutions like Controller Based Encryption (CBE) or in the drive system with Self-Encrypting Drives (SEDs). Session encryption is typically coupled with encryption of these data at rest (DAR) solutions to also protect data in transit. Transport encryption is likely via TLS.
保存されたデータの完全なディスク暗号化を実現する方法はいくつかあります。暗号化は、コントローラベースの暗号化（CBE）などのソリューションを使用してストレージメディアの近くで転送中に保存されるデータに対して、または自己暗号化ドライブ（SED）を使用してドライブシステムで実行できます。セッションの暗号化は通常、これらの保存データ（DAR）ソリューションの暗号化と組み合わせて、転送中のデータも保護します。トランスポートの暗号化は、おそらくTLS経由です。
Monitoring for transport of data-to-storage platforms, where object-level encryption is performed close to or on the storage platform, is similar to that described in Section 3.3.1.1. The primary difference for these solutions is the possible exposure of sensitive information, which could include privacy-related data, financial information, or intellectual property if session encryption via TLS is not deployed. Session encryption is typically used with these solutions, but that decision would be based on a risk assessment. There are use cases where DAR or disk-level encryption is required. Examples include preventing exposure of data if physical disks are stolen or lost. In the case where TLS is in use, monitoring and the exposure of data is limited to a 5-tuple.
オブジェクトレベルの暗号化がストレージプラットフォームの近くまたは上で実行されるデータからストレージプラットフォームへの転送の監視は、セクション3.3.1.1で説明されているものと同様です。これらのソリューションの主な違いは、プライバシー関連データ、財務情報、またはTLSを介したセッション暗号化が導入されていない場合の知的財産を含む可能性のある機密情報の露出の可能性です。通常、セッション暗号化はこれらのソリューションで使用されますが、その決定はリスク評価に基づいて行われます。 DARまたはディスクレベルの暗号化が必要なユースケースがあります。例としては、物理ディスクが盗難または紛失した場合にデータが漏洩するのを防ぐことが挙げられます。 TLSが使用されている場合、データの監視と公開は5タプルに制限されます。
Storage services also include data replication, which may occur between data centers and may leverage Internet connections to tunnel traffic. The traffic may use an Internet Small Computer System Interface (iSCSI) [RFC7143] or Fibre Channel over TCP/IP (FCIP) [RFC7146] encapsulated in IPsec. Either transport or tunnel mode may be used for IPsec depending upon the termination points of the IPsec session, if it is from the storage platform itself or from a gateway device at the edge of the data center, respectively.
ストレージサービスには、データレプリケーションも含まれます。これは、データセンター間で発生し、インターネット接続を利用してトラフィックをトンネルすることができます。トラフィックでは、IPsecにカプセル化されたインターネットスモールコンピューターシステムインターフェイス（iSCSI）[RFC7143]またはファイバーチャネルオーバーTCP / IP（FCIP）[RFC7146]を使用できます。 IPsecセッションの終了ポイントに応じて、トランスポートモードまたはトンネルモードのいずれかをIPsecに使用できます（ストレージプラットフォーム自体からのものか、データセンターの端にあるゲートウェイデバイスからのものか）。
The monitoring of data flows between data centers (for data replication) may be performed for security and operational purposes and would typically concentrate more on operational aspects since these flows are essentially virtual private networks (VPNs) between data centers. Operational considerations include capacity and availability monitoring. The security monitoring may be to detect anomalies in the data flows, similar to what was described in Section 3.3.1.1. If IPsec tunnel mode is in use, monitoring is limited to a 2-tuple; with transport mode, it's limited to a 5-tuple.
データセンター間のデータフローの監視（データレプリケーションのため）は、セキュリティと運用の目的で実行され、これらのフローはデータセンター間の仮想プライベートネットワーク（VPN）であるため、通常は運用面に集中します。運用上の考慮事項には、容量と可用性の監視が含まれます。セキュリティモニタリングは、セクション3.3.1.1で説明したものと同様に、データフローの異常を検出することです。 IPsecトンネルモードが使用されている場合、監視は2タプルに制限されます。トランスポートモードでは、5タプルに制限されます。
Encryption of network traffic within the private enterprise is a growing trend, particularly in industries with audit and regulatory requirements. Some enterprise-internal networks are almost completely TLS and/or IPsec encrypted.
民間企業内のネットワークトラフィックの暗号化は、特に監査および規制要件のある業界で成長傾向です。一部の企業内部ネットワークは、ほぼ完全にTLSやIPsecで暗号化されています。
For each type of monitoring, different techniques and access to parts of the data stream are part of current practice. As we transition to an increased use of encryption, alternate methods of monitoring for operational purposes may be necessary to reduce the practice of breaking encryption (other policies may apply in some enterprise settings).
監視の種類ごとに、さまざまな手法とデータストリームの一部へのアクセスが現在の実践の一部です。暗号化の使用の増加に移行するにつれて、暗号化を破る習慣を減らすために、運用目的で監視する別の方法が必要になる場合があります（他のポリシーが一部のエンタープライズ設定に適用される場合があります）。
Large corporate enterprises are the owners of the platforms, data, and network infrastructure that provide critical business services to their user communities. As such, these enterprises are responsible for all aspects of the performance, availability, security, and quality of experience for all user sessions. In many such enterprises, users are required to consent to the enterprise monitoring all their activities as a condition of employment. Subsections of Section 4 discuss techniques that access data beyond the data-link, network, and transport-level headers typically used in service provider networks since the corporate enterprise owns the data. These responsibilities break down into three basic areas:
大企業は、ユーザーコミュニティに重要なビジネスサービスを提供するプラットフォーム、データ、ネットワークインフラストラクチャの所有者です。そのため、これらの企業は、すべてのユーザーセッションのパフォーマンス、可用性、セキュリティ、エクスペリエンスの品質のあらゆる側面に責任を負っています。このような企業の多くでは、ユーザーは企業がすべての活動を雇用条件として監視していることに同意する必要があります。セクション4のサブセクションでは、企業がデータを所有しているため、サービスプロバイダーネットワークで通常使用されるデータリンク、ネットワーク、トランスポートレベルのヘッダーを超えてデータにアクセスする手法について説明します。これらの責任は、3つの基本的な領域に分類されます。
1. Security Monitoring and Control
1. セキュリティの監視と制御
2. Application-Performance Monitoring and Reporting
2. アプリケーションパフォーマンスの監視とレポート
3. Network Diagnostics and Troubleshooting In each of the above areas, technical support teams utilize collection, monitoring, and diagnostic systems. Some organizations currently use attack methods such as replicated TLS server RSA private keys to decrypt passively monitored copies of encrypted TLS packet streams.
3.ネットワークの診断とトラブルシューティング上記の各領域では、テクニカルサポートチームが収集、監視、診断システムを利用しています。現在、一部の組織では、複製されたTLSサーバーのRSA秘密鍵などの攻撃方法を使用して、暗号化されたTLSパケットストリームの受動的に監視されたコピーを復号化しています。
For an enterprise to avoid costly application down time and deliver expected levels of performance, protection, and availability, some forms of traffic analysis, sometimes including examination of packet payloads, are currently used.
企業がコストのかかるアプリケーションのダウンタイムを回避し、期待されるレベルのパフォーマンス、保護、および可用性を実現するために、パケットペイロードの検査を含む、いくつかの形式のトラフィック分析が現在使用されています。
Enterprise users are subject to the policies of their organization and the jurisdictions in which the enterprise operates. As such, proxies may be in use to:
エンタープライズユーザーは、組織のポリシーおよび企業が運営する管轄区域の対象となります。そのため、プロキシは次の目的で使用されている可能性があります。
1. intercept outbound session traffic to monitor for intellectual property leakage (by users, malware, and trojans),
1. （ユーザー、マルウェア、トロイの木馬による）知的財産の漏洩を監視するために、送信セッショントラフィックを傍受します。
2. detect viruses/malware entering the network via email or web traffic,
2. 電子メールまたはWebトラフィックを介してネットワークに侵入するウイルス/マルウェアを検出し、
3. detect malware/trojans in action, possibly connecting to remote hosts,
3. 動作中のマルウェア/トロイの木馬を検出し、リモートホストに接続する可能性があります。
4. detect attacks (cross-site scripting and other common web-related attacks),
4. 攻撃の検出（クロスサイトスクリプティングおよびその他の一般的なWeb関連の攻撃）、
5. track misuse and abuse by employees,
5. 従業員による誤用と虐待を追跡し、
6. restrict the types of protocols permitted to/from the entire corporate environment, and
6. 企業環境全体との間で許可されるプロトコルの種類を制限し、
7. detect and defend against Internet DDoS attacks, including both volumetric and Layer 7 attacks.
7. ボリューム攻撃とレイヤー7攻撃の両方を含むインターネットDDoS攻撃を検出して防御します。
A significant portion of malware hides its activity within TLS or other encryption protocols. This includes lateral movement, Command and Control (C&C), and Data Exfiltration.
マルウェアの大部分は、その活動をTLSまたはその他の暗号化プロトコル内に隠します。これには、横移動、コマンドとコントロール（C＆C）、およびデータの引き出しが含まれます。
The impact to a fully encrypted internal network would include cost and possible loss of detection capabilities associated with the transformation of the network architecture and tools for monitoring. The capabilities of detection through traffic fingerprinting, logging, host-level transaction monitoring, and flow analysis would vary depending on access to a 2-tuple or 5-tuple in the network as well.
完全に暗号化された内部ネットワークへの影響には、コストと、監視のためのネットワークアーキテクチャとツールの変換に関連する検出機能の損失の可能性が含まれます。トラフィックのフィンガープリント、ロギング、ホストレベルのトランザクションモニタリング、フロー分析による検出機能は、ネットワーク内の2タプルまたは5タプルへのアクセスによっても異なります。
Security monitoring in the enterprise may also be performed at the endpoint with numerous current solutions that mitigate the same problems as some of the above-mentioned solutions. Since the software agents operate on the device, they are able to monitor traffic before it is encrypted, monitor for behavior changes and lock down devices to use only the expected set of applications. Session encryption does not affect these solutions. Some might argue that scaling is an issue in the enterprise, but some large enterprises have used these tools effectively.
企業のセキュリティ監視は、上記のソリューションのいくつかと同じ問題を軽減する多数の現在のソリューションを使用してエンドポイントで実行することもできます。ソフトウェアエージェントはデバイス上で動作するため、暗号化される前にトラフィックを監視し、動作の変化を監視し、デバイスをロックして、予想されるアプリケーションのセットのみを使用できます。セッションの暗号化はこれらのソリューションには影響しません。企業ではスケーリングが問題であると主張する人もいますが、一部の大企業ではこれらのツールを効果的に使用しています。
Use of bring-your-own-device (BYOD) policies within organizations may limit the scope of monitoring permitted with these alternate solutions. Network endpoint assessment (NEA) or the use of virtual hosts could help to bridge the monitoring gap.
組織内でデバイスを持参（BYOD）ポリシーを使用すると、これらの代替ソリューションで許可される監視の範囲が制限される場合があります。ネットワークエンドポイントアセスメント（NEA）または仮想ホストの使用は、監視のギャップを埋めるのに役立ちます。
There are two main goals of monitoring:
監視の主な目的は2つあります。
1. Assess traffic volume on a per-application basis for billing, capacity planning, optimization of geographical location for servers or proxies, and other goals.
1. 課金、容量計画、サーバーまたはプロキシの地理的位置の最適化、およびその他の目標について、アプリケーションごとにトラフィック量を評価します。
2. Assess performance in terms of application response time and user-perceived response time.
2. アプリケーションの応答時間とユーザーが感じる応答時間の観点からパフォーマンスを評価します。
Network-based application-performance monitoring tracks application response time by user and by URL, which is the information that the application owners and the lines of business request. CDNs add complexity in determining the ultimate endpoint destination. By their very nature, such information is obscured by CDNs and encrypted protocols, adding a new challenge for troubleshooting network and application problems. URL identification allows the application support team to do granular, code-level troubleshooting at multiple tiers of an application.
ネットワークベースのアプリケーションパフォーマンスモニタリングは、ユーザーとURLによってアプリケーションの応答時間を追跡します。これは、アプリケーションの所有者と基幹業務が要求する情報です。 CDNは、最終的なエンドポイントの宛先の決定をさらに複雑にします。そのような性質上、そのような情報はCDNと暗号化されたプロトコルによって隠され、ネットワークとアプリケーションの問題のトラブルシューティングに新たな課題を追加します。 URLの識別により、アプリケーションサポートチームは、アプリケーションの複数の層で詳細なコードレベルのトラブルシューティングを行うことができます。
New methodologies to monitor user-perceived response time and to separate network from server time are evolving. For example, the IPv6 Destination Option Header (DOH) implementation of Performance and Diagnostic Metrics (PDM) [RFC8250] will provide this. Using PDM with IPsec Encapsulating Security Payload (ESP) Transport Mode requires placement of the PDM DOH within the ESP-encrypted payload to avoid leaking timing and sequence number information that could be useful to an attacker. Use of PDM DOH also may introduce some security weaknesses, including a timing attack, as described in Section 4 of [RFC8250]. For these and other reasons, [RFC8250] requires that the PDM DOH option be explicitly turned on by administrative action in each host where this measurement feature will be used.
ユーザーが感じる応答時間を監視し、サーバー時間からネットワークを分離するための新しい方法論が進化しています。たとえば、IPv6宛先オプションヘッダー（DOH）のパフォーマンスと診断メトリック（PDM）[RFC8250]の実装はこれを提供します。 IPsecカプセル化セキュリティペイロード（ESP）トランスポートモードでPDMを使用するには、攻撃者に役立つ可能性のあるタイミングとシーケンス番号情報の漏洩を防ぐために、ESP暗号化ペイロード内にPDM DOHを配置する必要があります。 [RFC8250]のセクション4で説明されているように、PDM DOHを使用すると、タイミング攻撃などのセキュリティ上の弱点が生じることもあります。これらおよびその他の理由により、[RFC8250]では、この測定機能が使用される各ホストの管理アクションによってPDM DOHオプションを明示的にオンにする必要があります。
One primary key to network troubleshooting is the ability to follow a transaction through the various tiers of an application in order to isolate the fault domain. A variety of factors relating to the structure of the modern data center and multi-tiered application have made it difficult to follow a transaction in network traces without the ability to examine some of the packet payload. Alternate methods, such as log analysis, need improvement to fill this gap.
ネットワークのトラブルシューティングの主なキーの1つは、障害ドメインを分離するために、アプリケーションのさまざまな層を介してトランザクションを追跡する機能です。最新のデータセンターと多層アプリケーションの構造に関連するさまざまな要因により、一部のパケットペイロードを検査する機能なしに、ネットワークトレースでトランザクションを追跡することが困難になっています。ログ分析などの代替方法では、このギャップを埋めるための改善が必要です。
CDNs, NATs, and Network Address and Port Translators (NAPTs) obscure the ultimate endpoint designation (see [RFC6269] for types of address sharing and a list of issues). Troubleshooting a problem for a specific end user requires finding information such as the IP address and other identifying information so that their problem can be resolved in a timely manner.
CDN、NAT、ネットワークアドレスおよびポートトランスレーター（NAPT）は、最終的なエンドポイントの指定を不明瞭にします（アドレス共有のタイプと問題のリストについては、[RFC6269]を参照してください）。特定のエンドユーザーの問題をトラブルシューティングするには、問題をタイムリーに解決できるように、IPアドレスやその他の識別情報などの情報を見つける必要があります。
NAT is also frequently used by lower layers of the data-center infrastructure. Firewalls, load balancers, web servers, app servers, and middleware servers all regularly NAT the source IP of packets. Combine this with the fact that users are often allocated randomly by load balancers to all these devices, and the network troubleshooter is often left with very few options in today's environment due to poor logging implementations in applications. As such, network troubleshooting is used to trace packets at a particular layer, decrypt them, and look at the payload to find a user session.
NATは、データセンターインフラストラクチャの下位層でも頻繁に使用されます。ファイアウォール、ロードバランサー、ウェブサーバー、アプリサーバー、ミドルウェアサーバーはすべて、パケットの送信元IPを定期的にNAT処理します。これと、ユーザーがロードバランサーによってこれらすべてのデバイスにランダムに割り当てられることが多く、アプリケーションのロギング実装が不十分なため、今日の環境ではネットワークトラブルシューティングツールのオプションが非常に少ないことがよくあります。そのため、ネットワークのトラブルシューティングは、特定のレイヤーでパケットを追跡し、それらを復号化し、ペイロードを調べてユーザーセッションを見つけるために使用されます。
This kind of bulk packet capture and bulk decryption is frequently used when troubleshooting a large and complex application. Endpoints typically don't have the capacity to handle this level of network packet capture, so out-of-band networks of robust packet brokers and network sniffers that use techniques such as copies of TLS RSA private keys accomplish this task today.
この種のバルクパケットキャプチャとバルク復号化は、大規模で複雑なアプリケーションのトラブルシューティングを行うときに頻繁に使用されます。エンドポイントには通常、このレベルのネットワークパケットキャプチャを処理する能力がないため、TLS RSA秘密鍵のコピーなどの手法を使用する堅牢なパケットブローカーとネットワークスニファーの帯域外ネットワークが、今日このタスクを実行します。
TCP pipelining / session multiplexing used mainly by middleboxes today allows for multiple end-user sessions to share the same TCP connection. This raises several points of interest with an increased use of encryption. TCP session multiplexing should still be possible when TLS or TCPcrypt is in use since the TCP header information is exposed, leaving the 5-tuple accessible. The use of TCP session multiplexing of an IP-layer encryption, e.g., IPsec, that only exposes a 2-tuple would not be possible. Troubleshooting capabilities with encrypted sessions from the middlebox may limit troubleshooting to the use of logs from the endpoints performing the TCP multiplexing or from the middleboxes prior to any additional encryption that may be added to tunnel the TCP multiplexed traffic.
現在ミドルボックスで主に使用されているTCPパイプライン化/セッションの多重化により、複数のエンドユーザーセッションで同じTCP接続を共有できます。これにより、暗号化の使用が増えるにつれて、いくつかの関心が高まります。 TLSまたはTCPcryptが使用されている場合でも、TCPヘッダー情報が公開され、5タプルにアクセス可能なままになるため、TCPセッションの多重化は引き続き可能です。 2タプルのみを公開するIPレイヤー暗号化（IPsecなど）のTCPセッション多重化の使用は不可能です。ミドルボックスからの暗号化されたセッションのトラブルシューティング機能は、TCP多重化トラフィックをトンネリングするために追加される可能性のある追加の暗号化の前に、TCP多重化を実行するエンドポイントまたはミドルボックスからのログの使用にトラブルシューティングを制限する場合があります。
Increased use of HTTP/2 will likely further increase the prevalence of session multiplexing, both on the Internet and in the private data center. HTTP pipelining requires both the client and server to participate; visibility of packets once encrypted will hide the use of HTTP pipelining for any monitoring that takes place outside of the endpoint or proxy solution. Since HTTP pipelining is between a client and server, logging capabilities may require improvement in some servers and clients for debugging purposes if this is not already possible. Visibility for middleboxes includes anything exposed by TLS and the 5-tuple.
HTTP / 2の使用が増えると、インターネットとプライベートデータセンターの両方で、セッションの多重化の普及率がさらに高まるでしょう。 HTTPパイプライン化には、クライアントとサーバーの両方が参加する必要があります。暗号化されたパケットの可視性は、エンドポイントまたはプロキシソリューションの外部で行われる監視のためのHTTPパイプラインの使用を隠します。 HTTPパイプライン処理はクライアントとサーバーの間で行われるため、まだ可能でない場合、デバッグ機能のために一部のサーバーとクライアントでログ機能の改善が必要になる場合があります。ミドルボックスの可視性には、TLSおよび5タプルによって公開されるすべてが含まれます。
When an application server makes an HTTP service call to back-end services on behalf of a user session, it uses a completely different URL and a completely different TCP connection. Troubleshooting via network trace involves matching up the user request with the HTTP service call. Some organizations do this today by decrypting the TLS packet and inspecting the payload. Logging has not been adequate for their purposes.
アプリケーションサーバーがユーザーセッションに代わってバックエンドサービスへのHTTPサービス呼び出しを行う場合、アプリケーションサーバーは完全に異なるURLと完全に異なるTCP接続を使用します。ネットワークトレースによるトラブルシューティングでは、ユーザーリクエストとHTTPサービスコールを照合します。今日、一部の組織では、TLSパケットを復号化してペイロードを検査することでこれを行っています。ロギングはそれらの目的には十分ではありませんでした。
Many applications use text formats such as XML to transport data or application-level information. When transaction failures occur and the logs are inadequate to determine the cause, network and application teams work together, each having a different view of the transaction failure. Using this troubleshooting method, the network packet is correlated with the actual problem experienced by an application to find a root cause. The inability to access the payload prevents this method of troubleshooting.
多くのアプリケーションは、XMLなどのテキスト形式を使用して、データまたはアプリケーションレベルの情報を転送します。トランザクション障害が発生し、ログが原因を特定するのに不十分な場合、ネットワークチームとアプリケーションチームは連携し、それぞれがトランザクション障害について異なる見方をします。このトラブルシューティング方法を使用すると、ネットワークパケットは、根本的な原因を見つけるためにアプリケーションが経験する実際の問題と関連付けられます。ペイロードにアクセスできないため、このトラブルシューティング方法を回避できます。
Corporate networks commonly monitor outbound session traffic to detect or prevent attacks as well as to guarantee service-level expectations. In some cases, alternate options are available when encryption is in use through a proxy or a shift to monitoring at the endpoint. In both cases, scaling is a concern, and advancements to support this shift in monitoring practices will assist the deployment of end-to-end encryption.
企業ネットワークは通常、発信セッショントラフィックを監視して、攻撃を検出または防止し、サービスレベルの期待を保証します。場合によっては、プロキシを介して暗号化が使用されているとき、またはエンドポイントでの監視への移行時に、代替オプションが利用できます。どちらの場合も、スケーリングが問題であり、監視手法のこの変化をサポートするための進歩は、エンドツーエンドの暗号化の展開に役立ちます。
Some DLP tools intercept traffic at the Internet gateway or proxy services with the ability to MITM encrypted session traffic (HTTP/ TLS). These tools may monitor for key words important to the enterprise including business-sensitive information such as trade secrets, financial data, PII, or PHI. Various techniques are used to intercept HTTP/TLS sessions for DLP and other purposes and can be misused as described in "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)" [RFC7457] (see Section 2.8). Note: many corporate policies allow access to personal financial and other sites for users without interception. Another option is to terminate a TLS session prior to the point where monitoring is performed. Aside from exposing user information to the enterprise, MITM devices often are subject to severe security defects, which can lead to exposure of user data to attackers outside the enterprise user data [UserData]. In addition, implementation errors in middleboxes have led to major difficulties in deploying new versions of security protocols such as TLS [Ben17a] [Ben17b] [Res17a] [Res17b].
一部のDLPツールは、インターネットゲートウェイまたはプロキシサービスでトラフィックを傍受し、MITM暗号化セッショントラフィック（HTTP / TLS）を使用できます。これらのツールは、企業秘密、財務データ、PII、またはPHIなどのビジネス機密情報を含む、企業にとって重要なキーワードを監視する場合があります。 DLPおよびその他の目的でHTTP / TLSセッションをインターセプトするためにさまざまな手法が使用され、「トランスポート層セキュリティ（TLS）およびデータグラムTLS（DTLS）に対する既知の攻撃の要約」[RFC7457]（セクション2.8を参照）で説明されているように悪用される可能性があります。注：多くの企業ポリシーでは、ユーザーが傍受することなく個人の金融サイトやその他のサイトにアクセスできます。別のオプションは、監視が実行されるポイントの前にTLSセッションを終了することです。ユーザー情報を企業に公開することは別として、MITMデバイスは多くの場合、深刻なセキュリティ欠陥にさらされ、企業ユーザーデータ[UserData]の外部の攻撃者にユーザーデータを公開する可能性があります。さらに、ミドルボックスの実装エラーが原因で、TLS [Ben17a] [Ben17b] [Res17a] [Res17b]などのセキュリティプロトコルの新しいバージョンを導入する際に大きな困難が生じています。
Monitoring traffic patterns for anomalous behavior such as increased flows of traffic that could be bursty at odd times or flows to unusual destinations (small or large amounts of traffic) is common. This traffic may or may not be encrypted, and various methods of encryption or just obfuscation may be used.
異常なタイミングでバーストする可能性のあるトラフィックの増加や異常な宛先（少量または大量のトラフィック）へのフローなど、異常な動作のトラフィックパターンを監視することは一般的です。このトラフィックは暗号化されている場合とされていない場合があり、さまざまな暗号化方法または単に難読化が使用されます。
Web-filtering devices are sometimes used to allow only access to well-known sites found to be legitimate and free of malware on last check by a web-filtering service company. One common example of web filtering in a corporate environment is blocking access to sites that are not well known to these tools for the purpose of blocking malware; this may be noticeable to those in research who are unable to access colleagues' individual sites or new websites that have not yet been screened. In situations where new sites are required for access, they can typically be added after notification by the user or log alerts and review. Account access for personal mail may be blocked in corporate settings to prevent another vector for malware from entering as well as to prevent intellectual property leaks out of the network. This method remains functional with increased use of encryption and may be more effective at preventing malware from entering the network. Some enterprises may be more aggressive in their filtering and monitoring policy, causing undesirable outcomes. Web-filtering solutions monitor and potentially restrict access based on the destination URL (when available), server name, IP address, or DNS name. A complete URL may be used in cases where access restrictions vary for content on a particular site or for the sites hosted on a particular server. In some cases, the enterprise may use a proxy to access this additional information based on their policy. This type of restriction is intended to be transparent to users in a corporate setting as the typical corporate user does not access sites that are not well known to these tools. However, the mechanisms that these web filters use to do monitoring and enforcement have the potential to cause access issues or other user-visible failures.
Webフィルタリングデバイスは、Webフィルタリングサービス会社による最後のチェックで、合法でマルウェアのないことがわかっている有名なサイトへのアクセスのみを許可するために使用されることがあります。企業環境でのWebフィルタリングの一般的な例の1つは、マルウェアをブロックする目的でこれらのツールによく知られていないサイトへのアクセスをブロックすることです。これは、同僚の個々のサイトやまだスクリーニングされていない新しいWebサイトにアクセスできない研究者にとっては目立つかもしれません。アクセスするために新しいサイトが必要な状況では、通常、ユーザーからの通知またはアラートのログとレビュー後にサイトを追加できます。個人用メールへのアカウントアクセスは、企業の設定でブロックされる可能性があり、マルウェアの別のベクトルが侵入するのを防ぎ、知的財産がネットワークから漏洩するのを防ぎます。この方法は暗号化の使用を増やしても機能し続け、マルウェアがネットワークに侵入するのを防ぐのにより効果的です。企業によっては、フィルタリングと監視のポリシーに積極的で、望ましくない結果を引き起こす場合があります。 Webフィルタリングソリューションは、宛先URL（利用可能な場合）、サーバー名、IPアドレス、またはDNS名に基づいてアクセスを監視し、場合によっては制限します。特定のサイトのコンテンツまたは特定のサーバーでホストされているサイトのアクセス制限が異なる場合は、完全なURLを使用できます。企業は、ポリシーに基づいて、プロキシを使用してこの追加情報にアクセスする場合があります。一般的な企業ユーザーはこれらのツールに知られていないサイトにアクセスしないため、このタイプの制限は企業設定のユーザーに対して透過的であることを目的としています。ただし、これらのWebフィルターが監視および適用を行うために使用するメカニズムは、アクセスの問題や他のユーザーに表示される障害を引き起こす可能性があります。
Desktop DLP tools are used in some corporate environments as well. Since these tools reside on the desktop, they can intercept traffic before it is encrypted and may provide a continued method for monitoring leakage of intellectual property from the desktop to the Internet or attached devices.
デスクトップDLPツールは、一部の企業環境でも使用されています。これらのツールはデスクトップ上にあるため、暗号化される前にトラフィックを傍受でき、デスクトップからインターネットまたは接続されたデバイスへの知的財産の漏洩を監視するための継続的な方法を提供します。
DLP tools can also be deployed by network service providers, as they have the vantage point of monitoring all traffic paired with destinations off the enterprise network. This makes an effective solution for enterprises that allow "bring-your-own" devices when the traffic is not encrypted and for devices outside the desktop category (such as mobile phones) that are used on corporate networks nonetheless.
DLPツールは、企業ネットワークの宛先とペアになっているすべてのトラフィックを監視するという利点があるため、ネットワークサービスプロバイダーによっても展開できます。これにより、トラフィックが暗号化されていない場合に「持ち込み」デバイスを許可する企業や、それでも企業ネットワークで使用されるデスクトップカテゴリ外のデバイス（携帯電話など）に効果的なソリューションが提供されます。
Enterprises may wish to reduce the traffic on their Internet access facilities by monitoring requests for within-policy content and caching it. In this case, repeated requests for Internet content spawned by URLs in email trade newsletters or other sources can be served within the enterprise network. Gradual deployment of end-to-end encryption would tend to reduce the cacheable content over time, owing to concealment of critical headers and payloads. Many forms of enterprise-performance management may be similarly affected. It should be noted that transparent caching is considered an anti-pattern.
企業は、ポリシー内のコンテンツの要求を監視し、それをキャッシュすることにより、インターネットアクセス設備のトラフィックを削減したい場合があります。この場合、電子メールトレードニュースレターやその他のソースのURLによって生成されたインターネットコンテンツに対する繰り返し要求は、エンタープライズネットワーク内で処理できます。エンドツーエンドの暗号化を段階的に展開すると、重要なヘッダーとペイロードが隠蔽されるため、時間の経過とともにキャッシュ可能なコンテンツが減少する傾向があります。企業業績管理の多くの形態が同様に影響を受ける可能性があります。透過キャッシングはアンチパターンと見なされることに注意してください。
Effective incident response today requires collaboration at Internet scale. This section will only focus on efforts of collaboration at Internet scale that are dedicated to specific attack types. They may require new monitoring and detection techniques in an increasingly encrypted Internet. As mentioned previously, some service providers have been interfering with STARTTLS to prevent session encryption to be able to perform functions they are used to (injecting ads, monitoring, etc.). By detailing the current monitoring methods used for attack detection and response, this information can be used to devise new monitoring methods that will be effective in the changed Internet via collaboration and innovation.
今日の効果的なインシデント対応には、インターネット規模でのコラボレーションが必要です。このセクションでは、特定の攻撃タイプに特化したインターネット規模でのコラボレーションの取り組みにのみ焦点を当てます。暗号化が進むインターネットでは、新しい監視および検出技術が必要になる場合があります。前述のように、一部のサービスプロバイダーはSTARTTLSを妨害して、セッションの暗号化が慣れている機能（広告の挿入、監視など）を実行できないようにしています。攻撃の検出と応答に使用されている現在の監視方法を詳しく説明することにより、この情報を使用して、コラボレーションと革新を通じて変化するインターネットで効果的な新しい監視方法を考案できます。
Changes to improve encryption or to deploy OS methods have little impact on the detection of malicious actors. Malicious actors have had access to strong encryption for quite some time. Incident responders, in many cases, have developed techniques to locate malicious traffic within encrypted sessions. The following section will note some examples where detection and mitigation of such traffic has been successful.
暗号化を改善するため、またはOSメソッドを展開するための変更は、悪意のある攻撃者の検出にほとんど影響を与えません。悪意のある俳優は、かなり前から強力な暗号化を利用しています。インシデントレスポンダーは、多くの場合、暗号化されたセッション内の悪意のあるトラフィックを見つけるための技術を開発しています。次のセクションでは、このようなトラフィックの検出と軽減が成功した例をいくつか示します。
The largest operational effort to prevent mail abuse is through the Messaging, Malware, Mobile Anti-Abuse Working Group (M3AAWG) [M3AAWG]. Mail abuse is combatted directly with mail administrators who can shut down or stop continued mail abuse originating from large-scale providers that participate in using the Abuse Reporting Format (ARF) agents standardized in the IETF [RFC5965] [RFC6430] [RFC6590] [RFC6591] [RFC6650] [RFC6651] [RFC6652]. The ARF agent directly reports abuse messages to the appropriate service provider who can take action to stop or mitigate the abuse. Since this technique uses the actual message, the use of SMTP over TLS between mail gateways will not affect its usefulness. As mentioned previously, SMTP over TLS only protects data while in transit, and the messages may be exposed on mail servers or mail gateways if a user-to-user encryption method is not used. Current user-to-user message encryption methods on email (S/MIME and PGP) do not encrypt the email header information used by ARF and the service provider operators in their efforts to mitigate abuse.
メールの悪用を防止するための最大の運用上の取り組みは、メッセージング、マルウェア、モバイルの不正使用防止ワーキンググループ（M3AAWG）[M3AAWG]を通じて行われます。メールの乱用は、IETFで標準化されたAbuse Reporting Format（ARF）エージェントの使用に参加する大規模プロバイダーからの継続的なメールの乱用をシャットダウンまたは停止できるメール管理者と直接闘います[RFC5965] [RFC6430] [RFC6590] [RFC6591 ] [RFC6650] [RFC6651] [RFC6652]。 ARFエージェントは、適切なサービスプロバイダーに虐待メッセージを直接報告します。サービスプロバイダーは、虐待を停止または軽減するためのアクションを実行できます。この手法は実際のメッセージを使用するため、メールゲートウェイ間でSMTP over TLSを使用しても、その有用性には影響しません。前述のように、SMTP over TLSは転送中のデータのみを保護し、ユーザー間の暗号化方式が使用されていない場合、メッセージはメールサーバーまたはメールゲートウェイで公開される可能性があります。電子メール（S / MIMEおよびPGP）の現在のユーザー間メッセージ暗号化方式は、ARFおよびサービスプロバイダーのオペレーターが悪用を緩和するために使用する電子メールヘッダー情報を暗号化しません。
Another effort, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)" [RFC7489], is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection. DMARC is also not affected by the use of STARTTLS.
別の取り組み、「ドメインベースのメッセージ認証、レポート、および適合性（DMARC）」[RFC7489]は、アクションのないものから配信の変更まで、認証チェックに失敗したメッセージのますます厳格な処理を可能にするポリシー配布のメカニズムです。メッセージ拒否に。 DMARCは、STARTTLSの使用による影響も受けません。
Responses to Denial-of-Service (DoS) attacks are typically coordinated by the service provider community with a few key vendors who have tools to assist in the mitigation efforts. Traffic patterns are determined from each DoS attack to stop or rate limit the traffic flows with patterns unique to that DoS attack.
通常、サービス拒否（DoS）攻撃への対応は、軽減の取り組みを支援するツールを持ついくつかの主要ベンダーとサービスプロバイダーコミュニティによって調整されます。トラフィックパターンは、各DoS攻撃から特定され、そのDoS攻撃に固有のパターンでトラフィックフローを停止またはレート制限します。
Data types used in monitoring traffic for DDoS are described in the documents in development by the DDoS Open Threat Signaling (DOTS) [DOTS] Working Group. The impact of encryption can be understood from their documented use cases [DDOS-USECASE].
DDoSのトラフィックの監視に使用されるデータ型は、DDoS Open Threat Signaling（DOTS）[DOTS]ワーキンググループが開発中のドキュメントで説明されています。暗号化の影響は、文書化された使用例[DDOS-USECASE]から理解できます。
Data types used in DDoS attacks have been detailed in the Incident Object Description Exchange Format (IODEF) Guidance document (see [RFC8274], Appendix B.2) with the help of several members of the service provider community. The examples provided are intended to help identify the useful data in detecting and mitigating these attacks independent of the transport and protocol descriptions in the documents.
DDoS攻撃で使用されるデータ型については、サービスプロバイダーコミュニティのメンバーの協力を得て、インシデントオブジェクト記述交換形式（IODEF）ガイダンスドキュメント（[RFC8274]、付録B.2を参照）で詳しく説明されています。提供されている例は、ドキュメント内のトランスポートおよびプロトコルの説明とは無関係に、これらの攻撃を検出して軽減するのに役立つデータを特定するのに役立ちます。
Investigations and responses to phishing attacks follow well-known patterns, requiring access to specific fields in email headers as well as content from the body of the message. When reporting phishing attacks, the recipient has access to each field as well as the body to make content reporting possible, even when end-to-end encryption is used. The email header information is useful to identify the mail servers and accounts used to generate or relay the attack messages in order to take the appropriate actions. The content of the message often includes an embedded attack that may be in an infected file or may be a link that results in the download of malware to the user's system.
フィッシング攻撃に対する調査と対応は、よく知られているパターンに従っており、メッセージの本文のコンテンツだけでなく、電子メールのヘッダーの特定のフィールドへのアクセスも必要です。フィッシング攻撃を報告する場合、受信者は、エンドツーエンドの暗号化が使用されている場合でも、コンテンツの報告を可能にするために、本文だけでなく各フィールドにもアクセスできます。電子メールヘッダー情報は、適切なアクションを実行するために、攻撃メッセージの生成または中継に使用されるメールサーバーとアカウントを識別するのに役立ちます。多くの場合、メッセージの内容には、感染したファイルに埋め込まれた攻撃や、ユーザーのシステムへのマルウェアのダウンロードを引き起こすリンクが含まれている可能性があります。
Administrators often find it helpful to use header information to track down similar messages in their mail queue or in users' inboxes to prevent further infection. Combinations of To:, From:, Subject:, and Received: from header information might be used for this purpose. Administrators may also search for document attachments of the same name or size or that contain a file with a matching hash to a known phishing attack. Administrators might also add URLs contained in messages to block lists locally, or this may also be done by browser vendors through larger-scale efforts like that of the Anti-Phishing Working Group (APWG). See "Coordinating Attack Response at Internet Scale (CARIS) Workshop Report" [RFC8073] for additional information and pointers to the APWG's efforts on anti-phishing.
管理者は、ヘッダー情報を使用して、メールキューまたはユーザーの受信トレイにある同様のメッセージを追跡し、さらなる感染を防ぐと役立つことがよくあります。 To：、From：、Subject：、Received：fromヘッダー情報の組み合わせをこの目的で使用できます。管理者は、同じ名前またはサイズの添付ファイル、または既知のフィッシング攻撃に一致するハッシュを持つファイルを含む添付ファイルを検索することもできます。管理者は、メッセージに含まれるURLをローカルでブロックリストに追加することもできます。また、これは、フィッシング対策ワーキンググループ（APWG）のような大規模な取り組みを通じてブラウザベンダーが行うこともできます。追加情報とAPWGのフィッシング対策への取り組みについては、「インターネットスケールでの攻撃対応（CARIS）ワークショップレポート」[RFC8073]を参照してください。
A full list of the fields used in phishing attack incident responses can be found in RFC 5901. Future plans to increase privacy protections may limit some of these capabilities if some email header fields are encrypted, such as the To:, From:, and Subject: header fields. This does not mean that those fields should not be encrypted, only that we should be aware of how they are currently used.
フィッシング攻撃のインシデントレスポンスで使用されるフィールドの完全なリストは、RFC 5901にあります。プライバシー保護を強化する将来の計画では、To：、From：、Subjectなどの一部の電子メールヘッダーフィールドが暗号化されている場合、これらの機能の一部が制限される可能性があります。 ：ヘッダーフィールド。これは、それらのフィールドが暗号化されるべきではないことを意味するのではなく、それらが現在どのように使用されているかを認識しなければならないことだけです。
Some products protect users from phishing by maintaining lists of known phishing domains (such as misspelled bank names) and blocking access. This can be done by observing DNS, cleartext HTTP, or Server Name Indication (SNI) in TLS, in addition to analyzing email. Alternate options to detect and prevent phishing attacks may be needed. More recent examples of data exchanged in spear phishing attacks has been detailed in the IODEF Guidance document (see [RFC8274], Appendix B.3).
一部の製品は、既知のフィッシングドメイン（スペルミスのある銀行名など）のリストを維持し、アクセスをブロックすることにより、ユーザーをフィッシングから保護します。これは、電子メールの分析に加えて、TLSでDNS、クリアテキストHTTP、またはサーバー名表示（SNI）を監視することで実行できます。フィッシング攻撃を検出して防止するための代替オプションが必要になる場合があります。スピアフィッシング攻撃で交換されるデータの最近の例は、IODEFガイダンスドキュメントに記載されています（[RFC8274]、付録B.3を参照）。
Botnet detection and mitigation is complex as botnets may involve hundreds or thousands of hosts with numerous C&C servers. The techniques and data used to monitor and detect each may vary. Connections to C&C servers are typically encrypted; therefore, a move to an increasingly encrypted Internet may not affect the detection and sharing methods used.
ボットネットには多数のC＆Cサーバーを備えた数百または数千のホストが含まれる可能性があるため、ボットネットの検出と緩和は複雑です。それぞれを監視および検出するために使用される手法とデータは異なる場合があります。 C＆Cサーバーへの接続は通常暗号化されています。したがって、ますます暗号化されるインターネットへの移行は、使用される検出および共有方法に影響を与えない可能性があります。
Techniques for the detection and monitoring of malware vary. As mentioned in Section 4, malware monitoring may occur at gateways to the organization analyzing email and web traffic. These services can also be provided by service providers, changing the scale and location of this type of monitoring. Additionally, incident responders may identify attributes unique to types of malware to help track down instances by their communication patterns on the Internet or by alterations to hosts and servers.
マルウェアの検出と監視の手法はさまざまです。セクション4で述べたように、マルウェアの監視は、電子メールとWebトラフィックを分析する組織へのゲートウェイで発生する可能性があります。これらのサービスは、サービスプロバイダーが提供することもでき、このタイプのモニタリングの規模と場所を変更します。さらに、インシデントレスポンダーは、マルウェアのタイプに固有の属性を識別して、インターネット上の通信パターンまたはホストとサーバーへの変更によってインスタンスを追跡するのに役立ちます。
Data types used in malware investigations have been summarized in an example of the IODEF Guidance document (see [RFC8274], Appendix B.3).
マルウェア調査で使用されるデータタイプは、IODEFガイダンスドキュメントの例にまとめられています（[RFC8274]、付録B.3を参照）。
The IETF has reacted to spoofed-source IP address-based attacks, recommending the use of network ingress filtering in BCP 38 [RFC2827] and of the unicast Reverse Path Forwarding (uRPF) mechanism [RFC3704]. But uRPF suffers from limitations regarding its granularity: a malicious node can still use a spoofed IP address included inside the prefix assigned to its link. Source Address Validation Improvement (SAVI) mechanisms try to solve this issue. Basically, a SAVI mechanism is based on the monitoring of a specific address assignment/management protocol (e.g., Stateless Address Autoconfiguration (SLAAC) [RFC4862], Secure Neighbor Discovery (SEND) [RFC3971], and DHCPv4/v6 [RFC2131][RFC3315]) and, according to this monitoring, sets up a filtering policy allowing only the IP flows with a correct source IP address (i.e., any packet with a source IP address from a node not owning it is dropped). The encryption of parts of the address assignment/management protocols, critical for SAVI mechanisms, can result in a dysfunction of the SAVI mechanisms.
IETFは、スプーフィングされたソースIPアドレスベースの攻撃に対応し、BCP 38 [RFC2827]でのネットワーク入力フィルタリングとユニキャストReverse Path Forwarding（uRPF）メカニズム[RFC3704]の使用を推奨しています。しかし、uRPFにはその粒度に関する制限があります。悪意のあるノードは、そのリンクに割り当てられたプレフィックス内に含まれる偽装されたIPアドレスを引き続き使用できます。ソースアドレス検証改善（SAVI）メカニズムは、この問題を解決しようとします。基本的に、SAVIメカニズムは、特定のアドレス割り当て/管理プロトコル（例：ステートレスアドレス自動構成（SLAAC）[RFC4862]、Secure Neighbor Discovery（SEND）[RFC3971]、およびDHCPv4 / v6 [RFC2131] [RFC3315]の監視に基づいています。 ]）そして、この監視に従って、正しい送信元IPアドレスを持つIPフローのみを許可するフィルタリングポリシーを設定します（つまり、所有していないノードからの送信元IPアドレスを持つパケットはドロップされます）。 SAVIメカニズムにとって重要なアドレス割り当て/管理プロトコルの一部の暗号化は、SAVIメカニズムの機能不全を引き起こす可能性があります。
Although incident response work will continue, new methods to prevent system compromise through security automation and continuous monitoring [SACM] may provide alternate approaches where system security is maintained as a preventative measure.
インシデント対応作業は継続しますが、セキュリティの自動化と継続的な監視[SACM]を通じてシステムの侵害を防止する新しい方法は、システムのセキュリティが予防策として維持される代替アプローチを提供する可能性があります。
This section describes specific techniques used in monitoring applications that are visible to the network if a 5-tuple is exposed and as such can potentially be used as input for future network-management approaches. It also includes an overview of IP Flow Information Export (IPFIX), a flow-based protocol used to export information about network flows.
このセクションでは、5タプルが公開されている場合にネットワークから見えるアプリケーションの監視に使用される特定の手法について説明します。そのため、将来のネットワーク管理アプローチの入力として使用できる可能性があります。また、ネットワークフローに関する情報のエクスポートに使用されるフローベースのプロトコルであるIPフロー情報エクスポート（IPFIX）の概要も含まれています。
Many of the accounting, monitoring, and measurement tasks described in this document, especially in Sections 2.3.2, 3.1.1, 4.1.3, 4.2, and 5.2, use the IPFIX protocol [RFC7011] for export and storage of the monitored information. IPFIX evolved from the widely deployed NetFlow protocol [RFC3954], which exports information about flows identified by 5-tuple. While NetFlow was largely concerned with exporting per-flow byte and packet counts for accounting purposes, IPFIX's extensible Information Model [RFC7012] provides a variety of Information Elements (IEs) [IPFIX-IANA] for representing information above and below the traditional network-layer flow information. Enterprise-specific IEs allow exporter vendors to define their own non-standard IEs as well, and many of these are driven by header and payload inspection at the Metering Process.
このドキュメント、特にセクション2.3.2、3.1.1、4.1.3、4.2、および5.2で説明されているアカウンティング、監視、および測定タスクの多くは、監視された情報のエクスポートと保存にIPFIXプロトコル[RFC7011]を使用します。 IPFIXは、広く採用されているNetFlowプロトコル[RFC3954]から発展しました。これは、5タプルで識別されるフローに関する情報をエクスポートします。 NetFlowはアカウンティングの目的でフローごとのバイト数とパケット数のエクスポートに主に関係していましたが、IPFIXの拡張可能な情報モデル[RFC7012]は、従来のネットワーク層の上下に情報を表すためのさまざまな情報要素（IE）[IPFIX-IANA]を提供しますフロー情報。企業固有のIEを使用すると、輸出業者のベンダーは独自の非標準IEを定義することもできます。これらの多くは、メータリングプロセスでのヘッダーとペイロードの検査によって駆動されます。
While the deployment of encryption has no direct effect on the use of IPFIX, certain defined IEs may become unavailable when the Metering Process observing the traffic cannot decrypt former cleartext information. For example, HTTPS renders HTTP header analysis impossible, so IEs derived from the header (e.g., httpContentType, httpUserAgent) cannot be exported.
暗号化の展開がIPFIXの使用に直接影響を与えることはありませんが、トラフィックを監視するメータリングプロセスが以前のクリアテキスト情報を解読できない場合、特定の定義済みIEが使用できなくなる可能性があります。たとえば、HTTPSはHTTPヘッダー分析を不可能にするため、ヘッダーから派生したIE（httpContentType、httpUserAgentなど）はエクスポートできません。
The collection of IPFIX data itself, of course, provides a point of centralization for information that is potentially business and privacy critical. The IPFIX File Format specification [RFC5655] recommends encryption for this data at rest, and the IP Flow Anonymization specification [RFC6235] defines a metadata format for describing the anonymization functions applied to an IPFIX dataset, if anonymization is employed for data sharing of IPFIX information between enterprises or network operators.
もちろん、IPFIXデータ自体の収集は、潜在的にビジネスとプライバシーにとって重要な情報の一元化のポイントを提供します。 IPFIXファイル形式仕様[RFC5655]はこのデータの保存時の暗号化を推奨し、IPフロー匿名化仕様[RFC6235]は、IPFIX情報のデータ共有に匿名化が採用されている場合、IPFIXデータセットに適用される匿名化機能を記述するためのメタデータ形式を定義します企業またはネットワーク事業者間。
When initiating the TLS handshake, the client may provide an extension field (server_name) that indicates the server to which it is attempting a secure connection. TLS SNI was standardized in 2003 to enable servers to present the "correct TLS certificate" to clients in a deployment of multiple virtual servers hosted by the same server infrastructure and IP address. Although this is an optional extension, it is today supported by all modern browsers, web servers, and developer libraries. Akamai [Nygren] reports that many of their customers see client TLS SNI usage over 99%. It should be noted that HTTP/2 introduces the Alt-SVC method for upgrading the connection from HTTP/1 to either unencrypted or encrypted HTTP/2. If the initial HTTP/1 request is unencrypted, the destination alternate service name can be identified before the communication is potentially upgraded to encrypted HTTP/2 transport. HTTP/2 requires the TLS implementation to support the SNI extension (see Section 9.2 of [RFC7540]). It is also worth noting that [RFC7838] "allows an origin server to nominate additional means of interacting with it on the network", while [RFC8164] allows for a URI to be accessed with HTTP/2 and TLS using Opportunistic Security (on an experimental basis).
TLSハンドシェイクを開始するとき、クライアントは、安全な接続を試みているサーバーを示す拡張フィールド（server_name）を提供できます。 TLS SNIは2003年に標準化され、同じサーバーインフラストラクチャとIPアドレスでホストされている複数の仮想サーバーの展開で、サーバーがクライアントに「正しいTLS証明書」を提示できるようになりました。これはオプションの拡張機能ですが、現在、すべての最新のブラウザー、Webサーバー、および開発者ライブラリーでサポートされています。 Akamai [Nygren]は、顧客の多くがクライアントのTLS SNI使用率を99％以上見ていると報告しています。 HTTP / 2では、接続をHTTP / 1から非暗号化または暗号化されたHTTP / 2にアップグレードするためのAlt-SVCメソッドが導入されていることに注意してください。最初のHTTP / 1要求が暗号化されていない場合、通信が暗号化されたHTTP / 2トランスポートにアップグレードされる前に、宛先代替サービス名を特定できます。 HTTP / 2では、SNI拡張をサポートするためにTLS実装が必要です（[RFC7540]のセクション9.2を参照）。 [RFC7838]は「オリジンサーバーがネットワーク上でそれと対話するための追加の手段を指定できるようにする」ことにも注意する必要があります。一方、[RFC8164]は、URIにHTTP / 2およびTLSでOpportunistic Securityを使用してアクセスできるようにします。実験的基礎）。
This information is only available if the client populates the SNI extension. Doing so is an optional part of the TLS standard, and as stated above, this has been implemented by all major browsers. Due to its optional nature, though, existing network filters that examine a TLS ClientHello for an SNI extension cannot expect to always find one. "SNI Encryption in TLS Through Tunneling" [SNI-TLS] has been adopted by the TLS Working Group, which provides solutions to encrypt SNI. As such, there will be an option to encrypt SNI in future versions of TLS. The per-domain nature of SNI may not reveal the specific service or media type being accessed, especially where the domain is of a provider offering a range of email, video, web pages, etc. For example, certain blog or social network feeds may be deemed "adult content", but the SNI will only indicate the server domain rather than a URL path.
この情報は、クライアントがSNI拡張を設定する場合にのみ利用できます。これはTLS標準のオプションの部分であり、前述のとおり、これはすべての主要なブラウザーで実装されています。ただし、そのオプションの性質により、SNI拡張についてTLS ClientHelloを検査する既存のネットワークフィルターは、常にそれを見つけることを期待できません。 「トンネリングによるTLSのSNI暗号化」[SNI-TLS]は、SNIを暗号化するソリューションを提供するTLSワーキンググループによって採用されました。そのため、TLSの将来のバージョンでは、SNIを暗号化するオプションがあります。 SNIのドメインごとの性質は、アクセスされている特定のサービスまたはメディアタイプを明らかにしない場合があります。特に、ドメインが一連の電子メール、ビデオ、Webページなどを提供するプロバイダーのものである場合です。たとえば、特定のブログまたはソーシャルネットワークのフィードは、 「アダルトコンテンツ」と見なされますが、SNIはURLパスではなくサーバードメインのみを示します。
There are additional issues for identification of content using SNI: [RFC7540] includes connection coalescing, [RFC8336] defines the ORIGIN frame, and the proposal outlined in [HTTP2-CERTS] will increase the difficulty of passive monitoring.
SNIを使用したコンテンツの識別には追加の問題があります。[RFC7540]には接続の合体が含まれ、[RFC8336]はORIGINフレームを定義し、[HTTP2-CERTS]で概説されている提案はパッシブモニタリングの難易度を高めます。
ALPN is a TLS extension that may be used to indicate the application protocol within the TLS session. This is likely to be of more value to the network where it indicates a protocol dedicated to a particular traffic type (such as video streaming) rather than a multi-use protocol. ALPN is used as part of HTTP/2 'h2', but will not indicate the traffic types that may make up streams within an HTTP/2 multiplex. ALPN is sent cleartext in the ClientHello, and the server returns it in Encrypted Extensions in TLS 1.3.
ALPNは、TLSセッション内のアプリケーションプロトコルを示すために使用できるTLS拡張です。これは、マルチユースプロトコルではなく、特定のトラフィックタイプ専用のプロトコル（ビデオストリーミングなど）を示すネットワークにとって、より価値のあるものになる可能性があります。 ALPNはHTTP / 2 'h2'の一部として使用されますが、HTTP / 2マルチプレックス内でストリームを構成する可能性のあるトラフィックタイプは示しません。 ALPNはClientHelloでクリアテキストで送信され、サーバーはそれをTLS 1.3の暗号化拡張機能で返します。
The content length of encrypted traffic is effectively the same as that of the cleartext. Although block ciphers utilize padding, this makes a negligible difference. Bitrate and pacing are generally application specific and do not change much when the content is encrypted. Multiplexed formats (such as HTTP/2 and QUIC [QUIC]) may, however, incorporate several application streams over one connection, which makes the bitrate/pacing no longer application specific. Also, packet padding is available in HTTP/2, TLS 1.3, and many other protocols. Traffic analysis is made more difficult by such countermeasures.
暗号化されたトラフィックのコンテンツ長は、実質的にクリアテキストのコンテンツ長と同じです。ブロック暗号はパディングを利用しますが、これはごくわずかな違いになります。ビットレートとペーシングは一般にアプリケーション固有であり、コンテンツが暗号化されてもそれほど変化しません。ただし、多重化された形式（HTTP / 2やQUIC [QUIC]など）には、1つの接続で複数のアプリケーションストリームが組み込まれる場合があり、ビットレート/ペーシングがアプリケーション固有ではなくなります。また、パケットパディングは、HTTP / 2、TLS 1.3、およびその他の多くのプロトコルで使用できます。このような対策により、トラフィック分析はより困難になります。
Transport header encryption prevents the use of transit proxies in the center of the network and the use of some edge proxies by preventing the proxies from taking action on the stream. It may be that the claimed benefits of such proxies could be achieved by end-to-end client and server optimizations, distribution using CDNs, plus the ability to continue connections across different access technologies (across dynamic user IP addresses). The following aspects should be considered in this approach:
トランスポートヘッダーの暗号化は、ネットワークの中央での中継プロキシの使用と、プロキシがストリームに対してアクションを実行できないようにすることで、一部のエッジプロキシの使用を防止します。そのようなプロキシの主張された利点は、エンドツーエンドのクライアントとサーバーの最適化、CDNを使用した配信、および（動的ユーザーIPアドレス全体の）異なるアクセステクノロジー間で接続を継続する機能によって達成できる可能性があります。このアプローチでは、次の側面を考慮する必要があります。
1. In a wireless mobile network, the delay and channel capacity per user and sector varies due to coverage, contention, user mobility, scheduling balances fairness, capacity, and service QoE. If most users are at the cell edge, the controller cannot use more-complex Quadrature Amplitude Modulation (QAM), thus reducing total cell capacity; similarly, if a Universal Mobile Telecommunications System (UMTS) edge is serving some number of CS-Voice Calls, the remaining capacity for packet services is reduced.
1. ワイヤレスモバイルネットワークでは、カバレッジ、競合、ユーザーモビリティ、スケジューリングバランスの公平性、容量、およびサービスQoEにより、ユーザーおよびセクターごとの遅延とチャネル容量が異なります。ほとんどのユーザーがセルエッジにいる場合、コントローラーはより複雑な直交振幅変調（QAM）を使用できないため、セルの総容量が減少します。同様に、ユニバーサルモバイルテレコミュニケーションシステム（UMTS）エッジがいくつかのCS-Voice Callsを処理している場合、パケットサービスの残りの容量が減少します。
2. Mobile wireless networks service inbound roamers (users of Operator A in the foreign network of Operator B) by backhauling their traffic through the network (from Operator B to Operator A) and then serving them through the P-Gateway (PGW), General Packet Radio Service (GPRS) Support Node (GGSN), CDN, etc., of Operator A (the user's home operator). Increasing window sizes to compensate for the path RTT will have the limitations outlined earlier for TCP. The outbound roamer scenario has a similar TCP performance impact.
2. モバイルワイヤレスネットワークは、ネットワーク（オペレーターBからオペレーターAへ）を介してトラフィックをバックホールし、Pゲートウェイ（PGW）、一般パケット無線を介してサービスを提供することにより、インバウンドローマー（オペレーターBの外部ネットワークのオペレーターAのユーザー）にサービスを提供します。オペレーターA（ユーザーのホームオペレーター）のサービス（GPRS）サポートノード（GGSN）、CDNなど。パスRTTを補うためにウィンドウサイズを大きくすると、TCPについて前に説明した制限があります。アウトバウンドローマーシナリオには、同様のTCPパフォーマンスの影響があります。
3. Issues in deploying CDNs in Radio Access Networks (RANs) include decreasing the client-server control loop that requires deploying CDNs / Cloud functions that terminate encryption closer to the edge. In Cellular RAN, the user IP traffic is encapsulated into GPRS Tunneling Protocol-User Plane (GTP-U in UMTS and LTE) tunnels to handle user mobility; the tunnels terminate in APN/GGSN/PGW that are in central locations. One user's traffic may flow through one or more APN's (for example, Internet APN, Roaming APN for Operator X, Video-Service APN, OnDeckAPN, etc.). The scope of operator private IP addresses may be limited to specific APNs. Since CDNs generally operate on user IP flows, deploying them would require enhancing them with tunnel translation, tunnel-management functions, etc.
3.無線アクセスネットワーク（RAN）にCDNを展開する際の問題には、エッジの近くで暗号化を終了するCDN /クラウド機能の展開を必要とするクライアントサーバー制御ループの減少が含まれます。セルラーRANでは、ユーザーモビリティを処理するために、ユーザーIPトラフィックがGPRSトンネリングプロトコル-ユーザープレーン（UMTSおよびLTEのGTP-U）トンネルにカプセル化されます。トンネルは、中央の場所にあるAPN / GGSN / PGWで終了します。 1人のユーザーのトラフィックが1つ以上のAPN（たとえば、インターネットAPN、オペレーターXのローミングAPN、ビデオサービスAPN、OnDeckAPNなど）を通過する場合があります。オペレーターのプライベートIPアドレスの範囲は、特定のAPNに制限される場合があります。 CDNは一般にユーザーIPフローで動作するため、展開するにはトンネル変換、トンネル管理機能などを使用して拡張する必要があります。
4. While CDNs that decrypt flows or split connection proxies (similar to split TCP) could be deployed closer to the edges to reduce control-loop RTT, with transport header encryption, such CDNs perform optimization functions only for partner client flows. Therefore, content from some Small-Medium Businesses (SMBs) would not get such CDN benefits.
4. フローまたはスプリット接続プロキシ（スプリットTCPに類似）を復号化するCDNをエッジの近くに配置して、トランスポートヘッダーの暗号化により制御ループRTTを削減できますが、そのようなCDNはパートナークライアントフローに対してのみ最適化機能を実行します。したがって、一部の中小企業（SMB）のコンテンツは、このようなCDNのメリットを得られません。
As stated in [RFC7258], "an appropriate balance [between network management and pervasive monitoring mitigations] will emerge over time as real instances of this tension are considered." Numerous operators made it clear in their response to this document that they fully support strong encryption and providing privacy for end users; this is a common goal. Operators recognize that not all the practices documented need to be supported going forward, either because of the risk to end-user privacy or because alternate technologies and tools have already emerged. This document is intended to support network engineers and other innovators to work toward solving network and security management problems with protocol designers and application developers in new ways that facilitate adoption of strong encryption rather than preventing the use of encryption. By having the discussions on network and security management practices with application developers and protocol designers, each side of the debate can understand each other's goals, work toward alternate solutions, and disband with practices that should no longer be supported. A goal of this document is to assist the IETF in understanding some of the current practices so as to identify new work items for IETF-related use cases that can facilitate the adoption of strong session encryption and support network and security management.
[RFC7258]で述べられているように、「この緊張の実際のインスタンスが考慮されると、適切なバランス[ネットワーク管理と広範囲にわたる監視の緩和の間]が時間の経過とともに出現します。」多数のオペレーターがこのドキュメントへの回答で、強力な暗号化を完全にサポートし、エンドユーザーにプライバシーを提供することを明らかにしました。これは共通の目標です。オペレーターは、エンドユーザーのプライバシーに対するリスクのため、または代替のテクノロジーとツールがすでに出現しているため、文書化されているすべてのプラクティスを今後サポートする必要があるわけではないことを認識しています。このドキュメントは、暗号化の使用を防止するのではなく、強力な暗号化の採用を促進する新しい方法で、ネットワークエンジニアおよびその他の革新者がプロトコル設計者およびアプリケーション開発者とのネットワークおよびセキュリティ管理問題の解決に向けて取り組むことを支援することを目的としています。アプリケーション開発者およびプロトコル設計者とネットワークおよびセキュリティ管理の実践について話し合うことにより、討論の両側は、互いの目標を理解し、代替ソリューションに取り組み、もはやサポートされるべきではない実践を解散することができます。このドキュメントの目的は、強力なセッション暗号化の採用を促進し、ネットワークおよびセキュリティ管理をサポートできるIETF関連のユースケースの新しい作業項目を特定するために、IETFが現在のプラクティスのいくつかを理解するのを支援することです。
There are no additional security considerations as this is a summary and does not include a new protocol or functionality.
これは概要であり、新しいプロトコルや機能が含まれていないため、セキュリティに関する追加の考慮事項はありません。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[ACCORD] IETF, "Alternatives to Content Classification for Operator Resource Deployment (accord) (BOF)", IETF-95 Proceedings, April 2016, <https://www.ietf.org/proceedings/95/accord.html>.
[アコード] IETF、「オペレーターリソースデプロイメント（アコード）（BOF）のコンテンツ分類の代替」、IETF-95議事録、2016年4月、<https://www.ietf.org/proceedings/95/accord.html>。
[Ben17a] Benjamin, D., "Chrome Data", Presentation before the TLS WG at IETF 100, November 2017, <https://datatracker.ietf.org/meeting/100/materials/ slides-100-tls-sessa-tls13/>.
[Ben17a] Benjamin、D。、「Chrome Data」、TLS WGの前のプレゼンテーション、IETF 100、2017年11月、<https://datatracker.ietf.org/meeting/100/materials/ slides-100-tls-sessa- tls13 />。
[Ben17b] Benjamin, D., "Subject: Additional TLS 1.3 results from Chrome", message to the TLS mailing list, 18 December 2017, <https://www.ietf.org/mail-archive/web/tls/current/ msg25168.html>.
[Ben17b] Benjamin、D。、「件名：Chromeからの追加のTLS 1.3の結果」、TLSメーリングリストへのメッセージ、2017年12月18日、<https://www.ietf.org/mail-archive/web/tls/current / msg25168.html>。
[CAIDA] CAIDA, "The CAIDA USCD Anonymized Internet Traces 2016 Dataset", <http://www.caida.org/data/passive/ passive_2016_dataset.xml>.
[CAIDA] CAIDA、「CAIDA USCD匿名インターネットトレース2016データセット」、<http://www.caida.org/data/passive/passive_2016_dataset.xml>。
[DarkMail] "Dark Mail Technical Alliance", <https://darkmail.info/>.
[DarkMail]「Dark Mail Technical Alliance」、<https://darkmail.info/>。
[DDOS-USECASE] Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS Open Threat Signaling", Work in Progress, draft-ietf-dots-use-cases-16, July 2018.
[DDOS-USECASE] Dobbins、R.、Migault、D.、Fouant、S.、Moskowitz、R.、Teague、N.、Xia、L。、およびK.西塚、「DDoS Open Threat Signalingの使用例」、 Work in Progress、draft-ietf-dots-use-cases-16、2018年7月。
[DOTS] IETF, "DDoS Open Threat Signaling (dots)", <https://datatracker.ietf.org/wg/dots/charter>.
[DOTS] IETF、「DDoS Open Threat Signaling（dots）」、<https://datatracker.ietf.org/wg/dots/charter>。
[EFF2014] Hoffman-Andrews, J., "ISPs Removing Their Customers' Email Encryption", November 2014, <https://www.eff.org/deeplinks/2014/11/ starttls-downgrade-attacks>.
[EFF2014] Hoffman-Andrews、J。、「ISPが顧客の電子メール暗号化を削除する」、2014年11月、<https://www.eff.org/deeplinks/2014/11/ starttls-downgrade-attacks>。
[Enrich] Narseo Vallina-Rodriguez, N., Sundaresan, S., Kreibich, C., and V. Paxson, "Header Enrichment or ISP Enrichment: Emerging Privacy Threats in Mobile Networks", Proceedings of the ACM SIGCOMM Workshop on Hot Topics in Middleboxes and Network Function Virtualization, pp. 23-30, DOI 10.1145/2785989.2786002, August 2015.
[エンリッチ] Narseo Vallina-Rodriguez、N.、Sundaresan、S.、Kreibich、C。、およびV. Paxson、「Header Enrichment or ISP Enrichment：Emerging Privacy Threats in Mobile Networks」、ACM SIGCOMM Workshop on Hot Topicsミドルボックスとネットワーク機能の仮想化、23〜30ページ、DOI 10.1145 / 2785989.2786002、2015年8月。
[GENEVE-REQS] Migault, D., Boutros, S., Wing, D., and S. Krishnan, "Geneve Protocol Security Requirements", Work in Progress, draft-mglt-nvo3-geneve-security-requirements-03, February 2018.
[GENEVE-REQS] Migault、D.、Boutros、S.、Wing、D。、およびS. Krishnan、「Geneve Protocol Security Requirements」、Work in Progress、draft-mglt-nvo3-geneve-security-requirements-03、 2018年2月。
[HTTP2-CERTS] Bishop, M., Sullivan, N., and M. Thomson, "Secondary Certificate Authentication in HTTP/2", Work in Progress, draft-ietf-httpbis-http2-secondary-certs-02, June 2018.
[HTTP2-CERTS] Bishop、M.、Sullivan、N。、およびM. Thomson、「HTTP / 2での2次証明書認証」、作業中、draft-ietf-httpbis-http2-secondary-certs-02、2018年6月。
[IPFIX-IANA] IANA, "IP Flow Information Export (IPFIX) Entities", <https://www.iana.org/assignments/ipfix/>.
[IPFIX-IANA] IANA、「IPフロー情報エクスポート（IPFIX）エンティティ」、<https://www.iana.org/assignments/ipfix/>。
[JNSLP] Eskens, S., "10 Standards for Oversight and Transparency of National Intelligence Services", Surveillance, Vol. 8, No. 3, July 2016, <http://jnslp.com/?s=10+Standards+for+Ov ersight+and+Transparency+of+National>.
[JNSLP] Eskens、S。、「National Intelligence Servicesの監視と透明性に関する10の基準」、Surveillance、Vol。 8、No。3、2016年7月、<http://jnslp.com/?s=10+Standards+for+Ov ersight + and + Transparency + of + National>。
[M3AAWG] M3AAWG, "Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG)", <https://www.maawg.org/>.
[M3AAWG] M3AAWG、「メッセージング、マルウェア、モバイルの不正使用防止ワーキンググループ（M3AAWG）」、<https://www.maawg.org/>。
[MIDDLEBOXES] Dolson, D., Snellman, J., Boucadair, M., and C. Jacquenet, "An Inventory of Transport-centric Functions Provided by Middleboxes", Work in Progress, draft-dolson-transport-middlebox-03, June 2018.
[MIDDLEBOXES] Dolson、D.、Snellman、J.、Boucadair、M。、およびC. Jacquenet、「ミドルボックスによって提供されるトランスポート中心の機能のインベントリ」、Work in Progress、draft-dolson-transport-middlebox-03、 2018年6月。
[Nygren] Nygren, E., "Reaching toward Universal TLS SNI", Akamai Technologies, March 2017, <https://blogs.akamai.com/2017/03/ reaching-toward-universal-tls-sni.html>.
[Nygren] Nygren、E。、「Universal TLS SNIへの到達」、Akamai Technologies、2017年3月、<https://blogs.akamai.com/2017/03/ reaching-toward-universal-tls-sni.html>。
[QUIC] IETF, "QUIC (quic)", <https://datatracker.ietf.org/wg/quic/charter/>.
[QUIC] IETF、「彼（何でも）」<https://datatracker.ietf.org/wg/quic/charter/>。
[Res17a] Rescorla, E., "Subject: Preliminary data on Firefox TLS 1.3 Middlebox experiment", message to the TLS mailing list, 5 December 2017, <https://www.ietf.org/mail-archive/ web/tls/current/msg25091.html>.
[Res17a] Rescorla、E。、「件名：Firefox TLS 1.3 Middlebox実験の予備データ」、TLSメーリングリストへのメッセージ、2017年12月5日、<https://www.ietf.org/mail-archive/ web / tls /current/msg25091.html>。
[Res17b] Rescorla, E., "Subject: More compatibility measurement results", message to the TLS mailing list, 22 December 2017, <https://www.ietf.org/mail-archive/web/tls/current/ msg25179.html>.
[Res17b] Rescorla、E。、「件名：互換性測定結果の増加」、TLSメーリングリストへのメッセージ、2017年12月22日、<https://www.ietf.org/mail-archive/web/tls/current/ msg25179 .html>。
[RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, DOI 10.17487/RFC1945, May 1996, <https://www.rfc-editor.org/info/rfc1945>.
[RFC1945] Berners-Lee、T.、Fielding、R。、およびH. Frystyk、「Hypertext Transfer Protocol-HTTP / 1.0」、RFC 1945、DOI 10.17487 / RFC1945、1996年5月、<https：//www.rfc -editor.org/info/rfc1945>。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, <https://www.rfc-editor.org/info/rfc1958>.
[RFC1958] Carpenter、B。、編、「インターネットのアーキテクチャ原則」、RFC 1958、DOI 10.17487 / RFC1958、1996年6月、<https://www.rfc-editor.org/info/rfc1958>。
[RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic Technology and the Internet", BCP 200, RFC 1984, DOI 10.17487/RFC1984, August 1996, <https://www.rfc-editor.org/info/rfc1984>.
[RFC1984] IABとIESG、「暗号化技術とインターネットに関するIABとIESGの声明」、BCP 200、RFC 1984、DOI 10.17487 / RFC1984、1996年8月、<https://www.rfc-editor.org/info/rfc1984 >。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、DOI 10.17487 / RFC2131、1997年3月、<https://www.rfc-editor.org/info/rfc2131>。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.
[RFC2474]ニコルズ、K。、ブレイク、S。、ベイカー、F。、およびD.ブラック、「IPv4およびIPv6ヘッダーのDiffServフィールド（DSフィールド）の定義」、RFC 2474、DOI 10.17487 / RFC2474、 1998年12月、<https://www.rfc-editor.org/info/rfc2474>。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, <https://www.rfc-editor.org/info/rfc2663>.
[RFC2663] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス変換（NAT）の用語と考慮事項」、RFC 2663、DOI 10.17487 / RFC2663、1999年8月、<https://www.rfc-editor.org/info / rfc2663>。
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, DOI 10.17487/RFC2775, February 2000, <https://www.rfc-editor.org/info/rfc2775>.
[RFC2775] Carpenter、B。、「Internet Transparency」、RFC 2775、DOI 10.17487 / RFC2775、2000年2月、<https://www.rfc-editor.org/info/rfc2775>。
[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>。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IPソースアドレススプーフィングを使用するサービス拒否攻撃の阻止」、BCP 38、RFC 2827、DOI 10.17487 / RFC2827、2000年5月、<https：// www .rfc-editor.org / info / rfc2827>。
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, DOI 10.17487/RFC3135, June 2001, <https://www.rfc-editor.org/info/rfc3135>.
[RFC3135] Border、J.、Kojo、M.、Griner、J。、モンテネグロ、G。、およびZ. Shelby、「リンク関連の劣化を軽減するためのパフォーマンス強化プロキシ」、RFC 3135、DOI 10.17487 / RFC3135、6月2001、<https://www.rfc-editor.org/info/rfc3135>。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC3315] Droms、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315 、DOI 10.17487 / RFC3315、2003年7月、<https://www.rfc-editor.org/info/rfc3315>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <https://www.rfc-editor.org/info/rfc3550>。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, <https://www.rfc-editor.org/info/rfc3704>.
[RFC3704]ベイカー、F。およびP.サボラ、「マルチホームネットワークの入力フィルタリング」、BCP 84、RFC 3704、DOI 10.17487 / RFC3704、2004年3月、<https://www.rfc-editor.org/info/rfc3704 >。
[RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture", RFC 3724, DOI 10.17487/RFC3724, March 2004, <https://www.rfc-editor.org/info/rfc3724>.
[RFC3724] Kempf、J.、Ed。、Austein、R.、Ed。、およびIAB、「中間の台頭とエンドツーエンドの未来：インターネットアーキテクチャの進化に関する考察」、RFC 3724 、DOI 10.17487 / RFC3724、2004年3月、<https://www.rfc-editor.org/info/rfc3724>。
[RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004, <https://www.rfc-editor.org/info/rfc3954>.
[RFC3954] Claise、B。、編、「Cisco Systems NetFlow Services Export Version 9」、RFC 3954、DOI 10.17487 / RFC3954、2004年10月、<https://www.rfc-editor.org/info/rfc3954>。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, <https://www.rfc-editor.org/info/rfc3971>.
[RFC3971] Arkko、J.、Ed。、Kempf、J.、Zill、B。、およびP. Nikander、「SEcure Neighbor Discovery（SEND）」、RFC 3971、DOI 10.17487 / RFC3971、2005年3月、<https：/ /www.rfc-editor.org/info/rfc3971>。
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, <https://www.rfc-editor.org/info/rfc4787>.
[RFC4787]オーデ、F、エド。およびC.ジェニングス、「ユニキャストUDPのネットワークアドレス変換（NAT）動作要件」、BCP 127、RFC 4787、DOI 10.17487 / RFC4787、2007年1月、<https://www.rfc-editor.org/info/rfc4787> 。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、DOI 10.17487 / RFC4862、2007年9月、<https://www.rfc-editor.org/info / rfc4862>。
[RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, "Specification of the IP Flow Information Export (IPFIX) File Format", RFC 5655, DOI 10.17487/RFC5655, October 2009, <https://www.rfc-editor.org/info/rfc5655>.
[RFC5655] Trammell、B.、Boschi、E.、Mark、L.、Zseby、T。、およびA. Wagner、「Specification of the IP Flow Information Export（IPFIX）File Format」、RFC 5655、DOI 10.17487 / RFC5655 、2009年10月、<https://www.rfc-editor.org/info/rfc5655>。
[RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, DOI 10.17487/RFC5965, August 2010, <https://www.rfc-editor.org/info/rfc5965>.
[RFC5965] Shafranovich、Y.、Levine、J。、およびM. Kucherawy、「電子メールフィードバックレポートの拡張可能なフォーマット」、RFC 5965、DOI 10.17487 / RFC5965、2010年8月、<https：//www.rfc-editor。 org / info / rfc5965>。
[RFC6108] Chung, C., Kasyanov, A., Livingood, J., Mody, N., and B. Van Lieu, "Comcast's Web Notification System Design", RFC 6108, DOI 10.17487/RFC6108, February 2011, <https://www.rfc-editor.org/info/rfc6108>.
[RFC6108] Chung、C.、Kasyanov、A.、Livingood、J.、Mody、N。、およびB. Van Lieu、「ComcastのWeb通知システムの設計」、RFC 6108、DOI 10.17487 / RFC6108、2011年2月、<https ：//www.rfc-editor.org/info/rfc6108>。
[RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization Support", RFC 6235, DOI 10.17487/RFC6235, May 2011, <https://www.rfc-editor.org/info/rfc6235>.
[RFC6235] Boschi、E。およびB. Trammell、「IP Flow Anonymization Support」、RFC 6235、DOI 10.17487 / RFC6235、2011年5月、<https://www.rfc-editor.org/info/rfc6235>。
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, <https://www.rfc-editor.org/info/rfc6269>.
[RFC6269]フォード、M。、エド、ブーカデア、M。、デュランド、A。、リーバイス、P。、およびP.ロバーツ、「IPアドレス共有の問題」、RFC 6269、DOI 10.17487 / RFC6269、2011年6月、 <https://www.rfc-editor.org/info/rfc6269>。
[RFC6430] Li, K. and B. Leiba, "Email Feedback Report Type Value: not-spam", RFC 6430, DOI 10.17487/RFC6430, November 2011, <https://www.rfc-editor.org/info/rfc6430>.
[RFC6430] Li、K。およびB. Leiba、「Email Feedback Report Type Value：not-spam」、RFC 6430、DOI 10.17487 / RFC6430、2011年11月、<https://www.rfc-editor.org/info/ rfc6430>。
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, <https://www.rfc-editor.org/info/rfc6455>.
[RFC6455] Fette、I。およびA. Melnikov、「The WebSocket Protocol」、RFC 6455、DOI 10.17487 / RFC6455、2011年12月、<https://www.rfc-editor.org/info/rfc6455>。
[RFC6590] Falk, J., Ed. and M. Kucherawy, Ed., "Redaction of Potentially Sensitive Data from Mail Abuse Reports", RFC 6590, DOI 10.17487/RFC6590, April 2012, <https://www.rfc-editor.org/info/rfc6590>.
[RFC6590]フォーク、J。、エド。およびM. Kucherawy、Ed。、「Mail Abuse Reportsからの機密性の高いデータの編集」、RFC 6590、DOI 10.17487 / RFC6590、2012年4月、<https://www.rfc-editor.org/info/rfc6590>。
[RFC6591] Fontana, H., "Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6591, DOI 10.17487/RFC6591, April 2012, <https://www.rfc-editor.org/info/rfc6591>.
[RFC6591] Fontana、H。、「Abuse Reporting Formatを使用した認証失敗の報告」、RFC 6591、DOI 10.17487 / RFC6591、2012年4月、<https://www.rfc-editor.org/info/rfc6591>。
[RFC6650] Falk, J. and M. Kucherawy, Ed., "Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)", RFC 6650, DOI 10.17487/RFC6650, June 2012, <https://www.rfc-editor.org/info/rfc6650>.
[RFC6650] Falk、J。およびM. Kucherawy、編、「電子メールフィードバックレポートの作成と使用：不正使用報告形式（ARF）の適用性に関する声明」、RFC 6650、DOI 10.17487 / RFC6650、2012年6月、<https ：//www.rfc-editor.org/info/rfc6650>。
[RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting", RFC 6651, DOI 10.17487/RFC6651, June 2012, <https://www.rfc-editor.org/info/rfc6651>.
[RFC6651] Kucherawy、M。、「Extensions to DomainKeys Identified Mail（DKIM）for Failure Reporting」、RFC 6651、DOI 10.17487 / RFC6651、2012年6月、<https://www.rfc-editor.org/info/rfc6651> 。
[RFC6652] Kitterman, S., "Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6652, DOI 10.17487/RFC6652, June 2012, <https://www.rfc-editor.org/info/rfc6652>.
[RFC6652] Kitterman、S。、「Sender Policy Framework（SPF）Authentication Failure Reporting Using a Abuse Reporting Format」、RFC 6652、DOI 10.17487 / RFC6652、2012年6月、<https://www.rfc-editor.org/info / rfc6652>。
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <https://www.rfc-editor.org/info/rfc7011>.
[RFC7011] Claise、B。、編、Trammell、B。、編、およびP. Aitken、「フロー情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、STD 77、RFC 7011、 DOI 10.17487 / RFC7011、2013年9月、<https://www.rfc-editor.org/info/rfc7011>。
[RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, September 2013, <https://www.rfc-editor.org/info/rfc7012>.
[RFC7012]クレイズ、B。、エド。およびB. Trammell、編、「IPフロー情報エクスポート（IPFIX）の情報モデル」、RFC 7012、DOI 10.17487 / RFC7012、2013年9月、<https://www.rfc-editor.org/info/rfc7012>。
[RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, "Internet Small Computer System Interface (iSCSI) Protocol (Consolidated)", RFC 7143, DOI 10.17487/RFC7143, April 2014, <https://www.rfc-editor.org/info/rfc7143>.
[RFC7143] Chadalapaka、M.、Satran、J.、Meth、K。、およびD. Black、「インターネットスモールコンピュータシステムインターフェイス（iSCSI）プロトコル（統合）」、RFC 7143、DOI 10.17487 / RFC7143、2014年4月、< https://www.rfc-editor.org/info/rfc7143>。
[RFC7146] Black, D. and P. Koning, "Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3", RFC 7146, DOI 10.17487/RFC7146, April 2014, <https://www.rfc-editor.org/info/rfc7146>.
[RFC7146] Black、D.、P。Koning、「IPを介したブロックストレージプロトコルの保護：IPsec v3のRFC 3723要件の更新」、RFC 7146、DOI 10.17487 / RFC7146、2014年4月、<https：//www.rfc-editor .org / info / rfc7146>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<https://www.rfc-editor.org/info/ rfc7230>。
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <https://www.rfc-editor.org/info/rfc7234>.
[RFC7234] Fielding、R.、Ed。、Nottingham、M.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Caching"、RFC 7234、DOI 10.17487 / RFC7234、June 2014 、<https://www.rfc-editor.org/info/rfc7234>。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7258] Farrell、S。およびH. Tschofenig、「Pervasive Monitoring Is a Attack」、BCP 188、RFC 7258、DOI 10.17487 / RFC7258、2014年5月、<https://www.rfc-editor.org/info/rfc7258 >。
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, <https://www.rfc-editor.org/info/rfc7348>.
[RFC7348] Mahalingam、M.、Dutt、D.、Duda、K.、Agarwal、P.、Kreeger、L.、Sridhar、T.、Bursell、M。、およびC. Wright、「Virtual eXtensible Local Area Network（ VXLAN）：A Layer over Overlaying Virtualized Layer 2 Networks over Layer 3 Networks」、RFC 7348、DOI 10.17487 / RFC7348、2014年8月、<https://www.rfc-editor.org/info/rfc7348>。
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7435] Dukhovni、V。、「日和見セキュリティ：ほとんどの場合はある程度の保護」、RFC 7435、DOI 10.17487 / RFC7435、2014年12月、<https://www.rfc-editor.org/info/rfc7435>。
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, February 2015, <https://www.rfc-editor.org/info/rfc7457>.
[RFC7457] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「トランスポート層セキュリティ（TLS）およびデータグラムTLS（DTLS）に対する既知の攻撃の要約」、RFC 7457、DOI 10.17487 / RFC7457、2015年2月、 <https://www.rfc-editor.org/info/rfc7457>。
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <https://www.rfc-editor.org/info/rfc7489>.
[RFC7489] Kucherawy、M.、Ed。およびE. Zwicky、編、「ドメインベースのメッセージ認証、レポート、および準拠（DMARC）」、RFC 7489、DOI 10.17487 / RFC7489、2015年3月、<https://www.rfc-editor.org/info/ rfc7489>。
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015, <https://www.rfc-editor.org/info/rfc7498>.
[RFC7498]クイン、P。、エド。 T.ナドー編、「サービス機能連鎖の問題ステートメント」、RFC 7498、DOI 10.17487 / RFC7498、2015年4月、<https://www.rfc-editor.org/info/rfc7498>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<https://www.rfc-editor.org/info/rfc7525>。
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>.
[RFC7540] Belshe、M.、Peon、R。、およびM. Thomson、編、「Hypertext Transfer Protocol Version 2（HTTP / 2）」、RFC 7540、DOI 10.17487 / RFC7540、2015年5月、<https：// www.rfc-editor.org/info/rfc7540>。
[RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, <https://www.rfc-editor.org/info/rfc7619>.
[RFC7619] Smyslov、V。およびP. Wouters、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）のNULL認証方式」、RFC 7619、DOI 10.17487 / RFC7619、2015年8月、<https：//www.rfc- editor.org/info/rfc7619>。
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., Trammell, B., Huitema, C., and D. Borkmann, "Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement", RFC 7624, DOI 10.17487/RFC7624, August 2015, <https://www.rfc-editor.org/info/rfc7624>.
[RFC7624] Barnes、R.、Schneier、B.、Jennings、C.、Hardie、T.、Trammell、B.、Huitema、C。、およびD. Borkmann、「広範にわたる監視に直面した場合の機密性：脅威モデルand Problem Statement」、RFC 7624、DOI 10.17487 / RFC7624、2015年8月、<https://www.rfc-editor.org/info/rfc7624>。
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>.
[RFC7665] Halpern、J.、Ed。 C. Pignataro、編、「Service Function Chaining（SFC）Architecture」、RFC 7665、DOI 10.17487 / RFC7665、2015年10月、<https://www.rfc-editor.org/info/rfc7665>。
[RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. Nordmark, "Technical Considerations for Internet Service Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, March 2016, <https://www.rfc-editor.org/info/rfc7754>.
[RFC7754] Barnes、R.、Cooper、A.、Kolkman、O.、Thaler、D。、およびE. Nordmark、「Technical Considerations for Internet Service Blocking and Filtering」、RFC 7754、DOI 10.17487 / RFC7754、March 2016、 <https://www.rfc-editor.org/info/rfc7754>。
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC7799]モートン、A。、「アクティブおよびパッシブメトリックおよびメソッド（中間のハイブリッドタイプを使用）」、RFC 7799、DOI 10.17487 / RFC7799、2016年5月、<https://www.rfc-editor.org/info / rfc7799>。
[RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, Ed., "Real-Time Streaming Protocol Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 2016, <https://www.rfc-editor.org/info/rfc7826>.
[RFC7826] Schulzrinne、H.、Rao、A.、Lanphier、R.、Westerlund、M。、およびM. Stiemerling、編、「Real-Time Streaming Protocol Version 2.0」、RFC 7826、DOI 10.17487 / RFC7826、12月2016、<https://www.rfc-editor.org/info/rfc7826>。
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP Alternative Services", RFC 7838, DOI 10.17487/RFC7838, April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[RFC7838]ノッティンガム、M。、マクマナス、P.、J。レシュケ、「HTTP代替サービス」、RFC 7838、DOI 10.17487 / RFC7838、2016年4月、<https://www.rfc-editor.org/info/ rfc7838>。
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7858] Hu、Z.、Zhu、L.、Heidemann、J.、Mankin、A.、Wessels、D。、およびP. Hoffman、「DNS over Transport Layer Security（TLS）の仕様」、RFC 7858、DOI 10.17487 / RFC7858、2016年5月、<https://www.rfc-editor.org/info/rfc7858>。
[RFC8073] Moriarty, K. and M. Ford, "Coordinating Attack Response at Internet Scale (CARIS) Workshop Report", RFC 8073, DOI 10.17487/RFC8073, March 2017, <https://www.rfc-editor.org/info/rfc8073>.
[RFC8073]モリアーティ、K。およびM.フォード、「インターネットスケールでの攻撃応答の調整（CARIS）ワークショップレポート」、RFC 8073、DOI 10.17487 / RFC8073、2017年3月、<https://www.rfc-editor.org/ info / rfc8073>。
[RFC8164] Nottingham, M. and M. Thomson, "Opportunistic Security for HTTP/2", RFC 8164, DOI 10.17487/RFC8164, May 2017, <https://www.rfc-editor.org/info/rfc8164>.
[RFC8164]ノッティンガム、M。およびM.トムソン、「HTTP / 2の日和見セキュリティ」、RFC 8164、DOI 10.17487 / RFC8164、2017年5月、<https://www.rfc-editor.org/info/rfc8164>。
[RFC8165] Hardie, T., "Design Considerations for Metadata Insertion", RFC 8165, DOI 10.17487/RFC8165, May 2017, <https://www.rfc-editor.org/info/rfc8165>.
[RFC8165] Hardie、T。、「メタデータ挿入の設計上の考慮事項」、RFC 8165、DOI 10.17487 / RFC8165、2017年5月、<https://www.rfc-editor.org/info/rfc8165>。
[RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 Performance and Diagnostic Metrics (PDM) Destination Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, <https://www.rfc-editor.org/info/rfc8250>.
[RFC8250] Elkins、N.、Hamilton、R。、およびM. Ackermann、「IPv6 Performance and Diagnostic Metrics（PDM）Destination Option」、RFC 8250、DOI 10.17487 / RFC8250、2017年9月、<https：//www.rfc -editor.org/info/rfc8250>。
[RFC8274] Kampanakis, P. and M. Suzuki, "Incident Object Description Exchange Format Usage Guidance", RFC 8274, DOI 10.17487/RFC8274, November 2017, <https://www.rfc-editor.org/info/rfc8274>.
[RFC8274] Kampanakis、P。およびM. Suzuki、「Incident Object Description Exchange Format Usage Guidance」、RFC 8274、DOI 10.17487 / RFC8274、2017年11月、<https://www.rfc-editor.org/info/rfc8274> 。
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, <https://www.rfc-editor.org/info/rfc8300>.
[RFC8300] Quinn、P.、Ed。、Elzur、U.、Ed。、and C. Pignataro、Ed。、 "Network Service Header（NSH）"、RFC 8300、DOI 10.17487 / RFC8300、January 2018、<https： //www.rfc-editor.org/info/rfc8300>。
[RFC8336] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame", RFC 8336, DOI 10.17487/RFC8336, March 2018, <https://www.rfc-editor.org/info/rfc8336>.
[RFC8336]ノッティンガム、M。およびE.ナイグレン、「The ORIGIN HTTP / 2 Frame」、RFC 8336、DOI 10.17487 / RFC8336、2018年3月、<https://www.rfc-editor.org/info/rfc8336>。
[SACM] IETF, "Security Automation and Continuous Monitoring (sacm)", <https://datatracker.ietf.org/wg/sacm/charter/>.
[SACM] IETF、「セキュリティの自動化と継続的監視（sacm）」、<https://datatracker.ietf.org/wg/sacm/charter/>。
[SNI-TLS] Huitema, C. and E. Rescorla, "Issues and Requirements for SNI Encryption in TLS", Work in Progress, draft-ietf-tls-sni-encryption-03, May 2018.
[SNI-TLS] Huitema、C。およびE. Rescorla、「TLSでのSNI暗号化の問題と要件」、作業中、draft-ietf-tls-sni-encryption-03、2018年5月。
[Snowden] Verble, J., "The NSA and Edward Snowden: Surveillance in the 21st Century", SIGCAS Computer & Society, Vol. 44, No. 3, DOI 10.1145/2684097.2684101, September 2014, <http://www.jjsylvia.com/bigdatacourse/wp-content/ uploads/2016/04/p14-verble-1.pdf>.
[スノーデン]バーブルJ。、「NSAとエドワードスノーデン：21世紀の監視」、SIGCAS Computer＆Society、Vol。 44、No。3、DOI 10.1145 / 2684097.2684101、2014年9月、<http://www.jjsylvia.com/bigdatacourse/wp-content/uploads/2016/04/p14-verble-1.pdf>。
[TCPcrypt] IETF, "TCP Increased Security (tcpinc)", <https://datatracker.ietf.org/wg/tcpinc/charter>.
[TCPcrypt] IETF、「TCPセキュリティ強化（tcpinc）」、<https://datatracker.ietf.org/wg/tcpinc/charter>。
[TS3GPP] 3GPP, "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3", 3GPP TS 24.301, version 15.2.0, March 2018.
[TS3GPP] 3GPP、「進化したパケットシステム（EPS）の非アクセス層（NAS）プロトコル、ステージ3」、3GPP TS 24.301、バージョン15.2.0、2018年3月。
[UPCON] 3GPP, "User Plane Congestion Management", 3GPP Rel-13, September 2014, <http://www.3gpp.org/DynaReport/ FeatureOrStudyItemFile-570029.htm>.
[UPCON] 3GPP、「User Plane Congestion Management」、3GPP Rel-13、2014年9月、<http://www.3gpp.org/DynaReport/ FeatureOrStudyItemFile-570029.htm>。
[UserData] Durumeric, Z., Ma, Z., Springall, D., Barnes, R., Sullivan, N., Bursztein, E., Bailey, M., Alex Halderman, J., and V. Paxson, "The Security Impact of HTTPS Interception", Network and Distributed Systems Symposium, February 2017, <http://dx.doi.org/10.14722/ndss.2017.23456>.
[UserData] Durumeric、Z.、Ma、Z.、Springall、D.、Barnes、R.、Sullivan、N.、Bursztein、E.、Bailey、M.、Alex Halderman、J.、and V. Paxson、 " HTTPSインターセプトのセキュリティへの影響」、ネットワークおよび分散システムシンポジウム、2017年2月、<http://dx.doi.org/10.14722/ndss.2017.23456>。
Acknowledgements
謝辞
Thanks to our reviewers, Natasha Rooney, Kevin Smith, Ashutosh Dutta, Brandon Williams, Jean-Michel Combes, Nalini Elkins, Paul Barrett, Badri Subramanyan, Igor Lubashev, Suresh Krishnan, Dave Dolson, Mohamed Boucadair, Stephen Farrell, Warren Kumari, Alia Atlas, Roman Danyliw, Mirja Kuehlewind, Ines Robles, Joe Clarke, Kyle Rose, Christian Huitema, and Chris Morrow for their editorial and content suggestions. Surya K. Kovvali provided material for Section 7. Chris Morrow and Nik Teague provided reviews and updates specific to the DoS fingerprinting text. Brian Trammell provided the IPFIX text.
レビュー担当者のおかげで、ナターシャルーニー、ケビンスミス、アシュトシュドゥッタ、ブランドンウィリアムズ、ジャンミッシェルコームス、ナリーニエルキンス、ポールバレット、バドリスブラマニアン、イゴールルバシェフ、スレーシュクリシュナン、デイブドルソン、モハメッドブーカデア、スティーブンファレル、ウォーレンクマリ、アリア編集とコンテンツの提案については、Atlas、Roman Danyliw、Mirja Kuehlewind、Ines Robles、Joe Clarke、Kyle Rose、Christian Huitema、Chris Morrowの各氏。 Surya K. Kovvaliがセクション7の資料を提供しました。ChrisMorrowとNik Teagueが、DoSフィンガープリントテキストに固有のレビューと更新を提供しました。 Brian TrammellがIPFIXテキストを提供しました。
Authors' Addresses
著者のアドレス
Kathleen Moriarty (editor) Dell EMC 176 South St Hopkinton, MA United States of America
キャスリーンモリアーティ（編集者）Dell EMC 176 South St Hopkinton、MAアメリカ合衆国
Email: Kathleen.Moriarty@dell.com
Al Morton (editor) AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 United States of America
Al Morton（編集者）AT＆T Labs 200 Laurel Avenue South Middletown、NJ 07748アメリカ合衆国
Phone: +1 732 420 1571
Fax: +1 732 368 1192
Email: acm@research.att.com