RFC 8404

📜 Effects of Pervasive Encryption on Operators 🎀

okay bestie, let's get the vibes right first 💖 this doc is RFC 8404 ✨, written by K. Moriarty, Ed. (Dell EMC) and A. Morton, Ed. (AT&T Labs) 🫶. It's Informational 🌸, which means it's just sharing knowledge, not a standards-track spec. It came out in July 2018 🦋, and it doesn't obsolete or update any other RFCs 💅. Its ISSN is 2070-1721 🌈.

---

Status of This Memo ✨

not a standards track spec, just published for info 📚 but it's an IETF product, approved by the IESG 👑. not every IESG-approved doc is on the standards path, see Section 2 of RFC 7841 for that 💅. errata and feedback live at https://www.rfc-editor.org/info/rfc8404 🧚

Copyright Notice 💜

© 2018 IETF Trust and the document authors, all rights reserved 🔒. this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) 📄. if you pull code components out of it, they need the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty 🙈.

Table of Contents 🗂️

okay so the TOC is long, so we'll be going through it in parts 🍓. the big picture is that the doc starts with an Introduction (Section 1) 🌸, then covers Network Service Provider Monitoring Practices (Section 2) 🔍, Hosting and Application SP environments (Section 3) ☁️, Encryption for Enterprises (Section 4) 🏢, Security Monitoring for Specific Attack Types (Section 5) 🛡️, Application-Based Flow Information (Section 6) 📡, mobile networks (Section 7) 📱, responses and looking forward (Section 8) 🔮, Security Considerations (Section 9) 🚨, IANA Considerations (Section 10) 📋, and then the References, Acknowledgements and Authors' Addresses 💌.

---

1. Introduction ✨

okay so here's the setup 💅. pervasive monitoring revelations led to the IETF consensus that pervasive monitoring is an attack [RFC7258], so people are working hard to encrypt more Internet traffic 🔐. pervasive monitoring is a big deal for users, operators, and app providers alike 😭.

RFC 7258 is super clear that protecting users' privacy matters when we write IETF specs 🫶, BUT it also says that making networks unmanageable to fight monitoring is NOT an acceptable outcome 🙅‍♀️. instead, we need a balance, and that balance is supposed to show up over time 🦋.

this doc is all about the practices network operators use to manage, operate, and secure their networks 🛠️, and how those practices could get hit as encryption goes up 📉. it shares operators' perspectives on why they do what they do and what they expect to happen as encryption spreads 🧠. it's basically a summary of what the ops community is worried about as they move to managing networks with less visibility 👀.

BUT, not an endorsement 💀. this doc does NOT say these practices are good, and it's not a full treatment of every effect either 🙈. some of these practices are controversial technically or business-wise, or just clash with earlier IETF statements (see [RFC1958], [RFC1984], and [RFC2804]) 📚. the e2e (end-to-end) principle is treated as a guiding principle for Internet protocols by [RFC2775], [RFC3724], and [RFC7754] 🌈.

the goal is to help IETF folks understand how pervasive encryption, both opportunistic and strong end-to-end encryption, affects operational practices 🎀. the point is to make sure operational impact is part of the conversation when we design future protocols ✨. maybe new methods could hit some of the same goals even when less cleartext is visible to operators (including methods that rely on endpoints where that makes sense) 💜. talking through current practices and possible future changes is a prerequisite for cross-industry and cross-layer work that moves us toward a functional Internet with pervasive encryption 🧚.

traditional network management, planning, security ops, and performance optimization were all built on an Internet where most data traffic flows unencrypted 🍓. unencrypted traffic made it easy to get info for ops and troubleshooting at every layer 🔎, but it also made pervasive monitoring by unseen parties possible 😬. with more awareness of privacy across the whole Internet 🔒, it's important to catalog the management, ops, and security practices that depend on cleartext 📋, and see whether critical ops can be met in less invasive ways 💅.

this doc talks about a few kinds of Service Providers (SPs) 🏢. network service providers (aka network operators) mainly provide IP packet transport, though they may bundle other services with it 📦. application service providers mostly offer systems that act as an endpoint in communication with the app user 📱. hosting service providers lease computing, storage, and comms systems in data centers ☁️. in practice, lots of companies play two or more of these roles, even if they're historically known for one 🌸.

last thing 💖: this doc includes a sampling of current practices, not every nuance, and some sections cover tech used across a broad range of devices and use cases 🌈.

1.1. Additional Background on Encryption Changes

okay so, pervasive encryption in this doc means all the session encryption types 🔐, like Transport Layer Security (TLS), IP Security (IPsec), TCPcrypt [TCPcrypt], QUIC [QUIC] (IETF's take on Google's QUIC), and others that are getting deployed more and more ✨. It's well understood that session encryption helps stop both passive and active attacks on transport protocols 🛡️. If you want the deep dive on pervasive monitoring, check out "Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement" [RFC7624] 📚. Active attacks have been a reason to encrypt more for a long time, but stopping pervasive monitoring only became a focus a few years ago 👀. So the Internet Architecture Board (IAB) put out a statement pushing for more encryption in November 2014 (see <https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/>) 🎀. The vibe on encryption has shifted over time too: ease of deployment is now a top priority, and it gets balanced against giving the maximum possible security no matter how hard it is to deploy 💅.

One big shift is Opportunistic Security (OS) [RFC7435] 🦋. It says that when authenticated encryption isn't possible, a cleartext session should get upgraded to unauthenticated session encryption instead of no encryption at all 🌸. OS encourages upgrades away from cleartext, but it can't require or guarantee them 🙈. Once OS is in use, it leaves room to evolve into authenticated encryption 🌈. All of this matters because it boosts an end user's privacy expectations, which makes pervasive monitoring cost prohibitive 💜. Even with OS in play, active attacks are still possible on unauthenticated sessions 😬. OS has been implemented as NULL Authentication with IPsec [RFC7619], and a bunch of infrastructure use cases, like server-to-server encryption, deploy this mode 🧚. OS does a great job of reducing pervasive monitoring by making monitoring more expensive, but some applications have risk profiles that call for authenticated and secure session encryption plus prevention of active attacks 🔥. IPsec, and other session encryption protocols, with authentication have tons of useful applications, and usage has gone up for infrastructure stuff like virtual private networks between data centers 🍓. OS, along with other protocol developments like the Automated Certificate Management Environment (ACME), has pushed session encryption usage up across the Internet 🚀.

Risk profiles vary, and so do the types of session encryption that get deployed ⭐. To understand how much visibility has changed, here are a few examples 👑. Work keeps going to improve how TLS and DTLS sessions are implemented, developed, and configured, so active attacks used to monitor or intercept session data get prevented 🛡️. The jump from TLS 1.2 to 1.3 makes TLS more secure, but it also hides more of the session negotiation and gives less visibility on the wire 🫣. The Using TLS in Applications (UTA) Working Group has been publishing docs to make TLS and DTLS sessions more secure 📝. They documented the known attack vectors in [RFC7457] and best practices for TLS and DTLS in [RFC7525], and more docs are in development 🧁. TLS 1.3 was built on the recommendations from these documents, so it could be a more inherently secure end-to-end protocol 💖.

Beyond encrypted website access (HTTP over TLS), there are other well-deployed application-level transport encryption efforts 🌐. Examples are MTA-to-MTA (mail transfer agent) session encryption for email (SMTP over TLS) and gateway-to-gateway encryption for instant messaging (the Extensible Messaging and Presence Protocol (XMPP) over TLS) 📨. Even though this protects against transport-layer attacks, the servers could still be a point of vulnerability if user-to-user encryption isn't provided for these messaging protocols 😱. User-to-user content encryption schemes like S/MIME and Pretty Good Privacy (PGP) for email, and Off-the-Record (OTR) encryption for XMPP, are used by folks who want to protect their data as it crosses intermediary servers 🔒. They prevent transport-layer attacks by giving an end-to-end solution 🏆. User-to-user schemes are under review, and more options will show up to ease configuration requirements, which makes this kind of option more accessible to non-technical users who care about their privacy 🌷.

Increased use of encryption, whether opportunistic or authenticated, at the transport, network, or application layer, affects how networks are operated, managed, and secured 🧩. In some cases, new ways to operate, manage, and secure networks will evolve in response ✨. In other cases, the capabilities currently available for monitoring or troubleshooting networks could become unavailable 💀. This document lists a collection of functions that network operators use today and that may be impacted by the shift to more encryption 📋. It doesn't try to specify responses or solutions to these impacts, though. It just documents the current state 🫶.

1.2. Examples of Attempts to Preserve Functions

After the Snowden [Snowden] revelations 😳, application service providers (Yahoo, Google, etc.) responded by encrypting traffic between their data centers (IPsec) to stop passive monitoring from happening without their knowledge 🛡️. Infrastructure traffic over the public Internet had been encrypted for a while, but this universal encryption change was specific to their private backbones 🏰. Big mail service providers also started encrypting session transport (TLS) to hosted mail services 📬. This and other increases in encryption had the immediate effect of providing confidentiality and integrity for protected data 💅, but it created a problem for some network-management functions 😭. Operators could no longer access some session streams, so several of them took action to get back the operational practices that used to depend on cleartext data sessions 🔧.

The Electronic Frontier Foundation (EFF) reported [EFF2014] that several network service providers were using a downgrade attack to stop SMTP over TLS, by breaking STARTTLS (Section 3.2 of [RFC7525]) 🚫. That basically blocks the negotiation process, which leads to falling back to cleartext 📉. There have already been documented cases of service providers preventing STARTTLS so session encryption negotiation doesn't happen on some sessions 🙅. Doing that lets them inject a super cookie that enables advertisers to track users 🍪, and those actions are also considered an attack 🚨. These are examples of undesirable behavior that could be prevented through upfront discussions in protocol work, where operators and protocol designers figure out the implications of these actions 🤝. In other cases, some service providers and enterprises have relied on middleboxes having access to cleartext for load-balancing, monitoring for attack traffic, meeting regulatory requirements, or other purposes 🧐. The implications are very different for enterprises that own the data on their networks, or that have explicit agreements allowing user traffic monitoring, compared to service providers who may be accessing content in a way that violates privacy considerations ⚖️. Also, service provider equipment is designed to access only the headers exposed for the data-link, network, and transport layers 📦. Digging deeper into packets is possible, but there's typically a high degree of accuracy from the header information and packet sizes when you're limited to headers from these three layers 🎯. Service providers also have the option of adding routing overlay protocols to traffic 🛣️. These middlebox implementations, whether their functions are considered legitimate by the IETF or not, have been impacted by increases in encrypted traffic 📉. Only methods that keep with the goal of balancing network management and pervasive monitoring mitigation, as discussed in [RFC7258], should be considered in work toward a solution coming out of this document 🌟.

It's well known that national surveillance programs monitor traffic for criminal activities [JNSLP] [RFC2804] [RFC7258] 🕵️. Governments vary in how they balance monitoring against protecting user privacy, data, and assets ⚖️. Those that favor unencrypted access to data ignore the real need to protect users' identities, financial transactions, and intellectual property, which require security and encryption to prevent crime 🔐. A clear understanding of technology, encryption, and monitoring goals will help with developing solutions 💡. Work continues toward finding an appropriate balance that allows for management while protecting user privacy with strong encryption solutions 🫶.

2. Network Service Provider Monitoring Practices

For this definition, service providers include the backbone ISPs, as well as those providing infrastructure at scale for core Internet use (hosted infrastructure and services such as email) 🌐.

Network service providers use various techniques to operate, manage, and secure their networks 🛠️. The subsections below detail the purpose of several techniques, plus 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 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 super useful for lots of things 📊, like input for studies by the Center for Applied Internet Data Analysis (CAIDA) [CAIDA], network planning, and optimization 🗺️. Tracking trends in Internet traffic growth, from earlier peer-to-peer communication to the huge adoption of unicast video streaming applications, has relied on a view of traffic composition with a particular level of assumed accuracy 📈. That accuracy was based on access to cleartext by the people running the surveys 👀.

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

2.1.2. Troubleshooting 🔍✨

okay so network operators use protocol-dissecting analyzers when they're responding to customer problems 💅, to spot attack traffic 🚨, and to find root causes like misconfiguration 🔧. In limited cases, packet captures are also used when a customer approves access to their packets or provides captures close to the endpoint 🎀. The dissection is generally limited to supporting protocols (e.g., DNS and DHCP) 🌸, network and transport protocols (e.g., IP and TCP) 🦋, and some higher-layer protocols (e.g., RTP and the RTP Control Protocol (RTCP)) 🎶. Troubleshooting will move closer to the endpoint as encryption increases, and adjusting practices to troubleshoot effectively with a 5-tuple may require some education 📚. Packet-loss investigations, and those where access is limited to a 2-tuple (IPsec tunnel mode), rely on network and transport-layer headers taken at the endpoint 🧠. In this case, captures on intermediate nodes are not reliable, because there are far too many cases of aggregate interfaces and alternate paths in service provider networks 🙈.

Network operators are often the first ones called in to investigate application problems (e.g., "my HD video is choppy") 📺, so they have to rule out the network and network services as the cause before anything else 🫶. When diagnosing a customer problem, the starting point may be a particular application that isn't working 💀. Being able to identify the traffic of the problem application is important, and packet capture provided from the customer close to the edge may be used for this purpose 🍓. IP address filtering is not useful for applications using Content Delivery Networks (CDNs) or cloud providers 🙅‍♀️. After identifying the traffic, an operator may analyze the traffic characteristics and routing of that traffic 🗺️. This diagnostic step is important for determining the root cause before exploring whether the issue is directly with the application 🔎.

For example, by investigating packet loss (from TCP sequence and acknowledgement numbers) 📉, Round-Trip Time (RTT) (from TCP timestamp options or application-layer transactions, e.g., DNS or HTTP response time) ⏱️, TCP receive-window size 🪟, packet corruption (from checksum verification) 🧩, inefficient fragmentation 🥴, or application-layer problems, the operator can narrow the problem down to a portion of the network, server overload, client or server misconfiguration, and so on 🎯. Network operators may also be able to identify the presence of attack traffic that doesn't conform to the application the user claims to be using 🕵️‍♀️. In many instances, the exposed packet header is sufficient for this type of troubleshooting ✨.

One way of quickly excluding the network as the bottleneck during troubleshooting is to check whether the speed is limited by the endpoints 🏃‍♀️. For example, the connection speed might instead be limited by suboptimal TCP options, the sender's congestion window 🪟, the sender temporarily running out of data to send 🫠, the sender waiting for the receiver to send another request, or the receiver closing the receive window 🙃. All of this information can be derived from the cleartext TCP header 🔓💖.

Packet captures and protocol-dissecting analyzers have been important tools 🧰. Automated monitoring has also been used to proactively identify poor network conditions 🤖, leading to maintenance and network upgrades before user experience declines 📈. For example, findings of loss and jitter in Voice over IP (VoIP) traffic can be a predictor of future customer dissatisfaction (supported by metadata from RTP/RTCP) [RFC3550] 📞, or increases in DNS response time can generally make interactive web browsing look sluggish 🐌. But to detect these problems, the application or service stream must first be distinguished from others 🧁.

When increased encryption is used, operators lose a source of data that may be used to debug user issues 😭. For example, IPsec obscures TCP and RTP header information, while TLS and the Secure Real-time Transport Protocol (SRTP) do not 🔐. Because of this, application-server operators using increased encryption might be called upon more frequently to help with debugging and troubleshooting 📣. So they may want to think about what tools can be put in the hands of their clients or network operators 🧰💜.

Further, the performance of some services can be managed and repaired more efficiently when information on user transactions is available to the service provider 🚀. It may be possible to continue transaction-monitoring activities without cleartext access to the application layers of interest 🫧; however, inaccuracy will increase and the efficiency of repair activities will decrease 📉. For example, an application-protocol error or failure would be opaque to network troubleshooters when transport encryption is applied 🌫️, making root cause location more difficult and, therefore, increasing the time to repair ⏳. Repair time directly reduces the availability of the service, and most network operators have made availability a key metric in their Service Level Agreements (SLAs) and/or subscription rebates 💸. Also, there may be more cases of user-communication failures when additional encryption processes are introduced (e.g., key management at large scale) 🔑, leading to more customer service contacts and, at the same time, less information available to network-operation repair teams 😩.

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 estimating user and service quality indicators at network edges for circuit emulation (CEM), as well as input for mitigation methods 📊. If the makeup of active services per user and per sector is not visible to a server that provides Internet Access Point Names (APNs), it cannot perform mitigation functions based on the 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 from network-based optimization or enhancement of user traffic (otherwise, deployment would not have occurred) 🎉, application providers have likewise noted some degraded performance and/or user experience, and such cases may result in additional operator troubleshooting 🛠️. Further, encrypted application streams might avoid outdated optimization or enhancement techniques, where they exist 🦋.

A gap exists for vendors where built-in diagnostics and serviceability are not adequate to provide detailed logging and debugging capabilities that, when possible, could be accessed with cleartext network parameters 🕳️. In addition to traditional logging and debugging methods, packet tracing and inspection along the service path gives operators the visibility to keep diagnosing problems reported both internally and by their customers 🔍. Logging of the service path upon exit for routing overlay protocols will help with policy management and troubleshooting for traffic flows on encrypted networks 🗂️. Protocol trace logging and protocol data unit (PDU) logging should also be considered to improve visibility for monitoring and troubleshooting application-level traffic 📝. Additional work on this gap would help network operators better troubleshoot and manage networks with increasing amounts of encrypted traffic 💪🌈.

2.1.3. Traffic-Analysis Fingerprinting 🪪💅

Fingerprinting is used in traffic analysis and monitoring to identify traffic streams that match certain patterns 🧬. This technique can be used with both cleartext and encrypted sessions 🔓🔐. Some Distributed Denial-of-Service (DDoS) prevention techniques at the network-provider level rely on the ability to fingerprint traffic in order to mitigate the effect of this type of attack 🛡️. So fingerprinting may be an aspect of an attack or part of attack countermeasures 🥊.

A common, early trigger for DDoS mitigation is observing uncharacteristic traffic volumes or sources, congestion, or degradation of a given network or service 🚨📉. One approach to mitigating such an attack involves distinguishing attacker traffic from legitimate user traffic 🕵️‍♀️. The ability to examine layers and payloads above transport provides an increased range of filtering opportunities at each layer, in the clear 👁️. If fewer layers are in the clear, there are reduced filtering opportunities available to mitigate attacks 😬. However, fingerprinting is still possible 🫣.

Passive monitoring of network traffic can lead to an invasion of privacy by external actors at the endpoints of the monitored traffic 🚨🙈. Encryption of traffic end to end is one method to obfuscate some of the potentially identifying information 🫥.

For example, browser fingerprints are made up of many characteristics, including User Agents, HTTP Accept headers, browser plug-in details, screen size and color details, system fonts, and time zones 🖥️🎨. A monitoring system could easily identify a specific browser and, by correlating other information, identify a specific user 👑. Iconic behavior, honestly 💀.

2.2. Traffic Optimization and Management ⚡🎀

2.2.1. Load Balancers ✨

okay bestie, load balancers are lowkey the unsung heroes 💅 A standalone load balancer is a function you can grab off the shelf, park in front of a pool of servers, configure appropriately, and boom, it balances traffic across the pool 🎀 This is a typical setup, periodt. Standalone load balancers rely on the plainly observable info in the packets they forward, plus industry-accepted standards for reading that info 🦋 Usually that's a 5-tuple of the connection. This setup terminates TLS sessions at the load balancer, so it becomes the endpoint instead of the server 😭 Standalone load balancers count as middleboxes, but they're an integral part of server infrastructure that scales, so they're giving main character energy 👑

Now the integrated load balancer is a different vibe 🌸 It's developed to be an integral part of the service the server pool behind it provides. These load balancers can communicate state with their pool of servers to route flows to the right servers, and they run on non-standard, system-specific info 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 arriving at a different load balancer in the pool, those packets continue to be forwarded to the original server in the server pool ✨ This requirement matters more as the chance of such a load balancer change event goes up 💀

Mobile operators deploy integrated load balancers to help maintain connection state as devices migrate 📱 With so many mobile connected devices around, there's an acute need for connection-oriented protocols that keep connections alive after an endpoint migrates to a new network 🫶 This connection persistence is a real challenge for multihomed anycast-based services, which large content owners and CDNs usually use 😭 Here's the tea: switching networks mid-connection greatly increases the chances that packets get routed to a different anycast point of presence (POP), because the new network has different connectivity and Internet peering arrangements 🙈 The load balancer in the new POP, potentially thousands of miles away, won't have info about the new flow and won't be able to route it back to the original POP. Not me 💀

To help with endpoint network migration challenges, anycast service operations are likely to employ integrated load balancers that, working with their pool servers, make sure client-to-server packets carry some extra identification in plainly observable parts of the packets (on top of the 5-tuple) 🦋 As noted in Section 2 of [RFC7258], careful consideration in protocol design to mitigate pervasive monitoring is important, while still ensuring manageability of the network 🔥

An area for further research includes end-to-end solutions that would provide a simpler architecture and that may solve the CDN anycast issue 🌈 In that case, connections would be migrated to a CDN unicast address.

Current protocols, such as TCP, let stateless integrated load balancers work by availing them of additional plaintext info in client-to-server packets 🍓 For TCP, that info can be encoded by using server-generated sequence numbers (that the client ACKs), segment values, lengths of the packets sent, etc. Using some of these mechanisms for load balancing negates some of the security assumptions behind those primitives (for example, 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, like QUIC's proposed connection ID, which gives the load balancer visibility 💖 An identifier could be used for tracking purposes, but this may be an improvement over bolting it onto an unrelated transport signal 🎀

This method allows tight control by one of the endpoints and can be rotated to avoid roving client linkability. In other words, being a specific, separate signal, it can be governed in a way that's finely targeted at that specific use case 🫶

Some integrated load balancers can use additional plainly observable info even for today's protocols that aren't network-migration tolerant ✨ This extra info allows improved availability and scalability of the load-balancing operation 🔥 For example, BGP reconvergence can cause a flow to switch anycast POPs, even without a network change by any endpoint 😭 Also, a system that can encode the identity of the pool server in plaintext info available in each incoming packet can provide stateless load balancing 🧚 This ability confers great reliability and scalability advantages, even if the flow stays in a single POP, because the load-balancing system doesn't have to keep state for each flow 💅 Even more importantly, there's no requirement to continuously synchronize such state among the pool of load balancers 👑 An integrated load balancer repurposing limited existing bits in transport-flow state must maintain and synchronize per-flow state occasionally: using the sequence number as a cookie only works for so long, given that there aren't that many bits available to divide across a pool of machines 💀

Mobile operators apply 3GPP Self-Organizing Networks (SONs) for intelligent workflows like content-aware Mobility Load Balancing (MLB) 🌸 Where network load balancers have been configured to route according to application-layer semantics, an encrypted payload is effectively invisible 🙈 This has led to 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 affect 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 because 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 handle this by queuing traffic according to its required bandwidth and acceptable latency. For example, a user is unlikely to notice a 20 ms delay when receiving a simple web page, an email, or an instant message response, but will very likely notice a rebuffering pause in a video playback or a VoIP call de-jitter buffer 🙈 Ideally, the scheduler manages the queue so that each user has an acceptable experience as conditions vary, but inferences of the traffic type have been used to make bearer assignments and set scheduler priority 🎀

Deep Packet Inspection (DPI) allows identification of applications based on payload signatures, instead of trusting well-known port numbers 🔍 Application- and transport-layer encryption make traffic type estimation more complex and less accurate, so it may not be effectual to use this info as input for queue management 🥺 With WebSockets [RFC6455], for example, many forms of communication (from isochronous/real-time to bulk/elastic file transfer) take place over HTTP port 80 or port 443, so only the messages and higher-layer data make application differentiation possible 🧚 If the monitoring system sees only "HTTP port 443", it can't tell apart application streams that would benefit from priority queuing from ones that wouldn't 😵‍💫

Mobile networks especially rely on content- and 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 like the one described in Section 6.5 of 3GPP TS 24.301 [TS3GPP] 🌟 The UE's request includes the Quality Class Indicator (QCI) appropriate for each application, based on their different delay/loss/throughput expectations 💖 However, UE requests for dedicated bearers and QCI may not be supported at the subscriber's service level, or in all mobile networks 🙃

These effects and potential alternative solutions have been discussed at the accord BoF [ACCORD] at IETF 95 🗣️

This section does not consider traffic discrimination by service providers related to Net Neutrality, where traffic may be favored according to the service provider's preference instead of the user's preference 🚫 These use cases are considered out of scope for this document as controversial practices 🙅‍♀️

2.2.3. Network-Congestion Management 🌧️

For 3GPP User Plane Congestion Management (UPCON) [UPCON], the focus is on the ability to understand content and manage networks during periods of congestion 🚦 Mitigating techniques such as deferred download, off-peak acceleration, and outbound roamers are a few examples of the areas explored in the associated 3GPP documents 📚 The documents describe the issues, describe the data used in managing congestion, and make policy recommendations 🎀

2.2.4. Performance-Enhancing Proxies ✨

okay so performance-enhancing TCP proxies may do local retransmission at the network edge 🦋, and that includes mobile networks too. In TCP, duplicated ACKs get detected and possibly hidden when the proxy retransmits a segment that was lost on the mobile link, without the far end getting involved at all (see Section 2.1.1 of [RFC3135] and Section 3.5 of [MIDDLEBOXES]) 💅.

Operators say this edge optimization helps real-time transmission over long-delay Internet paths or networks with large capacity variation (like mobile/cellular networks) 🔥. but ngl, these optimizations can also cause performance problems, for example if the characteristics of some packet streams start to vary a lot from what the proxy was designed for 💀.

Some operators have stated that performance-enhancing proxies have a lower RTT to the client, so they determine how responsive flow control is 🫶. A lower RTT makes the flow-control loop more responsive to changes in mobile-network conditions and allows faster adaptation in a delay- and capacity-varying network caused by user mobility 🌈.

Some providers also use service-provider-operated proxies to cut the control delay between the sender and a receiver on a mobile network, where resources are limited 🧚. The RTT decides how fast a user's attempt to cancel a video gets recognized, and therefore how fast the traffic stops, which keeps unwanted video packets from piling up in the radio-scheduler queue 😭. If encryption gets in the way, performance-enhancing proxies could use routing overlay protocols to do the same job, but that comes with extra overhead 🙈.

An application-type-aware network edge (middlebox) can go even further: it can control pacing, limit simultaneous HD videos, or prioritize active videos over new ones, etc. 🎀 Services at this more granular level are limited when encryption is used 🔒.

Performance-enhancing proxies are mainly used on long-delay links (satellite) 🛰️, where they get access to the TCP header so they can send an early ACK and make the long-delay link seem shorter 🍓. With some specific forms of flow control, TCP can actually be more efficient than alternatives such as proxies 👑. The editors cannot cite research on this point specific to the performance-enhancing proxies described, but they agree this area could be explored 🔍. The goal would be to figure out whether flow-control modifications could preserve end-to-end performance on long-delay path sessions where the TCP header is exposed 💜.

2.2.5. Caching and Content Replication near the Network Edge

the features and efficiency of some Internet services can be boosted by analyzing user flows and the applications they provide 🌸. For example, caching popular content at a location close to the requesting user can improve delivery efficiency. That means lower request response times, and less use of links on the international Internet when content is located remotely 🌍. Service providers, through an authorized agreement where they act on someone's behalf, use DPI together with content-distribution networks to figure out if they can intervene effectively 🕵️‍♀️. Encryption of packet contents at a given protocol layer usually makes DPI processing of that layer and higher layers impossible 🔐. That being said, some content providers stop caching so they can control content delivery through encrypted end-to-end sessions 🙅‍♀️. CDNs vary in how they deploy end-to-end encryption 🤷‍♀️. The business risk of losing control of content is a motivation, separate from privacy and pervasive monitoring, that is pushing these content providers toward end-to-end encryption 💰.

It's worth noting that caching was first supported in [RFC1945] and continued in the recent update of "Hypertext Transfer Protocol (HTTP/1.1): Caching" [RFC7234] 📚. Some operators also run transparent caches that neither the user nor the origin opts in to. The use of these caches is controversial within the IETF and is generally ruled out by the use of HTTPS 🚫.

Content replication in caches (for example, live video and content protected by Digital Rights Management (DRM)) is used to make the most efficient use of limited bandwidth, which maximizes the user's Quality of Experience (QoE) 📺. Especially in mobile networks, duplicating every stream through the transit network increases backhaul cost for live TV 💸. 3GPP Enhanced Multimedia Broadcast/Multicast Services (eMBMS) use trusted edge proxies to deliver the same stream to different users, using either unicast or multicast depending on channel conditions to the user 📡. There are ongoing efforts to support multicast inside carrier networks while still preserving end-to-end security. Automatic Multicast Tunneling (AMT), for instance, lets CDNs deliver a single (potentially encrypted) copy of a live stream to a carrier network over the public Internet. The carrier can then distribute that live stream as efficiently as possible within its own network using multicast 🎶.

Alternate approaches are in the early stages of being explored to allow caching of encrypted content 🧪. These solutions need cooperation from content owners and fall outside the scope of what this document covers 🫡. 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

on top of caching, lots of apps offer data compression to save 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, like a browser, or it can be available to all applications through a system-level application 📱. The main method is for the mobile application to connect to a centralized server as a transparent proxy (the user does not opt in), with the data channel between the client application and the server using compression to cut down bandwidth use 🗜️. The effectiveness of these systems depends on the server having access to unencrypted data flows 🔓.

Aggregated data stream content compression, which spans objects and data sources that can be treated as part of one unified compression scheme (e.g., through a shared segment store), is often effective at offloading data when there's a network element close to the receiver that can see all the content 📦.

2.2.7. Service Function Chaining

Service Function Chaining (SFC) is defined in RFC 7665 [RFC7665] and RFC 8300 [RFC8300] 🔗. As discussed in RFC 7498 [RFC7498], common SFC deployments may use classifiers to send traffic into VLANs instead of using a Network Service Header (NSH), as defined in RFC 8300 [RFC8300] 🏷️. As described in RFC 7665 [RFC7665], the ordered steering of traffic to support specific optimizations depends on a classifier's ability to determine the microflows. RFC 2474 [RFC2474] defines the following 📖:

Microflow: a single instance of an application-to-application flow of packets which is identified by source address, destination address, protocol id, and source port, destination port (where applicable).

SFC currently depends on a classifier to at least identify the microflow 🧠. As the classifier's visibility drops from a 5-tuple to a 2-tuple, or if information above the transport layer becomes inaccessible, the SFC classifier can't do its job, and the service functions on the path may be adversely affected 😱.

There are also mechanisms to protect security and privacy 🛡️. In the SFC case, the layer below a network service header can be protected with session encryption 🔐. The goal is to protect end-user data while keeping the intended functions of RFC 7665 [RFC7665] working at the same time 💅✨.

2.3. Content Filtering, Network Access, and Accounting

Mobile networks and many ISPs operate under the regulations of their licensing government authority 🏛️. These regulations include Lawful Intercept, adherence to Codes of Practice on content filtering, and application of court-order filters 📜. Such regulations assume network access to provide content filtering and accounting, as discussed below 👇. As previously stated, the intent of this document is to document existing practices. The development of IETF protocols follows the guiding principles of [RFC1984] and [RFC2804], and explicitly does not support tools and methods that could be used for wiretapping and censorship 🚫🙅‍♀️.

2.3.1. Content Filtering 🚫✨

okay bestie, there are SO many reasons a service provider might block content 💀: following orders from law enforcement or regulators, parental controls, enforcing content-based billing, or other reasons some people might find inappropriate 🙈. If you want the full tea on filtering techniques and motivations (plus the IAB consensus on those mechanisms), see RFC 7754 [RFC7754] 📚. This section documents some of the content-blocking stuff operators are actually doing right now, and how encryption changes the game 🎮. Content blocking can also happen on endpoints or at the edge of enterprise networks, but those scenarios aren't covered here 💅.

In a mobile network, content filtering usually happens in the core network 📱. On other networks it could be in the core or at the edge 🌐. A proxy gets installed that looks at the transport metadata of what users are viewing, and filters based on either a blacklist of sites or the user's predefined profile (like for age-sensitive content) 👀. There are lots of ways to do this, but one popular move is: the proxy spots a DNS lookup for a host name in a URL that's on the operator's blacklist 🕵️. Later requests to that domain get rerouted to a proxy that checks whether the full URL matches a blocked URL on the list, and it returns a 404 if there's a match ❌. All other requests should complete ✅. This trick doesn't work when DNS traffic is encrypted (for example, by employing [RFC7858]) 🔐. This method is also used by other types of network providers who enable traffic inspection but not modification 🔍.

Content filtering via a proxy can also use an intercepting certificate 🎀. The client's session is terminated at the proxy so the traffic can be inspected in cleartext, and a new session is created from the intercepting device to the client's destination 😳. This is an opt-in strategy for the client, since the endpoint is configured to trust the intercepting certificate 🫶. Changes to TLS 1.3 don't affect this more invasive kind of interception, which has the potential to expose every HTTPS session to an active man in the middle (MITM) 😱.

Another form of content filtering is parental control, where some users are deliberately denied access to age-sensitive content as a feature for the service subscriber 🧸. Some sites mix universal and age-sensitive content with 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 stop working once sessions are encrypted 🙅. This granular filtering could happen at the endpoint or as a proxy service 🖥️. However, the lack of ability to efficiently manage endpoints as a service reduces network service providers' ability to offer parental control 😩.

2.3.2. Network Access and Data Usage 📶

Approved access to a network is a prerequisite for requesting Internet traffic 🔑.

However, there are cases (beyond parental control) when a network service provider currently redirects customer requests for content, which affects content accessibility 🚧:

1. The network service provider is doing the accounting and billing for the content provider, and the customer has not (yet) purchased the requested content 💸.
2. More content may not be allowed because the customer has hit their usage limit and needs to buy 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 the reason for the block and the steps to proceed 🪧. [RFC6108] describes one viable web notification system 💌. When HTTP headers and content are encrypted, this properly stops mobile carriers from intercepting the traffic and doing an HTTP redirect 🔐. As a result, some mobile carriers block customers' encrypted requests, which hurts customer experience because the blocking reason has to be conveyed some other way 😤. The customer may need to call customer care to find out the reason and/or resolve the issue, which could stretch out the time needed to restore network access 📞. There are well-deployed SMS-based solutions that don't involve out-of-specification protocol interception, but this is still an unsolved problem for non-SMS users 📩.

Further, when the requested service is about to eat up the rest of the user's plan limits, the transmission could be terminated, and advance notifications may be sent to the user by their service provider to warn them before the plan runs out ⏰. If web content is encrypted, the network provider can't know the data transfer size at request time 🙈. Without visibility into the application type and content size, the network would continue the transmission and stop the transfer only when the limit was reached 🛑. A partial transfer may not be usable by the client, which wastes both network and user resources and possibly leads to customer complaints 😭. The content provider doesn't know a user's service plans or current usage, so it can't warn the user about plan exhaustion 🫠.

Also, some mobile network operators sell tariffs that allow free-data access to certain sites, known as 'zero rating' 🎁. A session to visit such a site incurs no additional cost or data usage to the user 💖. For some implementations, zero rating is impacted if encryption hides the details of the content domain from the network 🥲.

2.3.3. Application Layer Gateways (ALGs) 🚪

Application Layer Gateways (ALGs) assist applications to set connectivity across Network Address Translators (NATs), firewalls, and/or load balancers for specific applications running across mobile networks 🧩. Section 2.9 of [RFC2663] describes the role of ALGs and their interaction with NAT and/or application payloads 📖. ALGs are deployed with an aim to improve connectivity. However, it is an IETF best common practice recommendation that ALGs for UDP-based protocols be turned off [RFC4787] 🙅‍♀️.

One example of an ALG in current use is aimed at video applications that use the Real-Time Streaming Protocol (RTSP) [RFC7826] primary stream as a means to identify related RTP/RTCP [RFC3550] flows at setup 🎥. The ALG in this case relies on the 5-tuple flow information derived from RTSP to provision NAT or other middleboxes and provide connectivity 🛠️. Implementations vary, and two examples follow 👇:

1. Parse the content of the RTSP stream and identify the 5-tuple of the supporting streams as they are being negotiated.
2. Intercept and modify the 5-tuple information of the supporting media streams as they are being negotiated on the RTSP stream, which is more intrusive to the media streams 😬.

When RTSP-stream content is encrypted, the 5-tuple information within the payload is not visible to these ALG implementations, so they cannot provision their associated middleboxes with that information 🔒.

The deployment of IPv6 may well reduce the need for NAT and the corresponding requirement for ALGs 🌍.

2.3.4. HTTP Header Insertion 📝

Some mobile carriers use HTTP header insertion (see Section 3.2.1 of [RFC7230]) to provide information about their customers to third parties or to their own internal systems [Enrich] 🏷️. Third parties use the inserted information for analytics, customization, advertising, cross-site tracking of users, customer billing, or selectively allowing or blocking content 👀. HTTP header insertion is also used to pass information internally between a mobile service provider's sub-systems, thus keeping the internal systems loosely coupled 🧶. When HTTP connections are encrypted to protect user privacy, mobile network service providers cannot insert headers to accomplish the (sometimes controversial 👀) functions above 🔐.

Guidance from the Internet Architecture Board has been provided in "Design Considerations for Metadata Insertion" [RFC8165] 🏛️. The guidance asserts that designs that share metadata only by explicit actions at the host are preferable to designs in which middleboxes insert metadata ✅. Alternate notification methods that follow this and other guidance would be helpful to mobile carriers 🙌.

3. Encryption in Hosting and Application SP Environments ☁️

Hosted environments have had varied requirements in the past for encryption 🌥️, with many businesses choosing to use these services primarily for data and applications that are not business or privacy sensitive. A shift happened before the revelations on surveillance/passive monitoring, when businesses started asking hosted environments for higher levels of security so that additional applications and services could be hosted externally 📈. Businesses that understood the threats of monitoring in hosted environments increased that pressure for more secure access and session encryption, to protect the management of hosted environments as well as the data and applications 🔐💪.

3.1. Management-Access Security 🗝️

Hosted environments may have multiple levels of management access, where some may be strictly for the Hosting service provider (infrastructure that may be shared among customers), and some may be accessed by a specific customer for application management 🏢. In some cases, there are multiple levels of hosting service providers, further complicating the security of management infrastructure and the associated requirements 🌀.

Hosting service provider management access is typically segregated from other traffic with a control channel and may or may not be encrypted depending upon the isolation characteristics of the management session 🧱. Customer access may be through a dedicated connection, but discussion for that connection method is out of scope for this document 🙅.

In overlay networks (e.g., Virtual eXtensible Local Area Network (VXLAN), Geneve, etc.) that are used to provide hosted services, management access for a customer to support application management may depend upon the security mechanisms available as part of that overlay network 🧅. While overlay-network data encapsulations may be used to indicate the desired isolation, this is not sufficient to prevent deliberate attacks that are aware of the use of the overlay network ⚠️. [GENEVE-REQS] describes requirements to handle attacks 📋. It is possible to use an overlay header in combination with IPsec or other encrypted traffic sessions, but this adds the requirement for authentication infrastructure and may reduce packet transfer performance 🐢. The use of an overlay header may also be deployed as a mechanism to manage encrypted traffic streams on the network-by-network service providers 🧑‍🤝‍🧑. Additional extension mechanisms to provide integrity and/or privacy protections are being investigated for overlay encapsulations 🔬. Section 7 of [RFC7348] describes some of the security issues possible when deploying VXLAN on Layer 2 networks 🧐. Rogue endpoints can join the multicast groups that carry broadcast traffic, for example 😱.

3.1.1. Monitoring Customer Access ✨

Okay, so hosted apps that let customers do some management stuff 🖥️ might also need the hosting provider to keep an eye on things 👀. That monitoring could cover access controls like authentication, authorization, and accounting, making sure the filtering and firewall rules are continuously being met 🔐. Customers can get in at more than one level, like regular user access and admin access 👑. The provider may need to check access through session monitoring or by going through logs, just so the security SLAs for access management are actually being met 📋. Using session encryption to reach hosted environments means the access restrictions can only look at the metadata described below 🙈. Monitoring and filtering can happen at either of these levels:

• 2-tuple: IP level, using source and destination IP addresses alone, or
• 5-tuple: IP and protocol level, using a source IP address, destination IP address, protocol number, source port number, and destination port number.

Session encryption at the application level, like TLS, still lets you see the 5-tuple right now 🔓. IP-level encryption, like IPsec in tunnel mode, hides the original 5-tuple and can make it harder to restrict traffic with filtering 😬. This shift might not affect every hosting provider setup, though 🤷‍♀️, because other controls can be used to authenticate sessions, or customers might have to connect to the organization first before reaching the hosted application 🏢. Access may need to shift so the same level of access-control management is kept 💅. Logs can also be used to check that access-control restrictions are met, but they're only as good as what's visible at the point where the logs get made, since encryption limits that 📝. Log analysis is out of scope for this document 🙃.

3.1.2. SP Content Monitoring of Applications 🔍

Okay, these observations apply to any IT org that's responsible for delivering services 💼. That could be to third parties, like a web-based service, or to internal customers in an enterprise, like a data-processing system that's part of the business 🏬.

Data center operators have a bunch of processes that look at the contents of IP packets (passive methods of measurement, as defined in [RFC7799]) 👀. These are usually for service assurance or security as part of running the data center 🛡️.

Examples include:

• Network-Performance Monitoring / Application-Performance Monitoring
• Intrusion defense/prevention systems
• Malware detection
• Fraud monitoring
• Application DDOS protection
• Cyber-attack investigation
• Proof of regulatory compliance
• Data leakage prevention

Lots of application service providers just end sessions to and from the Internet at the edge of the data center through SSL/TLS offload in the load balancer ⚖️. That not only takes some load off the application servers, it also makes it easier to monitor session content 🙌.

But sometimes encryption deeper in the data center is needed to protect personal information or to meet industry regulations, like the ones set by the Payment Card Industry (PCI) 🔒. In those situations, people have used different methods so service assurance and security processes can still get at unencrypted data 🔓. Some of these are SSL/TLS decryption in dedicated units that then forward packets to SP-controlled tools, or real-time or post-capture decryption inside the tools themselves 🧰. A bunch of these tools do passive decryption by handing the monitoring device the server's private key 🗝️. The move toward more use of the forward-secret key exchange mechanism affects how these techniques work 😭.

Data center operators might also keep packet recordings so they can investigate attacks, breaches of internal processes, and so on 🕵️‍♀️. In some industries, organizations might be legally required to keep this info for compliance 📜.

Investigations like this have used access to the unencrypted contents of the packet 🔎. Other ways of investigating attacks or process breaches will rely on endpoint information, like logs 🪵. As noted before, logs often don't have complete info, and that's seen as a concern, so some people end up relying on session access for extra details 🥲.

Application service providers may offer content-level monitoring options to catch intellectual property leakage or other attacks 🚨. In service provider environments where Data Loss Prevention (DLP) was set up on the assumption that the provider has cleartext access to session streams, encrypted streams stop those setups from searching for the keywords or phrases configured in the DLP system 🚫. DLP is often used to prevent leakage of Personally Identifiable Information (PII), financial account information, Personal Health Information (PHI), and PCI data 💳. If session encryption is terminated at a gateway before reaching these services, DLP on session data can still happen 🙌. Where to terminate encryption for hosted environments is a risk decision made between the application service provider and the customer organization, based on their priorities ⚖️. DLP can be done at the server for the hosted application, and on an end user's system in an organization, as alternate or additional content monitoring points 💻. This isn't really done that often in a service provider environment though 🤔.

Application service providers, by their very nature, control the application endpoint 🏠. So a lot of the info gleaned from sessions is still available on that endpoint ✅. But when there's a gap in the application's logging and debugging capabilities, providers have ended up accessing data in transport for monitoring and debugging 😅.

3.2. Hosted Applications 🏢

Organizations are increasingly using hosted applications instead of in-house solutions that need equipment and software maintenance 📈. Examples include Enterprise Resource Planning (ERP) solutions, payroll service, time and attendance, travel and expense reporting, and more 🧾. Organizations may need some level of management access to these hosted applications and will typically require session encryption or a dedicated channel for that activity 🔐.

In other cases, a hosting service provider may fully manage hosted applications, with SLA expectations for availability and performance, as well as for security functions like malware detection 🛡️. Because these hosted environments are sensitive, encryption is already really common 🙌. Any impact may be similar to an enterprise that uses tools inside the hosted environment to monitor traffic 🔧. No additional concerns were reported in the call for contributions 📭.

3.2.1. Monitoring Managed Applications 📊

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

• Availability: ability to establish connections with hosts to access applications, and to tell apart network-related and host-related causes of unavailability 🔌.
• Performance: ability to complete transactions within a target response time, and to tell apart network-related and host-related causes of excess response time 🐢.

Here, like with all passive monitoring, the accuracy of inferences depends on the cleartext info available 🔍. Encryption tends to reduce that info, and so reduces the accuracy of each inference 📉. Passive measurement of some metrics will be impossible with encryption that stops inferring packet correspondence across multiple observation points, like for packet-loss metrics 💔.

Application logging currently doesn't have enough detail to make accurate inferences in an environment with more encryption 🪵. That makes it a gap for passive performance monitoring 🕳️. (This could be closed if log details are enhanced in the future ✨.)

3.2.2. Mail Service Providers 📬

Mail (application) service providers vary in what they offer 💌. Options may include a fully hosted solution, where mail is stored outside an organization's environment on mail service provider equipment 🏬. Or the offering may be limited to monitoring incoming mail to remove spam (Section 5.1), phishing attacks (Section 5.3), and malware (Section 5.6) before mail gets sent to the organization's equipment 🗑️. In both of these cases, the content of messages and headers is monitored to detect and remove messages that are undesirable or may be considered an attack 🚨.

STARTTLS should have zero effect on anti-spam efforts for SMTP traffic 💅. Anti-spam services could easily be performed on an SMTP gateway, which removes the need for TLS decryption services 🙌. The impact to anti-spam service providers should just be a change in tools, where middleboxes were deployed to do these functions 🔧.

Lots of efforts are emerging to improve user-to-user encryption, including promotion of PGP and newer efforts like Dark Mail [DarkMail] 🔐✨. Of course, content-based spam filtering won't be possible on encrypted content 😩.

3.3. Data Storage 🗄️

Tons of service offerings give you hosted storage solutions 📦. This section describes the different offerings, details the monitoring for each type of service, and explains how encryption may affect the operational and security monitoring that's done 🔍.

Trends in data storage encryption for hosted environments include a range of options 🌈. The list below is intentionally high-level 🫶. It describes the types of encryption used alongside data storage that may be hosted remotely, meaning the storage is physically located in an external data center and needs transport over the Internet 🌐. Monitoring options will vary with each encryption approach described below 📋. In most cases, solutions have been identified that keep encryption going while still keeping management capabilities through logging or other means 🎀.

3.3.1. Object-Level Encryption 🔐

okay so, for higher security and/or privacy of data and applications 💅, options that give you end-to-end encryption of the data from the user's desktop or server all the way to the storage platform may be preferred 🫶. This covers any solution that encrypts data at the object level, not the transport level 🎀. The encryption can happen with libraries on the system or at the application level, which includes file-encryption services through a file manager 🗂️.

Object-level encryption is super useful when data storage is hosted, or when the storage location gets picked based on capacity or a set of parameters that automate the decisions 🤖. So like, large datasets that get accessed infrequently could be sent to an off-site storage platform at an external hosting service, data that gets accessed a lot may be stored locally, or the choice of where to store a dataset could be based on the transaction type 🍓. Object-level encryption gets its own group in this document because 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 where they sit in the network 👀.

3.3.1.1. Monitoring for Hosted Storage

Monitoring of hosted storage solutions that use host-level (object) encryption is what this subsection is all about ✨. 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 side may be there to detect anomalies in the data flows, which could include changes to destination, the amount of data transferred, or alterations in the size and frequency of flows 🕵️‍♀️. The operational side covers capacity and availability monitoring 📊.

3.3.2. Disk Encryption, Data at Rest (DAR) 💾

There are multiple ways to get full disk encryption for stored data, bestie 🧚. Data can be encrypted while it's in transit close to the storage media with solutions like Controller Based Encryption (CBE), or inside the drive system with Self-Encrypting Drives (SEDs) 🔐. Session encryption is typically paired with these data-at-rest (DAR) solutions so the data in transit is protected too 🦋. Transport encryption is likely to be via TLS 💜.

3.3.2.1. Monitoring Session Flows for DAR Solutions

Monitoring the transport of data to storage platforms, where object-level encryption happens close to or on the storage platform, is pretty much the same as what we just covered in Section 3.3.1.1 🙌. The big difference with these solutions is the possible exposure of sensitive information, which could include privacy-related data, financial information, or intellectual property if session encryption via TLS is not deployed 😬. Session encryption is typically used with these solutions, but that decision should come out of 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 happen between data centers and may use Internet connections to tunnel traffic 🛤️. The traffic may use an Internet Small Computer System Interface (iSCSI) [RFC7143] or Fibre Channel over TCP/IP (FCIP) [RFC7146] encapsulated in IPsec 🔗. Either transport or tunnel mode may be used for IPsec, depending on the termination points of the IPsec session: transport mode if it's terminated at the storage platform itself, and tunnel mode if it's terminated at a gateway device at the edge of the data center 🚪.

3.3.3.1. Monitoring IPsec for Data Replication Services

Monitoring the data flows between data centers (for data replication) may be performed for security and operational purposes 🧐. It would typically focus more on the operational side, since these flows are basically virtual private networks (VPNs) between data centers 🏢. Operational considerations include capacity and availability monitoring 📈. The security monitoring may be there to detect anomalies in the data flows, similar to what was described in Section 3.3.1.1 🔍. If IPsec tunnel mode is in use, monitoring is limited to a 2-tuple; with transport mode, it's limited to a 5-tuple 🎀.

---

4. Encryption for Enterprises 🏢💖

Encrypting network traffic inside a private enterprise is a growing trend, especially 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 move toward more encryption, alternate methods of monitoring for operational purposes may be necessary to reduce the practice of breaking encryption (other policies may apply in some enterprise settings) 🙏.

4.1. Monitoring Practices of the Enterprise 👑

Large corporate enterprises own the platforms, data, and network infrastructure that provide critical business services to their user communities 🏛️. That means these enterprises are responsible for all aspects of the performance, availability, security, and quality of experience for all user sessions 💅. In many of these enterprises, users are required to consent to the enterprise monitoring all their activities as a condition of employment 📝. The subsections of Section 4 talk about techniques that access data beyond the data-link, network, and transport-level headers that are typically used in service provider networks, since the corporate enterprise owns the data 🗝️. These responsibilities break down into three basic areas:

1. Security Monitoring and Control 🛡️
2. Application-Performance Monitoring and Reporting 📈
3. Network Diagnostics and Troubleshooting 🔧

In each of these areas, technical support teams use 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 downtime and deliver expected levels of performance, protection, and availability, some forms of traffic analysis are currently used, sometimes including examination of packet payloads 🎯.

4.1.1. Security Monitoring in the Enterprise 🕵️‍♀️

Enterprise users are subject to the policies of their organization and the jurisdictions where the enterprise operates 🌸. So proxies may be in use to:

1. intercept outbound session traffic to monitor for intellectual property leakage (by users, malware, and trojans) 🔍
2. detect viruses/malware entering the network via email or web traffic 📧
3. detect malware/trojans in action, possibly connecting to remote hosts 🦠
4. detect attacks (cross-site scripting and other common web-related attacks) 🚫
5. track misuse and abuse by employees 👀
6. restrict the types of protocols permitted to/from the entire corporate environment 🚧
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 😱. That includes lateral movement, Command and Control (C&C), and Data Exfiltration 🥲.

The impact on a fully encrypted internal network would include cost and a possible loss of detection capabilities, tied to the transformation of the network architecture and the tools used for monitoring 💸. The detection capabilities through traffic fingerprinting, logging, host-level transaction monitoring, and flow analysis would vary depending on access to a 2-tuple or 5-tuple in the network too 🎀.

Security monitoring in the enterprise may also be done at the endpoint, with numerous current solutions that address the same problems as some of the solutions mentioned above 💻. Since the software agents operate on the device, they can monitor traffic before it's encrypted, watch for behavior changes, and lock devices down 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 💪.

Bring-your-own-device (BYOD) policies within organizations may limit the scope of monitoring permitted with these alternate solutions 📱. Network endpoint assessment (NEA) or the use of virtual hosts could help bridge that monitoring gap 🌉.

4.1.2. Monitoring Application Performance in the Enterprise ⏱️

There are two main goals of monitoring, bestie 🎯:

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 info that application owners and the lines of business request 📊. CDNs add complexity when you're trying to figure out the ultimate endpoint destination 🌐. By their very nature, this information is obscured by CDNs and encrypted protocols, which adds a new challenge for troubleshooting network and application problems 😩. URL identification lets the application support team do granular, code-level troubleshooting at multiple tiers of an application 🧑‍🔧.

New methodologies to monitor user-perceived response time and to separate network time from server time are evolving 🦋. For example, the IPv6 Destination Option Header (DOH) implementation of Performance and Diagnostic Metrics (PDM) [RFC8250] will provide this ✨. Using PDM with IPsec Encapsulating Security Payload (ESP) Transport Mode requires placing the PDM DOH within the ESP-encrypted payload, so timing and sequence number information doesn't leak that could be useful to an attacker 🙈. Using PDM DOH may also introduce some security weaknesses, including a timing attack, as described in Section 4 of [RFC8250] 😭. For these and other reasons, [RFC8250] requires that the PDM DOH option be explicitly turned on by administrative action in each host where this measurement feature will be used 🔑.

4.1.3. Diagnostics and Troubleshooting for Enterprise Networks 🔍

One primary key to network troubleshooting is being able to follow a transaction through the various tiers of an application, so you can isolate the fault domain 🗺️. Lots of factors tied to the structure of the modern data center and multi-tiered applications have made it hard to follow a transaction in network traces without being able to examine some of the packet payload 😵‍💫. Alternate methods, like log analysis, need to improve to fill that gap 🫶.

4.1.3.1. Address Sharing (NAT) 🌸

CDNs, NATs, and Network Address and Port Translators (NAPTs) totally obscure the ultimate endpoint designation 🫣 (see [RFC6269] for types of address sharing and a list of issues). So when you're troubleshooting a problem for one specific end user, you need stuff like the IP address and other identifying info to get their issue fixed fast ⏱️✨

NAT is also super popular with the lower layers of data-center infrastructure 🏢 Firewalls, load balancers, web servers, app servers, and middleware servers all regularly NAT the source IP of packets. Now add in the fact that load balancers randomly allocate users to all these devices, and the network troubleshooter is often left with very few options 😭 in today's environment, mostly because applications have poor logging. So network troubleshooting ends up tracing packets at a particular layer, decrypting them, and looking at the payload to find a user session 🕵️‍♀️

This kind of bulk packet capture and bulk decryption is frequently used when troubleshooting a large and complex application 💅 Endpoints typically don't have the capacity to handle this level of network packet capture, so out-of-band networks of robust packet brokers and network sniffers that use techniques such as copies of TLS RSA private keys get the job done today 🔑

4.1.3.2. TCP Pipelining / Session Multiplexing 🦋

TCP pipelining / session multiplexing, used mainly by middleboxes today, lets multiple end-user sessions share the same TCP connection 🧩 This raises a few points of interest as encryption use goes up. TCP session multiplexing should still be possible when TLS or TCPcrypt is in use, since the TCP header information is exposed, which leaves the 5-tuple accessible 👀 Using TCP session multiplexing with an IP-layer encryption, e.g., IPsec, that only exposes a 2-tuple would not be possible 🙅‍♀️ Troubleshooting with encrypted sessions from the middlebox may limit you to logs from the endpoints doing the TCP multiplexing, or from the middleboxes before any additional encryption that may be added to tunnel the TCP multiplexed traffic 📋

Increased use of HTTP/2 will likely make session multiplexing even more common, both on the Internet and in the private data center 🚀 HTTP pipelining requires both the client and server to participate. Once packets are encrypted, visibility is lost, so the use of HTTP pipelining gets hidden from any monitoring that happens outside of the endpoint or proxy solution 🫥 Since HTTP pipelining happens between a client and server, logging may need to improve in some servers and clients for debugging purposes, if that isn't already possible 🛠️ Visibility for middleboxes includes anything exposed by TLS and the 5-tuple ✨

4.1.3.3. HTTP Service Calls 📞

When an application server makes an HTTP service call to back-end services on behalf of a user session, it uses a completely different URL and a completely different TCP connection 🙃 So troubleshooting via network trace means matching up the user request with the HTTP service call, which is a whole thing 😩 Some organizations do this today by decrypting the TLS packet and inspecting the payload. Logging just hasn't been adequate for their purposes 🤷‍♀️

4.1.3.4. Application-Layer Data 📦

Lots of applications use text formats such as XML to transport data or application-level information 📄 When transaction failures happen and the logs aren't enough to figure out the cause, network and application teams have to work together, and each one has a different view of the failure 👯 With this method, the network packet gets correlated with the actual problem the application experienced, so the root cause can be found 🔍 The inability to access the payload blocks this method of troubleshooting, and that's the tea 🫖

4.2. Techniques for Monitoring Internet-Session Traffic 🌐

Corporate networks commonly monitor outbound session traffic to detect or prevent attacks, and also to guarantee service-level expectations 🛡️ When encryption is in use, alternate options are sometimes available through a proxy or a shift to monitoring at the endpoint. In both cases, scaling is a concern, and advancements that support this shift in monitoring practices will help the deployment of end-to-end encryption 💜

Some DLP tools intercept traffic at the Internet gateway or proxy services, with the ability to MITM encrypted session traffic (HTTP/TLS). Ngl, that's a lot 😬 These tools may monitor for keywords important to the enterprise, including business-sensitive information such as trade secrets, financial data, PII, or PHI. Various techniques are used to intercept HTTP/TLS sessions for DLP and other purposes, and they can be misused as described in "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)" [RFC7457] (see Section 2.8) 🙈

Note: many corporate policies allow access to personal financial and other sites for users without interception. Another option is to terminate a TLS session prior to the point where monitoring is performed. Aside from exposing user information to the enterprise, MITM devices are often subject to severe security defects, which can lead to exposure of user data to attackers outside the enterprise user data [UserData] 💀 In addition, implementation errors in middleboxes have led to major difficulties in deploying new versions of security protocols such as TLS [Ben17a] [Ben17b] [Res17a] [Res17b] 😭

Monitoring traffic patterns for anomalous behavior is super common 👀 That includes increased flows of traffic that could be bursty at odd times, or flows to unusual destinations (small or large amounts of traffic). This traffic may or may not be encrypted, and various methods of encryption, or just obfuscation, may be used 🎭

Web-filtering devices are sometimes used to allow access only to well-known sites that were found to be legitimate and free of malware on the last check by a web-filtering service company 🧹 One common example of web filtering in a corporate environment is blocking access to sites that aren't well known to these tools, for the purpose of blocking malware. This may be noticeable to researchers who can't access colleagues' individual sites, or to anyone trying new websites that haven't been screened yet 🔬 When new sites are needed, they can typically be added after the user gives notification or after log alerts and review 📝 Account access for personal mail may be blocked in corporate settings to prevent another vector for malware from entering, and to stop intellectual property from leaking out of the network 🔐 This method still works with increased use of encryption, and it may be more effective at preventing malware from entering the network 💪 Some enterprises may be more aggressive in their filtering and monitoring policy, which can cause undesirable outcomes 😬

Web-filtering solutions monitor and potentially restrict access based on the destination URL (when available), server name, IP address, or DNS name 🗺️ A complete URL may be used when access restrictions vary for content on a particular site, or for the sites hosted on a particular server. In some cases, the enterprise may use a proxy to access this additional information, based on their policy 🧐 This type of restriction is intended to be transparent to users in a corporate setting, since the typical corporate user doesn't access sites that aren't well known to these tools 🫠 However, the mechanisms these web filters use for monitoring and enforcement have the potential to cause access issues or other user-visible failures 🚫

Desktop DLP tools are used in some corporate environments too 💻 Since these tools live on the desktop, they can intercept traffic before it's encrypted, and they may provide a continued way to monitor leakage of intellectual property from the desktop to the Internet or attached devices 🔒

DLP tools can also be deployed by network service providers, since 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 anyway 📱

Enterprises may wish to reduce the traffic on their Internet access facilities by monitoring requests for within-policy content and caching it 🧠 In this case, repeated requests for Internet content spawned by URLs in email trade newsletters or other sources can be served within the enterprise network 📨 Gradual deployment of end-to-end encryption would tend to reduce the cacheable content over time, owing to the concealment of critical headers and payloads 🙈 Many forms of enterprise-performance management may be similarly affected 📉 It should be noted that transparent caching is considered an anti-pattern 🚩

---

5. Security Monitoring for Specific Attack Types 🚨

Effective incident response today requires collaboration at Internet scale 🤝 This section will only focus on efforts of collaboration at Internet scale that are dedicated to specific attack types. They may require new monitoring and detection techniques in an increasingly encrypted Internet 🔐 As mentioned previously, some service providers have been interfering with STARTTLS to prevent session encryption, so they can do the stuff they're used to, like injecting ads or monitoring 👀 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, through collaboration and innovation ✨

Changes to improve encryption or to deploy OS methods have little impact on the detection of malicious actors 🫶 Malicious actors have had access to strong encryption for quite some time 😤 Incident responders, in many cases, have developed techniques to locate malicious traffic within encrypted sessions 🕵️‍♀️ The following section will note some examples where detection and mitigation of such traffic has been successful 🎉

5.1. Mail Abuse and Spam 📧

Okay bestie, the biggest squad effort against mail abuse comes from the Messaging, Malware, Mobile Anti-Abuse Working Group (M3AAWG) [M3AAWG] 💅. Mail abuse gets shut down directly by mail administrators, who can stop ongoing abuse coming from large-scale providers that take part in using the Abuse Reporting Format (ARF) agents standardized in the IETF [RFC5965] [RFC6430] [RFC6590] [RFC6591] [RFC6650] [RFC6651] [RFC6652] 🫶. The ARF agent reports abuse messages straight to the right service provider, who can then act to stop or mitigate the abuse.

Since this technique uses the actual message, SMTP over TLS between mail gateways won't affect how useful it is ✨. But remember, as we said before, SMTP over TLS only protects data while it's in transit 🙈. The messages can still be exposed on mail servers or mail gateways if a user-to-user encryption method isn't used. And current user-to-user email encryption (S/MIME and PGP) doesn't encrypt the email header information that ARF and the service provider operators rely on to mitigate abuse. Not me getting stuck on that little detail 😭.

Another effort, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)" [RFC7489], is a mechanism for policy distribution 📜. It enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection. DMARC is also not affected by the use of STARTTLS 💖.

5.2. Denial of Service 🛡️

Responses to Denial-of-Service (DoS) attacks are typically coordinated by the service provider community with a few key vendors who have tools to help with mitigation 🔥. Traffic patterns are figured out from each DoS attack so the traffic flows can be stopped or rate limited using patterns unique to that particular attack.

Data types used in monitoring traffic for DDoS are described in the documents being developed by the DDoS Open Threat Signaling (DOTS) [DOTS] Working Group 🧚. The impact of encryption can be understood from their documented use cases [DDOS-USECASE].

Data types used in DDoS attacks have been detailed in the Incident Object Description Exchange Format (IODEF) Guidance document (see [RFC8274], Appendix B.2), with the help of several members of the service provider community 👑. The examples are meant to help identify the useful data for detecting and mitigating these attacks, independent of the transport and protocol descriptions in the documents.

5.3. Phishing 🎣

Investigations and responses to phishing attacks follow well-known patterns 🕵️‍♀️. They need 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, so content reporting is possible even when end-to-end encryption is used. The email header information is useful for identifying the mail servers and accounts used to generate or relay the attack messages, so the right actions can be taken. The content of the message often includes an embedded attack, which may be an infected file or a link that results in malware being downloaded to the user's system 💀.

Administrators often find it helpful to use header information to track down similar messages in their mail queue or in users' inboxes, to prevent further infection 🌸. Combinations of To:, From:, Subject:, and Received: header information might be used for this purpose. Administrators may also search for document attachments with the same name or size, or that contain a file with a matching hash to a known phishing attack. Administrators might also add URLs contained in messages to block lists locally. This may also be done by browser vendors through larger-scale efforts, like those of the Anti-Phishing Working Group (APWG). See "Coordinating Attack Response at Internet Scale (CARIS) Workshop Report" [RFC8073] for additional information and pointers to the APWG's efforts on anti-phishing 🦋.

A full list of the fields used in phishing attack incident responses can be found in RFC 5901. Future plans to increase privacy protections may limit some of these capabilities if some email header fields are encrypted, such as the To:, From:, and Subject: header fields. This does not mean that those fields should not be encrypted. It only means we should be aware of how they're currently used 💜.

Some products protect users from phishing by maintaining lists of known phishing domains (such as misspelled bank names) and blocking access. This can be done by observing DNS, cleartext HTTP, or Server Name Indication (SNI) in TLS, in addition to analyzing email. Alternate options to detect and prevent phishing attacks may be needed. More recent examples of data exchanged in spear phishing attacks have been detailed in the IODEF Guidance document (see [RFC8274], Appendix B.3) 🔍.

5.4. Botnets 🤖

Botnet detection and mitigation is complex, since botnets may involve hundreds or thousands of hosts with numerous C&C servers 😵. The techniques and data used to monitor and detect each may vary. Connections to C&C servers are typically encrypted, so a move to an increasingly encrypted Internet may not affect the detection and sharing methods used 🫠.

5.5. Malware 🦠

Techniques for detecting and monitoring malware vary. As mentioned in Section 4, malware monitoring may occur at gateways to the organization that analyze email and web traffic. These services can also be provided by service providers, which changes the scale and location of this type of monitoring. Incident responders may also identify attributes unique to types of malware, helping them track down instances by their communication patterns on the Internet or by alterations to hosts and servers 🔎.

Data types used in malware investigations have been summarized in an example of the IODEF Guidance document (see [RFC8274], Appendix B.3) 🌈.

5.6. Spoofed-Source IP Address Protection 🕵️

The IETF has reacted to spoofed-source IP address-based attacks by recommending network ingress filtering in BCP 38 [RFC2827] and the unicast Reverse Path Forwarding (uRPF) mechanism [RFC3704] 🛑. But uRPF has granularity limitations: a malicious node can still use a spoofed IP address included inside the prefix assigned to its link. Source Address Validation Improvement (SAVI) mechanisms try to solve this issue ✨.

Basically, a SAVI mechanism monitors a specific address assignment or management protocol (e.g., Stateless Address Autoconfiguration (SLAAC) [RFC4862], Secure Neighbor Discovery (SEND) [RFC3971], and DHCPv4/v6 [RFC2131][RFC3315]). Based on that monitoring, it sets up a filtering policy that allows only the IP flows with a correct source IP address. In other words, any packet with a source IP address from a node that doesn't own it is dropped 🚫. The encryption of parts of the address assignment and management protocols, which are critical for SAVI mechanisms, can cause the SAVI mechanisms to stop working properly 😭.

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. In those approaches, 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 are visible to the network if a 5-tuple is exposed. These techniques can potentially be used as input for future network-management approaches 🧠. It also includes an overview of IP Flow Information Export (IPFIX), a flow-based protocol used to export information about network flows.

6.1. IP Flow Information Export 📤

Many of the accounting, monitoring, and measurement tasks described in this document, especially in Sections 2.3.2, 3.1.1, 4.1.3, 4.2, and 5.2, use the IPFIX protocol [RFC7011] for export and storage of the monitored information 💾. IPFIX evolved from the widely deployed NetFlow protocol [RFC3954], which exports information about flows identified by 5-tuple. NetFlow was mostly concerned with exporting per-flow byte and packet counts for accounting purposes. IPFIX's extensible Information Model [RFC7012], on the other hand, provides a variety of Information Elements (IEs) [IPFIX-IANA] for representing information above and below the traditional network-layer flow information 🎀. Enterprise-specific IEs also let exporter vendors define their own non-standard IEs, 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 can't decrypt former cleartext information 😤. For example, HTTPS makes HTTP header analysis impossible, so IEs derived from the header (e.g., httpContentType, httpUserAgent) can't be exported.

The collection of IPFIX data is, of course, a point of centralization for information that is potentially business and privacy critical 🔐. The IPFIX File Format specification [RFC5655] recommends encryption for this data at rest. The IP Flow Anonymization specification [RFC6235] defines a metadata format for describing the anonymization functions applied to an IPFIX dataset, if anonymization is used for sharing IPFIX information between enterprises or network operators 🫶.

6.2. TLS Server Name Indication ✨

Okay bestie, so when a client starts a TLS handshake, it may send an extension field called server_name to tell the server which site it's trying to securely reach 🦋. TLS SNI got standardized back in 2003 so that servers hosting a bunch of virtual servers on the same infrastructure and IP address could show each client the "correct TLS certificate" 🎀. It's technically optional, but it's literally supported by all modern browsers, web servers, and developer libraries, so it's giving universal. Akamai [Nygren] reports that many of their customers see client TLS SNI usage over 99%. Iconic 😭.

It's also worth noting that HTTP/2 brings in the Alt-SVC method for upgrading a connection from HTTP/1 to either unencrypted or encrypted HTTP/2 🔥. If the first HTTP/1 request is unencrypted, the destination alternate service name can be identified before the communication might get upgraded to encrypted HTTP/2 transport. HTTP/2 requires the TLS implementation to support the SNI extension (see Section 9.2 of [RFC7540]). Plus, [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 info is only available if the client actually fills in the SNI extension. That's an optional part of the TLS standard, and like we said, every major browser has implemented it 💅. But because it's optional, existing network filters that look at a TLS ClientHello for an SNI extension can't assume they'll always find one 🙈. "SNI Encryption in TLS Through Tunneling" [SNI-TLS] has been adopted by the TLS Working Group, and it offers solutions to encrypt SNI, so there will be an option to encrypt SNI in future versions of TLS 🔐✨. SNI is per-domain, so it might not reveal the specific service or media type being accessed, especially when the domain belongs to a provider offering email, video, web pages, and more 🌸. For example, certain blog or social network feeds might be deemed "adult content", but the SNI will only show the server domain and not the URL path.

There are extra wrinkles for identifying content using SNI too 👀: [RFC7540] includes connection coalescing, [RFC8336] defines the ORIGIN frame, and the proposal outlined in [HTTP2-CERTS] will make passive monitoring even harder. Main character plot twist 🦋.

---

6.3. Application-Layer Protocol Negotiation (ALPN) 🌈

ALPN is a TLS extension that may be used to indicate the application protocol inside the TLS session 💜. This is probably more useful to the network when it points at a protocol dedicated to one particular traffic type (like video streaming) instead of a multi-use protocol. ALPN is used as part of HTTP/2 'h2', but it won't tell you the traffic types that might make up streams inside an HTTP/2 multiplex 🙃. Also, ALPN is sent cleartext in the ClientHello, and the server sends it back in Encrypted Extensions in TLS 1.3. Cleartext means anyone can read it, so keep that in mind 👀.

---

6.4. Content Length, Bitrate, and Pacing 🍓

The content length of encrypted traffic is basically the same as the cleartext. Block ciphers do use padding, but that makes a negligible difference 🤷‍♀️. Bitrate and pacing are usually application specific and don't change much when the content is encrypted 🎀. Multiplexed formats, though (like HTTP/2 and QUIC [QUIC]), can pack several application streams into one connection, which means the bitrate and pacing are no longer application specific 😳. Also, packet padding is available in HTTP/2, TLS 1.3, and plenty of other protocols, and those countermeasures make traffic analysis harder 🫶.

---

7. Effect of Encryption on the Evolution of Mobile Networks 📱

Okay, so transport header encryption stops transit proxies in the middle of the network from working, and it also stops some edge proxies from acting on the stream 🚫. The claimed benefits of those proxies might be achievable with end-to-end client and server optimizations, distribution using CDNs, and the ability to keep connections going across different access technologies (even when user IP addresses change) ✨. Here's what to think about with this approach:

1. In a wireless mobile network, the delay and channel capacity per user and sector vary because of coverage, contention, user mobility, and scheduling (which balances fairness, capacity, and service QoE). If most users are at the cell edge, the controller can't use more complex Quadrature Amplitude Modulation (QAM), which cuts total cell capacity. Similarly, if a Universal Mobile Telecommunications System (UMTS) edge is serving some number of CS-Voice Calls, the leftover capacity for packet services shrinks 📉.
2. Mobile wireless networks serve inbound roamers (users of Operator A in the foreign network of Operator B) by backhauling their traffic through the network (from Operator B to Operator A), then serving them through the P-Gateway (PGW), General Packet Radio Service (GPRS) Support Node (GGSN), CDN, etc. of Operator A, the user's home operator 🌍. Increasing window sizes to compensate for the path RTT runs into the TCP limitations outlined earlier. The outbound roamer scenario has a similar TCP performance impact 😤.
3. Deploying CDNs in Radio Access Networks (RANs) has some issues, including reducing the client-server control loop, which means deploying CDNs or cloud functions that terminate encryption closer to the edge 🏃‍♀️. In Cellular RAN, user IP traffic is encapsulated in GPRS Tunneling Protocol-User Plane (GTP-U in UMTS and LTE) tunnels to handle user mobility, and those tunnels terminate in APN/GGSN/PGW boxes that sit in central locations 🏢. One user's traffic can flow through one or more APN's (for example, Internet APN, Roaming APN for Operator X, Video-Service APN, OnDeckAPN, etc.). Operator private IP addresses might be limited to specific APNs. Since CDNs generally operate on user IP flows, deploying them would mean enhancing them with tunnel translation, tunnel-management functions, and so on 🛠️.
4. CDNs that decrypt flows or split connection proxies (similar to split TCP) could be deployed closer to the edges to reduce the control-loop RTT. But with transport header encryption, those CDNs only perform optimization functions for partner client flows 🥲. So content from some Small-Medium Businesses (SMBs) wouldn't get those CDN benefits.

---

8. Response to Increased Encryption and Looking Forward 🔮

As [RFC7258] puts it, "an appropriate balance [between network management and pervasive monitoring mitigations] will emerge over time as real instances of this tension are considered." 💜 Lots of operators made it super clear in their responses to this document that they fully support strong encryption and privacy for end users. That's a shared goal, bestie 🫶. Operators also get that not every practice in this document needs to keep being supported going forward, either because it puts end-user privacy at risk or because better technologies and tools have already shown up 🌟.

This document is meant to help network engineers and other innovators work with protocol designers and application developers on network and security management problems in new ways, ways that make strong encryption easier to adopt instead of blocking it 🔐. When network and security management folks talk with application developers and protocol designers, each side gets what the other is going for, works on alternate solutions, and retires the practices that shouldn't be supported anymore 🧹. One goal of this document is to help the IETF understand some of today's practices, so it can spot new work items for IETF-related use cases that make strong session encryption easier to adopt while still supporting network and security management 🦋.

---

9. Security Considerations 🚨

There are no additional security considerations because this is a summary and doesn't include a new protocol or functionality. Dramatic, I know, but it's true 💀.

---

10. IANA Considerations 🎀

This document has no IANA actions. Zero registry drama 💅.

---

11. Informative References 📚

• [ACCORD] IETF, "Alternatives to Content Classification for Operator Resource Deployment (accord) (BOF)", IETF-95 Proceedings, April 2016, https://www.ietf.org/proceedings/95/accord.html.
• [Ben17a] Benjamin, D., "Chrome Data", Presentation before the TLS WG at IETF 100, November 2017, https://datatracker.ietf.org/meeting/100/materials/slides-100-tls-sessa-tls13/.
• [Ben17b] Benjamin, D., "Subject: Additional TLS 1.3 results from Chrome", message to the TLS mailing list, 18 December 2017, https://www.ietf.org/mail-archive/web/tls/current/msg25168.html.
• [CAIDA] CAIDA, "The CAIDA USCD Anonymized Internet Traces 2016 Dataset", http://www.caida.org/data/passive/passive_2016_dataset.xml.
• [DarkMail] "Dark Mail Technical Alliance", https://darkmail.info/.
• [DDOS-USECASE] Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS Open Threat Signaling", Work in Progress, draft-ietf-dots-use-cases-16, July 2018.
• [DOTS] IETF, "DDoS Open Threat Signaling (dots)", https://datatracker.ietf.org/wg/dots/charter.
• [EFF2014] Hoffman-Andrews, J., "ISPs Removing Their Customers' Email Encryption", November 2014, https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks.
• [Enrich] Narseo Vallina-Rodriguez, N., Sundaresan, S., Kreibich, C., and V. Paxson, "Header Enrichment or ISP Enrichment: Emerging Privacy Threats in Mobile Networks", Proceedings of the ACM SIGCOMM Workshop on Hot Topics in Middleboxes and Network Function Virtualization, pp. 23-30, DOI 10.1145/2785989.2786002, August 2015.
• [GENEVE-REQS] Migault, D., Boutros, S., Wing, D., and S. Krishnan, "Geneve Protocol Security Requirements", Work in Progress, draft-mglt-nvo3-geneve-security-requirements-03, February 2018.
• [HTTP2-CERTS] Bishop, M., Sullivan, N., and M. Thomson, "Secondary Certificate Authentication in HTTP/2", Work in Progress, draft-ietf-httpbis-http2-secondary-certs-02, June 2018.
• [IPFIX-IANA] IANA, "IP Flow Information Export (IPFIX) Entities", https://www.iana.org/assignments/ipfix/.
• [JNSLP] Eskens, S., "10 Standards for Oversight and Transparency of National Intelligence Services", Surveillance, Vol. 8, No. 3, July 2016, http://jnslp.com/?s=10+Standards+for+Oversight+and+Transparency+of+National.
• [M3AAWG] M3AAWG, "Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG)", https://www.maawg.org/.
• [MIDDLEBOXES] Dolson, D., Snellman, J., Boucadair, M., and C. Jacquenet, "An Inventory of Transport-centric Functions Provided by Middleboxes", Work in Progress, draft-dolson-transport-middlebox-03, June 2018.
• [Nygren] Nygren, E., "Reaching toward Universal TLS SNI", Akamai Technologies, March 2017, https://blogs.akamai.com/2017/03/reaching-toward-universal-tls-sni.html.
• [QUIC] IETF, "QUIC (quic)", https://datatracker.ietf.org/wg/quic/charter/.
• [Res17a] Rescorla, E., "Subject: Preliminary data on Firefox TLS 1.3 Middlebox experiment", message to the TLS mailing list, 5 December 2017, https://www.ietf.org/mail-archive/web/tls/current/msg25091.html.
• [Res17b] Rescorla, E., "Subject: More compatibility measurement results", message to the TLS mailing list, 22 December 2017, https://www.ietf.org/mail-archive/web/tls/current/msg25179.html.
• [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, DOI 10.17487/RFC1945, May 1996, https://www.rfc-editor.org/info/rfc1945.
• [RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, https://www.rfc-editor.org/info/rfc1958.
• [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic Technology and the Internet", BCP 200, RFC 1984, DOI 10.17487/RFC1984, August 1996, https://www.rfc-editor.org/info/rfc1984.
• [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, https://www.rfc-editor.org/info/rfc2131.
• [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, https://www.rfc-editor.org/info/rfc2474.
• [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, https://www.rfc-editor.org/info/rfc2663.
• [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, DOI 10.17487/RFC2775, February 2000, https://www.rfc-editor.org/info/rfc2775.
• [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, DOI 10.17487/RFC2804, May 2000, https://www.rfc-editor.org/info/rfc2804.
• [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, https://www.rfc-editor.org/info/rfc2827.
• [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, DOI 10.17487/RFC3135, June 2001, https://www.rfc-editor.org/info/rfc3135.
• [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, https://www.rfc-editor.org/info/rfc3315.
• [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, https://www.rfc-editor.org/info/rfc3550.
• [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, https://www.rfc-editor.org/info/rfc3704.
• [RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture", RFC 3724, DOI 10.17487/RFC3724, March 2004, https://www.rfc-editor.org/info/rfc3724.
• [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004, https://www.rfc-editor.org/info/rfc3954.
• [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, https://www.rfc-editor.org/info/rfc3971.
• [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, https://www.rfc-editor.org/info/rfc4787.
• [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, https://www.rfc-editor.org/info/rfc4862.
• [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, "Specification of the IP Flow Information Export (IPFIX) File Format", RFC 5655, DOI 10.17487/RFC5655, October 2009, https://www.rfc-editor.org/info/rfc5655.
• [RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, DOI 10.17487/RFC5965, August 2010, https://www.rfc-editor.org/info/rfc5965.
• [RFC6108] Chung, C., Kasyanov, A., Livingood, J., Mody, N., and B. Van Lieu, "Comcast's Web Notification System Design", RFC 6108, DOI 10.17487/RFC6108, February 2011, https://www.rfc-editor.org/info/rfc6108.
• [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization Support", RFC 6235, DOI 10.17487/RFC6235, May 2011, https://www.rfc-editor.org/info/rfc6235.
• [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, https://www.rfc-editor.org/info/rfc6269.
• [RFC6430] Li, K. and B. Leiba, "Email Feedback Report Type Value: not-spam", RFC 6430, DOI 10.17487/RFC6430, November 2011, https://www.rfc-editor.org/info/rfc6430.
• [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, https://www.rfc-editor.org/info/rfc6455.
• [RFC6590] Falk, J., Ed. and M. Kucherawy, Ed., "Redaction of Potentially Sensitive Data from Mail Abuse Reports", RFC 6590, DOI 10.17487/RFC6590, April 2012, https://www.rfc-editor.org/info/rfc6590.
• [RFC6591] Fontana, H., "Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6591, DOI 10.17487/RFC6591, April 2012, https://www.rfc-editor.org/info/rfc6591.
• [RFC6650] Falk, J. and M. Kucherawy, Ed., "Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)", RFC 6650, DOI 10.17487/RFC6650, June 2012, https://www.rfc-editor.org/info/rfc6650.
• [RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting", RFC 6651, DOI 10.17487/RFC6651, June 2012, https://www.rfc-editor.org/info/rfc6651.
• [RFC6652] Kitterman, S., "Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6652, DOI 10.17487/RFC6652, June 2012, https://www.rfc-editor.org/info/rfc6652.
• [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, https://www.rfc-editor.org/info/rfc7011.
• [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, September 2013, https://www.rfc-editor.org/info/rfc7012.
• [RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, "Internet Small Computer System Interface (iSCSI) Protocol (Consolidated)", RFC 7143, DOI 10.17487/RFC7143, April 2014, https://www.rfc-editor.org/info/rfc7143.
• [RFC7146] Black, D. and P. Koning, "Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3", RFC 7146, DOI 10.17487/RFC7146, April 2014, https://www.rfc-editor.org/info/rfc7146.
• [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, https://www.rfc-editor.org/info/rfc7230.
• [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, https://www.rfc-editor.org/info/rfc7234.
• [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, https://www.rfc-editor.org/info/rfc7258.
• [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, https://www.rfc-editor.org/info/rfc7348.
• [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, https://www.rfc-editor.org/info/rfc7435.
• [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, February 2015, https://www.rfc-editor.org/info/rfc7457.
• [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, https://www.rfc-editor.org/info/rfc7489.
• [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015, https://www.rfc-editor.org/info/rfc7498.
• [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, https://www.rfc-editor.org/info/rfc7525.
• [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, https://www.rfc-editor.org/info/rfc7540.
• [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, https://www.rfc-editor.org/info/rfc7619.

Okay bestie, the references are the receipts 🧾✨ every citation the RFC leans on is in here, and I've kept each one exactly as written. Here's who helped make this happen 🫶

   [RFC7624]  Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
              Trammell, B., Huitema, C., and D. Borkmann,
              "Confidentiality in the Face of Pervasive Surveillance: A
              Threat Model and Problem Statement", RFC 7624,
              DOI 10.17487/RFC7624, August 2015,
              <https://www.rfc-editor.org/info/rfc7624>.

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <https://www.rfc-editor.org/info/rfc7665>.

   [RFC7754]  Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E.
              Nordmark, "Technical Considerations for Internet Service
              Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754,
              March 2016, <https://www.rfc-editor.org/info/rfc7754>.

   [RFC7799]  Morton, A., "Active and Passive Metrics and Methods (with
              Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
              May 2016, <https://www.rfc-editor.org/info/rfc7799>.

   [RFC7826]  Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
              and M. Stiemerling, Ed., "Real-Time Streaming Protocol
              Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December
              2016, <https://www.rfc-editor.org/info/rfc7826>.

   [RFC7838]  Nottingham, M., McManus, P., and J. Reschke, "HTTP
              Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
              April 2016, <https://www.rfc-editor.org/info/rfc7838>.

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "Specification for DNS over Transport
              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
              2016, <https://www.rfc-editor.org/info/rfc7858>.

   [RFC8073]  Moriarty, K. and M. Ford, "Coordinating Attack Response at
              Internet Scale (CARIS) Workshop Report", RFC 8073,
              DOI 10.17487/RFC8073, March 2017,
              <https://www.rfc-editor.org/info/rfc8073>.

   [RFC8164]  Nottingham, M. and M. Thomson, "Opportunistic Security for
              HTTP/2", RFC 8164, DOI 10.17487/RFC8164, May 2017,
              <https://www.rfc-editor.org/info/rfc8164>.

   [RFC8165]  Hardie, T., "Design Considerations for Metadata
              Insertion", RFC 8165, DOI 10.17487/RFC8165, May 2017,
              <https://www.rfc-editor.org/info/rfc8165>.

   [RFC8250]  Elkins, N., Hamilton, R., and M. Ackermann, "IPv6
              Performance and Diagnostic Metrics (PDM) Destination
              Option", RFC 8250, DOI 10.17487/RFC8250, September 2017,
              <https://www.rfc-editor.org/info/rfc8250>.

   [RFC8274]  Kampanakis, P. and M. Suzuki, "Incident Object Description
              Exchange Format Usage Guidance", RFC 8274,
              DOI 10.17487/RFC8274, November 2017,
              <https://www.rfc-editor.org/info/rfc8274>.

   [RFC8300]  Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
              "Network Service Header (NSH)", RFC 8300,
              DOI 10.17487/RFC8300, January 2018,
              <https://www.rfc-editor.org/info/rfc8300>.

   [RFC8336]  Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame",
              RFC 8336, DOI 10.17487/RFC8336, March 2018,
              <https://www.rfc-editor.org/info/rfc8336>.

   [SACM]     IETF, "Security Automation and Continuous Monitoring
              (sacm)", <https://datatracker.ietf.org/wg/sacm/charter/>.

   [SNI-TLS]  Huitema, C. and E. Rescorla, "Issues and Requirements for
              SNI Encryption in TLS", Work in Progress, draft-ietf-tls-
              sni-encryption-03, May 2018.

   [Snowden]  Verble, J., "The NSA and Edward Snowden: Surveillance in
              the 21st Century", SIGCAS Computer & Society, Vol. 44,
              No. 3, DOI 10.1145/2684097.2684101, September 2014,
              <http://www.jjsylvia.com/bigdatacourse/wp-content/
              uploads/2016/04/p14-verble-1.pdf>.

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

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

   [UPCON]    3GPP, "User Plane Congestion Management", 3GPP Rel-13,
              September 2014, <http://www.3gpp.org/DynaReport/
              FeatureOrStudyItemFile-570029.htm>.

   [UserData]
              Durumeric, Z., Ma, Z., Springall, D., Barnes, R.,
              Sullivan, N., Bursztein, E., Bailey, M., Alex Halderman,
              J., and V. Paxson, "The Security Impact of HTTPS
              Interception", Network and Distributed Systems Symposium,
              February 2017,
              <http://dx.doi.org/10.14722/ndss.2017.23456>.

Acknowledgements 🫶

Huge thank-you to our reviewers, Natasha Rooney, Kevin Smith, Ashutosh Dutta, Brandon Williams, Jean-Michel Combes, Nalini Elkins, Paul Barrett, Badri Subramanyan, Igor Lubashev, Suresh Krishnan, Dave Dolson, Mohamed Boucadair, Stephen Farrell, Warren Kumari, Alia Atlas, Roman Danyliw, Mirja Kuehlewind, Ines Robles, Joe Clarke, Kyle Rose, Christian Huitema, and Chris Morrow, who gave us editorial and content suggestions that were literally so helpful 💖 Surya K. Kovvali brought the material for Section 7 🌸 Chris Morrow and Nik Teague did the reviews and updates for the DoS fingerprinting text 🔥 And Brian Trammell wrote the IPFIX text, which is iconic 👑

Authors' Addresses 💅

The editors who held this whole thing together are below 🦋

   Kathleen Moriarty (editor)
   Dell EMC
   176 South St
   Hopkinton, MA
   United States of America

   Email: Kathleen.Moriarty@dell.com


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

   Phone: +1 732 420 1571
   Fax:   +1 732 368 1192
   Email: acm@research.att.com