doc: Add RFC documents

1 files changed, 2971 insertions, 0 deletions

diff --git a/doc/rfc/rfc8404.txt b/doc/rfc/rfc8404.txt
new file mode 100644
index 0000000..f18e786
--- /dev/null
+++ b/doc/rfc/rfc8404.txt
@@ -0,0 +1,2971 @@
+
+
+
+
+
+
+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.
+
+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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moriarty & Morton             Informational                     [Page 1]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+Copyright Notice
+
+   Copyright (c) 2018 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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.
+
+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
+
+
+
+Moriarty & Morton             Informational                     [Page 2]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+       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
+
+1.  Introduction
+
+   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.
+
+   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
+
+
+
+Moriarty & Morton             Informational                     [Page 3]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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].
+
+   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.
+
+   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.
+
+
+
+
+
+Moriarty & Morton             Informational                     [Page 4]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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.
+
+1.1.  Additional Background on Encryption Changes
+
+   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.
+
+   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.
+
+
+
+
+
+Moriarty & Morton             Informational                     [Page 5]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+
+Moriarty & Morton             Informational                     [Page 6]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+1.2.  Examples of Attempts to Preserve Functions
+
+   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.
+
+   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.
+
+
+
+Moriarty & Morton             Informational                     [Page 7]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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.
+
+2.  Network Service Provider Monitoring Practices
+
+   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).
+
+   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.
+
+2.1.  Passive Monitoring
+
+2.1.1.  Traffic Surveys
+
+   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.
+
+   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
+
+
+
+Moriarty & Morton             Informational                     [Page 8]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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.
+
+2.1.2.  Troubleshooting
+
+   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.
+
+   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.
+
+   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
+
+
+
+
+
+Moriarty & Morton             Informational                     [Page 9]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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.
+
+   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.
+
+   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.
+
+   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
+
+
+
+Moriarty & Morton             Informational                    [Page 10]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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.
+
+   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.
+
+2.1.3.  Traffic-Analysis Fingerprinting
+
+   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.
+
+
+
+Moriarty & Morton             Informational                    [Page 11]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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.
+
+   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.
+
+2.2.  Traffic Optimization and Management
+
+2.2.1.  Load Balancers
+
+   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.
+
+   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
+
+
+
+Moriarty & Morton             Informational                    [Page 12]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+
+
+Moriarty & Morton             Informational                    [Page 13]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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.
+
+   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.
+
+   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.
+
+2.2.2.  Differential Treatment Based on Deep Packet Inspection (DPI)
+
+   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
+
+
+
+Moriarty & Morton             Informational                    [Page 14]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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.
+
+   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.
+
+   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.
+
+   These effects and potential alternative solutions have been discussed
+   at the accord BoF [ACCORD] at 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.
+
+
+
+
+
+
+Moriarty & Morton             Informational                    [Page 15]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+2.2.3.  Network-Congestion Management
+
+   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.
+
+2.2.4.  Performance-Enhancing Proxies
+
+   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]).
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+Moriarty & Morton             Informational                    [Page 16]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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.
+
+2.2.5.  Caching and Content Replication near the Network Edge
+
+   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.
+
+   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.
+
+   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
+
+
+
+Moriarty & Morton             Informational                    [Page 17]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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.
+
+   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.
+
+2.2.6.  Content Compression
+
+   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.
+
+2.2.7.  Service Function Chaining
+
+   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:
+
+      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).
+
+
+
+Moriarty & Morton             Informational                    [Page 18]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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.
+
+   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.
+
+2.3.  Content Filtering, Network Access, and Accounting
+
+   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.
+
+2.3.1.  Content Filtering
+
+   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.
+
+   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
+
+
+
+Moriarty & Morton             Informational                    [Page 19]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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.
+
+   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).
+
+   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.
+
+2.3.2.  Network Access and Data Usage
+
+   Approved access to a network is a prerequisite to requests for
+   Internet traffic.
+
+   However, there are cases (beyond parental control) when a network
+   service provider currently redirects customer requests for content
+   (affecting content accessibility):
+
+   1.  The network service provider is performing the accounting and
+       billing for the content provider, and the customer has not (yet)
+       purchased the requested content.
+
+   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.
+
+
+
+
+
+Moriarty & Morton             Informational                    [Page 20]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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.
+
+   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.
+
+   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.
+
+2.3.3.  Application Layer Gateways (ALGs)
+
+   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].
+
+
+
+
+
+
+
+Moriarty & Morton             Informational                    [Page 21]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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:
+
+   1.  Parse the content of the RTSP stream and identify the 5-tuple of
+       the supporting streams as they are being negotiated.
+
+   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.
+
+   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.
+
+   The deployment of IPv6 may well reduce the need for NAT and the
+   corresponding requirement for ALGs.
+
+2.3.4.  HTTP Header Insertion
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+
+Moriarty & Morton             Informational                    [Page 22]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+3.  Encryption in Hosting and Application SP Environments
+
+   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.
+
+3.1.  Management-Access Security
+
+   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
+
+
+
+
+Moriarty & Morton             Informational                    [Page 23]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   the security issues possible when deploying VXLAN on Layer 2
+   networks.  Rogue endpoints can join the multicast groups that carry
+   broadcast traffic, for example.
+
+3.1.1.  Monitoring Customer Access
+
+   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:
+
+   2-tuple:  IP level with source and destination IP addresses alone, or
+
+   5-tuple:  IP and protocol level with a source IP address, destination
+      IP address, protocol number, source port number, and destination
+      port number.
+
+   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.
+
+3.1.2.  SP Content Monitoring of Applications
+
+   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.
+
+
+
+
+
+Moriarty & Morton             Informational                    [Page 24]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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.
+
+   Examples include:
+
+      - Network-Performance Monitoring / Application-Performance
+        Monitoring
+
+      - Intrusion defense/prevention systems
+
+      - Malware detection
+
+      - Fraud monitoring
+
+      - Application DDOS protection
+
+      - 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.
+
+   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.
+
+   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.
+
+
+
+Moriarty & Morton             Informational                    [Page 25]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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.
+
+   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.
+
+3.2.  Hosted Applications
+
+   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.
+
+   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
+
+
+
+Moriarty & Morton             Informational                    [Page 26]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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.
+
+3.2.1.  Monitoring Managed Applications
+
+   Performance, availability, and other aspects of an SLA are often
+   collected through passive monitoring.  For example:
+
+   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  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.
+
+   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).
+
+3.2.2.  Mail Service Providers
+
+   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.
+
+   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.
+
+
+
+
+Moriarty & Morton             Informational                    [Page 27]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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.
+
+3.3.  Data Storage
+
+   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.
+
+3.3.1.  Object-Level Encryption
+
+   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.
+
+   Impacts to monitoring may include access to content inspection for
+   data-leakage prevention and similar technologies, depending on their
+   placement in the network.
+
+
+
+
+
+
+Moriarty & Morton             Informational                    [Page 28]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+3.3.1.1.  Monitoring for Hosted Storage
+
+   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.
+
+3.3.2.  Disk Encryption, Data at Rest (DAR)
+
+   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.
+
+3.3.2.1.  Monitoring Session Flows for DAR Solutions
+
+   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.3.  Cross-Data-Center Replication Services
+
+   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
+
+
+
+Moriarty & Morton             Informational                    [Page 29]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   session, if it is from the storage platform itself or from a gateway
+   device at the edge of the data center, respectively.
+
+3.3.3.1.  Monitoring IPsec for Data Replication Services
+
+   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.
+
+4.  Encryption for Enterprises
+
+   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.
+
+   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).
+
+4.1.  Monitoring Practices of the Enterprise
+
+   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:
+
+   1.  Security Monitoring and Control
+
+   2.  Application-Performance Monitoring and Reporting
+
+   3.  Network Diagnostics and Troubleshooting
+
+
+
+Moriarty & Morton             Informational                    [Page 30]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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.
+
+   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.
+
+4.1.1.  Security Monitoring in the Enterprise
+
+   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),
+
+   2.  detect viruses/malware entering the network via email or web
+       traffic,
+
+   3.  detect malware/trojans in action, possibly connecting to remote
+       hosts,
+
+   4.  detect attacks (cross-site scripting and other common web-related
+       attacks),
+
+   5.  track misuse and abuse by employees,
+
+   6.  restrict the types of protocols permitted to/from the entire
+       corporate environment, and
+
+   7.  detect and defend against Internet DDoS attacks, including both
+       volumetric and Layer 7 attacks.
+
+   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.
+
+   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.
+
+
+
+Moriarty & Morton             Informational                    [Page 31]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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.
+
+4.1.2.  Monitoring Application Performance in the Enterprise
+
+   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.
+
+   2.  Assess performance in terms of application response time and
+       user-perceived response time.
+
+   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.
+
+   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]
+
+
+
+
+
+Moriarty & Morton             Informational                    [Page 32]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   requires that the PDM DOH option be explicitly turned on by
+   administrative action in each host where this measurement feature
+   will be used.
+
+4.1.3.  Diagnostics and Troubleshooting for Enterprise Networks
+
+   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.
+
+4.1.3.1.  Address Sharing (NAT)
+
+   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.
+
+   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.
+
+   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.
+
+4.1.3.2.  TCP Pipelining / Session Multiplexing
+
+   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
+
+
+
+Moriarty & Morton             Informational                    [Page 33]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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.
+
+   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.
+
+4.1.3.3.  HTTP Service Calls
+
+   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.
+
+4.1.3.4.  Application-Layer Data
+
+   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.
+
+4.2.  Techniques for Monitoring Internet-Session Traffic
+
+   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.
+
+
+
+Moriarty & Morton             Informational                    [Page 34]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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].
+
+   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
+
+
+
+Moriarty & Morton             Informational                    [Page 35]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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.
+
+   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 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.
+
+   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.
+
+5.  Security Monitoring for Specific Attack Types
+
+   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.
+
+   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
+
+
+
+Moriarty & Morton             Informational                    [Page 36]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   malicious traffic within encrypted sessions.  The following section
+   will note some examples where detection and mitigation of such
+   traffic has been successful.
+
+5.1.  Mail Abuse and Spam
+
+   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.
+
+   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.
+
+5.2.  Denial of Service
+
+   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.
+
+   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].
+
+   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
+
+
+
+Moriarty & Morton             Informational                    [Page 37]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   help identify the useful data in detecting and mitigating these
+   attacks independent of the transport and protocol descriptions in the
+   documents.
+
+5.3.  Phishing
+
+   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.
+
+   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.
+
+   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).
+
+
+
+
+Moriarty & Morton             Informational                    [Page 38]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+5.4.  Botnets
+
+   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.
+
+5.5.  Malware
+
+   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.
+
+   Data types used in malware investigations have been summarized in an
+   example of the IODEF Guidance document (see [RFC8274], Appendix B.3).
+
+5.6.  Spoofed-Source IP Address Protection
+
+   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.
+
+5.7.  Further Work
+
+   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.
+
+
+
+Moriarty & Morton             Informational                    [Page 39]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+6.  Application-Based Flow Information Visible to a Network
+
+   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.
+
+6.1.  IP Flow Information Export
+
+   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.
+
+   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.
+
+   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.
+
+6.2.  TLS Server Name Indication
+
+   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
+
+
+
+Moriarty & Morton             Informational                    [Page 40]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   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).
+
+   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.
+
+   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.
+
+6.3.  Application-Layer Protocol Negotiation (ALPN)
+
+   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.
+
+
+
+
+
+Moriarty & Morton             Informational                    [Page 41]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+6.4.  Content Length, Bitrate, and Pacing
+
+   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.
+
+7.  Effect of Encryption on the Evolution of Mobile Networks
+
+   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:
+
+   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.
+
+   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.
+
+   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
+
+
+
+Moriarty & Morton             Informational                    [Page 42]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+       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.
+
+   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.
+
+8.  Response to Increased Encryption and Looking Forward
+
+   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.
+
+9.  Security Considerations
+
+   There are no additional security considerations as this is a summary
+   and does not include a new protocol or functionality.
+
+
+
+
+
+Moriarty & Morton             Informational                    [Page 43]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+10.  IANA Considerations
+
+   This document has no IANA actions.
+
+11.  Informative References
+
+   [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>.
+
+   [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/>.
+
+   [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>.
+
+   [CAIDA]    CAIDA, "The CAIDA USCD Anonymized Internet Traces 2016
+              Dataset", <http://www.caida.org/data/passive/
+              passive_2016_dataset.xml>.
+
+   [DarkMail] "Dark Mail Technical Alliance", <https://darkmail.info/>.
+
+   [DDOS-USECASE]
+              Dobbins, R., Migault, D., Fouant, S., Moskowitz, R.,
+              Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS
+              Open Threat Signaling", Work in Progress, draft-ietf-dots-
+              use-cases-16, July 2018.
+
+   [DOTS]     IETF, "DDoS Open Threat Signaling (dots)",
+              <https://datatracker.ietf.org/wg/dots/charter>.
+
+   [EFF2014]  Hoffman-Andrews, J., "ISPs Removing Their Customers' Email
+              Encryption", November 2014,
+              <https://www.eff.org/deeplinks/2014/11/
+              starttls-downgrade-attacks>.
+
+   [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.
+
+
+
+
+Moriarty & Morton             Informational                    [Page 44]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   [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.
+
+   [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.
+
+   [IPFIX-IANA]
+              IANA, "IP Flow Information Export (IPFIX) Entities",
+              <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>.
+
+   [M3AAWG]   M3AAWG, "Messaging, Malware and Mobile Anti-Abuse Working
+              Group (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.
+
+   [Nygren]   Nygren, E., "Reaching toward Universal TLS SNI",
+              Akamai Technologies, March 2017,
+              <https://blogs.akamai.com/2017/03/
+              reaching-toward-universal-tls-sni.html>.
+
+   [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>.
+
+   [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>.
+
+
+
+
+
+Moriarty & Morton             Informational                    [Page 45]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   [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>.
+
+   [RFC1958]  Carpenter, B., Ed., "Architectural Principles of the
+              Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996,
+              <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>.
+
+   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
+              RFC 2131, DOI 10.17487/RFC2131, March 1997,
+              <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>.
+
+   [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>.
+
+   [RFC2775]  Carpenter, B., "Internet Transparency", RFC 2775,
+              DOI 10.17487/RFC2775, February 2000,
+              <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>.
+
+   [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>.
+
+   [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>.
+
+
+
+
+Moriarty & Morton             Informational                    [Page 46]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+
+
+Moriarty & Morton             Informational                    [Page 47]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol",
+              RFC 6455, DOI 10.17487/RFC6455, December 2011,
+              <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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+
+
+
+
+
+Moriarty & Morton             Informational                    [Page 48]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
+              Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
+              RFC 7234, DOI 10.17487/RFC7234, June 2014,
+              <https://www.rfc-editor.org/info/rfc7234>.
+
+   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
+              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
+              2014, <https://www.rfc-editor.org/info/rfc7258>.
+
+   [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>.
+
+   [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>.
+
+
+
+
+
+
+Moriarty & Morton             Informational                    [Page 49]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+
+
+
+Moriarty & Morton             Informational                    [Page 50]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [RFC8165]  Hardie, T., "Design Considerations for Metadata
+              Insertion", RFC 8165, DOI 10.17487/RFC8165, May 2017,
+              <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>.
+
+   [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>.
+
+   [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>.
+
+
+
+
+
+
+Moriarty & Morton             Informational                    [Page 51]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+   [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>.
+
+   [SACM]     IETF, "Security Automation and Continuous Monitoring
+              (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.
+
+   [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>.
+
+   [TCPcrypt]
+              IETF, "TCP Increased Security (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.
+
+   [UPCON]    3GPP, "User Plane Congestion Management", 3GPP Rel-13,
+              September 2014, <http://www.3gpp.org/DynaReport/
+              FeatureOrStudyItemFile-570029.htm>.
+
+   [UserData]
+              Durumeric, Z., Ma, Z., Springall, D., Barnes, R.,
+              Sullivan, N., Bursztein, E., Bailey, M., Alex Halderman,
+              J., and V. Paxson, "The Security Impact of HTTPS
+              Interception", Network and Distributed Systems Symposium,
+              February 2017,
+              <http://dx.doi.org/10.14722/ndss.2017.23456>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moriarty & Morton             Informational                    [Page 52]
+
+RFC 8404                  Effects of Encryption                July 2018
+
+
+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.
+
+Authors' Addresses
+
+   Kathleen Moriarty (editor)
+   Dell EMC
+   176 South St
+   Hopkinton, MA
+   United States of America
+
+   Email: Kathleen.Moriarty@dell.com
+
+
+   Al Morton (editor)
+   AT&T Labs
+   200 Laurel Avenue South
+   Middletown, NJ  07748
+   United States of America
+
+   Phone: +1 732 420 1571
+   Fax:   +1 732 368 1192
+   Email: acm@research.att.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moriarty & Morton             Informational                    [Page 53]
+