Skip to main content

Effects of Pervasive Encryption on Operators

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8404.
Authors Kathleen Moriarty , Al Morton
Last updated 2018-02-08 (Latest revision 2018-01-31)
RFC stream Internet Engineering Task Force (IETF)
Stream WG state (None)
Document shepherd Paul E. Hoffman
Shepherd write-up Show Last changed 2018-01-22
IESG IESG state Became RFC 8404 (Informational)
Consensus boilerplate Yes
Telechat date (None)
Has enough positions to pass.
Responsible AD Warren "Ace" Kumari
Send notices to "Paul Hoffman" <>,,
IANA IANA review state IANA OK - No Actions Needed
Network Working Group                                   K. Moriarty, Ed.
Internet-Draft                                                  Dell EMC
Intended status: Informational                            A. Morton, Ed.
Expires: August 4, 2018                                        AT&T Labs
                                                        January 31, 2018

              Effects of Pervasive Encryption on Operators


   Pervasive Monitoring (PM) attacks on the privacy of Internet users is
   of serious concern to both the user and the operator communities.
   RFC7258 discussed the critical need to protect users' privacy when
   developing IETF specifications and also recognized making networks
   unmanageable to mitigate PM is not an acceptable outcome, an
   appropriate balance is needed.  This document discusses current
   security and network operations and management practices that may be
   impacted by the shift to increased use of encryption to help guide
   protocol development in support of manageable, secure networks.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 4, 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
   ( in effect on the date of
   publication of this document.  Please review these documents

Moriarty & Morton        Expires August 4, 2018                 [Page 1]
Internet-Draft            Effect of Encryption              January 2018

   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  . . . . . . .   6
   2.  Network Service Provider Monitoring . . . . . . . . . . . . .   7
     2.1.  Passive Monitoring  . . . . . . . . . . . . . . . . . . .   7
       2.1.1.  Traffic Surveys . . . . . . . . . . . . . . . . . . .   7
       2.1.2.  Troubleshooting . . . . . . . . . . . . . . . . . . .   8
       2.1.3.  Traffic Analysis Fingerprinting . . . . . . . . . . .  10
     2.2.  Traffic Optimization and Management . . . . . . . . . . .  11
       2.2.1.  Load Balancers  . . . . . . . . . . . . . . . . . . .  11
       2.2.2.  Differential Treatment based on Deep Packet
               Inspection (DPI)  . . . . . . . . . . . . . . . . . .  13
       2.2.3.  Network Congestion Management . . . . . . . . . . . .  14
       2.2.4.  Performance-enhancing Proxies . . . . . . . . . . . .  14
       2.2.5.  Caching and Content Replication Near the Network Edge  15
       2.2.6.  Content Compression . . . . . . . . . . . . . . . . .  16
       2.2.7.  Service Function Chaining . . . . . . . . . . . . . .  16
     2.3.  Network Access and Accounting . . . . . . . . . . . . . .  17
       2.3.1.  Content Filtering . . . . . . . . . . . . . . . . . .  17
       2.3.2.  Network Access and Data Usage . . . . . . . . . . . .  18
       2.3.3.  Application Layer Gateways  . . . . . . . . . . . . .  19
       2.3.4.  HTTP Header Insertion . . . . . . . . . . . . . . . .  20
   3.  Encryption in Hosting SP Environments . . . . . . . . . . . .  20
     3.1.  Management Access Security  . . . . . . . . . . . . . . .  20
       3.1.1.  Customer Access Monitoring  . . . . . . . . . . . . .  21
       3.1.2.  SP Content Monitoring of Applications . . . . . . . .  22
     3.2.  Hosted Applications . . . . . . . . . . . . . . . . . . .  24
       3.2.1.  Monitoring Managed Applications . . . . . . . . . . .  24
       3.2.2.  Mail Service Providers  . . . . . . . . . . . . . . .  25
     3.3.  Data Storage  . . . . . . . . . . . . . . . . . . . . . .  25
       3.3.1.  Object-level Encryption . . . . . . . . . . . . . . .  25
       3.3.2.  Disk Encryption, Data at Rest . . . . . . . . . . . .  26
       3.3.3.  Cross Data Center Replication Services  . . . . . . .  27
   4.  Encryption for Enterprises  . . . . . . . . . . . . . . . . .  27
     4.1.  Monitoring Practices of the Enterprise  . . . . . . . . .  28
       4.1.1.  Security Monitoring in the Enterprise . . . . . . . .  28
       4.1.2.  Application Performance Monitoring in the Enterprise   29
       4.1.3.  Enterprise Network Diagnostics and Troubleshooting  .  30
     4.2.  Techniques for Monitoring Internet Session Traffic  . . .  32
   5.  Security Monitoring for Specific Attack Types . . . . . . . .  33

Moriarty & Morton        Expires August 4, 2018                 [Page 2]
Internet-Draft            Effect of Encryption              January 2018

     5.1.  Mail Abuse and SPAM . . . . . . . . . . . . . . . . . . .  33
     5.2.  Denial of Service . . . . . . . . . . . . . . . . . . . .  34
     5.3.  Phishing  . . . . . . . . . . . . . . . . . . . . . . . .  34
     5.4.  Botnets . . . . . . . . . . . . . . . . . . . . . . . . .  35
     5.5.  Malware . . . . . . . . . . . . . . . . . . . . . . . . .  35
     5.6.  Spoofed Source IP Address Protection  . . . . . . . . . .  36
     5.7.  Further work  . . . . . . . . . . . . . . . . . . . . . .  36
   6.  Application-based Flow Information Visible to a Network . . .  36
     6.1.  IP Flow Information Export  . . . . . . . . . . . . . . .  36
     6.2.  TLS Server Name Indication  . . . . . . . . . . . . . . .  37
     6.3.  Application Layer Protocol Negotiation (ALPN) . . . . . .  38
     6.4.  Content Length, BitRate and Pacing  . . . . . . . . . . .  38
   7.  Impact on Mobility Network Optimizations and New Services . .  38
     7.1.  Effect of Encrypted ACKs  . . . . . . . . . . . . . . . .  39
     7.2.  Effect of Encrypted Transport Headers . . . . . . . . . .  39
     7.3.  Effect of Encryption on New or Emerging Services  . . . .  39
     7.4.  Effect of Encryption on Mobile Network Evolution  . . . .  39
   8.  Response to Increased Encryption and Looking Forward  . . . .  40
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  41
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  41
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  41
   12. Informative References  . . . . . . . . . . . . . . . . . . .  41
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  49

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 (PM) is of serious concern to users, operators, and
   application providers.  RFC7258 discussed the critical need to
   protect users' privacy when developing IETF specifications and also
   recognized that making networks unmanageable to mitigate PM is not an
   acceptable outcome, but rather that 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
   concerns of the operational community as they transition to managing
   networks with less visibility.  The 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
   perspective or contradictory to previous IETF statements (e.g.,

Moriarty & Morton        Expires August 4, 2018                 [Page 3]
Internet-Draft            Effect of Encryption              January 2018

   [RFC1958], [RFC1984], [RFC2804]).  The following informational
   documents consider the end to end (e2e) architectural principle, 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 for 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 in an 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.

   This document refers to several different forms of service providers,
   distinguished with adjectives.  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 end-point in communications with
   the application user, and hosting service providers lease computing,
   storage, and communications systems in datacenters.  In practice,
   many companies perform two or more service provider roles, but may be
   historically associated with one.

   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.

Moriarty & Morton        Expires August 4, 2018                 [Page 4]
Internet-Draft            Effect of Encryption              January 2018

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, QUIC and others that are increasing in deployment
   usage.  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 pervassive 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.  Perspectives on encryption paradigms have shifted
   over time from always requiring unbreakable session encryption to
   allowing for the acceptance of risk profiles that include breakable
   session encryption that deployed more easily instead of no

   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 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 pervassive
   monitoring by increasing the cost to monitor, it is recognized that
   risk profiles for some applications require authenticated and secure
   session encryption as well to prevent 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.

   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 enhances the security

Moriarty & Morton        Expires August 4, 2018                 [Page 5]
Internet-Draft            Effect of Encryption              January 2018

   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] and have documented Best Practices for
   TLS and DTLS in [RFC7525] and have other documents in the queue.  The
   recommendations from these documents were were built upon for TLS 1.3
   to provide a more inherently secure end-to-end protocol.

   In addition to encrypted web site access (HTTP over TLS), there are
   other well-deployed application level transport encryption efforts
   such as mail transfer agent (MTA)-to-MTA session encryption transport
   for email (SMTP over TLS) and gateway-to-gateway for instant
   messaging (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 PGP for email
   and encryption (e.g.  Off-the-Record (OTR)) for XMPP are used by
   those interested to protect their data as it crosses intermediary
   servers, preventing the vulnerability described 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 draft does not attempt to specify responses or
   solutions to these impacts, but rather documents the current state.

1.2.  Examples of Attempts to Preserve Functions

   Following the Snowden [Snowden] revelations, application service
   providers responded by encrypting traffic between their data centers
   (IPsec) to prevent passive monitoring from taking place unbeknownst
   to them (Yahoo, Google, etc.).  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

Moriarty & Morton        Expires August 4, 2018                 [Page 6]
Internet-Draft            Effect of Encryption              January 2018

   integrity for protected data, but created a problem for some network
   management functions.  They 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

   The 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 clear text.
   In other cases, some service providers have relied on middleboxes
   having access to clear text for the purposes of load balancing,
   monitoring for attack traffic, meeting regulatory requirements, or
   for other purposes.  These middlebox implementations, whether
   performing functions 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 PM
   mitigation in [RFC7258] should be considered in solution work
   resulting from this document.

2.  Network Service Provider Monitoring

   Network Service Providers (SP) for this definition include the
   backbone Internet Service providers 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 each technique and 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 CAIDA studies [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.

Moriarty & Morton        Expires August 4, 2018                 [Page 7]
Internet-Draft            Effect of Encryption              January 2018

   Passive monitoring makes inferences about observed traffic using the
   maximal information available, and is subject to inaccuracies
   stemming from incomplete sampling (of packets in a stream) or loss
   due to monitoring system overload.  When encryption conceals more
   layers in each packet, reliance on pattern inferences and other
   heuristics grows, and accuracy suffers.  For example, the traffic
   patterns between server and browser are dependent on browser supplier
   and version, even when the sessions use the same server application
   (e.g., web e-mail access).  It remains to be seen whether more
   complex inferences can be mastered to produce the same monitoring

2.1.2.  Troubleshooting

   Network operators use packet captures and 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.  The protocol dissection is
   generally limited to supporting protocols (e.g., DNS, DHCP), network
   and transport (e.g., IP, TCP), and some higher layer protocols (e.g.,
   RTP, RTCP).

   Network operators are often the first ones called upon to investigate
   application problems (e.g., "my HD video is choppy").  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 is often 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.

   For example, by investigating packet loss (from TCP sequence and
   acknowledgement numbers), round-trip-time (from TCP timestamp options
   or application-layer transactions, e.g., DNS or HTTP response time),
   TCP receive-window size, packet corruption (from checksum
   verification), inefficient fragmentation, or application-layer
   problems, the operator can narrow the problem to a portion of the
   network, server overload, client or server misconfiguration, etc.
   Network operators may also be able to identify the presence of attack
   traffic as not conforming to the application the user claims to be

   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

Moriarty & Morton        Expires August 4, 2018                 [Page 8]
Internet-Draft            Effect of Encryption              January 2018

   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 VoIP traffic can be a predictor of future customer
   dissatisfaction (supported by metadata from the RTP/RTCP protocol )
   [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 using increased encryption, operators lose a source of data that
   may be used to debug user issues.  Because of this, application
   server operators using increased encryption might be called upon more
   frequently to assist with debugging and troubleshooting, and thus 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
   such monitoring activities without clear text access to the
   application layers of interest, but 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 and/or subscription rebates.
   Also, there may be more cases of user communication failures when the
   additional encryption processes are introduced (e.g., key management
   at large scale), leading to more customer service contacts and (at
   the same time) less information available to network operations
   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
   make-up of active services per user and per sector are not visible to

Moriarty & Morton        Expires August 4, 2018                 [Page 9]
Internet-Draft            Effect of Encryption              January 2018

   a server that provides Internet Access Point Names (APN), 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.

   Vendors must be aware that in order for operators to better
   troubleshoot and manage networks with increasing amounts of encrypted
   traffic, built-in diagnostics and serviceability must be enhanced to
   provide detailed logging and debugging capabilities that, when
   possible, can reveal cleartext network parameters.  In addition to
   traditional logging and debugging methods, packet tracing and
   inspection along the service path will provide operators the
   visibility to continue to diagnose problems reported both internally
   and by their customers.

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 clear text or 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.

   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 a new 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.  Many DoS mitigation systems
   perform this manner of passive monitoring.

Moriarty & Morton        Expires August 4, 2018                [Page 10]
Internet-Draft            Effect of Encryption              January 2018

   For example, browser fingerprints are comprised of many
   characteristics, including User Agent, HTTP Accept headers, browser
   plug-in details, screen size and color details, system fonts and time
   zone.  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, 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 rely on industry-accepted standards in interpreting the plainly
   observable information.  Typically, this is a 5-tuple of the
   connection.  This configuration terminates TLS sessions at the load
   balancer, making it the end point instead of the server.  Standalone
   load balancers are considered middleboxes, but 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
   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 chances of such
   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 multi-homed anycast-based
   services typically employed by large content owners and Content
   Distribution Networks (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

Moriarty & Morton        Expires August 4, 2018                [Page 11]
Internet-Draft            Effect of Encryption              January 2018

   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

   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 PM is important, while ensuring manageability of
   the network.

   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 scaleability 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 plain text information available in each incoming
   packet is able to provide stateless load balancing.  This ability
   confers great reliability and scaleability 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.

   Current protocols, such as TCP, allow the development of stateless
   integrated load balancers by availing such load balancers of
   additional plain text information in client-to-server packets.  In
   case of TCP, such information can be encoded by having server-
   generated sequence numbers (that are ACK'd 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.
   This method allows for tight control by one of the endpoints and can

Moriarty & Morton        Expires August 4, 2018                [Page 12]
Internet-Draft            Effect of Encryption              January 2018

   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.

   Mobile operators apply Self Organizing Networks (3GPP SON) for
   intelligent workflows such as content-aware MLB (Mobility Load
   Balancing).  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 to
   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
   alleviate this by queuing traffic according to its required bandwidth
   and acceptable latency: for example, a user is unlikely to notice a
   20ms delay when receiving a simple Web page or email, or an instant
   message response, but will very likely notice a re-buffering 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, and 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

Moriarty & Morton        Expires August 4, 2018                [Page 13]
Internet-Draft            Effect of Encryption              January 2018

   port 443", it cannot distinguish application streams that would
   benefit from priority queueing 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

   These effects and potential alternative solutions have been discussed
   at the accord BoF [ACCORD] at IETF95.

2.2.3.  Network Congestion Management

   For User Plane Congestion Management (3GPP UPCON) - ability to
   understand content and manage network during congestion.  Mitigating
   techniques such as deferred download, off-peak acceleration, and
   outbound roamers.

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 [I-D.dolson-plus-middlebox-benefits]).

   This optimization at network edges measurably 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, performance-enhancing proxies have a lower Round-Trip
   Time (RTT) to the client and therefore determine the responsiveness
   of flow control.  A lower RTT makes the flow control loop more
   responsive to changing in the mobile network conditions and enables

Moriarty & Morton        Expires August 4, 2018                [Page 14]
Internet-Draft            Effect of Encryption              January 2018

   faster adaptation in a delay and capacity varying network due to user

   Further, service-provider-operated proxies are used 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 un-wanted video packets from
   entering the radio scheduler queue.

   An application-type-aware network edge (middlebox) can further
   control pacing, limit simultaneous HD videos, or prioritize active
   videos against new videos, etc.

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
   International Internet links when content is remotely located), and
   authorized parties acting on their behalf use DPI in combination with
   content distribution networks to determine if they can intervene
   effectively.  Caching was first supported in [RFC1945] and continued
   in the recent update of "Hypertext Transfer Protocol (HTTP/1.1):
   Caching" in [RFC7234].  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 is a
   motivation outside of privacy and pervasive monitoring that are
   driving end-to-end encryption for these content providers.

   Content replication in caches (for example live video, Digital Rights
   Management (DRM) protected content) 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.  The Enhanced Multimedia Broadcast/
   Multicast Services (3GPP eMBMS) - trusted edge proxies facilitate
   delivering same stream to different users, using either unicast or
   multicast depending on channel conditions to the user.  There are on-
   going efforts to support multicast inside carrier networks while
   preserving end-to-end security: 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

Moriarty & Morton        Expires August 4, 2018                [Page 15]
Internet-Draft            Effect of Encryption              January 2018

   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; however, they still 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
   proxy, 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

   There is work in progress to specify protocols that permit Service
   Function Chaining (SFC).  SFC is the ordered steering and application
   of traffic in order to provide optimizations, and a Classifier
   [RFC7665] performs this function.  If the classifier's visibility is
   reduced from a 5-tuple to a 2-tuple, or if information above the
   transport layer becomes unaccessible, then the SFC Classifier will
   not be 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 -- but at the same time not making the network inoperable or

Moriarty & Morton        Expires August 4, 2018                [Page 16]
Internet-Draft            Effect of Encryption              January 2018

2.3.  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].

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 RFC7754 [RFC7754] for a survey of
   Internet filtering techniques and motivations.  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 are not addressed in this

   In a mobile network content filtering usually occurs in the core
   network.  A proxy is installed which analyses the transport metadata
   of the content users are viewing and either filters content based on
   a blacklist of sites or based on the user's pre-defined 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 which appears
   on a blacklist being used by the operator.  The subsequent requests
   to that domain will be re-routed to a proxy which checks whether the
   full URL matches a blocked URL on the list, and 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

   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.  Changes to TLSv1.3 do not
   impact this more invasive method of interception, where this has the

Moriarty & Morton        Expires August 4, 2018                [Page 17]
Internet-Draft            Effect of Encryption              January 2018

   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.  However, the lack of ability to efficiently manage
   endpoints as a service reduces providers' ability to offer parental

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.

   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 prevents mobile carriers
   from intercepting the traffic and performing an HTTP redirect.  As a
   result, some mobile carriers block customer's encrypted requests,
   which is a far less optimal 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, both an inconvenience
   to the customer and additional overhead to the mobile network service

   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

Moriarty & Morton        Expires August 4, 2018                [Page 18]
Internet-Draft            Effect of Encryption              January 2018

   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 user's service plans or current usage,
   and cannot warn the user of plan exhaustion.

   In addition, mobile network operator often 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.  This feature is impacted if encryption hides the details of
   the content domain from the network.

2.3.3.  Application Layer Gateways

   Application Layer Gateways (ALG) assist applications to set
   connectivity across Network Address Translators (NAT), 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.  ALG are
   deployed with an aim to improve connectivity.  However, it is an IETF
   Best Common Practice recommendation that ALGs for UDP-based protocols
   SHOULD be turned off [RFC4787].

   One example of an ALG in current use is aimed at video applications
   that use the Real Time Session Protocol (RTSP) [RFC7826] primary
   stream as a means to identify related Real Time Protocol/Real Time
   Control Protocol (RTP/RTCP) [RFC3550] flows at set-up.  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, and
   therefore they cannot provision their associated middelboxes with
   that information.

Moriarty & Morton        Expires August 4, 2018                [Page 19]
Internet-Draft            Effect of Encryption              January 2018

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,
   to bill the customer, or to selectively allow or block 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 users privacy, mobile network service providers cannot insert
   headers to accomplish the, sometimes considered controversial,
   functions above.

3.  Encryption in Hosting 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 only increased that
   pressure to provide more secure access and session encryption to
   protect the management of hosted environments as well as for 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 SP (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

   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.  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

Moriarty & Morton        Expires August 4, 2018                [Page 20]
Internet-Draft            Effect of Encryption              January 2018

   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. [draft-mglt-nvo3-geneve-security-
   requirements] describes requirements to handle attacks.  It is
   possible to use an overlay header in combination with IPsec or other
   encrypted traffic sessions, but this adds the requirement for
   authentication infrastructure and may reduce packet transfer
   performance.  The use of an overlay header may also be deployed as a
   mechanism to manage encrypted traffic streams on the network by
   network service providers.  Additional extension mechanisms to
   provide integrity and/or privacy protections are being investigated
   for overlay encapsulations.  Section 7 of [RFC7348] describes some of
   the security issues possible when deploying VXLAN on Layer 2
   networks.  Rogue endpoints can join the multicast groups that carry
   broadcast traffic, for example.

3.1.1.  Customer Access Monitoring

   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
   either through session monitoring or log evaluation to ensure
   security service level agreements (SLA) 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 an:

   2-tuple  IP-level with source and destination IP addresses alone, or

   5-tuple  IP and protocol-level with source IP address, destination IP
      address, protocol number, source port number, and destination port

   Session encryption at the application level, TLS for example,
   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

Moriarty & Morton        Expires August 4, 2018                [Page 21]
Internet-Draft            Effect of Encryption              January 2018

   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.

   Organizations responsible for the operation of a data center have
   many processes which 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

      - 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.

Moriarty & Morton        Expires August 4, 2018                [Page 22]
Internet-Draft            Effect of Encryption              January 2018

   These include SSL/TLS decryption in dedicated units, which then
   forward packets to SP-controlled tools, or by real-time or post-
   capture decryption in the tools themselves.  The use of tools that
   perform SSL/TLS decryption are impacted by the increased use of
   encryption that prevents interception.

   Data center operators may also maintain packet recordings in order to
   be able to investigate attacks, breach of internal processes, etc.
   In some industries, organizations may be legally required to maintain
   such information for compliance purposes.  Investigations of this
   nature have used access to the unencrypted contents of the packet.
   Alternate methods to investigate attacks or breach 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

   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 Payment Card Information (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 are still available on that endpoint.  However, when a gap
   exists in the application's logging and debugging capabilities, this
   has led the application service provider to access data-in-transport
   for monitoring and debugging.

Moriarty & Morton        Expires August 4, 2018                [Page 23]
Internet-Draft            Effect of Encryption              January 2018

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 service level agreement expectations for
   availability and performance as well as for security functions
   including malware detection.  Due to the sensitive nature of these
   hosted environments, the use of encryption is already prevalent.  Any
   impact may be similar to an enterprise with tools being used inside
   of the hosted environment to monitor traffic.  Additional concerns
   were not reported in the call for contributions.

3.2.1.  Monitoring Managed Applications

   Performance, availability, and other aspects of a SLA are often
   collected through passive monitoring.  For example:

   o  Availability: ability to establish connections with hosts to
      access applications, and discern the difference between network or
      host-related causes of unavailability.

   o  Performance: ability to complete transactions within a target
      response time, and discern the difference between network or host-
      related causes of excess response time.

   Here, as with all passive monitoring, the accuracy of inferences are
   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).

Moriarty & Morton        Expires August 4, 2018                [Page 24]
Internet-Draft            Effect of Encryption              January 2018

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], malware [Section 5.6],
   and phishing attacks [Section 5.3] before mail is directed to the
   organization's equipment.  In both of these cases, content of the
   messages and headers is monitored to detect SPAM, malware, phishing,
   and other messages that may be considered an attack.

   STARTTLS ought 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.

   Many efforts are emerging to improve user-to-user encryption,
   including promotion of PGP and newer efforts such as Dark Mail
   [DarkMail].  Of course, 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, solution 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 transport level.  Encryption of data may be performed with
   libraries on the system or at the application level, which includes

Moriarty & Morton        Expires August 4, 2018                [Page 25]
Internet-Draft            Effect of Encryption              January 2018

   file encryption services via a file manager.  Object-level encryption
   is useful when data storage is hosted, or scenarios when storage
   location is determined based on capacity or based on a set of
   parameters to automate decisions.  This could mean that large data
   sets 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 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.  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

   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 (SED).  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.  Monitoring Session Flows for Data at Rest (DAR) Solutions

   Monitoring for transport of data to storage platforms, where object
   level encryption is performed close to or on the storage platform are
   similar to those described in the section on Monitoring for Hosted
   Storage.  The primary difference for these solutions is the possible
   exposure of sensitive information, which could include privacy

Moriarty & Morton        Expires August 4, 2018                [Page 26]
Internet-Draft            Effect of Encryption              January 2018

   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 iSCSI [RFC7143] or FC/IP [RFC7146]
   encapsulated in IPsec.  Either transport or tunnel mode may be used
   for IPsec depending upon the termination points of the IPsec session,
   if it is from the storage platform itself or from a gateway device at
   the edge of the data center respectively.  Monitoring Of IPSec for Data Replication Services

   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 (VPN) 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 the "Monitoring for
   Hosted Storage Section".  If IPsec tunnel mode is in use, monitoring
   is limited to a 2-tuple, or with transport mode, 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

Moriarty & Morton        Expires August 4, 2018                [Page 27]
Internet-Draft            Effect of Encryption              January 2018

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.  These responsibilities
   break down into three basic areas:

   1.  Security Monitoring and Control

   2.  Application Performance Monitoring and Reporting

   3.  Network Diagnostics and Troubleshooting

   In each of the above areas, technical support teams utilize
   collection, monitoring, and diagnostic systems.  Some organizations
   currently use attack methods such as replicated TLS server RSA
   private keys to decrypt passively monitored copies of encrypted TLS
   packet streams.

   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

   3.  detect malware/Trojans in action, possibly connecting to remote

   4.  detect attacks (Cross site scripting and other common web related

   5.  track misuse and abuse by employees,

   6.  restrict the types of protocols permitted to/from the entire
       corporate environment,

Moriarty & Morton        Expires August 4, 2018                [Page 28]
Internet-Draft            Effect of Encryption              January 2018

   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, 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, logs,
   host-level transaction monitoring, and flow analysis would vary
   depening on access to a 2-tuple or 5-tuple in the network as well.

   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 permited with these alternate
   solutions.  Network endpoint assessment (NEA) or the use of virtual
   hosts could help to bridge the monitoring gap.

4.1.2.  Application Performance Monitoring 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.  Content
   Delivery Networks (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

Moriarty & Morton        Expires August 4, 2018                [Page 29]
Internet-Draft            Effect of Encryption              January 2018

   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) will provide this
   [I-D.ietf-ippm-6man-pdm-option].  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 7 of
   [I-D.ietf-ippm-6man-pdm-option].  For these and other reasons,
   [I-D.ietf-ippm-6man-pdm-option] 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.  Enterprise Network Diagnostics and Troubleshooting

   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.  Address Sharing (NAT)

   Content Delivery Networks (CDNs) and NATs and Network Address and
   Port Translators (NAPT) 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, 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.

Moriarty & Morton        Expires August 4, 2018                [Page 30]
Internet-Draft            Effect of Encryption              January 2018

   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.  TCP Pipelining/Session Multiplexing

   TCP Pipelining/Session Multiplexing used mainly by middleboxes today
   allow for multiple end user sessions to share the same TCP
   connection.  This rasises 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 TCP
   session multiplexing of an IP layer encyption, 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 end points 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; visibilty of packets once encrypted will hide the use of
   HTTP pipelining for any monitoring that takes place outside of the
   endpoint or proxy solution.  Since HTTP pipelining is between a
   client and server, logging capabilities may require improvement in
   some servers and clients for debugging purposes if this is not
   already possible.  Visibility for middleboxes includes anything
   exposed by TLS and the 5-tuple.  HTTP 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.  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

Moriarty & Morton        Expires August 4, 2018                [Page 31]
Internet-Draft            Effect of Encryption              January 2018

   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, but techniques like that of data leakage
   prevention tools at a proxy would not be possible if encrypted
   traffic cannot be intercepted, encouraging alternate options such as
   performing these functions at the edge.

   Some DLP tools intercept traffic at the Internet gateway or proxy
   services with the ability to man-in-the-middle (MiTM) encrypted
   session traffic (HTTP/TLS).  These tools may use key words important
   to the enterprise including business sensitive information such as
   trade secrets, financial data, personally identifiable information
   (PII), or personal health information (PHI).  Various techniques are
   used to intercept HTTP/TLS sessions for DLP and other purposes, and
   are described in "Summarizing Known Attacks on TLS and DTLS"
   [RFC7457].  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.

   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 proxies are sometimes used to filter traffic, allowing only
   access to well-known sites found to be legitimate and free of malware
   on last check by a proxy service company.  This type of restriction
   is usually not noticeable in a corporate setting as the typical
   corporate user does not access sites that are not well-known to these
   tools, but may be noticeable to those in research who are unable to
   access colleague's individual sites or new web sites 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
   proxy log alerts and review.  Home mail account access may be blocked
   in corporate settings to prevent another vector for malware to enter
   as well as for intellectual property to leak out of the network.
   This method remains functional with increased use of encryption and

Moriarty & Morton        Expires August 4, 2018                [Page 32]
Internet-Draft            Effect of Encryption              January 2018

   may be more effective at preventing malware from entering the
   network.  Web proxy solutions monitor and potentially restrict access
   based on the destination URL or the 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.

   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 of
   monitoring intellectual property leakage 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

   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 e-mail 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.

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.

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

Moriarty & Morton        Expires August 4, 2018                [Page 33]
Internet-Draft            Effect of Encryption              January 2018

   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], and [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 abuse mitigation efforts.

5.2.  Denial of Service

   Response to Denial of Service (DoS) attacks are typically coordinated
   by the SP 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
   DDoS Open Threat Signaling (DOTS) [DOTS] working group documents in

   Data types used in DDoS attacks have been detailed in the IODEF
   Guidance draft [I-D.ietf-mile-iodef-guidance], Appendix A.2, with the
   help of several members of the service provider community.  The
   examples provided are intended to help identify the useful data in
   detecting and mitigating these attacks independent of the transport
   and protocol descriptions in the drafts.

5.3.  Phishing

   Investigations and response 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 contains 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.

Moriarty & Morton        Expires August 4, 2018                [Page 34]
Internet-Draft            Effect of Encryption              January 2018

   Administrators often find it helpful to use header information to
   track down similar message in their mail queue or users inboxes to
   prevent further infection.  Combinations of To:, From:, Subject:,
   Received: from header information might be used for this purpose.
   Administrators may also search for document attachments of the same
   name, size, or containing 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 scales efforts like that of the Anti-Phishing
   Working Group (APWG).  See the 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 response
   can be found in RFC5901.  Future plans to increase privacy
   protections may limit some of these capabilities if some email header
   fields are encrypted, such as 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, clear-text 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 draft
   [I-D.ietf-mile-iodef-guidance], Appendix A.3.

5.4.  Botnets

   Botnet detection and mitigation is complex and may involve hundreds
   or thousands of hosts with numerous Command and Control (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

   Malware monitoring and detection techniques vary.  As mentioned in
   the enterprise section, 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.

Moriarty & Morton        Expires August 4, 2018                [Page 35]
Internet-Draft            Effect of Encryption              January 2018

   Data types used in malware investigations have been summarized in an
   example of the IODEF Guidance draft [I-D.ietf-mile-iodef-guidance],
   Appendix A.1.

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 BCP 38 [RFC2827]
   and the unicast Reverse Path Forwarding (uRPF) mechanism [RFC2504].
   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.  The Source Address Validation
   Improvements (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., SLAAC [RFC4862], SEND
   [RFC3971], DHCPv4/v6 [RFC2131][RFC3315]) and, according to this
   monitoring, set-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.

6.  Application-based Flow Information Visible to a Network

   This section describes specific techniques used in monitoring
   applications that is visible to the network if a 5-tuple is exposed
   and as such can potentially be used an input future network
   management approaches.  It also includes an overview of 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 Section 2.3.2, Section 3.1.1,
   Section 4.1.3, Section 4.2, and Section 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)

Moriarty & Morton        Expires August 4, 2018                [Page 36]
Internet-Draft            Effect of Encryption              January 2018

   [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 formerly 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 potentially business- and privacy-critical
   information.  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) which indicates the server to which it
   is attempting a secure connection.  TLS SNI was standardized in 2003
   to enable servers to present the "correct TLS certificate" to clients
   in a deployment of multiple virtual servers hosted by the same server
   infrastructure and IP-address.  Although this is an optional
   extension, it is today supported by all modern browsers, web servers
   and developer libraries.  Akamai [Nygren] reports that many of their
   customer 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 Server Name Indication (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 visible if the client is populating the
   Server Name Indication extension.  This need not be done, but may be
   done as per TLS standard and as stated above this has been

Moriarty & Morton        Expires August 4, 2018                [Page 37]
Internet-Draft            Effect of Encryption              January 2018

   implemented by all major browsers.  Therefore, even if existing
   network filters look out for seeing a Server Name Indication
   extension, they may not find one.  The SNI Encryption in TLS Through
   Tunneling [I-D.ietf-tls-sni-encryption] draft 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 Server Name Indication will only indicate the
   server domain rather than a URL path.

   There are additional issues for identification of content using SNI:
   [RFC7540] includes connection coalesing,
   [I-D.ietf-httpbis-origin-frame] defines the ORIGIN frame, and the
   [I-D.bishop-httpbis-http2-additional-certs] proposal will increase
   the difficulty of passive monitoring.

6.3.  Application Layer Protocol Negotiation (ALPN)

   ALPN is a TLS extension which 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 which may make up streams within an
   HTTP/2 multiplex.  ALPN is sent clear text in the ClientHello and the
   server returns it in Encrypted Extensions in TLS 1.3.

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 utilise 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) 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

7.  Impact on Mobility Network Optimizations and New Services

   This section should be deleted and 7.4 becomes section 7.  It is here
   as a placeholder for comparison to previous versions only.  The text
   has been integrated into Section 2.

Moriarty & Morton        Expires August 4, 2018                [Page 38]
Internet-Draft            Effect of Encryption              January 2018

7.1.  Effect of Encrypted ACKs

   This section should be deleted.  It is here as a placeholder for
   comparison to previous versions only.  The text has been integrated
   into Section 2.

7.2.  Effect of Encrypted Transport Headers

   This section should be deleted.  It is here as a placeholder for
   comparison to previous versions only.  The text has been integrated
   into Section 2.

7.3.  Effect of Encryption on New or Emerging Services

   This section should be deleted.  It is here as a placeholder for
   comparison to previous versions only.  The text has been integrated
   into Section 2.

7.4.  Effect of Encryption on Mobile Network Evolution

   The transport header encryption prevents trusted transit proxies.  It
   may be that the benefits of such proxies could be achieved by end to
   end client & server optimizations and distribution using CDNs, plus
   the ability to continue connections across different access
   technologies (across dynamic user IP addresses).  The following
   aspects need to 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, and scheduling balances fairness, capacity and service
       QoE.  If most users are at the cell edge, the controller cannot
       use more complex QAM, thus reducing total cell capacity;
       similarly if a UMTS edge is serving some number of CS-Voice
       Calls, the remaining capacity for packet services is reduced.

   2.  Roamers: Mobile wireless networks service in-bound roamers (Users
       of Operator A in a foreign operator Network B) by backhauling
       their traffic though Operator B's network to Operator A's Network
       and then serving through the P-Gateway (PGW), General GPRS
       Support Node (GGSN), Content Distribution Network (CDN) etc., of
       Operator A (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 RAN: Decreasing Client-Server control
       loop requires deploying CDNs/Cloud functions that terminate
       encryption closer to the edge.  In Cellular RAN, the user IP

Moriarty & Morton        Expires August 4, 2018                [Page 39]
Internet-Draft            Effect of Encryption              January 2018

       traffic is encapsulated into General Packet Radio Service (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 APN.
       Since CDNs generally operate on user IP flows, deploying them
       would require enhancing them with tunnel translation, etc.,
       tunnel management functions.

   4.  While CDNs that de-encrypt flows or split-connection proxy
       (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; thus content from some Small-Medium Businesses (SMBs)
       would not get such CDN benefits.

8.  Response to Increased Encryption and Looking Forward

   In the best case scenario, engineers and other innovators would work
   to solve the problems at hand in new ways rather than prevent the use
   of encryption.  As stated in [RFC7258], "an appropriate balance
   (between network management and PM mitigations) will emerge over time
   as real instances of this tension are considered."

   There has already been documented cases of service providers
   preventing STARTTLS [NoEncrypt] to prevent session encryption
   negotiation on some session to inject a super cookie.  In order to
   effectively deploy encryption and prevent interception,
   considerations for protocol design should factor in network
   management functions to work toward the balance called out in

   It is well known that national surveillance programs monitor traffic
   [JNSLP] as Internet security practitioners monitor for criminal
   activities.  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' identity, financial transactions and intellectual property,
   which requires security and encryption to prevent crime.  A clear
   understanding of technology, encryption, and monitoring goals will
   aid in the development of solutions to appropriately balance these
   with privacy.  As this understanding increases, hopefully the
   discussions will improve; this draft is meant to help further the

Moriarty & Morton        Expires August 4, 2018                [Page 40]
Internet-Draft            Effect of Encryption              January 2018

   Changes to improve encryption or to deploy OS methods have little
   impact on the detection of malicious actors; they already have access
   to strong encryption.  The current push to increase encryption is
   aimed at increasing users' privacy and providing application
   integrity.  There is already protection in place for purchases,
   financial transactions, systems management infrastructure, and
   intellectual property although this too can be improved.  The
   Opportunistic Security (OS) [RFC7435] efforts aim to increase the
   costs of monitoring through the use of encryption that can be subject
   to active attacks, but make passive monitoring broadly cost
   prohibitive.  This is meant to restrict monitoring to sessions where
   there is reason to have suspicion.

9.  Security Considerations

   There are no additional security considerations as this is a summary
   and does not include a new protocol or functionality.

10.  IANA Considerations

   This memo makes no requests of IANA.

11.  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 Kuhlewind, Ines Robles, Joe Clarke, and Kyle Rose 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.

12.  Informative References

   [ACCORD]   "Acord BoF IETF95

   [CAIDA]    "CAIDA *Anonymized Internet Traces*
              [ and

              "The Dark Mail Technical Aliance".

Moriarty & Morton        Expires August 4, 2018                [Page 41]
Internet-Draft            Effect of Encryption              January 2018

   [DOTS], "DDoS Open
              Threat Signaling IETF Working Group".

   [EFF]      "Electronic Frontier Foundation".

   [EFF2014]  "EFF Report on STARTTLS Downgrade Attacks

   [Enrich]   Narseo Vallina-Rodriguez, et al., "Header Enrichment or
              ISP Enrichment? Emerging Privacy Threats in Mobile
              Networks, Hot Middlebox'15, August 17-21 2015, London,
              United Kingdom", 2015.

              Bishop, M., Sullivan, N., and M. Thomson, "Secondary
              Certificate Authentication in HTTP/2", draft-bishop-
              httpbis-http2-additional-certs-05 (work in progress),
              October 2017.

              Dolson, D., Snellman, J., Boucadair, M., and C. Jacquenet,
              "Beneficial Functions of Middleboxes", draft-dolson-plus-
              middlebox-benefits-03 (work in progress), March 2017.

              Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame",
              draft-ietf-httpbis-origin-frame-06 (work in progress),
              January 2018.

              Elkins, N., Hamilton, R., and m.,
              "IPv6 Performance and Diagnostic Metrics (PDM) Destination
              Option", draft-ietf-ippm-6man-pdm-option-13 (work in
              progress), June 2017.

              Kampanakis, P. and M. Suzuki, "Incident Object Description
              Exchange Format Usage Guidance", draft-ietf-mile-iodef-
              guidance-11 (work in progress), September 2017.

              Huitema, C. and E. Rescorla, "SNI Encryption in TLS
              Through Tunneling", draft-ietf-tls-sni-encryption-00 (work
              in progress), August 2017.

Moriarty & Morton        Expires August 4, 2018                [Page 42]
Internet-Draft            Effect of Encryption              January 2018

              "IP Flow Information Export (IPFIX) Entities

   [JNSLP]    Surveillance, Vol. 8 No. 3, "10 Standards for Oversight
              and Transparency of National Intelligence Services

   [M3AAWG]   "Messaging, Malware, Mobile Anti-Abuse Working Group

   [Map3GPP], "Mapping between
              technologies and specifications".

              "ISPs Removing their Customers EMail Encryption

   [Nygren] reaching-toward-
              universal-tls-sni.html, "Erik Nygren, personal reference".

   [RFC1945]  Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
              Transfer Protocol -- HTTP/1.0", RFC 1945,
              DOI 10.17487/RFC1945, May 1996,

   [RFC1958]  Carpenter, B., Ed., "Architectural Principles of the
              Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996,

   [RFC1984]  IAB and IESG, "IAB and IESG Statement on Cryptographic
              Technology and the Internet", BCP 200, RFC 1984,
              DOI 10.17487/RFC1984, August 1996,

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, DOI 10.17487/RFC2131, March 1997,

   [RFC2275]  Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
              Access Control Model (VACM) for the Simple Network
              Management Protocol (SNMP)", RFC 2275,
              DOI 10.17487/RFC2275, January 1998,

Moriarty & Morton        Expires August 4, 2018                [Page 43]
Internet-Draft            Effect of Encryption              January 2018

   [RFC2504]  Guttman, E., Leong, L., and G. Malkin, "Users' Security
              Handbook", FYI 34, RFC 2504, DOI 10.17487/RFC2504,
              February 1999, <>.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, DOI 10.17487/RFC2663, August 1999,

   [RFC2775]  Carpenter, B., "Internet Transparency", RFC 2775,
              DOI 10.17487/RFC2775, February 2000,

   [RFC2804]  IAB and IESG, "IETF Policy on Wiretapping", RFC 2804,
              DOI 10.17487/RFC2804, May 2000,

   [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, <>.

   [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,

   [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, <>.

   [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, <>.

   [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,

   [RFC3954]  Claise, B., Ed., "Cisco Systems NetFlow Services Export
              Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004,

Moriarty & Morton        Expires August 4, 2018                [Page 44]
Internet-Draft            Effect of Encryption              January 2018

   [RFC3971]  Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
              "SEcure Neighbor Discovery (SEND)", RFC 3971,
              DOI 10.17487/RFC3971, March 2005,

   [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, <>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,

   [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, <>.

   [RFC5965]  Shafranovich, Y., Levine, J., and M. Kucherawy, "An
              Extensible Format for Email Feedback Reports", RFC 5965,
              DOI 10.17487/RFC5965, August 2010,

   [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,

   [RFC6235]  Boschi, E. and B. Trammell, "IP Flow Anonymization
              Support", RFC 6235, DOI 10.17487/RFC6235, May 2011,

   [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,

   [RFC6430]  Li, K. and B. Leiba, "Email Feedback Report Type Value:
              not-spam", RFC 6430, DOI 10.17487/RFC6430, November 2011,

   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol",
              RFC 6455, DOI 10.17487/RFC6455, December 2011,

Moriarty & Morton        Expires August 4, 2018                [Page 45]
Internet-Draft            Effect of Encryption              January 2018

   [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,

   [RFC6591]  Fontana, H., "Authentication Failure Reporting Using the
              Abuse Reporting Format", RFC 6591, DOI 10.17487/RFC6591,
              April 2012, <>.

   [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, <>.

   [RFC6651]  Kucherawy, M., "Extensions to DomainKeys Identified Mail
              (DKIM) for Failure Reporting", RFC 6651,
              DOI 10.17487/RFC6651, June 2012,

   [RFC6652]  Kitterman, S., "Sender Policy Framework (SPF)
              Authentication Failure Reporting Using the Abuse Reporting
              Format", RFC 6652, DOI 10.17487/RFC6652, June 2012,

   [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,

   [RFC7012]  Claise, B., Ed. and B. Trammell, Ed., "Information Model
              for IP Flow Information Export (IPFIX)", RFC 7012,
              DOI 10.17487/RFC7012, September 2013,

   [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, <>.

   [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,

Moriarty & Morton        Expires August 4, 2018                [Page 46]
Internet-Draft            Effect of Encryption              January 2018

   [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,

   [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,

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
              2014, <>.

   [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,

   [RFC7435]  Dukhovni, V., "Opportunistic Security: Some Protection
              Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
              December 2014, <>.

   [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, <>.

   [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, <>.

   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
              DOI 10.17487/RFC7540, May 2015,

   [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,

Moriarty & Morton        Expires August 4, 2018                [Page 47]
Internet-Draft            Effect of Encryption              January 2018

   [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,

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,

   [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, <>.

   [RFC7799]  Morton, A., "Active and Passive Metrics and Methods (with
              Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
              May 2016, <>.

   [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, <>.

   [RFC7838]  Nottingham, M., McManus, P., and J. Reschke, "HTTP
              Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
              April 2016, <>.

   [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, <>.

   [RFC8073]  Moriarty, K. and M. Ford, "Coordinating Attack Response at
              Internet Scale (CARIS) Workshop Report", RFC 8073,
              DOI 10.17487/RFC8073, March 2017,

   [RFC8164]  Nottingham, M. and M. Thomson, "Opportunistic Security for
              HTTP/2", RFC 8164, DOI 10.17487/RFC8164, May 2017,

              "RFC Editor Abbreviation List".

Moriarty & Morton        Expires August 4, 2018                [Page 48]
Internet-Draft            Effect of Encryption              January 2018

   [SACM], "Security
              Automation and Continuous Monitoring (sacm) IETF Working

              content/uploads/2016/04/p14-verble-1.pdf, "The NSA and
              Edward Snowden: Surveillance In The 21st Century", 2014.

   [TS3GPP]   "3GPP TS 24.301, "Non-Access-Stratum (NAS) protocol for
              Evolved Packet System (EPS); Stage 3"", 2017.

              SpecificationDetails.aspx?specificationId=558, "3GPP TR
              21.905 V13.1.0 (2016-06) Vocabulary for 3GPP

              "3GPP Web pages on specific topics of interest".

              Xing Xu, et al., "Investigating Transparent Web Proxies in
              Cellular Networks, Passive and Active Measurement
              Conference (PAM)", 2015.

Authors' Addresses

   Kathleen Moriarty (editor)
   Dell EMC
   176 South St
   Hopkinton, MA

   Phone: +1

   Al Morton (editor)
   AT&T Labs
   200 Laurel Avenue South
   Middletown,, NJ  07748

   Phone: +1 732 420 1571
   Fax:   +1 732 368 1192

Moriarty & Morton        Expires August 4, 2018                [Page 49]