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
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.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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）的产品。互联网工程指导小组（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.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
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）体系结构原则是互联网协议发展的指导原则[RFC227] [RFC324] [RFC774]。
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数据包传输，尽管他们可能将其他服务与数据包传输捆绑在一起。或者，应用程序服务提供商主要提供作为端点参与与应用程序用户通信的系统，托管服务提供商在数据中心租赁计算、存储和通信系统。在实践中，许多公司执行两个或多个服务提供商角色，但历史上可能与一个相关。
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对谷歌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.
机会主义安全（Opportunity Security，OS）[RFC7435]中记录了一个这样的转变，这表明当无法使用经过身份验证的加密时，明文会话应该升级为未经身份验证的会话加密，而不是不加密。操作系统鼓励从明文升级，但不能要求或保证这样的升级。一旦使用了操作系统，它就可以演变为经过身份验证的加密。这些努力对于提高最终用户对隐私的期望是必要的，这使得普及监控成本过高。在使用操作系统的情况下，未经身份验证的会话仍可能受到主动攻击。操作系统已通过IPsec[RFC7619]实现为空身份验证，并且有许多基础架构用例，例如部署此模式的服务器到服务器加密。虽然操作系统通过增加监控成本有助于减少普遍监控，但人们认识到，某些应用程序的风险模式需要经过身份验证和安全的会话加密，以及防止主动攻击。IPsec和其他具有身份验证的会话加密协议有许多有用的应用程序，基础设施应用程序（如数据中心之间的虚拟专用网络）的使用率也有所增加。操作系统以及其他协议的发展，如自动证书管理环境（ACME），增加了Internet上会话加密的使用。
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.
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.translate error, please retry
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.
除了加密的网站访问（通过TLS的HTTP）外，还有其他部署良好的应用程序级传输加密工作，如MTA到MTA（邮件传输代理）的电子邮件会话加密传输（通过TLS的SMTP）和用于即时消息传递的网关到网关（通过TLS的可扩展消息和状态协议（XMPP））。尽管这确实提供了针对传输层攻击的保护，但如果没有为这些消息传递协议提供用户对用户加密，服务器可能会成为一个漏洞点。用户对用户内容加密方案，如电子邮件的S/MIME和Pretty Good Privacy（PGP）以及XMPP的Off-the-the-Record（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.
在斯诺登[斯诺登]事件曝光后，应用服务提供商（雅虎、谷歌等）通过加密其数据中心（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.
电子前沿基金会（EFF）报告了[EF201]一些网络服务提供商使用降级攻击来阻止SMTP通过TaltTLS（TruttLs的第3.2节）来攻击TLS，这实质上阻止了协商过程，导致使用明文的回退。已经有记录在案的服务提供商阻止STARTTLS以避免某些会话上的会话加密协商。这样做可以让他们注入超级cookie，让广告商能够跟踪用户；这些行为也被视为攻击。这些作为不良行为的示例，可以通过协议工作中的预先讨论来防止，以便操作员和协议设计者理解此类行为的含义。在其他情况下，一些服务提供商和企业依赖于能够访问明文的中间包来实现负载平衡、监控攻击流量、满足监管要求或其他目的。对于在其网络上拥有数据或拥有允许监控用户流量的明确协议的企业，其影响与那些可能以违反隐私考虑的方式访问内容的服务提供商的影响大不相同。此外，服务提供商设备设计为仅访问为数据链路、网络和传输层公开的报头。深入研究数据包是可能的，但当仅限于来自这三层的报头信息时，报头信息和数据包大小通常具有较高的准确性。服务提供商还可以选择向流量中添加路由覆盖协议。这些中间盒实现，执行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]。各国政府在监控与保护用户隐私、数据和资产之间的平衡上各不相同。赞成不加密访问数据的人忽视了保护用户身份、金融交易和知识产权（需要安全和加密以防止犯罪）的真正需要。对技术、加密和监控目标的清晰理解将有助于解决方案的开发，因为我们将继续努力找到适当的平衡点，以实现管理，同时使用强大的加密解决方案保护用户隐私。
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以及为核心互联网使用提供大规模基础设施的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.
网络运营商通常是第一个被要求调查应用程序问题的人（例如，“我的高清视频乱七八糟”），首先排除网络和网络服务是潜在问题的原因。在诊断客户问题时，起点可能是某个无法工作的特定应用程序。识别问题应用程序的通信量的能力很重要，从靠近边缘的客户处提供的数据包捕获可用于此目的；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
例如，通过调查数据包丢失（来自TCP序列和确认号）、往返时间（RTT）（来自TCP时间戳选项或应用层事务，例如DNS或HTTP响应时间）、TCP接收窗口大小、数据包损坏（来自校验和验证）、低效分段或应用层问题，运营商可以将问题缩小到网络的一部分、服务器过载、客户端或服务器配置错误等。网络运营商还可以识别是否存在攻击
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.
流量不符合用户声称使用的应用程序。在许多情况下，公开的数据包头足以进行此类故障排除。
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.
在故障排除过程中，快速排除网络瓶颈的一种方法是检查速度是否受到端点的限制。例如，连接速度可能会受到次优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.
数据包捕获和协议解析分析器一直是重要的工具。自动监控还被用于主动识别不良网络状况，从而在用户体验下降之前进行维护和网络升级。例如，IP语音（VoIP）流量丢失和抖动的发现可能是未来客户不满的预测因素（由RTP/RTCP的元数据支持）[RFC3550]，或者DNS响应时间的增加通常会使交互式web浏览显得迟缓。但是，要检测此类问题，必须首先将应用程序或服务流与其他应用程序或服务流区分开来。
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和安全实时传输协议（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
此外，当服务提供者可以获得关于用户事务的信息时，可以更有效地管理和修复一些服务的性能。在没有明文访问感兴趣的应用层的情况下，可以继续事务监视活动；但是，不准确度将增加，维修活动的效率将降低。例如，应用传输加密时，应用程序协议错误或故障对网络故障诊断人员来说是不透明的，这使得根本原因定位更加困难，因此增加了修复时间。修复时间直接降低了服务的可用性，大多数网络运营商已将可用性作为其服务级别协议（SLA）和/或订阅回扣中的一项关键指标。此外，当引入额外的加密过程（例如，大规模的密钥管理）时，可能会有更多的用户通信失败的情况，从而导致更多的客户
service contacts and (at the same time) less information available to network-operation repair teams.
服务联系人和（同时）网络运营维修团队可用的信息较少。
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.
在移动网络中，关于TCP流传输过程的知识（通过观察ACK、重传、丢包和扇区利用率等）进一步用于测量网络段（扇区、eNodeB（eNB）等）的性能。该信息用作关键性能指标（KPI），并用于估计网络边缘的用户/服务关键质量指标，以用于电路仿真（CEM）以及缓解方法的输入。如果提供Internet接入点名称（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缓解的常见早期触发因素包括观察给定网络或服务的异常流量或来源、拥塞或降级。缓解此类攻击的一种方法涉及区分攻击者流量和合法用户流量。检查传输层和有效载荷的能力为clear中的每一层提供了更大范围的过滤机会。如果清除的层较少，这意味着可用于减轻攻击的过滤机会减少。然而，指纹识别仍然是可能的。
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.
被动监控网络流量可能导致外部参与者在监控流量的端点侵犯隐私。端到端流量加密是混淆某些潜在识别信息的一种方法。例如，浏览器指纹由许多特征组成，包括用户代理、HTTP接受头、浏览器插件详细信息、屏幕大小和颜色详细信息、系统字体和时区。监控系统可以很容易地识别特定的浏览器，并通过关联其他信息来识别特定的用户。
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 anycast的问题。在这种情况下，连接将迁移到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的情况下，可以通过服务器生成的序列号（由客户端确认）、段值、发送的数据包长度等对此类信息进行编码。使用这些机制中的一些进行负载平衡会否定与这些原语相关的一些安全假设（例如，路径外攻击者很难猜测流的有效序列号）。另一种可能是用于存储负载平衡器状态的专用机制，如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.
该方法允许由一个端点进行严格控制，并且可以旋转以避免客户机的可链接性：换句话说，作为一个特定的、独立的信号，它可以以一种针对特定用例的方式进行管理。
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，即使任何端点都不改变网络。此外，能够以每个传入数据包中可用的明文信息对池服务器的标识进行编码的系统能够提供无状态负载平衡。这种能力带来了极大的可靠性和可伸缩性优势，即使流保持在单个POP中，因为不需要负载平衡系统来保持每个流的状态。更重要的是，不需要在负载平衡器池中持续同步这种状态。在传输流状态下重新调整有限现有位用途的集成负载平衡器必须偶尔维护和同步每个流状态：将序列号用作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.
移动运营商将3GPP自组织网络（SONs）应用于智能工作流，如内容感知移动负载平衡（MLB）。如果网络负载平衡器已配置为根据应用层语义进行路由，则加密的有效负载实际上是不可见的。这导致了在负载平衡器前拦截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.
通过根据所需带宽和可接受延迟对流量进行排队来缓解这一问题：例如，用户在接收简单网页或电子邮件或即时消息响应时不太可能注意到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）允许基于有效负载签名识别应用程序，而不是信任已知的端口号。应用层和传输层加密使流量类型估计更复杂，更不准确；因此，将此信息用作队列管理的输入可能无效。例如，使用WebSocket[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.
移动网络尤其依赖于基于内容/应用程序的超顶级（OTT）服务优先级排序——每种应用程序类型或服务都有不同的延迟/损失/吞吐量预期，并且每种类型的流在加密后对边缘设备都是未知的。这阻碍了动态QoS适应。当用户设备（UE）使用诸如3GPP TS 24.301[TS3GPP]第6.5节中描述的机制请求特定应用流的专用承载（由UE知道）时，实现加密应用分离的替代方法是可能的。UE的请求包括基于每个应用的不同延迟/损失/吞吐量期望的适合于每个应用的质量等级指示器（QCI）。然而，在用户的服务级别或在所有移动网络中可能不支持UE对专用承载和QCI的请求。
These effects and potential alternative solutions have been discussed at the accord BoF [ACCORD] at IETF 95.
这些影响和潜在的替代解决方案已在IETF 95的雅阁转炉[雅阁]上进行了讨论。
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，并可能隐藏重复的ACK（参见[RFC3135]第2.1.1节和[Middlebox]第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.
应用程序类型感知的网络边缘（middlebox）可以进一步控制速度、限制同步高清视频、或根据新视频对活动视频进行优先级排序等。这种更精细级别的服务受到加密使用的限制。
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.
通过分析用户流及其提供的应用程序，可以增强某些Internet服务的功能和效率。例如，在靠近请求用户的位置对流行内容进行网络缓存可以提高交付效率（在降低请求响应时间和在内容位于远程位置时减少使用国际互联网上的链接方面），服务提供商通过代表其行事的授权协议，将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
缓存中的内容复制（例如，受数字版权管理（DRM）保护的实时视频和内容）用于最有效地利用可用的有限带宽，从而最大化用户的体验质量（QoE）。特别是在移动网络中，通过传输网络复制每个流会增加直播电视的回程成本。3GPP增强型多媒体广播/多播服务（eMBMS）利用受信任的边缘代理来促进向不同用户传送相同的流，根据用户的信道条件使用单播或多播。目前正在努力支持运营商网络内的多播，同时保持端到端的安全性：自动多播
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.
例如，隧道传输（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部署可以使用分类器将流量定向到VLAN，而不是使用RFC 8300[RFC8300]中定义的网络服务报头（NSH）。如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).
微流：应用程序到应用程序的数据包流的单个实例，由源地址、目标地址、协议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
在移动网络中，内容过滤通常发生在核心网络中。对于其他网络，内容过滤可能发生在核心网络或边缘。安装了一个代理，用于分析用户正在查看的内容的传输元数据，并根据站点黑名单或用户预定义的配置文件（例如，对于年龄敏感的内容）过滤内容。尽管过滤可以通过许多方法完成，但一种常用方法涉及基于代理的触发器，该代理识别出现在操作员使用的黑名单上的URL中主机名的DNS查找。这个
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.
对该域的后续请求将被重新路由到一个代理，该代理将检查完整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.
获准访问网络是请求Internet流量的先决条件。
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]描述了一种可行的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的目的是改善连通性。然而，IETF最佳通用实践建议关闭基于UDP协议的ALG[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的一个示例针对使用实时流协议（RTSP）[RFC7826]主流作为在设置时识别相关RTP/RTCP[RFC3550]流的手段的视频应用。在这种情况下，ALG依赖于从RTSP派生的5元组流信息来提供NAT或其他中间盒并提供连接。实现方式各不相同，下面有两个示例：
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流上协商，这对媒体流更具侵入性。
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节）向第三方或其内部系统提供有关其客户的信息。第三方将插入的信息用于分析、定制、广告、用户跨站点跟踪、客户计费，或选择性地允许或阻止内容。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
在用于提供托管服务的覆盖网络（例如，虚拟可扩展局域网（VXLAN）、Geneve等）中，客户支持应用程序管理的管理访问可能取决于覆盖网络中可用的安全机制。虽然覆盖网络数据封装可用于指示所需的隔离，但这不足以防止意识到覆盖网络使用的蓄意攻击。[GENEVE-REQS]描述了处理攻击的要求。可以将覆盖报头与IPsec或其他加密通信会话结合使用，但这增加了对身份验证基础设施的要求，并可能降低数据包传输性能。覆盖报头的使用也可以被部署为网络服务提供商管理网络上的加密业务流的机制。对于覆盖封装，正在研究提供完整性和/或隐私保护的其他扩展机制。[RFC7348]的第7节描述了一些
the security issues possible when deploying VXLAN on Layer 2 networks. Rogue endpoints can join the multicast groups that carry broadcast traffic, for example.
在第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元组。IP级加密，如隧道模式下的IPsec，阻止访问原始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卸载的形式终止与Internet之间的会话。这不仅减少了应用程序服务器上的负载，还简化了流程，以便能够监视会话内容。
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.
但是，在某些情况下，可能需要在数据中心进行更深入的加密，以保护个人信息或满足行业法规，例如支付卡行业（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
在其他情况下，托管应用程序可能完全由托管服务提供商进行管理，并具有可用性和性能以及安全功能（包括恶意软件检测）的SLA预期。由于这些托管环境的敏感性，加密的使用已经非常普遍。任何影响都可能被忽略
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.
类似于企业，在托管环境中使用工具来监控流量。捐款呼吁中没有报告其他关切。
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.
托管环境的数据存储加密趋势包括一系列选项。下面的列表是为了说明与远程托管的数据存储协同使用的加密类型，这意味着存储物理上位于需要通过Internet传输的外部数据中心中。监控选项将根据下面描述的每种加密方法而有所不同。在大多数情况下，已经确定了提供加密的解决方案，同时确保通过日志记录或其他方式维护管理功能。
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
存储服务还包括数据复制，这可能发生在数据中心之间，并可能利用Internet连接来传输流量。流量可以使用Internet小型计算机系统接口（iSCSI）[RFC7143]或封装在IPsec中的TCP/IP光纤通道（FCIP）[RFC7146]。根据IPsec的终止点，IPsec可以使用传输模式或隧道模式
session, if it is from the storage platform itself or from a gateway device at the edge of the data center, respectively.
会话，如果分别来自存储平台本身或数据中心边缘的网关设备。
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节的小节讨论了在数据链路、网络和传输级头之外访问数据的技术，这些头通常用于服务提供商网络，因为企业拥有这些数据。这些职责分为三个基本领域：
1. Security Monitoring and Control
1. 安全监控
2. Application-Performance Monitoring and Reporting
2. 应用程序性能监视和报告
3. Network Diagnostics and Troubleshooting
3. 网络诊断和故障排除
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.
在上述每个领域，技术支持团队都利用收集、监控和诊断系统。一些组织目前使用复制的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. 检测通过电子邮件或网络流量进入网络的病毒/恶意软件，
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. 检测并防御互联网DDoS攻击，包括容量攻击和第7层攻击。
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:
监测有两个主要目标：
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跟踪应用程序响应时间，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]
监控用户感知响应时间以及将网络时间与服务器时间分离的新方法正在发展。例如，性能和诊断指标（PDM）[RFC8250]的IPv6目标选项头（DOH）实现将提供这一点。使用带有IPsec封装安全有效负载（ESP）传输模式的PDM需要将PDM DOH放置在ESP加密的有效负载中，以避免泄漏可能对攻击者有用的时间和序列号信息。如[RFC8250]第4节所述，PDM DOH的使用还可能引入一些安全弱点，包括定时攻击。出于这些和其他原因，[RFC8250]
requires that the PDM DOH option be explicitly turned on by administrative action in each host where this measurement feature will be used.
要求在使用此测量功能的每个主机中通过管理操作显式打开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.
网络故障排除的一个主要关键是能够通过应用程序的各个层跟踪事务，以隔离容错域。与现代数据中心和多层应用程序的结构相关的各种因素使得在没有能力检查某些数据包负载的情况下，很难在网络跟踪中跟踪事务。替代方法，如日志分析，需要改进以填补这一空白。
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。防火墙、负载平衡器、web服务器、应用服务器和中间件服务器都定期NAT数据包的源IP。再加上负载平衡器通常会将用户随机分配到所有这些设备，而且在当今的环境中，由于应用程序中的日志记录实现较差，网络故障排除程序通常只有很少的选项。因此，网络故障排除用于跟踪特定层上的数据包，解密数据包，并查看有效负载以找到用户会话。
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
如今，主要由中间件使用的TCP管道/会话多路复用允许多个最终用户会话共享同一TCP连接。随着加密使用的增加，这引起了几个关注点。当使用TLS或TCPcrypt时，TCP会话多路复用应该仍然是可能的，因为TCP头信息是公开的，使得5元组可以访问。TCP会话的使用
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.
IP层加密（例如IPsec）的多路复用仅公开2元组是不可能的。使用来自中间盒的加密会话进行故障排除的功能可能会将故障排除限制为使用来自执行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工具在Internet网关或代理服务处拦截流量，并能够MITM加密会话流量（HTTP/TLS）。这些工具可以监控对企业重要的关键词，包括商业机密、财务数据、PII或PHI等商业敏感信息。各种技术用于拦截用于DLP和其他目的的HTTP/TLS会话，并可被误用，如“总结对传输层安全性（TLS）和数据报TLS（DTL）的已知攻击”[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
网络过滤设备有时只允许访问网络过滤服务公司最后一次检查时发现的合法且无恶意软件的知名网站。在公司环境中，一个常见的web过滤示例是为了阻止恶意软件而阻止对这些工具不熟悉的站点的访问；对于那些无法访问同事个人网站或尚未筛选的新网站的研究人员来说，这可能是显而易见的。在需要访问新站点的情况下，通常可以在用户通知或记录警报和审查后添加这些站点。在公司设置中，个人邮件的帐户访问可能会被阻止，以防止另一个恶意软件载体进入，并防止知识产权从网络中泄露出去。随着加密使用的增加，此方法仍能发挥作用，并且可能更有效地防止恶意软件进入网络。一些企业在过滤和监控策略方面可能更激进，导致不良结果。Web筛选解决方案基于目标URL（如果可用）、服务器名称、IP地址或DNS名称监视并可能限制访问。如果特定网站上的内容或特定服务器上托管的网站的访问限制不同，则可以使用完整的URL。在某些情况下，企业可能会根据其策略使用代理来访问这些附加信息。这种类型的限制旨在对网络中的用户透明
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筛选器用于监视和执行的机制可能会导致访问问题或其他用户可见的故障。
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工具也用于某些公司环境。由于这些工具驻留在桌面上，因此它们可以在对流量进行加密之前拦截流量，并且可以提供一种持续的方法来监控从桌面到Internet或连接设备的知识产权泄漏。
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.
企业可能希望通过监视策略内内容的请求并对其进行缓存来减少其Internet访问设施上的流量。在这种情况下，可以在企业网络中提供由电子邮件交易时事通讯或其他来源中的URL生成的对Internet内容的重复请求。逐渐部署端到端加密会随着时间的推移减少可缓存内容，这是因为隐藏了关键标头和有效负载。许多形式的企业绩效管理也可能受到类似的影响。应该注意的是，透明缓存被认为是一种反模式。
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.
加密会话中的恶意流量。下一节将介绍一些成功检测和缓解此类流量的示例。
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[RFC5965][RFC6430][RFC6590][RFC6591][RFC6650][RFC6651][RFC6652]标准化的滥用报告格式（ARF）代理的大型提供商的持续邮件滥用。ARF代理直接向适当的服务提供商报告滥用消息，该服务提供商可以采取措施阻止或缓解滥用。由于此技术使用实际的消息，因此在邮件网关之间通过TLS使用SMTP不会影响其用途。如前所述，TLS上的SMTP仅在传输过程中保护数据，如果未使用用户对用户的加密方法，则邮件可能会在邮件服务器或邮件网关上公开。当前电子邮件上的用户对用户消息加密方法（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开放威胁信号（DOTS）[DOTS]工作组正在开发的文件中描述了用于监测DDoS流量的数据类型。加密的影响可以从其记录的用例[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
在服务提供商社区的多个成员的帮助下，DDoS攻击中使用的数据类型已在事件对象描述交换格式（IODEF）指导文件（见[RFC8274]，附录B.2）中详细说明。所提供的示例旨在
help identify the useful data in detecting and mitigating these attacks independent of the transport and protocol descriptions in the documents.
帮助识别用于检测和缓解这些攻击的有用数据，而不依赖于文档中的传输和协议描述。
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.
管理员通常会发现，使用标题信息来跟踪邮件队列或用户收件箱中的类似邮件，以防止进一步感染，这很有帮助。为此，可能会使用收件人：、发件人：、主题：、接收到的发件人标头信息的组合。管理员还可以搜索相同名称或大小的文档附件，或包含与已知网络钓鱼攻击具有匹配哈希的文件的文档附件。管理员还可以将邮件中包含的URL添加到本地阻止列表中，或者这也可以由浏览器供应商通过反钓鱼工作组（APWG）等更大规模的工作来完成。请参阅“互联网规模（CARIS）协调攻击响应研讨会报告”[RFC8073]，以了解APWG在反钓鱼方面的更多信息和指示。
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中可以找到钓鱼攻击事件响应中使用的字段的完整列表。如果某些电子邮件标题字段（如收件人：、发件人：、主题：标题字段）被加密，未来增加隐私保护的计划可能会限制其中一些功能。这并不意味着这些字段不应该被加密，只是我们应该知道它们当前是如何使用的。
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]中使用网络入口过滤，并使用单播反向路径转发（uRPF）机制[RFC3704]。但uRPF在粒度方面受到限制：恶意节点仍然可以使用分配给其链接的前缀中包含的伪造IP地址。源地址验证改进（SAVI）机制试图解决这个问题。基本上，SAVI机制基于对特定地址分配/管理协议（例如，无状态地址自动配置（SLAAC）[RFC4862]、安全邻居发现（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）的概述，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]提供了各种信息元素[IPFIX-IANA]，用于表示传统网络层流信息之上和之下的信息。特定于企业的IEs允许出口商供应商定义自己的非标准IEs，其中许多IEs由计量过程中的收割台和有效负载检查驱动。
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头分析变得不可能，因此无法导出从头派生的IEs（例如，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
当启动TLS握手时，客户机可能会提供一个扩展字段（服务器名称），该字段指示其正尝试安全连接的服务器。TLS SNI于2003年标准化，使服务器能够在部署由同一服务器托管的多个虚拟服务器时向客户端提供“正确的TLS证书”
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).
基础设施和IP地址。尽管这是一个可选的扩展，但现在所有现代浏览器、web服务器和开发人员库都支持它。Akamai[Nygren]报告称，他们的许多客户看到客户端TLS SNI使用率超过99%。应该注意的是，HTTP/2引入了Alt SVC方法，用于将连接从HTTP/1升级到未加密或加密的HTTP/2。如果初始HTTP/1请求未加密，则在可能将通信升级到加密的HTTP/2传输之前，可以识别目标备用服务名称。HTTP/2要求TLS实现支持SNI扩展（见[RFC7540]第9.2节）。还值得注意的是，[RFC7838]“允许源服务器指定在网络上与其交互的其他方式”，而[RFC8164]允许通过HTTP/2和TLS使用机会主义安全访问URI（在实验基础上）。
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标准的可选部分，如上所述，所有主要浏览器都实现了这一点。但是，由于其可选性，检查TLS ClientHello以获取SNI扩展的现有网络过滤器不能总是找到一个。“通过隧道在TLS中进行SNI加密”[SNI-TLS]已被TLS工作组采用，该工作组提供加密SNI的解决方案。因此，在TLS的未来版本中将有一个加密SNI的选项。SNI的每个域性质可能不会透露所访问的特定服务或媒体类型，特别是当该域是提供一系列电子邮件、视频、网页等的提供商时。例如，某些博客或社交网络提要可能被视为“成人内容”，但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]定义了原始帧，[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中以明文形式发送，服务器在tls1.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]）可以通过一个连接合并多个应用程序流，这使得比特率/速度不再是特定于应用程序的。此外，HTTP/2、TLS1.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. 在无线移动网络中，每个用户和扇区的延迟和信道容量因覆盖、争用、用户移动性、调度平衡、公平性、容量和服务质量而变化。如果大多数用户位于小区边缘，则控制器不能使用更复杂的正交幅度调制（QAM），从而降低总小区容量；类似地，如果通用移动通信系统（UMTS）边缘正在服务某些数量的CS语音呼叫，则分组服务的剩余容量减小。
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）回送其流量，然后通过运营商A（用户的家庭运营商）的P-Gateway（PGW）、通用分组无线业务（GPRS）支持节点（GGSN）、CDN等为入站漫游者（运营商B的外部网络中运营商A的用户）提供服务. 增加窗口大小以补偿路径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
3. 在无线接入网络（RAN）中部署CDN的问题包括减少客户机-服务器控制循环，这需要部署CDN/云功能，在更靠近边缘的地方终止加密。在蜂窝RAN中，用户IP流量被封装到
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.
GPRS隧道协议用户平面（UMTS和LTE中的GTP-U）隧道用于处理用户移动性；隧道终止于位于中心位置的APN/GGSN/PGW。一个用户的流量可流经一个或多个APN（例如，互联网APN、运营商X的漫游APN、视频服务APN、OnDeckAPN等）。运营商专用IP地址的范围可能仅限于特定的APN。由于CDN通常在用户IP流上运行，因此部署CDN需要通过隧道转换、隧道管理功能等对其进行增强。
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数据”，在2017年11月IETF 100上TLS工作组的演示<https://datatracker.ietf.org/meeting/100/materials/ 幻灯片-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/ 被动_2016_dataset.xml>。
[DarkMail] "Dark Mail Technical Alliance", <https://darkmail.info/>.
[DarkMail]“暗邮技术联盟”<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.Nishizuka，“DDOS开放威胁信号的用例”，正在进行中，草稿-ietf-dots-Use-cases-162018年7月。
[DOTS] IETF, "DDoS Open Threat Signaling (dots)", <https://datatracker.ietf.org/wg/dots/charter>.
[DOTS]IETF，“DDoS开放威胁信号（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降级攻击>。
[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.
[Enrich]Narseo Vallina Rodriguez，N.，Sundaresan，S.，Kreibich，C.，和V.Paxson，“标题充实或ISP充实：移动网络中新出现的隐私威胁”，ACM SIGCOMM关于中间盒和网络功能虚拟化热门话题研讨会论文集，第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协议安全要求”，正在进行的工作，草稿-mglt-nvo3-GENEVE-Security-Requirements-032018年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中的二级证书认证”，正在进行的工作，草稿-ietf-httpbis-HTTP2-Secondary-CERTS-022018年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.，“国家情报机构监督和透明度的10项标准”，监视，第8卷，第3期，2016年7月<http://jnslp.com/?s=10+标准+用于+Ov ersight+和+National>的+Transparency+。
[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.
[middlebox]Dolson，D.，Snellman，J.，Boucadair，M.，和C.Jacquenet，“由middlebox提供的以运输为中心的功能清单”，在建工程，draft-Dolson-Transport-middlebox-032018年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.“实现通用TLS SNI”，Akamai Technologies，2017年3月<https://blogs.akamai.com/2017/03/ 走向通用tls sni.html>。
[QUIC] IETF, "QUIC (quic)", <https://datatracker.ietf.org/wg/quic/charter/>.
[QUIC]IETF，“QUIC（QUIC）”<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中间包实验的初步数据”，发送给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，“超文本传输协议——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.，Ed.，“互联网的架构原则”，RFC 1958，DOI 10.17487/RFC19581996年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.，“动态主机配置协议”，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]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6报头中区分服务字段（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.，“互联网透明度”，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]Ferguson，P.和D.Senie，“网络入口过滤：击败利用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，2001年6月<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.，和M.Carney，“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：实时应用的传输协议”，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]Baker，F.和P.Savola，“多宿网络的入口过滤”，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 3724DOI 10.17487/RFC37242004年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.，Ed.，“Cisco Systems NetFlow服务导出版本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，“安全邻居发现（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]Audet，F.，Ed.和C.Jennings，“单播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无状态地址自动配置”，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，“IP流信息导出（IPFIX）文件格式规范”，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 Liue，“康卡斯特的网络通知系统设计”，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流匿名化支持”，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.，Ed.，Boucadair，M.，Durand，A.，Levis，P.，和P.Roberts，“IP地址共享问题”，RFC 6269，DOI 10.17487/RFC62692011年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，“电子邮件反馈报告类型值：非垃圾邮件”，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，“WebSocket协议”，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]Falk，J.，Ed.和M.Kucherawy，Ed.，“邮件滥用报告中潜在敏感数据的编校”，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.，“使用滥用报告格式的认证失败报告”，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.，“用于故障报告的域密钥识别邮件（DKIM）扩展”，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.，“使用滥用报告格式的发送方策略框架（SPF）身份验证失败报告”，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.，Ed.，Trammell，B.，Ed.，和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]Claise，B.，Ed.和B.Trammell，Ed.，“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]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，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.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：缓存”，RFC 7234，DOI 10.17487/RFC72342014年6月<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，“普遍监控是一种攻击”，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，“虚拟可扩展局域网（VXLAN）：在第3层网络上覆盖虚拟化第2层网络的框架”，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，Ed.，“基于域的消息验证、报告和一致性（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]Quinn，P.，Ed.和T.Nadeau，Ed.，“服务功能链接的问题陈述”，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，“安全使用传输层安全性（TLS）和数据报传输层安全性（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.，Paon，R.，和M.Thomson，编辑，“超文本传输协议版本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）中的空身份验证方法”，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，“面对普遍监视的保密性：威胁模型和问题陈述”，RFC 7624，DOI 10.17487/RFC76242015年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，Ed.，“服务功能链（SFC）架构”，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，“互联网服务阻塞和过滤的技术考虑”，RFC 7754，DOI 10.17487/RFC7754，2016年3月<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]Morton，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.Stiemering，Ed.，“实时流协议版本2.0”，RFC 7826，DOI 10.17487/RFC78262016年12月<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.，McManus，P.，和J.Reschke，“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传输层安全规范（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]Moriarty，K.和M.Ford，“互联网规模（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]北埃尔金斯、右汉密尔顿和M.阿克曼，“IPv6性能和诊断指标（PDM）目标选项”，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，“事件对象描述交换格式使用指南”，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.，和C.Pignataro，Ed.，“网络服务头（NSH）”，RFC 8300，DOI 10.17487/RFC8300，2018年1月<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.尼格伦，“原始HTTP/2框架”，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加密的问题和要求”，正在进行的工作，草稿-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>.
[Snowden]Verble，J.，“国家安全局和爱德华·斯诺登：21世纪的监控”，SIGCAS计算机与社会，第44卷，第3期，DOI 10.1145/2684097.2684101，2014年9月<http://www.jjsylvia.com/bigdatacourse/wp-content/ 上传/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，“用户平面拥塞管理”，3GPP Rel-132014年9月<http://www.3gpp.org/DynaReport/ 特性studyitemfile-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.，和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.
感谢我们的评论员娜塔莎·鲁尼、凯文·史密斯、阿什图什·杜塔、布兰登·威廉姆斯、让·米歇尔·库姆斯、纳利尼·埃尔金斯、保罗·巴雷特、巴德里·苏布拉曼扬、伊戈尔·卢巴舍夫、苏雷什·克里希南、戴夫·多尔森、穆罕默德·布卡达尔、斯蒂芬·法雷尔、沃伦·库马里、艾莉亚·阿特拉斯、罗曼·达尼尔、米娅·库勒温德、伊内斯·罗伯斯、乔·克拉克、凯尔·罗斯、，Christian Huitema和Chris Morrow感谢他们的编辑和内容建议。Surya K.Kovali为第7节提供了材料。Chris Morrow和Nik Teague提供了DoS指纹文本的评论和更新。Brian Trammell提供了IPFIX文本。
Authors' Addresses
作者地址
Kathleen Moriarty (editor) Dell EMC 176 South St Hopkinton, MA United States of America
Kathleen Moriarty（编辑）戴尔EMC 176美国马萨诸塞州南霍普金顿
Email: Kathleen.Moriarty@dell.com
Email: Kathleen.Moriarty@dell.com
Al Morton (editor) AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 United States of America
美国新泽西州劳雷尔大道南米德尔顿200号AT&T实验室Al Morton（编辑）07748
Phone: +1 732 420 1571
Fax: +1 732 368 1192
Email: acm@research.att.com
Phone: +1 732 420 1571
Fax: +1 732 368 1192
Email: acm@research.att.com