idnits 2.17.00 (12 Aug 2021) /tmp/idnits39521/draft-mm-wg-effect-encrypt-25.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 15, 2018) is 1521 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Ben17a' is mentioned on line 1617, but not defined == Missing Reference: 'Ben17b' is mentioned on line 1617, but not defined == Missing Reference: 'Res17a' is mentioned on line 1617, but not defined == Missing Reference: 'Res17b' is mentioned on line 1617, but not defined == Unused Reference: 'TLS100Proceedings' is defined on line 2414, but no explicit reference was found in the text == Outdated reference: draft-ietf-dots-use-cases has been published as RFC 8903 == Outdated reference: draft-ietf-httpbis-origin-frame has been published as RFC 8336 == Outdated reference: draft-ietf-tls-sni-encryption has been published as RFC 8744 == Outdated reference: A later version (-06) exists of draft-mglt-nvo3-geneve-security-requirements-03 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Moriarty, Ed. 3 Internet-Draft Dell EMC 4 Intended status: Informational A. Morton, Ed. 5 Expires: September 16, 2018 AT&T Labs 6 March 15, 2018 8 Effects of Pervasive Encryption on Operators 9 draft-mm-wg-effect-encrypt-25 11 Abstract 13 Pervasive Monitoring (PM) attacks on the privacy of Internet users 14 are of serious concern to both the user and the operator communities. 15 RFC7258 discussed the critical need to protect users' privacy when 16 developing IETF specifications and also recognized making networks 17 unmanageable to mitigate PM is not an acceptable outcome; an 18 appropriate balance is needed. This document discusses current 19 security and network operations and management practices that may be 20 impacted by the shift to increased use of encryption to help guide 21 protocol development in support of manageable and secure networks. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 16, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Additional Background on Encryption Changes . . . . . . . 4 59 1.2. Examples of Attempts to Preserve Functions . . . . . . . 6 60 2. Network Service Provider Monitoring . . . . . . . . . . . . . 7 61 2.1. Passive Monitoring . . . . . . . . . . . . . . . . . . . 8 62 2.1.1. Traffic Surveys . . . . . . . . . . . . . . . . . . . 8 63 2.1.2. Troubleshooting . . . . . . . . . . . . . . . . . . . 8 64 2.1.3. Traffic Analysis Fingerprinting . . . . . . . . . . . 11 65 2.2. Traffic Optimization and Management . . . . . . . . . . . 12 66 2.2.1. Load Balancers . . . . . . . . . . . . . . . . . . . 12 67 2.2.2. Differential Treatment based on Deep Packet 68 Inspection (DPI) . . . . . . . . . . . . . . . . . . 14 69 2.2.3. Network Congestion Management . . . . . . . . . . . . 15 70 2.2.4. Performance-enhancing Proxies . . . . . . . . . . . . 15 71 2.2.5. Caching and Content Replication Near the Network Edge 16 72 2.2.6. Content Compression . . . . . . . . . . . . . . . . . 17 73 2.2.7. Service Function Chaining . . . . . . . . . . . . . . 18 74 2.3. Content Filtering, Network Access, and Accounting . . . . 18 75 2.3.1. Content Filtering . . . . . . . . . . . . . . . . . . 19 76 2.3.2. Network Access and Data Usage . . . . . . . . . . . . 20 77 2.3.3. Application Layer Gateways . . . . . . . . . . . . . 21 78 2.3.4. HTTP Header Insertion . . . . . . . . . . . . . . . . 22 79 3. Encryption in Hosting and Application SP Environments . . . . 22 80 3.1. Management Access Security . . . . . . . . . . . . . . . 22 81 3.1.1. Customer Access Monitoring . . . . . . . . . . . . . 23 82 3.1.2. SP Content Monitoring of Applications . . . . . . . . 24 83 3.2. Hosted Applications . . . . . . . . . . . . . . . . . . . 26 84 3.2.1. Monitoring Managed Applications . . . . . . . . . . . 26 85 3.2.2. Mail Service Providers . . . . . . . . . . . . . . . 27 86 3.3. Data Storage . . . . . . . . . . . . . . . . . . . . . . 27 87 3.3.1. Object-level Encryption . . . . . . . . . . . . . . . 27 88 3.3.2. Disk Encryption, Data at Rest . . . . . . . . . . . . 28 89 3.3.3. Cross Data Center Replication Services . . . . . . . 29 90 4. Encryption for Enterprises . . . . . . . . . . . . . . . . . 29 91 4.1. Monitoring Practices of the Enterprise . . . . . . . . . 30 92 4.1.1. Security Monitoring in the Enterprise . . . . . . . . 30 93 4.1.2. Application Performance Monitoring in the Enterprise 31 94 4.1.3. Enterprise Network Diagnostics and Troubleshooting . 32 95 4.2. Techniques for Monitoring Internet Session Traffic . . . 34 96 5. Security Monitoring for Specific Attack Types . . . . . . . . 36 97 5.1. Mail Abuse and spam . . . . . . . . . . . . . . . . . . . 36 98 5.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 37 99 5.3. Phishing . . . . . . . . . . . . . . . . . . . . . . . . 37 100 5.4. Botnets . . . . . . . . . . . . . . . . . . . . . . . . . 38 101 5.5. Malware . . . . . . . . . . . . . . . . . . . . . . . . . 38 102 5.6. Spoofed Source IP Address Protection . . . . . . . . . . 39 103 5.7. Further work . . . . . . . . . . . . . . . . . . . . . . 39 104 6. Application-based Flow Information Visible to a Network . . . 39 105 6.1. IP Flow Information Export . . . . . . . . . . . . . . . 39 106 6.2. TLS Server Name Indication . . . . . . . . . . . . . . . 40 107 6.3. Application Layer Protocol Negotiation (ALPN) . . . . . . 41 108 6.4. Content Length, BitRate and Pacing . . . . . . . . . . . 41 109 7. Effect of Encryption on Mobile Network Evolution . . . . . . 41 110 8. Response to Increased Encryption and Looking Forward . . . . 42 111 9. Security Considerations . . . . . . . . . . . . . . . . . . . 43 112 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 113 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 114 12. Informative References . . . . . . . . . . . . . . . . . . . 43 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 117 1. Introduction 119 In response to pervasive monitoring revelations and the IETF 120 consensus that Pervasive Monitoring is an Attack [RFC7258], efforts 121 are underway to increase encryption of Internet traffic. Pervasive 122 Monitoring (PM) is of serious concern to users, operators, and 123 application providers. RFC7258 discussed the critical need to 124 protect users' privacy when developing IETF specifications and also 125 recognized that making networks unmanageable to mitigate PM is not an 126 acceptable outcome, but rather that an appropriate balance would 127 emerge over time. 129 This document describes practices currently used by network operators 130 to manage, operate, and secure their networks and how those practices 131 may be impacted by a shift to increased use of encryption. It 132 provides network operators' perspectives about the motivations and 133 objectives of those practices as well as effects anticipated by 134 operators as use of encryption increases. It is a summary of 135 concerns of the operational community as they transition to managing 136 networks with less visibility. The document does not endorse the use 137 of the practices described herein. Nor does it aim to provide a 138 comprehensive treatment of the effects of current practices, some of 139 which have been considered controversial from a technical or business 140 perspective or contradictory to previous IETF statements (e.g., 141 [RFC1958], [RFC1984], [RFC2804]). The informational documents 142 consider the end to end (e2e) architectural principle to be a guiding 143 principle for the development of Internet protocols [RFC2775] 144 [RFC3724] [RFC7754]. 146 This document aims to help IETF participants understand network 147 operators' perspectives about the impact of pervasive encryption, 148 both opportunistic and strong end-to-end encryption, on operational 149 practices. The goal is to help inform future protocol development to 150 ensure that operational impact is part of the conversation. Perhaps, 151 new methods could be developed to accomplish some of the goals of 152 current practices despite changes in the extent to which cleartext 153 will be available to network operators (including methods that rely 154 on network endpoints where applicable). Discussion of current 155 practices and the potential future changes is provided as a 156 prerequisite to potential future cross-industry and cross-layer work 157 to support the ongoing evolution towards a functional Internet with 158 pervasive encryption. 160 Traditional network management, planning, security operations, and 161 performance optimization have been developed in an Internet where a 162 large majority of data traffic flows without encryption. While 163 unencrypted traffic has made information that aids operations and 164 troubleshooting at all layers accessible, it has also made pervasive 165 monitoring by unseen parties possible. With broad support and 166 increased awareness of the need to consider privacy in all aspects 167 across the Internet, it is important to catalog existing management, 168 operational, and security practices that have depended upon the 169 availability of cleartext to function and to explore if critical 170 operational practices can be met by less invasive means. 172 This document refers to several different forms of service providers, 173 distinguished with adjectives. For example, network service 174 providers (or network operators) provide IP-packet transport 175 primarily, though they may bundle other services with packet 176 transport. Alternatively, application service providers primarily 177 offer systems that participate as an end-point in communications with 178 the application user, and hosting service providers lease computing, 179 storage, and communications systems in datacenters. In practice, 180 many companies perform two or more service provider roles, but may be 181 historically associated with one. 183 This document includes a sampling of current practices and does not 184 attempt to describe every nuance. Some sections cover technologies 185 used over a broad spectrum of devices and use cases. 187 1.1. Additional Background on Encryption Changes 189 Pervasive encryption in this document refers to all types of session 190 encryption including Transport Layer Security (TLS), IP security 191 (IPsec), TCPcrypt [TCPcrypt], QUIC [QUIC] and others that are 192 increasing in deployment usage. It is well understood that session 193 encryption helps to prevent both passive and active attacks on 194 transport protocols; more on pervasive monitoring can be found in 195 Confidentiality in the Face of Pervasive Surveillance: A Threat Model 196 and Problem Statement [RFC7624]. Active attacks have long been a 197 motivation for increased encryption, and preventing pervasive 198 monitoring became a focus just a few years ago. As such, the 199 Internet Architecture Board (IAB) released a statement advocating for 200 increased use of encryption in November 2014. Perspectives on 201 encryption paradigms have shifted over time to incorporporate ease of 202 deployment as a high priority, and balance that against providing the 203 maximum possible level of security regardless of deployment 204 considerations. 206 One such shift is documented in "Opportunistic Security" (OS) 207 [RFC7435], which suggests that when use of authenticated encryption 208 is not possible, cleartext sessions should be upgraded to 209 unauthenticated session encryption, rather than no encryption. OS 210 encourages upgrading from cleartext, but cannot require or guarantee 211 such upgrades. Once OS is used, it allows for an evolution to 212 authenticated encryption. These efforts are necessary to improve end 213 user's expectation of privacy, making pervasive monitoring cost 214 prohibitive. With OS in use, active attacks are still possible on 215 unauthenticated sessions. OS has been implemented as NULL 216 Authentication with IPsec [RFC7619] and there are a number of 217 infrastructure use cases such as server to server encryption where 218 this mode is deployed. While OS is helpful in reducing pervasive 219 monitoring by increasing the cost to monitor, it is recognized that 220 risk profiles for some applications require authenticated and secure 221 session encryption as well to prevent active attacks. IPsec, and 222 other session encryption protocols, with authentication has many 223 useful applications and usage has increased for infrastructure 224 applications such as for virtual private networks between data 225 centers. OS as well as other protocol developments, like the 226 Automated Certificate Management Environment (ACME), have increased 227 the usage of session encryption on the Internet. 229 Risk profiles vary and so do the types of session encryption 230 deployed. To understand the scope of changes in visibility a few 231 examples are highlighted. Work continues to improve the 232 implementation, development and configuration of TLS and DTLS 233 sessions to prevent active attacks used to monitor or intercept 234 session data. The changes from TLS 1.2 to 1.3 enhance the security 235 of TLS, while hiding more of the session negotiation and providing 236 less visibility on the wire. The Using TLS in Applications (UTA) 237 working group has been publishing documentation to improve the 238 security of TLS and DTLS sessions. They have documented the known 239 attack vectors in [RFC7457] and have documented Best Practices for 240 TLS and DTLS in [RFC7525] and have other documents in the queue. The 241 recommendations from these documents were built upon for TLS 1.3 to 242 provide a more inherently secure end-to-end protocol. 244 In addition to encrypted web site access (HTTP over TLS), there are 245 other well-deployed application level transport encryption efforts 246 such as mail transfer agent (MTA)-to-MTA session encryption transport 247 for email (SMTP over TLS) and gateway-to-gateway for instant 248 messaging (Extensible Messaging and Presence Protocol (XMPP) over 249 TLS). Although this does provide protection from transport layer 250 attacks, the servers could be a point of vulnerability if user-to- 251 user encryption is not provided for these messaging protocols. User- 252 to-user content encryption schemes, such as S/MIME and PGP for email 253 and Off-the-Record (OTR) encryption for XMPP are used by those 254 interested to protect their data as it crosses intermediary servers, 255 preventing transport layer attacks by providing an end-to-end 256 solution. User-to-user schemes are under review and additional 257 options will emerge to ease the configuration requirements, making 258 this type of option more accessible to non-technical users interested 259 in protecting their privacy. 261 Increased use of encryption, either opportunistic or authenticated, 262 at the transport, network or application layer, impacts how networks 263 are operated, managed, and secured. In some cases, new methods to 264 operate, manage, and secure networks will evolve in response. In 265 other cases, currently available capabilities for monitoring or 266 troubleshooting networks could become unavailable. This document 267 lists a collection of functions currently employed by network 268 operators that may be impacted by the shift to increased use of 269 encryption. This draft does not attempt to specify responses or 270 solutions to these impacts, but rather documents the current state. 272 1.2. Examples of Attempts to Preserve Functions 274 Following the Snowden [Snowden] revelations, application service 275 providers responded by encrypting traffic between their data centers 276 (IPsec) to prevent passive monitoring from taking place unbeknownst 277 to them (Yahoo, Google, etc.). Infrastructure traffic carried over 278 the public Internet has been encrypted for some time, this change for 279 universal encryption was specific to their private backbones. Large 280 mail service providers also began to encrypt session transport (TLS) 281 to hosted mail services. This and other increases in the use of 282 encryption had the immediate effect of providing confidentiality and 283 integrity for protected data, but created a problem for some network 284 management functions. Operators could no longer gain access to some 285 session streams resulting in actions by several to regain their 286 operational practices that previously depended on cleartext data 287 sessions. 289 The EFF reported [EFF2014] several network service providers using a 290 downgrade attack to prevent the use of SMTP over TLS by breaking 291 STARTTLS (section 3.2 of [RFC7525]), essentially preventing the 292 negotiation process resulting in fallback to the use of clear text. 293 There have already been documented cases of service providers 294 preventing STARTTLS to prevent session encryption negotiation on some 295 session to inject a super cookie to enable tracking of users for 296 advertisers, also considered an attack. These serve as examples of 297 undesirable behavior that could be prevented through upfront 298 discussions in protocol work for operators and protocol designers to 299 understand the implications of such actions. In other cases, some 300 service providers and enterprises have relied on middleboxes having 301 access to clear text for the purposes of load balancing, monitoring 302 for attack traffic, meeting regulatory requirements, or for other 303 purposes. The implications for enterprises, who own the data on 304 their networks or have explicit agreements that permit monitoring of 305 user traffic is very different from service providers who may be 306 accessing content in a way that violates privacy considerations. 307 Additionally, service provider equipment is designed for accessing 308 only the headers exposed for the data-link, network, and transport 309 layers. Delving deeper into packets is possible, but there is 310 typically a high degree of accuracy from the header information and 311 packet sizes when limited to header information from these three 312 layers. Service providers also have the option of adding routing 313 overlay protocols to traffic. These middlebox implementations, 314 whether performing functions considered legitimate by the IETF or 315 not, have been impacted by increases in encrypted traffic. Only 316 methods keeping with the goal of balancing network management and PM 317 mitigation in [RFC7258] should be considered in solution work 318 resulting from this document. 320 It is well known that national surveillance programs monitor traffic 321 [JNSLP] [RFC2804] [RFC7258] monitor for criminal activities. 322 Governments vary on their balance between monitoring versus the 323 protection of user privacy, data, and assets. Those that favor 324 unencrypted access to data ignore the real need to protect users' 325 identity, financial transactions and intellectual property, which 326 requires security and encryption to prevent crime. A clear 327 understanding of technology, encryption, and monitoring goals will 328 aid in the development of solutions as work continues towards finding 329 an appropriate balance allowing for management while protecting users 330 privacy with strong encryption solutions. 332 2. Network Service Provider Monitoring 334 Network Service Providers (SP) for this definition include the 335 backbone Internet Service providers as well as those providing 336 infrastructure at scale for core Internet use (hosted infrastructure 337 and services such as email). 339 Network service providers use various techniques to operate, manage, 340 and secure their networks. The following subsections detail the 341 purpose of several techniques and which protocol fields are used to 342 accomplish each task. In response to increased encryption of these 343 fields, some network service providers may be tempted to undertake 344 undesirable security practices in order to gain access to the fields 345 in unencrypted data flows. To avoid this situation, new methods 346 could be developed to accomplish the same goals without service 347 providers having the ability to see session data. 349 2.1. Passive Monitoring 351 2.1.1. Traffic Surveys 353 Internet traffic surveys are useful in many pursuits, such as input 354 for Center for Applied Internet Data Analysis (CAIDA) studies 355 [CAIDA], network planning and optimization. Tracking the trends in 356 Internet traffic growth, from earlier peer-to-peer communication to 357 the extensive adoption of unicast video streaming applications, has 358 relied on a view of traffic composition with a particular level of 359 assumed accuracy, based on access to cleartext by those conducting 360 the surveys. 362 Passive monitoring makes inferences about observed traffic using the 363 maximal information available, and is subject to inaccuracies 364 stemming from incomplete sampling (of packets in a stream) or loss 365 due to monitoring system overload. When encryption conceals more 366 layers in each packet, reliance on pattern inferences and other 367 heuristics grows, and accuracy suffers. For example, the traffic 368 patterns between server and browser are dependent on browser supplier 369 and version, even when the sessions use the same server application 370 (e.g., web e-mail access). It remains to be seen whether more 371 complex inferences can be mastered to produce the same monitoring 372 accuracy. 374 2.1.2. Troubleshooting 376 Network operators use protocol-dissecting analyzers when responding 377 to customer problems, to identify the presence of attack traffic, and 378 to identify root causes of the problem such as misconfiguration. In 379 limited cases, packet captures may also be used when a customer 380 approves of access to their packets or provides packet captures close 381 to the endpoint. The protocol dissection is generally limited to 382 supporting protocols (e.g., DNS, DHCP), network and transport (e.g., 383 IP, TCP), and some higher layer protocols (e.g., RTP, RTCP). 385 Troubleshooting will move closer to the endpoint with increased 386 encryption and adjustments in practices to effectively troubleshoot 387 using a 5-tuple may require education. Packet loss investigations, 388 and those where access is limited to a 2-tuple (IPsec tunnel mode), 389 rely on network and transport layer headers taken at the endpoint. 390 In this case, captures on intermediate nodes are not reliable as 391 there are far too many cases of aggregate interfaces and alternate 392 paths in service provider networks. 394 Network operators are often the first ones called upon to investigate 395 application problems (e.g., "my HD video is choppy"), to first rule 396 out network and network services as a cause for the underlying issue. 397 When diagnosing a customer problem, the starting point may be a 398 particular application that isn't working. The ability to identify 399 the problem application's traffic is important and packet capture 400 provided from the customer close to the edge may be used for this 401 purpose; IP address filtering is not useful for applications using 402 content delivery networks (CDNs) or cloud providers. After 403 identifying the traffic, an operator may analyze the traffic 404 characteristics and routing of the traffic. This diagnostic step is 405 important to help determine the root cause before exploring if the 406 issue is directly with the application. 408 For example, by investigating packet loss (from TCP sequence and 409 acknowledgement numbers), round-trip-time (from TCP timestamp options 410 or application-layer transactions, e.g., DNS or HTTP response time), 411 TCP receive-window size, packet corruption (from checksum 412 verification), inefficient fragmentation, or application-layer 413 problems, the operator can narrow the problem to a portion of the 414 network, server overload, client or server misconfiguration, etc. 415 Network operators may also be able to identify the presence of attack 416 traffic as not conforming to the application the user claims to be 417 using. In many instances, the exposed packet header is sufficient 418 for this type of troubleshooting. 420 One way of quickly excluding the network as the bottleneck during 421 troubleshooting is to check whether the speed is limited by the 422 endpoints. For example, the connection speed might instead be 423 limited by suboptimal TCP options, the sender's congestion window, 424 the sender temporarily running out of data to send, the sender 425 waiting for the receiver to send another request, or the receiver 426 closing the receive window. All this information can be derived from 427 the cleartext TCP header. 429 Packet captures and protocol-dissecting analyzers have been important 430 tools. Automated monitoring has also been used to proactively 431 identify poor network conditions, leading to maintenance and network 432 upgrades before user experience declines. For example, findings of 433 loss and jitter in VoIP traffic can be a predictor of future customer 434 dissatisfaction (supported by metadata from the RTP/RTCP protocol ) 435 [RFC3550], or increases in DNS response time can generally make 436 interactive web browsing appear sluggish. But to detect such 437 problems, the application or service stream must first be 438 distinguished from others. 440 When increased encryption is used, operators lose a source of data 441 that may be used to debug user issues. For example, IPsec obscures 442 TCP and RTP header information, while TLS and SRTP do not. Because 443 of this, application server operators using increased encryption 444 might be called upon more frequently to assist with debugging and 445 troubleshooting, and thus may want to consider what tools can be put 446 in the hands of their clients or network operators. 448 Further, the performance of some services can be more efficiently 449 managed and repaired when information on user transactions is 450 available to the service provider. It may be possible to continue 451 transaction monitoring activities without clear text access to the 452 application layers of interest, but inaccuracy will increase and 453 efficiency of repair activities will decrease. For example, an 454 application protocol error or failure would be opaque to network 455 troubleshooters when transport encryption is applied, making root 456 cause location more difficult and therefore increasing the time-to- 457 repair. Repair time directly reduces the availability of the 458 service, and most network operators have made availability a key 459 metric in their Service Level Agreements and/or subscription rebates. 460 Also, there may be more cases of user communication failures when the 461 additional encryption processes are introduced (e.g., key management 462 at large scale), leading to more customer service contacts and (at 463 the same time) less information available to network operations 464 repair teams. 466 In mobile networks, knowledge about TCP's stream transfer progress 467 (by observing ACKs, retransmissions, packet drops, and the Sector 468 Utilization Level etc.) is further used to measure the performance of 469 Network Segments (Sector, eNodeB (eNB) etc.). This information is 470 used as key performance indicators (KPIs) and for the estimation of 471 user/service key quality indicators at network edges for circuit 472 emulation (CEM) as well as input for mitigation methods. If the 473 make-up of active services per user and per sector are not visible to 474 a server that provides Internet Access Point Names (APN), it cannot 475 perform mitigation functions based on network segment view. 477 It is important to note that the push for encryption by application 478 providers has been motivated by the application of the described 479 techniques. Although network operators have noted performance 480 improvements with network-based optimization or enhancement of user 481 traffic (otherwise, deployment would not have occurred), application 482 providers have likewise noted some degraded performance and/or user 483 experience, and such cases may result in additional operator 484 troubleshooting. Further, encrypted application streams might avoid 485 outdated optimization or enhancement techniques, where they exist. 487 A gap exists for vendors where built-in diagnostics and 488 serviceability are not adequate to provide detailed logging and 489 debugging capabilities that, when possible, could be accessed with 490 cleartext network parameters. In addition to traditional logging and 491 debugging methods, packet tracing and inspection along the service 492 path provides operators the visibility to continue to diagnose 493 problems reported both internally and by their customers. Logging of 494 service path upon exit for routing overlay protocols will assist with 495 policy management and troubleshooting capabilities for traffic flows 496 on encrypted networks. Protocol trace logging and protocol data unit 497 (PDU) logging should also be considered to improve visibility to 498 monitor and troubleshoot application level traffic. Additional work 499 on this gap would assist network operators to better troubleshoot and 500 manage networks with increasing amounts of encrypted traffic. 502 2.1.3. Traffic Analysis Fingerprinting 504 Fingerprinting is used in traffic analysis and monitoring to identify 505 traffic streams that match certain patterns. This technique can be 506 used with both clear text or encrypted sessions. Some Distributed 507 Denial of Service (DDoS) prevention techniques at the network 508 provider level rely on the ability to fingerprint traffic in order to 509 mitigate the effect of this type of attack. Thus, fingerprinting may 510 be an aspect of an attack or part of attack countermeasures. 512 A common, early trigger for DDoS mitigation includes observing 513 uncharacteristic traffic volumes or sources; congestion; or 514 degradation of a given network or service. One approach to mitigate 515 such an attack involves distinguishing attacker traffic from 516 legitimate user traffic. The ability to examine layers and payloads 517 above transport provides an increased range of filtering 518 opportunities at each layer in the clear. If fewer layers are in the 519 clear, this means that there are reduced filtering opportunities 520 available to mitigate attacks. However, fingerprinting is still 521 possible. 523 Passive monitoring of network traffic can lead to invasion of privacy 524 by external actors at the endpoints of the monitored traffic. 525 Encryption of traffic end-to-end is one method to obfuscate some of 526 the potentially identifying information. For example, browser 527 fingerprints are comprised of many characteristics, including User 528 Agent, HTTP Accept headers, browser plug-in details, screen size and 529 color details, system fonts and time zone. A monitoring system could 530 easily identify a specific browser, and by correlating other 531 information, identify a specific user. 533 2.2. Traffic Optimization and Management 535 2.2.1. Load Balancers 537 A standalone load balancer is a function one can take off the shelf, 538 place in front of a pool of servers, configure appropriately, and it 539 will balance the traffic load among servers in the pool. This is a 540 typical setup for load balancers. Standalone load balancers rely on 541 the plainly observable information in the packets they are forwarding 542 and rely on industry-accepted standards in interpreting the plainly 543 observable information. Typically, this is a 5-tuple of the 544 connection. This type of configuration terminates TLS sessions at 545 the load balancer, making it the end point instead of the server. 546 Standalone load balancers are considered middleboxes, but are an 547 integral part of server infrastructure that scales. 549 In contrast, an integrated load balancer is developed to be an 550 integral part of the service provided by the server pool behind that 551 load balancer. These load balancers can communicate state with their 552 pool of servers to better route flows to the appropriate servers. 553 They rely on non-standard system-specific information and operational 554 knowledge shared between the load balancer and its servers. 556 Both standalone and integrated load balancers can be deployed in 557 pools for redundancy and load sharing. For high availability, it is 558 important that when packets belonging to a flow start to arrive at a 559 different load balancer in the load balancer pool, the packets 560 continue to be forwarded to the original server in the server pool. 561 The importance of this requirement increases as the chances of such 562 load balancer change event increases. 564 Mobile operators deploy integrated load balancers to assist with 565 maintaining connection state as devices migrate. With the 566 proliferation of mobile connected devices, there is an acute need for 567 connection-oriented protocols that maintain connections after a 568 network migration by an endpoint. This connection persistence 569 provides an additional challenge for multi-homed anycast-based 570 services typically employed by large content owners and Content 571 Distribution Networks (CDNs). The challenge is that a migration to a 572 different network in the middle of the connection greatly increases 573 the chances of the packets routed to a different anycast point-of- 574 presence (POP) due to the new network's different connectivity and 575 Internet peering arrangements. The load balancer in the new POP, 576 potentially thousands of miles away, will not have information about 577 the new flow and would not be able to route it back to the original 578 POP. 580 To help with the endpoint network migration challenges, anycast 581 service operations are likely to employ integrated load balancers 582 that, in cooperation with their pool servers, are able to ensure that 583 client-to-server packets contain some additional identification in 584 plainly-observable parts of the packets (in addition to the 5-tuple). 585 As noted in Section 2 of [RFC7258], careful consideration in protocol 586 design to mitigate PM is important, while ensuring manageability of 587 the network. 589 An area for further research includes end-to-end solutions that would 590 provide a simpler architecture and may solve the issue with CDN 591 anycast. In this case, connections would be migrated to a CDN 592 unicast address. 594 Current protocols, such as TCP, allow the development of stateless 595 integrated load balancers by availing such load balancers of 596 additional plain text information in client-to-server packets. In 597 case of TCP, such information can be encoded by having server- 598 generated sequence numbers (that are ACK'd by the client), segment 599 values, lengths of the packet sent, etc. The use of some of these 600 mechanisms for load balancing negates some of the security 601 assumptions associated with those primitives (e.g., that an off-path 602 attacker guessing valid sequence numbers for a flow is hard). 603 Another possibility is a dedicated mechanism for storing load 604 balancer state, such as QUIC's proposed connection ID to provide 605 visibility to the load balancer. An identifier could be used for 606 tracking purposes, but this may provide an option that is an 607 improvement from bolting it on to an unrelated transport signal. 608 This method allows for tight control by one of the endpoints and can 609 be rotated to avoid roving client linkability: in other words, being 610 a specific, separate signal, it can be governed in a way that is 611 finely targeted at that specific use-case. 613 Some integrated load balancers have the ability to use additional 614 plainly observable information even for today's protocols that are 615 not network migration tolerant. This additional information allows 616 for improved availability and scalability of the load balancing 617 operation. For example, BGP reconvergence can cause a flow to switch 618 anycast POPs even without a network change by any endpoint. 619 Additionally, a system that is able to encode the identity of the 620 pool server in plain text information available in each incoming 621 packet is able to provide stateless load balancing. This ability 622 confers great reliability and scalability advantages even if the flow 623 remains in a single POP, because the load balancing system is not 624 required to keep state of each flow. Even more importantly, there's 625 no requirement to continuously synchronize such state among the pool 626 of load balancers. An integrated load balancer repurposing limited 627 existing bits in transport flow state must maintain and synchronize 628 per-flow state occasionally: using the sequence number as a cookie 629 only works for so long given that there aren't that many bits 630 available to divide across a pool of machines. 632 Mobile operators apply Self Organizing Networks (3GPP SON) for 633 intelligent workflows such as content-aware MLB (Mobility Load 634 Balancing). Where network load balancers have been configured to 635 route according to application-layer semantics, an encrypted payload 636 is effectively invisible. This has resulted in practices of 637 intercepting TLS in front of load balancers to regain that 638 visibility, but at a cost to security and privacy. 640 In future Network Function Virtualization (NFV) architectures, load 641 balancing functions are likely to be more prevalent (deployed at 642 locations throughout operators' networks). NFV environments will 643 require some type of identifier (IPv6 flow identifiers, the proposed 644 QUIC connection ID, etc.) for managing traffic using encrypted 645 tunnels. The shift to increased encryption will have an impact to 646 visibility of flow information and will require adjustments to 647 perform similar load balancing functions within an NFV. 649 2.2.2. Differential Treatment based on Deep Packet Inspection (DPI) 651 Data transfer capacity resources in cellular radio networks tend to 652 be more constrained than in fixed networks. This is a result of 653 variance in radio signal strength as a user moves around a cell, the 654 rapid ingress and egress of connections as users hand off between 655 adjacent cells, and temporary congestion at a cell. Mobile networks 656 alleviate this by queuing traffic according to its required bandwidth 657 and acceptable latency: for example, a user is unlikely to notice a 658 20ms delay when receiving a simple Web page or email, or an instant 659 message response, but will very likely notice a re-buffering pause in 660 a video playback or a VoIP call de-jitter buffer. Ideally, the 661 scheduler manages the queue so that each user has an acceptable 662 experience as conditions vary, but inferences of the traffic type 663 have been used to make bearer assignments and set scheduler priority. 665 Deep Packet Inspection (DPI) allows identification of applications 666 based on payload signatures, in contrast to trusting well-known port 667 numbers. Application and transport layer encryption make the traffic 668 type estimation more complex and less accurate, and therefore it may 669 not be effectual to use this information as input for queue 670 management. With the use of WebSockets [RFC6455], for example, many 671 forms of communications (from isochronous/real-time to bulk/elastic 672 file transfer) will take place over HTTP port 80 or port 443, so only 673 the messages and higher-layer data will make application 674 differentiation possible. If the monitoring system sees only "HTTP 675 port 443", it cannot distinguish application streams that would 676 benefit from priority queueing from others that would not. 678 Mobile networks especially rely on content/application based 679 prioritization of Over-the-Top (OTT) services - each application-type 680 or service has different delay/loss/throughput expectations, and each 681 type of stream will be unknown to an edge device if encrypted; this 682 impedes dynamic-QoS adaptation. An alternate way to achieve 683 encrypted application separation is possible when the User Equipment 684 (UE) requests a dedicated bearer for the specific application stream 685 (known by the UE), using a mechanism such as the one described in 686 Section 6.5 of 3GPP TS 24.301 [TS3GPP]. The UE's request includes 687 the Quality Class Indicator (QCI) appropriate for each application, 688 based on their different delay/loss/throughput expectations. 689 However, UE requests for dedicated bearers and QCI may not be 690 supported at the subscriber's service level, or in all mobile 691 networks. 693 These effects and potential alternative solutions have been discussed 694 at the accord BoF [ACCORD] at IETF95. 696 This section does not consider traffic discrimination by service 697 providers related to NetNeutrality, where traffic may be favored 698 according to the service provider preference as opposed to the user's 699 preference. These use cases are considered out-of-scope for this 700 document as controversial practices. 702 2.2.3. Network Congestion Management 704 For User Plane Congestion Management (3GPP UPCON) [UPCON], the 705 ability to understand content and manage networks during periods of 706 congestion is the focus of this 3GPP work item. Mitigating 707 techniques such as deferred download, off-peak acceleration, and 708 outbound roamers are a few examples of the areas explored in the 709 associated 3GPP documents. The documents describe the issues, the 710 data utilized in managing congestion, and make policy 711 recommendations. 713 2.2.4. Performance-enhancing Proxies 715 Performance-enhancing TCP proxies may perform local retransmission at 716 the network edge; this also applies to mobile networks. In TCP, 717 duplicated ACKs are detected and potentially concealed when the proxy 718 retransmits a segment that was lost on the mobile link without 719 involvement of the far end (see section 2.1.1 of [RFC3135] and 720 section 3.5 of [I-D.dolson-plus-middlebox-benefits]). 722 Operators report that this optimization at network edges improves 723 real-time transmission over long delay Internet paths or networks 724 with large capacity-variation (such as mobile/cellular networks). 725 However, such optimizations can also cause problems with performance, 726 for example if the characteristics of some packet streams begin to 727 vary significantly from those considered in the proxy design. 729 In general some operators have stated that performance-enhancing 730 proxies have a lower Round-Trip Time (RTT) to the client and 731 therefore determine the responsiveness of flow control. A lower RTT 732 makes the flow control loop more responsive to changes in the mobile 733 network conditions and enables faster adaptation in a delay and 734 capacity varying network due to user mobility. 736 Further, some use service-provider-operated proxies to reduce the 737 control delay between the sender and a receiver on a mobile network 738 where resources are limited. The RTT determines how quickly a user's 739 attempt to cancel a video is recognized and therefore how quickly the 740 traffic is stopped, thus keeping un-wanted video packets from 741 entering the radio scheduler queue. If impacted by encryption, 742 performance enhancing proxies could make use of routing overlay 743 protocols to accomplish the same task, but this results in additional 744 overhead. 746 An application-type-aware network edge (middlebox) can further 747 control pacing, limit simultaneous HD videos, or prioritize active 748 videos against new videos, etc. Services at this more granular level 749 are limited with the use of encryption. 751 Performance enhancing proxies are primarily used on long delay links 752 (satellite) with access to the TCP header to provide an early ACK and 753 make the long delay link of the path seem shorter. With some 754 specific forms of flow control, TCP can be more efficient than 755 alternatives such as proxies. The editors cannot cite research on 756 this point specific to the performance enhancing proxies described, 757 but agree this area could be explored to determine if flow-control 758 modifications could preserve the end-to-end performance on long delay 759 paths session where the TCP header is exposed. 761 2.2.5. Caching and Content Replication Near the Network Edge 763 The features and efficiency of some Internet services can be 764 augmented through analysis of user flows and the applications they 765 provide. For example, network caching of popular content at a 766 location close to the requesting user can improve delivery efficiency 767 (both in terms of lower request response times and reduced use of 768 International Internet links when content is remotely located), and 769 the service provider through an authorized agreement acting on their 770 behalf use DPI in combination with content distribution networks to 771 determine if they can intervene effectively. Encryption of packet 772 contents at a given protocol layer usually makes DPI processing of 773 that layer and higher layers impossible. That being said, it should 774 be noted that some content providers prevent caching to control 775 content delivery through the use of encrypted end-to-end sessions. 776 CDNs vary in their deployment options of end-to-end encryption. The 777 business risk of losing control of content is a motivation outside of 778 privacy and pervasive monitoring that are driving end-to-end 779 encryption for these content providers. 781 It should be noted that caching was first supported in [RFC1945] and 782 continued in the recent update of "Hypertext Transfer Protocol 783 (HTTP/1.1): Caching" in [RFC7234]. Some operators also operate 784 transparent caches which neither the user nor the origin opt-in. The 785 use of these caches is controversial within IETF and is generally 786 precluded by the use of HTTPS. 788 Content replication in caches (for example live video, Digital Rights 789 Management (DRM) protected content) is used to most efficiently 790 utilize the available limited bandwidth and thereby maximize the 791 user's Quality of Experience (QoE). Especially in mobile networks, 792 duplicating every stream through the transit network increases 793 backhaul cost for live TV. The Enhanced Multimedia Broadcast/ 794 Multicast Services (3GPP eMBMS) utilizes trusted edge proxies to 795 facilitate delivering the same stream to different users, using 796 either unicast or multicast depending on channel conditions to the 797 user. There are on-going efforts to support multicast inside carrier 798 networks while preserving end-to-end security: Automatic Multicast 799 Tunneling (AMT), for instance, allows CDNs to deliver a single 800 (potentially encrypted) copy of a live stream to a carrier network 801 over the public internet and for the carrier to then distribute that 802 live stream as efficiently as possible within its own network using 803 multicast. 805 Alternate approaches are in the early phase of being explored to 806 allow caching of encrypted content. These solutions require 807 cooperation from content owners and fall outside the scope of what is 808 covered in this document. Content delegation allows for replication 809 with possible benefits, but any form of delegation has the potential 810 to affect the expectation of client-server confidentiality. 812 2.2.6. Content Compression 814 In addition to caching, various applications exist to provide data 815 compression in order to conserve the life of the user's mobile data 816 plan or make delivery over the mobile link more efficient. The 817 compression proxy access can be built into a specific user level 818 application, such as a browser, or it can be available to all 819 applications using a system level application. The primary method is 820 for the mobile application to connect to a centralized server as a 821 transparent proxy (user does not opt-in), with the data channel 822 between the client application and the server using compression to 823 minimize bandwidth utilization. The effectiveness of such systems 824 depends on the server having access to unencrypted data flows. 826 Aggregated data stream content compression that spans objects and 827 data sources that can be treated as part of a unified compression 828 scheme (e.g., through the use of a shared segment store) is often 829 effective at providing data offload when there is a network element 830 close to the receiver that has access to see all the content. 832 2.2.7. Service Function Chaining 834 Service Function Chaining (SFC) has been defined in RFC7665 [RFC7665] 835 and RFC8300 [RFC8300]. As discussed in RFC7498 [RFC7498], common SFC 836 deployments may use classifiers to direct traffic into VLANs instead 837 of using NSH, as defined in RFC8300 [RFC8300]. As described in 838 RFC7665 [RFC7665], the ordered steering of traffic to support 839 specific optimizations depends upon the ability of a Classifier to 840 determine the microflows. RFC2474 [RFC2474] defines "Microflow: a 841 single instance of an application-to-application flow of packets 842 which is identified by source address, destination address, protocol 843 id, and source port, destination port (where applicable)." SFC 844 currently depends upon a classifier to at least identify the 845 microflow. As the classifier's visibility is reduced from a 5-tuple 846 to a 2-tuple, or if information above the transport layer becomes 847 inaccessible, then the SFC Classifier is not able to perform its job 848 and the service functions of the path may be adversely affected. 850 There are also mechanisms provided to protect security and privacy. 851 In the SFC case, the layer below a network service header can be 852 protected with session encryption. A goal is protecting end-user 853 data, while retaining the intended functions of RFC7665 [RFC7665] at 854 the same time. 856 2.3. Content Filtering, Network Access, and Accounting 858 Mobile Networks and many ISPs operate under the regulations of their 859 licensing government authority. These regulations include Lawful 860 Intercept, adherence to Codes of Practice on content filtering, and 861 application of court order filters. Such regulations assume network 862 access to provide content filtering and accounting, as discussed 863 below. As previously stated, the intent of this document is to 864 document existing practices; the development of IETF protocols 865 follows the guiding principles of [RFC1984] and [RFC2804] and 866 explicitly do not support tools and methods that could be used for 867 wiretapping and censorship. 869 2.3.1. Content Filtering 871 There are numerous reasons why service providers might block content: 872 to comply with requests from law enforcement or regulatory 873 authorities, to effectuate parental controls, to enforce content- 874 based billing, or for other reasons, possibly considered 875 inappropriate by some. See RFC7754 [RFC7754] for a survey of 876 Internet filtering techniques and motivations and the IAB consensus 877 on those mechanisms. This section is intended to document a 878 selection of current content blocking practices by operators and the 879 effects of encryption on those practices. Content blocking may also 880 happen at endpoints or at the edge of enterprise networks, but those 881 are not addressed in this section. 883 In a mobile network content filtering usually occurs in the core 884 network. With other networks, content filtering could occur in the 885 core network or at the edge. A proxy is installed which analyses the 886 transport metadata of the content users are viewing and either 887 filters content based on a blacklist of sites or based on the user's 888 pre-defined profile (e.g., for age sensitive content). Although 889 filtering can be done by many methods, one commonly used method 890 involves a trigger based on the proxy identifying a DNS lookup of a 891 host name in a URL which appears on a blacklist being used by the 892 operator. The subsequent requests to that domain will be re-routed 893 to a proxy which checks whether the full URL matches a blocked URL on 894 the list, and will return a 404 if a match is found. All other 895 requests should complete. This technique does not work in situations 896 where DNS traffic is encrypted (e.g., by employing [RFC7858] ). This 897 method is also used by other types of network providers enabling 898 traffic inspection, but not modification. 900 Content filtering via a proxy can also utilize an intercepting 901 certificate where the client's session is terminated at the proxy 902 enabling for cleartext inspection of the traffic. A new session is 903 created from the intercepting device to the client's destination; 904 this is an opt-in strategy for the client, where the endpoint is 905 configured to trust the intercepting certificate. Changes to TLSv1.3 906 do not impact this more invasive method of interception, that has the 907 potential to expose every HTTPS session to an active man in the 908 middle (MitM). 910 Another form of content filtering is called parental control, where 911 some users are deliberately denied access to age-sensitive content as 912 a feature to the service subscriber. Some sites involve a mixture of 913 universal and age-sensitive content and filtering software. In these 914 cases, more granular (application layer) metadata may be used to 915 analyze and block traffic. Methods that accessed cleartext 916 application-layer metadata no longer work when sessions are 917 encrypted. This type of granular filtering could occur at the 918 endpoint or as a proxy service. However, the lack of ability to 919 efficiently manage endpoints as a service reduces network service 920 providers' ability to offer parental control. 922 2.3.2. Network Access and Data Usage 924 Approved access to a network is a prerequisite to requests for 925 Internet traffic. 927 However, there are cases (beyond parental control) when a network 928 service provider currently redirects customer requests for content 929 (affecting content accessibility): 931 1. The network service provider is performing the accounting and 932 billing for the content provider, and the customer has not (yet) 933 purchased the requested content. 935 2. Further content may not be allowed as the customer has reached 936 their usage limit and needs to purchase additional data service, 937 which is the usual billing approach in mobile networks. 939 Currently, some network service providers redirect the customer using 940 HTTP redirect to a captive portal page that explains to those 941 customers the reason for the blockage and the steps to proceed. 942 [RFC6108] describes one viable web notification system. When the 943 HTTP headers and content are encrypted, this appropriately prevents 944 mobile carriers from intercepting the traffic and performing an HTTP 945 redirect. As a result, some mobile carriers block customer's 946 encrypted requests, which impacts customer experience because the 947 blocking reason must be conveyed by some other means. The customer 948 may need to call customer care to find out the reason and/or resolve 949 the issue, possibly extending the time needed to restore their 950 network access. While there are well deployed alternate SMS-based 951 solutions that do not involve out of specification protocol 952 interception, this is still an unsolved problem for non-SMS users. 954 Further, when the requested service is about to consume the remainder 955 of the user's plan limits, the transmission could be terminated and 956 advance notifications may be sent to the user by their service 957 provider to warn the user ahead of the exhausted plan. If web 958 content is encrypted, the network provider cannot know the data 959 transfer size at request time. Lacking this visibility of the 960 application type and content size, the network would continue the 961 transmission and stop the transfer when the limit was reached. A 962 partial transfer may not be usable by the client wasting both network 963 and user resources, possibly leading to customer complaints. The 964 content provider does not know user's service plans or current usage, 965 and cannot warn the user of plan exhaustion. 967 In addition, some mobile network operators sell tariffs that allow 968 free-data access to certain sites, known as 'zero rating'. A session 969 to visit such a site incurs no additional cost or data usage to the 970 user. For some implementations, zero rating is impacted if 971 encryption hides the details of the content domain from the network. 973 2.3.3. Application Layer Gateways 975 Application Layer Gateways (ALG) assist applications to set 976 connectivity across Network Address Translators (NAT), Firewalls, 977 and/or Load Balancers for specific applications running across mobile 978 networks. Section 2.9 of [RFC2663] describes the role of ALGs and 979 their interaction with NAT and/or application payloads. ALG are 980 deployed with an aim to improve connectivity. However, it is an IETF 981 Best Common Practice recommendation that ALGs for UDP-based protocols 982 should be turned off [RFC4787]. 984 One example of an ALG in current use is aimed at video applications 985 that use the Real Time Session Protocol (RTSP) [RFC7826] primary 986 stream as a means to identify related Real Time Protocol/Real Time 987 Control Protocol (RTP/RTCP) [RFC3550] flows at set-up. The ALG in 988 this case relies on the 5-tuple flow information derived from RTSP to 989 provision NAT or other middleboxes and provide connectivity. 990 Implementations vary, and two examples follow: 992 1. Parse the content of the RTSP stream and identify the 5-tuple of 993 the supporting streams as they are being negotiated. 995 2. Intercept and modify the 5-tuple information of the supporting 996 media streams as they are being negotiated on the RTSP stream, 997 which is more intrusive to the media streams. 999 When RTSP stream content is encrypted, the 5-tuple information within 1000 the payload is not visible to these ALG implementations, and 1001 therefore they cannot provision their associated middleboxes with 1002 that information. 1004 The deployment of IPv6 may well reduce the need for NAT, and the 1005 corresponding requirement for Application Layer Gateways. 1007 2.3.4. HTTP Header Insertion 1009 Some mobile carriers use HTTP header insertion (see section 3.2.1 of 1010 [RFC7230]) to provide information about their customers to third 1011 parties or to their own internal systems [Enrich]. Third parties use 1012 the inserted information for analytics, customization, advertising, 1013 cross-site tracking of users, to bill the customer, or to selectively 1014 allow or block content. HTTP header insertion is also used to pass 1015 information internally between a mobile service provider's sub- 1016 systems, thus keeping the internal systems loosely coupled. When 1017 HTTP connections are encrypted to protect users privacy, mobile 1018 network service providers cannot insert headers to accomplish the, 1019 sometimes considered controversial, functions above. 1021 Guidance from the Internet Architecture Board has been provided in 1022 RFC8165 [RFC8165] on Design Considerations for Metadata Insertion. 1023 The guidance asserts that designs that share metadata only by 1024 explicit actions at the host are preferable to designs in which 1025 middleboxes insert metadata. Alternate notification methods that 1026 follow this and other guidance would be helpful to mobile carriers. 1028 3. Encryption in Hosting and Application SP Environments 1030 Hosted environments have had varied requirements in the past for 1031 encryption, with many businesses choosing to use these services 1032 primarily for data and applications that are not business or privacy 1033 sensitive. A shift prior to the revelations on surveillance/passive 1034 monitoring began where businesses were asking for hosted environments 1035 to provide higher levels of security so that additional applications 1036 and service could be hosted externally. Businesses understanding the 1037 threats of monitoring in hosted environments increased that pressure 1038 to provide more secure access and session encryption to protect the 1039 management of hosted environments as well as for the data and 1040 applications. 1042 3.1. Management Access Security 1044 Hosted environments may have multiple levels of management access, 1045 where some may be strictly for the Hosting SP (infrastructure that 1046 may be shared among customers) and some may be accessed by a specific 1047 customer for application management. In some cases, there are 1048 multiple levels of hosting service providers, further complicating 1049 the security of management infrastructure and the associated 1050 requirements. 1052 Hosting service provider management access is typically segregated 1053 from other traffic with a control channel and may or may not be 1054 encrypted depending upon the isolation characteristics of the 1055 management session. Customer access may be through a dedicated 1056 connection, but discussion for that connection method is out-of-scope 1057 for this document. 1059 In overlay networks (e.g. VXLAN, Geneve, etc.) that are used to 1060 provide hosted services, management access for a customer to support 1061 application management may depend upon the security mechanisms 1062 available as part of that overlay network. While overlay network 1063 data encapsulations may be used to indicate the desired isolation, 1064 this is not sufficient to prevent deliberate attacks that are aware 1065 of the use of the overlay network. 1066 [I-D.mglt-nvo3-geneve-security-requirements] describes requirements 1067 to handle attacks. It is possible to use an overlay header in 1068 combination with IPsec or other encrypted traffic sessions, but this 1069 adds the requirement for authentication infrastructure and may reduce 1070 packet transfer performance. The use of an overlay header may also 1071 be deployed as a mechanism to manage encrypted traffic streams on the 1072 network by network service providers. Additional extension 1073 mechanisms to provide integrity and/or privacy protections are being 1074 investigated for overlay encapsulations. Section 7 of [RFC7348] 1075 describes some of the security issues possible when deploying VXLAN 1076 on Layer 2 networks. Rogue endpoints can join the multicast groups 1077 that carry broadcast traffic, for example. 1079 3.1.1. Customer Access Monitoring 1081 Hosted applications that allow some level of customer management 1082 access may also require monitoring by the hosting service provider. 1083 Monitoring could include access control restrictions such as 1084 authentication, authorization, and accounting for filtering and 1085 firewall rules to ensure they are continuously met. Customer access 1086 may occur on multiple levels, including user-level and administrative 1087 access. The hosting service provider may need to monitor access 1088 either through session monitoring or log evaluation to ensure 1089 security service level agreements (SLA) for access management are 1090 met. The use of session encryption to access hosted environments 1091 limits access restrictions to the metadata described below. 1092 Monitoring and filtering may occur at an: 1094 2-tuple IP-level with source and destination IP addresses alone, or 1096 5-tuple IP and protocol-level with source IP address, destination IP 1097 address, protocol number, source port number, and destination port 1098 number. 1100 Session encryption at the application level, TLS for example, 1101 currently allows access to the 5-tuple. IP-level encryption, such as 1102 IPsec in tunnel mode prevents access to the original 5-tuple and may 1103 limit the ability to restrict traffic via filtering techniques. This 1104 shift may not impact all hosting service provider solutions as 1105 alternate controls may be used to authenticate sessions or access may 1106 require that clients access such services by first connecting to the 1107 organization before accessing the hosted application. Shifts in 1108 access may be required to maintain equivalent access control 1109 management. Logs may also be used for monitoring that access control 1110 restrictions are met, but would be limited to the data that could be 1111 observed due to encryption at the point of log generation. Log 1112 analysis is out of scope for this document. 1114 3.1.2. SP Content Monitoring of Applications 1116 The following observations apply to any IT organization that is 1117 responsible for delivering services, whether to third-parties, for 1118 example as a web based service, or to internal customers in an 1119 enterprise, e.g. a data processing system that forms a part of the 1120 enterprise's business. 1122 Organizations responsible for the operation of a data center have 1123 many processes which access the contents of IP packets (passive 1124 methods of measurement, as defined in [RFC7799]). These processes 1125 are typically for service assurance or security purposes as part of 1126 their data center operations. 1128 Examples include: 1130 - Network Performance Monitoring/Application Performance 1131 Monitoring 1133 - Intrusion defense/prevention systems 1135 - Malware detection 1137 - Fraud Monitoring 1139 - Application DDOS protection 1141 - Cyber-attack investigation 1143 - Proof of regulatory compliance 1145 - Data Leakage Prevention 1147 Many application service providers simply terminate sessions to/from 1148 the Internet at the edge of the data center in the form of SSL/TLS 1149 offload in the load balancer. Not only does this reduce the load on 1150 application servers, it simplifies the processes to enable monitoring 1151 of the session content. 1153 However, in some situations, encryption deeper in the data center may 1154 be necessary to protect personal information or in order to meet 1155 industry regulations, e.g. those set out by the Payment Card Industry 1156 (PCI). In such situations, various methods have been used to allow 1157 service assurance and security processes to access unencrypted data. 1158 These include SSL/TLS decryption in dedicated units, which then 1159 forward packets to SP-controlled tools, or by real-time or post- 1160 capture decryption in the tools themselves. A number of these tools 1161 provide passive decryption by providing the monitoring device with 1162 the server's private key. The move to increased use of of forward- 1163 secret key exchange mechanism impacts the use of these techniques. 1165 Data center operators may also maintain packet recordings in order to 1166 be able to investigate attacks, breach of internal processes, etc. 1167 In some industries, organizations may be legally required to maintain 1168 such information for compliance purposes. Investigations of this 1169 nature have used access to the unencrypted contents of the packet. 1170 Alternate methods to investigate attacks or breach of process will 1171 rely on endpoint information, such as logs. As previously noted, 1172 logs often lack complete information, and this is seen as a concern 1173 resulting in some relying on session access for additional 1174 information. 1176 Application Service Providers may offer content-level monitoring 1177 options to detect intellectual property leakage, or other attacks. 1178 In service provider environments where Data Loss Prevention (DLP) has 1179 been implemented on the basis of the service provider having 1180 cleartext access to session streams, the use of encrypted streams 1181 prevents these implementations from conducting content searches for 1182 the keywords or phrases configured in the DLP system. DLP is often 1183 used to prevent the leakage of Personally Identifiable Information 1184 (PII) as well as financial account information, Personal Health 1185 Information (PHI), and Payment Card Information (PCI). If session 1186 encryption is terminated at a gateway prior to accessing these 1187 services, DLP on session data can still be performed. The decision 1188 of where to terminate encryption to hosted environments will be a 1189 risk decision made between the application service provider and 1190 customer organization according to their priorities. DLP can be 1191 performed at the server for the hosted application and on an end 1192 user's system in an organization as alternate or additional 1193 monitoring points of content; however, this is not frequently done in 1194 a service provider environment. 1196 Application service providers, by their very nature, control the 1197 application endpoint. As such, much of the information gleaned from 1198 sessions are still available on that endpoint. However, when a gap 1199 exists in the application's logging and debugging capabilities, this 1200 has led the application service provider to access data-in-transport 1201 for monitoring and debugging. 1203 3.2. Hosted Applications 1205 Organizations are increasingly using hosted applications rather than 1206 in-house solutions that require maintenance of equipment and 1207 software. Examples include Enterprise Resource Planning (ERP) 1208 solutions, payroll service, time and attendance, travel and expense 1209 reporting among others. Organizations may require some level of 1210 management access to these hosted applications and will typically 1211 require session encryption or a dedicated channel for this activity. 1213 In other cases, hosted applications may be fully managed by a hosting 1214 service provider with service level agreement expectations for 1215 availability and performance as well as for security functions 1216 including malware detection. Due to the sensitive nature of these 1217 hosted environments, the use of encryption is already prevalent. Any 1218 impact may be similar to an enterprise with tools being used inside 1219 of the hosted environment to monitor traffic. Additional concerns 1220 were not reported in the call for contributions. 1222 3.2.1. Monitoring Managed Applications 1224 Performance, availability, and other aspects of a SLA are often 1225 collected through passive monitoring. For example: 1227 o Availability: ability to establish connections with hosts to 1228 access applications, and discern the difference between network or 1229 host-related causes of unavailability. 1231 o Performance: ability to complete transactions within a target 1232 response time, and discern the difference between network or host- 1233 related causes of excess response time. 1235 Here, as with all passive monitoring, the accuracy of inferences are 1236 dependent on the cleartext information available, and encryption 1237 would tend to reduce the information and therefore, the accuracy of 1238 each inference. Passive measurement of some metrics will be 1239 impossible with encryption that prevents inferring packet 1240 correspondence across multiple observation points, such as for packet 1241 loss metrics. 1243 Application logging currently lacks detail sufficient to make 1244 accurate inferences in an environment with increased encryption, and 1245 so this constitutes a gap for passive performance monitoring (which 1246 could be closed if log details are enhanced in the future). 1248 3.2.2. Mail Service Providers 1250 Mail (application) service providers vary in what services they 1251 offer. Options may include a fully hosted solution where mail is 1252 stored external to an organization's environment on mail service 1253 provider equipment or the service offering may be limited to monitor 1254 incoming mail to remove spam [Section 5.1], malware [Section 5.6], 1255 and phishing attacks [Section 5.3] before mail is directed to the 1256 organization's equipment. In both of these cases, content of the 1257 messages and headers is monitored to detect spam, malware, phishing, 1258 and other messages that may be considered an attack. 1260 STARTTLS should have zero effect on anti-spam efforts for SMTP 1261 traffic. Anti-spam services could easily be performed on an SMTP 1262 gateway, eliminating the need for TLS decryption services. The 1263 impact to anti-spam service providers should be limited to a change 1264 in tools, where middleboxes were deployed to perform these functions. 1266 Many efforts are emerging to improve user-to-user encryption, 1267 including promotion of PGP and newer efforts such as Dark Mail 1268 [DarkMail]. Of course, content-based spam filtering will not be 1269 possible on encrypted content. 1271 3.3. Data Storage 1273 Numerous service offerings exist that provide hosted storage 1274 solutions. This section describes the various offerings and details 1275 the monitoring for each type of service and how encryption may impact 1276 the operational and security monitoring performed. 1278 Trends in data storage encryption for hosted environments include a 1279 range of options. The following list is intentionally high-level to 1280 describe the types of encryption used in coordination with data 1281 storage that may be hosted remotely, meaning the storage is 1282 physically located in an external data center requiring transport 1283 over the Internet. Options for monitoring will vary with each 1284 encryption approach described below. In most cases, solutions have 1285 been identified to provide encryption while ensuring management 1286 capabilities were maintained through logging or other means. 1288 3.3.1. Object-level Encryption 1290 For higher security and/or privacy of data and applications, options 1291 that provide end-to-end encryption of the data from the user's 1292 desktop or server to the storage platform may be preferred. This 1293 description includes any solution that encrypts data at the object 1294 level, not transport level. Encryption of data may be performed with 1295 libraries on the system or at the application level, which includes 1296 file encryption services via a file manager. Object-level encryption 1297 is useful when data storage is hosted, or scenarios when the storage 1298 location is determined based on capacity or based on a set of 1299 parameters to automate decisions. This could mean that large data 1300 sets accessed infrequently could be sent to an off-site storage 1301 platform at an external hosting service, data accessed frequently may 1302 be stored locally, or the decision could be based on the transaction 1303 type. Object-level encryption is grouped separately for the purpose 1304 of this document since data may be stored in multiple locations 1305 including off-site remote storage platforms. If session encryption 1306 is also used, the protocol is likely to be TLS. 1308 Impacts to monitoring may include access to content inspection for 1309 data leakage prevention and similar technologies, depending on their 1310 placement in the network. 1312 3.3.1.1. Monitoring for Hosted Storage 1314 Monitoring of hosted storage solutions that use host-level (object) 1315 encryption is described in this subsection. Host-level encryption 1316 can be employed for backup services, and occasionally for external 1317 storage services (operated by a third party) when internal storage 1318 limits are exceeded. 1320 Monitoring of data flows to hosted storage solutions is performed for 1321 security and operational purposes. The security monitoring may be to 1322 detect anomalies in the data flows that could include changes to 1323 destination, the amount of data transferred, or alterations in the 1324 size and frequency of flows. Operational considerations include 1325 capacity and availability monitoring. 1327 3.3.2. Disk Encryption, Data at Rest 1329 There are multiple ways to achieve full disk encryption for stored 1330 data. Encryption may be performed on data to be stored while in 1331 transit close to the storage media with solutions like Controller 1332 Based Encryption (CBE) or in the drive system with Self-Encrypting 1333 Drives (SED). Session encryption is typically coupled with 1334 encryption of these data at rest (DAR) solutions to also protect data 1335 in transit. Transport encryption is likely via TLS. 1337 3.3.2.1. Monitoring Session Flows for Data at Rest (DAR) Solutions 1339 Monitoring for transport of data to storage platforms, where object 1340 level encryption is performed close to or on the storage platform are 1341 similar to those described in the section on Monitoring for Hosted 1342 Storage. The primary difference for these solutions is the possible 1343 exposure of sensitive information, which could include privacy 1344 related data, financial information, or intellectual property if 1345 session encryption via TLS is not deployed. Session encryption is 1346 typically used with these solutions, but that decision would be based 1347 on a risk assessment. There are use cases where DAR or disk-level 1348 encryption is required. Examples include preventing exposure of data 1349 if physical disks are stolen or lost. In the case where TLS is in 1350 use, monitoring and the exposure of data is limited to a 5-tuple. 1352 3.3.3. Cross Data Center Replication Services 1354 Storage services also include data replication which may occur 1355 between data centers and may leverage Internet connections to tunnel 1356 traffic. The traffic may use iSCSI [RFC7143] or FC/IP [RFC7146] 1357 encapsulated in IPsec. Either transport or tunnel mode may be used 1358 for IPsec depending upon the termination points of the IPsec session, 1359 if it is from the storage platform itself or from a gateway device at 1360 the edge of the data center respectively. 1362 3.3.3.1. Monitoring Of IPsec for Data Replication Services 1364 Monitoring of data flows between data centers (for data replication) 1365 may be performed for security and operational purposes and would 1366 typically concentrate more on operational aspects since these flows 1367 are essentially virtual private networks (VPN) between data centers. 1368 Operational considerations include capacity and availability 1369 monitoring. The security monitoring may be to detect anomalies in 1370 the data flows, similar to what was described in the "Monitoring for 1371 Hosted Storage Section". If IPsec tunnel mode is in use, monitoring 1372 is limited to a 2-tuple, or with transport mode, a 5-tuple. 1374 4. Encryption for Enterprises 1376 Encryption of network traffic within the private enterprise is a 1377 growing trend, particularly in industries with audit and regulatory 1378 requirements. Some enterprise internal networks are almost 1379 completely TLS and/or IPsec encrypted. 1381 For each type of monitoring, different techniques and access to parts 1382 of the data stream are part of current practice. As we transition to 1383 an increased use of encryption, alternate methods of monitoring for 1384 operational purposes may be necessary to reduce the practice of 1385 breaking encryption (other policies may apply in some enterprise 1386 settings). 1388 4.1. Monitoring Practices of the Enterprise 1390 Large corporate enterprises are the owners of the platforms, data, 1391 and network infrastructure that provide critical business services to 1392 their user communities. As such, these enterprises are responsible 1393 for all aspects of the performance, availability, security, and 1394 quality of experience for all user sessions. In many such 1395 enterprises, users are required to consent to the enterprise 1396 monitoring all their activities as a condition of employment. 1397 Subsections of 4. Encryption for Enterprises may discuss techniques 1398 that access data beyond the data-link, network, and transport level 1399 headers typically used in SP networks since the corporate enterprise 1400 owns the data. These responsibilities break down into three basic 1401 areas: 1403 1. Security Monitoring and Control 1405 2. Application Performance Monitoring and Reporting 1407 3. Network Diagnostics and Troubleshooting 1409 In each of the above areas, technical support teams utilize 1410 collection, monitoring, and diagnostic systems. Some organizations 1411 currently use attack methods such as replicated TLS server RSA 1412 private keys to decrypt passively monitored copies of encrypted TLS 1413 packet streams. 1415 For an enterprise to avoid costly application down time and deliver 1416 expected levels of performance, protection, and availability, some 1417 forms of traffic analysis, sometimes including examination of packet 1418 payloads, are currently used. 1420 4.1.1. Security Monitoring in the Enterprise 1422 Enterprise users are subject to the policies of their organization 1423 and the jurisdictions in which the enterprise operates. As such, 1424 proxies may be in use to: 1426 1. intercept outbound session traffic to monitor for intellectual 1427 property leakage (by users, malware, and trojans), 1429 2. detect viruses/malware entering the network via email or web 1430 traffic, 1432 3. detect malware/Trojans in action, possibly connecting to remote 1433 hosts, 1435 4. detect attacks (Cross site scripting and other common web related 1436 attacks), 1438 5. track misuse and abuse by employees, 1440 6. restrict the types of protocols permitted to/from the entire 1441 corporate environment, 1443 7. detect and defend against Internet DDoS attacks, including both 1444 volumetric and layer 7 attacks. 1446 A significant portion of malware hides its activity within TLS or 1447 other encryption protocols. This includes lateral movement, Command 1448 and Control, and Data Exfiltration. 1450 The impact to a fully encrypted internal network would include cost 1451 and possible loss of detection capabilities associated with the 1452 transformation of the network architecture and tools for monitoring. 1453 The capabilities of detection through traffic fingerprinting, logs, 1454 host-level transaction monitoring, and flow analysis would vary 1455 depending on access to a 2-tuple or 5-tuple in the network as well. 1457 Security monitoring in the enterprise may also be performed at the 1458 endpoint with numerous current solutions that mitigate the same 1459 problems as some of the above mentioned solutions. Since the 1460 software agents operate on the device, they are able to monitor 1461 traffic before it is encrypted, monitor for behavior changes, and 1462 lock down devices to use only the expected set of applications. 1463 Session encryption does not affect these solutions. Some might argue 1464 that scaling is an issue in the enterprise, but some large 1465 enterprises have used these tools effectively. 1467 Use of Bring-your-own-device (BYOD) policies within organizations may 1468 limit the scope of monitoring permitted with these alternate 1469 solutions. Network endpoint assessment (NEA) or the use of virtual 1470 hosts could help to bridge the monitoring gap. 1472 4.1.2. Application Performance Monitoring in the Enterprise 1474 There are two main goals of monitoring: 1476 1. Assess traffic volume on a per-application basis, for billing, 1477 capacity planning, optimization of geographical location for 1478 servers or proxies, and other goals. 1480 2. Assess performance in terms of application response time and user 1481 perceived response time. 1483 Network-based Application Performance Monitoring tracks application 1484 response time by user and by URL, which is the information that the 1485 application owners and the lines of business request. Content 1486 Delivery Networks (CDNs) add complexity in determining the ultimate 1487 endpoint destination. By their very nature, such information is 1488 obscured by CDNs and encrypted protocols -- adding a new challenge 1489 for troubleshooting network and application problems. URL 1490 identification allows the application support team to do granular, 1491 code level troubleshooting at multiple tiers of an application. 1493 New methodologies to monitor user perceived response time and to 1494 separate network from server time are evolving. For example, the 1495 IPv6 Destination Option Header (DOH) implementation of Performance 1496 and Diagnostic Metrics (PDM) will provide this [RFC8250]. Using PDM 1497 with IPsec Encapsulating Security Payload (ESP) Transport Mode 1498 requires placement of the PDM DOH within the ESP encrypted payload to 1499 avoid leaking timing and sequence number information that could be 1500 useful to an attacker. Use of PDM DOH also may introduce some 1501 security weaknesses, including a timing attack, as described in 1502 Section 7 of [RFC8250]. For these and other reasons, [RFC8250] 1503 requires that the PDM DOH option be explicitly turned on by 1504 administrative action in each host where this measurement feature 1505 will be used. 1507 4.1.3. Enterprise Network Diagnostics and Troubleshooting 1509 One primary key to network troubleshooting is the ability to follow a 1510 transaction through the various tiers of an application in order to 1511 isolate the fault domain. A variety of factors relating to the 1512 structure of the modern data center and multi-tiered application have 1513 made it difficult to follow a transaction in network traces without 1514 the ability to examine some of the packet payload. Alternate 1515 methods, such as log analysis need improvement to fill this gap. 1517 4.1.3.1. Address Sharing (NAT) 1519 Content Delivery Networks (CDNs) and NATs and Network Address and 1520 Port Translators (NAPT) obscure the ultimate endpoint designation 1521 (See [RFC6269] for types of address sharing and a list of issues). 1522 Troubleshooting a problem for a specific end user requires finding 1523 information such as the IP address and other identifying information 1524 so that their problem can be resolved in a timely manner. 1526 NAT is also frequently used by lower layers of the data center 1527 infrastructure. Firewalls, Load Balancers, Web Servers, App Servers, 1528 and Middleware servers all regularly NAT the source IP of packets. 1529 Combine this with the fact that users are often allocated randomly by 1530 load balancers to all these devices, the network troubleshooter is 1531 often left with very few options in today's environment due to poor 1532 logging implementations in applications. As such, network 1533 troubleshooting is used to trace packets at a particular layer, 1534 decrypt them, and look at the payload to find a user session. 1536 This kind of bulk packet capture and bulk decryption is frequently 1537 used when troubleshooting a large and complex application. Endpoints 1538 typically don't have the capacity to handle this level of network 1539 packet capture, so out-of-band networks of robust packet brokers and 1540 network sniffers that use techniques such as copies of TLS RSA 1541 private keys accomplish this task today. 1543 4.1.3.2. TCP Pipelining/Session Multiplexing 1545 TCP pipelining/session multiplexing used mainly by middleboxes today 1546 allows for multiple end user sessions to share the same TCP 1547 connection. This raises several points of interest with an increased 1548 use of encryption. TCP session multiplexing should still be possible 1549 when TLS or TCPcrypt is in use since the TCP header information is 1550 exposed leaving the 5-tuple accessible. The use of TCP session 1551 multiplexing of an IP layer encryption, e.g. IPsec, that only 1552 exposes a 2-tuple would not be possible. Troubleshooting 1553 capabilities with encrypted sessions from the middlebox may limit 1554 troubleshooting to the use of logs from the end points performing the 1555 TCP multiplexing or from the middleboxes prior to any additional 1556 encryption that may be added to tunnel the TCP multiplexed traffic. 1558 Increased use of HTTP/2 will likely further increase the prevalence 1559 of session multiplexing, both on the Internet and in the private data 1560 center. HTTP pipelining requires both the client and server to 1561 participate; visibility of packets once encrypted will hide the use 1562 of HTTP pipelining for any monitoring that takes place outside of the 1563 endpoint or proxy solution. Since HTTP pipelining is between a 1564 client and server, logging capabilities may require improvement in 1565 some servers and clients for debugging purposes if this is not 1566 already possible. Visibility for middleboxes includes anything 1567 exposed by TLS and the 5-tuple. 1569 4.1.3.3. HTTP Service Calls 1571 When an application server makes an HTTP service call to back end 1572 services on behalf of a user session, it uses a completely different 1573 URL and a completely different TCP connection. Troubleshooting via 1574 network trace involves matching up the user request with the HTTP 1575 service call. Some organizations do this today by decrypting the TLS 1576 packet and inspecting the payload. Logging has not been adequate for 1577 their purposes. 1579 4.1.3.4. Application Layer Data 1581 Many applications use text formats such as XML to transport data or 1582 application level information. When transaction failures occur and 1583 the logs are inadequate to determine the cause, network and 1584 application teams work together, each having a different view of the 1585 transaction failure. Using this troubleshooting method, the network 1586 packet is correlated with the actual problem experienced by an 1587 application to find a root cause. The inability to access the 1588 payload prevents this method of troubleshooting. 1590 4.2. Techniques for Monitoring Internet Session Traffic 1592 Corporate networks commonly monitor outbound session traffic to 1593 detect or prevent attacks as well as to guarantee service level 1594 expectations. In some cases, alternate options are available when 1595 encryption is in use through a proxy or a shift to monitoring at the 1596 endpoint. In both cases, scaling is a concern and advancements to 1597 support this shift in monitoring practices will assist the deployment 1598 of end-to-end encryption. 1600 Some DLP tools intercept traffic at the Internet gateway or proxy 1601 services with the ability to man-in-the-middle (MiTM) encrypted 1602 session traffic (HTTP/TLS). These tools may monitor for key words 1603 important to the enterprise including business sensitive information 1604 such as trade secrets, financial data, personally identifiable 1605 information (PII), or personal health information (PHI). Various 1606 techniques are used to intercept HTTP/TLS sessions for DLP and other 1607 purposes, and can be misused as described in "Summarizing Known 1608 Attacks on TLS and DTLS" [RFC7457] Section 2.8. Note: many corporate 1609 policies allow access to personal financial and other sites for users 1610 without interception. Another option is to terminate a TLS session 1611 prior to the point where monitoring is performed. Aside from 1612 exposing user information to the enterprise MITM devices often are 1613 subject to severe security defects which can lead to exposure of user 1614 data to attackers outside the enterprise UserData [UserData]. In 1615 addition, implementation errors in middleboxes have led to major 1616 difficulties in deploying new versions of security protocols such as 1617 TLS [Ben17a][Ben17b][Res17a][Res17b] 1619 Monitoring traffic patterns for anomalous behavior such as increased 1620 flows of traffic that could be bursty at odd times or flows to 1621 unusual destinations (small or large amounts of traffic) is common. 1622 This traffic may or may not be encrypted and various methods of 1623 encryption or just obfuscation may be used. 1625 Web filtering devices are sometimes used to allow only access to 1626 well-known sites found to be legitimate and free of malware on last 1627 check by a web filtering service company. One common example of web 1628 filtering in a corporate environment is blocking access to sites that 1629 are not well-known to these tools for the purpose of blocking 1630 malware; this may be noticeable to those in research who are unable 1631 to access colleague's individual sites or new web sites that have not 1632 yet been screened. In situations where new sites are required for 1633 access, they can typically be added after notification by the user or 1634 log alerts and review. Home mail account access may be blocked in 1635 corporate settings to prevent another vector for malware to enter as 1636 well as for intellectual property to leak out of the network. This 1637 method remains functional with increased use of encryption and may be 1638 more effective at preventing malware from entering the network. Some 1639 enterprises may be more aggressive in their filtering and monitoring 1640 policy, causing undesirable outcomes. Web filtering solutions 1641 monitor and potentially restrict access based on the destination URL 1642 when available, server name, IP address, or the DNS name. A complete 1643 URL may be used in cases where access restrictions vary for content 1644 on a particular site or for the sites hosted on a particular server. 1645 In some cases, the enterprise may use a proxy to access this 1646 additional information based on their policy. This type of 1647 restriction is intended to be transparent to users in a corporate 1648 setting as the typical corporate user does not access sites which are 1649 not well-known to these tools. However, the mechanisms which these 1650 web filters use to do monitoring and enforcement have the potential 1651 to cause access issues or other user-visible failures. 1653 Desktop DLP tools are used in some corporate environments as well. 1654 Since these tools reside on the desktop, they can intercept traffic 1655 before it is encrypted and may provide a continued method of 1656 monitoring intellectual property leakage from the desktop to the 1657 Internet or attached devices. 1659 DLP tools can also be deployed by Network Service providers, as they 1660 have the vantage point of monitoring all traffic paired with 1661 destinations off the enterprise network. This makes an effective 1662 solution for enterprises that allow "bring-your-own" devices when the 1663 traffic is not encrypted, and for devices outside the desktop 1664 category (such as mobile phones) that are used on corporate networks 1665 nonetheless. 1667 Enterprises may wish to reduce the traffic on their Internet access 1668 facilities by monitoring requests for within-policy content and 1669 caching it. In this case, repeated requests for Internet content 1670 spawned by URLs in e-mail trade newsletters or other sources can be 1671 served within the enterprise network. Gradual deployment of end to 1672 end encryption would tend to reduce the cacheable content over time, 1673 owing to concealment of critical headers and payloads. Many forms of 1674 enterprise performance management may be similarly affected. It 1675 should be noted that transparent caching is considered an anti- 1676 pattern. 1678 5. Security Monitoring for Specific Attack Types 1680 Effective incident response today requires collaboration at Internet 1681 scale. This section will only focus on efforts of collaboration at 1682 Internet scale that are dedicated to specific attack types. They may 1683 require new monitoring and detection techniques in an increasingly 1684 encrypted Internet. As mentioned previously, some service providers 1685 have been interfering with STARTTLS to prevent session encryption to 1686 be able to perform functions they are used to (injecting ads, 1687 monitoring, etc.). By detailing the current monitoring methods used 1688 for attack detection and response, this information can be used to 1689 devise new monitoring methods that will be effective in the changed 1690 Internet via collaboration and innovation. 1692 Changes to improve encryption or to deploy OS methods have little 1693 impact on the detection of malicious actors. Malicious actors have 1694 had access to strong encryption for quite some time. Incident 1695 responders, in many cases, have developed techniques to locate 1696 malicious traffic within encrypted sessions. The following section 1697 will note some examples where detection and mitigation of such 1698 traffic has been successful. 1700 5.1. Mail Abuse and spam 1702 The largest operational effort to prevent mail abuse is through the 1703 Messaging, Malware, Mobile Anti-Abuse Working Group (M3AAWG)[M3AAWG]. 1704 Mail abuse is combatted directly with mail administrators who can 1705 shut down or stop continued mail abuse originating from large scale 1706 providers that participate in using the Abuse Reporting Format (ARF) 1707 agents standardized in the IETF [RFC5965], [RFC6430], [RFC6590], 1708 [RFC6591], [RFC6650], [RFC6651], and [RFC6652]. The ARF agent 1709 directly reports abuse messages to the appropriate service provider 1710 who can take action to stop or mitigate the abuse. Since this 1711 technique uses the actual message, the use of SMTP over TLS between 1712 mail gateways will not affect its usefulness. As mentioned 1713 previously, SMTP over TLS only protects data while in transit and the 1714 messages may be exposed on mail servers or mail gateways if a user- 1715 to-user encryption method is not used. Current user-to-user message 1716 encryption methods on email (S/MIME and PGP) do not encrypt the email 1717 header information used by ARF and the service provider operators in 1718 their abuse mitigation efforts. 1720 Another effort, Domain-based Message Authentication, Reporting, and 1721 Conformance (DMARC) [RFC7489] is a mechanism for policy distribution 1722 that enables increasingly strict handling of messages that fail 1723 authentication checks, ranging from no action, through altered 1724 delivery, up to message rejection. DMARC is also not affected by the 1725 use of STARTTLS. 1727 5.2. Denial of Service 1729 Response to Denial of Service (DoS) attacks are typically coordinated 1730 by the SP community with a few key vendors who have tools to assist 1731 in the mitigation efforts. Traffic patterns are determined from each 1732 DoS attack to stop or rate limit the traffic flows with patterns 1733 unique to that DoS attack. 1735 Data types used in monitoring traffic for DDoS are described in the 1736 DDoS Open Threat Signaling (DOTS) [DOTS] working group documents in 1737 development. The impact of encryption can be understood from their 1738 documented use cases[I-D.ietf-dots-use-cases]. 1740 Data types used in DDoS attacks have been detailed in the IODEF 1741 Guidance draft [RFC8274], Appendix A.2, with the help of several 1742 members of the service provider community. The examples provided are 1743 intended to help identify the useful data in detecting and mitigating 1744 these attacks independent of the transport and protocol descriptions 1745 in the drafts. 1747 5.3. Phishing 1749 Investigations and response to phishing attacks follow well-known 1750 patterns, requiring access to specific fields in email headers as 1751 well as content from the body of the message. When reporting 1752 phishing attacks, the recipient has access to each field as well as 1753 the body to make content reporting possible, even when end-to-end 1754 encryption is used. The email header information is useful to 1755 identify the mail servers and accounts used to generate or relay the 1756 attack messages in order to take the appropriate actions. The 1757 content of the message often contains an embedded attack that may be 1758 in an infected file or may be a link that results in the download of 1759 malware to the user's system. 1761 Administrators often find it helpful to use header information to 1762 track down similar message in their mail queue or users inboxes to 1763 prevent further infection. Combinations of To:, From:, Subject:, 1764 Received: from header information might be used for this purpose. 1765 Administrators may also search for document attachments of the same 1766 name, size, or containing a file with a matching hash to a known 1767 phishing attack. Administrators might also add URLs contained in 1768 messages to block lists locally or this may also be done by browser 1769 vendors through larger scales efforts like that of the Anti-Phishing 1770 Working Group (APWG). See the Coordinating Attack Response at 1771 Internet Scale (CARIS) workshop Report [RFC8073] for additional 1772 information and pointers to the APWG's efforts on anti- phishing. 1774 A full list of the fields used in phishing attack incident response 1775 can be found in RFC5901. Future plans to increase privacy 1776 protections may limit some of these capabilities if some email header 1777 fields are encrypted, such as To:, From:, and Subject: header fields. 1778 This does not mean that those fields should not be encrypted, only 1779 that we should be aware of how they are currently used. 1781 Some products protect users from phishing by maintaining lists of 1782 known phishing domains (such as misspelled bank names) and blocking 1783 access. This can be done by observing DNS, clear-text HTTP, or 1784 server name indication (SNI) in TLS, in addition to analyzing email. 1785 Alternate options to detect and prevent phishing attacks may be 1786 needed. More recent examples of data exchanged in spear phishing 1787 attacks has been detailed in the IODEF Guidance draft [RFC8274], 1788 Appendix A.3. 1790 5.4. Botnets 1792 Botnet detection and mitigation is complex as botnets may involve 1793 hundreds or thousands of hosts with numerous Command and Control 1794 (C&C) servers. The techniques and data used to monitor and detect 1795 each may vary. Connections to C&C servers are typically encrypted, 1796 therefore a move to an increasingly encrypted Internet may not affect 1797 the detection and sharing methods used. 1799 5.5. Malware 1801 Malware monitoring and detection techniques vary. As mentioned in 1802 the enterprise section, malware monitoring may occur at gateways to 1803 the organization analyzing email and web traffic. These services can 1804 also be provided by service providers, changing the scale and 1805 location of this type of monitoring. Additionally, incident 1806 responders may identify attributes unique to types of malware to help 1807 track down instances by their communication patterns on the Internet 1808 or by alterations to hosts and servers. 1810 Data types used in malware investigations have been summarized in an 1811 example of the IODEF Guidance draft [RFC8274], Appendix A.1. 1813 5.6. Spoofed Source IP Address Protection 1815 The IETF has reacted to spoofed source IP address-based attacks, 1816 recommending the use of network ingress filtering BCP 38 [RFC2827] 1817 and the unicast Reverse Path Forwarding (uRPF) mechanism [RFC2504]. 1818 But uRPF suffers from limitations regarding its granularity: a 1819 malicious node can still use a spoofed IP address included inside the 1820 prefix assigned to its link. The Source Address Validation 1821 Improvements (SAVI) mechanisms try to solve this issue. Basically, a 1822 SAVI mechanism is based on the monitoring of a specific address 1823 assignment/management protocol (e.g., SLAAC [RFC4862], SEND 1824 [RFC3971], DHCPv4/v6 [RFC2131][RFC3315]) and, according to this 1825 monitoring, set-up a filtering policy allowing only the IP flows with 1826 a correct source IP address (i.e., any packet with a source IP 1827 address, from a node not owning it, is dropped). The encryption of 1828 parts of the address assignment/management protocols, critical for 1829 SAVI mechanisms, can result in a dysfunction of the SAVI mechanisms. 1831 5.7. Further work 1833 Although incident response work will continue, new methods to prevent 1834 system compromise through security automation and continuous 1835 monitoring [SACM] may provide alternate approaches where system 1836 security is maintained as a preventative measure. 1838 6. Application-based Flow Information Visible to a Network 1840 This section describes specific techniques used in monitoring 1841 applications that is visible to the network if a 5-tuple is exposed 1842 and as such can potentially be used an input future network 1843 management approaches. It also includes an overview of IPFIX, a 1844 flow-based protocol used to export information about network flows. 1846 6.1. IP Flow Information Export 1848 Many of the accounting, monitoring and measurement tasks described in 1849 this document, especially Section 2.3.2, Section 3.1.1, 1850 Section 4.1.3, Section 4.2, and Section 5.2 use the IPFIX protocol 1851 [RFC7011] for export and storage of the monitored information. IPFIX 1852 evolved from the widely-deployed NetFlow protocol [RFC3954], which 1853 exports information about flows identified by 5-tuple. While NetFlow 1854 was largely concerned with exporting per-flow byte and packet counts 1855 for accounting purposes, IPFIX's extensible information model 1856 [RFC7012] provides a variety of Information Elements (IEs) 1857 [IPFIX-IANA] for representing information above and below the 1858 traditional network layer flow information. Enterprise-specific IEs 1859 allow exporter vendors to define their own non-standard IEs, as well, 1860 and many of these are driven by header and payload inspection at the 1861 metering process. 1863 While the deployment of encryption has no direct effect on the use of 1864 IPFIX, certain defined IEs may become unavailable when the metering 1865 process observing the traffic cannot decrypt formerly cleartext 1866 information. For example, HTTPS renders HTTP header analysis 1867 impossible, so IEs derived from the header (e.g. httpContentType, 1868 httpUserAgent) cannot be exported. 1870 The collection of IPFIX data itself, of course, provides a point of 1871 centralization for potentially business- and privacy-critical 1872 information. The IPFIX File Format specification [RFC5655] 1873 recommends encryption for this data at rest, and the IP Flow 1874 Anonymization specification [RFC6235] defines a metadata format for 1875 describing the anonymization functions applied to an IPFIX dataset, 1876 if anonymization is employed for data sharing of IPFIX information 1877 between enterprises or network operators. 1879 6.2. TLS Server Name Indication 1881 When initiating the TLS handshake, the Client may provide an 1882 extension field (server_name) which indicates the server to which it 1883 is attempting a secure connection. TLS SNI was standardized in 2003 1884 to enable servers to present the "correct TLS certificate" to clients 1885 in a deployment of multiple virtual servers hosted by the same server 1886 infrastructure and IP-address. Although this is an optional 1887 extension, it is today supported by all modern browsers, web servers 1888 and developer libraries. Akamai [Nygren] reports that many of their 1889 customer see client TLS SNI usage over 99%. It should be noted that 1890 HTTP/2 introduces the Alt-SVC method for upgrading the connection 1891 from HTTP/1 to either unencrypted or encrypted HTTP/2. If the 1892 initial HTTP/1 request is unencrypted, the destination alternate 1893 service name can be identified before the communication is 1894 potentially upgraded to encrypted HTTP/2 transport. HTTP/2 requires 1895 the TLS implementation to support the Server Name Indication (SNI) 1896 extension (see section 9.2 of [RFC7540]). It is also worth noting 1897 that [RFC7838] "allows an origin server to nominate additional means 1898 of interacting with it on the network", while [RFC8164] allows for a 1899 URI to be accessed with HTTP/2 and TLS using Opportunistic Security 1900 (on an experimental basis). 1902 This information is only available if the client populates the Server 1903 Name Indication extension. Doing so is an optional part of the TLS 1904 standard and as stated above this has been implemented by all major 1905 browsers. Due to its optional nature, though, existing network 1906 filters that examine a TLS ClientHello for a SNI extension cannot 1907 expect to always find one. The SNI Encryption in TLS Through 1908 Tunneling [I-D.ietf-tls-sni-encryption] draft has been adopted by the 1909 TLS working group, which provides solutions to encrypt SNI. As such, 1910 there will be an option to encrypt SNI in future versions of TLS. 1911 The per-domain nature of SNI may not reveal the specific service or 1912 media type being accessed, especially where the domain is of a 1913 provider offering a range of email, video, Web pages etc. For 1914 example, certain blog or social network feeds may be deemed 'adult 1915 content', but the Server Name Indication will only indicate the 1916 server domain rather than a URL path. 1918 There are additional issues for identification of content using SNI: 1919 [RFC7540] includes connection coalescing, 1920 [I-D.ietf-httpbis-origin-frame] defines the ORIGIN frame, and the 1921 [I-D.bishop-httpbis-http2-additional-certs] proposal will increase 1922 the difficulty of passive monitoring. 1924 6.3. Application Layer Protocol Negotiation (ALPN) 1926 ALPN is a TLS extension which may be used to indicate the application 1927 protocol within the TLS session. This is likely to be of more value 1928 to the network where it indicates a protocol dedicated to a 1929 particular traffic type (such as video streaming) rather than a 1930 multi-use protocol. ALPN is used as part of HTTP/2 'h2', but will 1931 not indicate the traffic types which may make up streams within an 1932 HTTP/2 multiplex. ALPN is sent clear text in the ClientHello and the 1933 server returns it in Encrypted Extensions in TLS 1.3. 1935 6.4. Content Length, BitRate and Pacing 1937 The content length of encrypted traffic is effectively the same as 1938 that of the cleartext. Although block ciphers utilize padding, this 1939 makes a negligible difference. Bitrate and pacing are generally 1940 application specific, and do not change much when the content is 1941 encrypted. Multiplexed formats (such as HTTP/2 and QUIC [QUIC]) may 1942 however incorporate several application streams over one connection, 1943 which makes the bitrate/pacing no longer application-specific. Also, 1944 packet padding is available in HTTP/2, TLS 1.3, and many other 1945 protocols. Traffic analysis is made more difficult by such 1946 countermeasures. 1948 7. Effect of Encryption on Mobile Network Evolution 1950 Transport header encryption prevents the use of transit proxies in 1951 center of the network and the use of some edge proxies by preventing 1952 the proxies from taking action on the stream. It may be that the 1953 claimed benefits of such proxies could be achieved by end-to-end 1954 client and server optimizations, distribution using CDNs, plus the 1955 ability to continue connections across different access technologies 1956 (across dynamic user IP addresses). The following aspects should be 1957 considered in this approach: 1959 1. In a wireless mobile network, the delay and channel capacity per 1960 user and sector varies due to coverage, contention, user 1961 mobility, scheduling balances fairness, capacity, and service 1962 QoE. If most users are at the cell edge, the controller cannot 1963 use more complex QAM, thus reducing total cell capacity; 1964 similarly if a UMTS edge is serving some number of CS-Voice 1965 Calls, the remaining capacity for packet services is reduced. 1967 2. Mobile wireless networks service in-bound roamers (Users of 1968 Operator A in a foreign operator Network B) by backhauling their 1969 traffic though Operator B's network to Operator A's Network and 1970 then serving through the P-Gateway (PGW), General GPRS Support 1971 Node (GGSN), Content Distribution Network (CDN) etc., of Operator 1972 A (User's Home Operator). Increasing window sizes to compensate 1973 for the path RTT will have the limitations outlined earlier for 1974 TCP. The outbound roamer scenario has a similar TCP performance 1975 impact. 1977 3. Issues in deploying CDNs in Radio Access Networks (RAN) include 1978 decreasing client-server control loop that requires deploying 1979 CDNs/Cloud functions that terminate encryption closer to the 1980 edge. In Cellular RAN, the user IP traffic is encapsulated into 1981 General Packet Radio Service (GPRS) Tunneling Protocol-User Plane 1982 (GTP-U in UMTS and LTE) tunnels to handle user mobility; the 1983 tunnels terminate in APN/GGSN/PGW that are in central locations. 1984 One user's traffic may flow through one or more APN's (for 1985 example Internet APN, Roaming APN for Operator X, Video-Service 1986 APN, OnDeckAPN etc.). The scope of operator private IP addresses 1987 may be limited to specific APNs. Since CDNs generally operate on 1988 user IP flows, deploying them would require enhancing them with 1989 tunnel translation, tunnel management functions etc. 1991 4. While CDNs that de-encrypt flows or split-connection proxy 1992 (similar to split-tcp) could be deployed closer to the edges to 1993 reduce control loop RTT, with transport header encryption, such 1994 CDNs perform optimization functions only for partner client 1995 flows. Therefore, content from some Small-Medium Businesses 1996 (SMBs) would not get such CDN benefits. 1998 8. Response to Increased Encryption and Looking Forward 2000 As stated in [RFC7258], "an appropriate balance (between network 2001 management and PM mitigations) will emerge over time as real 2002 instances of this tension are considered." Numerous operators made 2003 it clear in their response to this document that they fully support 2004 strong encryption and providing privacy for end users, this is a 2005 common goal. Operators recognize not all the practices documented 2006 need to be supported going forward, either because of the risk to end 2007 user privacy or alternate technologies and tools have already 2008 emerged. This document is intended to support network engineers and 2009 other innovators to work toward solving network and security 2010 management problems with protocol designers and application 2011 developers in new ways that facilitate adoption of strong encryption 2012 rather than preventing the use of encryption. By having the 2013 discussions on network and security management practices with 2014 application developers and protocol designers, each side of the 2015 debate can understand each others goals, work toward alternate 2016 solutions, and disband with practices that should no longer be 2017 supported. A goal of this document is to assist the IETF to 2018 understand some of the current practices so as to identify new work 2019 items for IETF-related use cases which can help facilitate the 2020 adoption of strong session encryption and support network and 2021 security management. 2023 9. Security Considerations 2025 There are no additional security considerations as this is a summary 2026 and does not include a new protocol or functionality. 2028 10. IANA Considerations 2030 This memo makes no requests of IANA. 2032 11. Acknowledgements 2034 Thanks to our reviewers, Natasha Rooney, Kevin Smith, Ashutosh Dutta, 2035 Brandon Williams, Jean-Michel Combes, Nalini Elkins, Paul Barrett, 2036 Badri Subramanyan, Igor Lubashev, Suresh Krishnan, Dave Dolson, 2037 Mohamed Boucadair, Stephen Farrell, Warren Kumari, Alia Atlas, Roman 2038 Danyliw, Mirja Kuhlewind, Ines Robles, Joe Clarke, Kyle Rose, 2039 Christian Huitema, and Chris Morrow for their editorial and content 2040 suggestions. Surya K. Kovvali provided material for section 7. 2041 Chris Morrow and Nik Teague provided reviews and updates specific to 2042 the DoS fingerprinting text. Brian Trammell provided the IPFIX text. 2044 12. Informative References 2046 [ACCORD] "Acord BoF IETF95 2047 https://www.ietf.org/proceedings/95/accord.html". 2049 [CAIDA] "CAIDA *Anonymized Internet Traces* 2050 [http://www.caida.org/data/overview/ and 2051 http://www.caida.org/data/passive/ 2052 passive_2016_dataset.xml]". 2054 [DarkMail] 2055 "The Dark Mail Technical Aliance https://darkmail.info/". 2057 [DOTS] https://datatracker.ietf.org/wg/dots/charter/, "DDoS Open 2058 Threat Signaling IETF Working Group". 2060 [EFF2014] "EFF Report on STARTTLS Downgrade Attacks 2061 https://www.eff.org/deeplinks/2014/11/ 2062 starttls-downgrade-attacks". 2064 [Enrich] Narseo Vallina-Rodriguez, et al., "Header Enrichment or 2065 ISP Enrichment, Emerging Privacy Threats in Mobile 2066 Networks, Hot Middlebox, August 17-21 2015, London, United 2067 Kingdom", 2015. 2069 [I-D.bishop-httpbis-http2-additional-certs] 2070 Bishop, M., Sullivan, N., and M. Thomson, "Secondary 2071 Certificate Authentication in HTTP/2", draft-bishop- 2072 httpbis-http2-additional-certs-05 (work in progress), 2073 October 2017. 2075 [I-D.dolson-plus-middlebox-benefits] 2076 Dolson, D., Snellman, J., Boucadair, M., and C. Jacquenet, 2077 "Beneficial Functions of Middleboxes", draft-dolson-plus- 2078 middlebox-benefits-03 (work in progress), March 2017. 2080 [I-D.ietf-dots-use-cases] 2081 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., 2082 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS 2083 Open Threat Signaling", draft-ietf-dots-use-cases-09 (work 2084 in progress), November 2017. 2086 [I-D.ietf-httpbis-origin-frame] 2087 Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame", 2088 draft-ietf-httpbis-origin-frame-06 (work in progress), 2089 January 2018. 2091 [I-D.ietf-tls-sni-encryption] 2092 Huitema, C. and E. Rescorla, "SNI Encryption in TLS 2093 Through Tunneling", draft-ietf-tls-sni-encryption-02 (work 2094 in progress), March 2018. 2096 [I-D.mglt-nvo3-geneve-security-requirements] 2097 Migault, D., Boutros, S., Wing, D., and S. Krishnan, 2098 "Geneve Protocol Security Requirements", draft-mglt-nvo3- 2099 geneve-security-requirements-03 (work in progress), 2100 February 2018. 2102 [IPFIX-IANA] 2103 "IP Flow Information Export (IPFIX) Entities 2104 https://www.iana.org/assignments/ipfix/". 2106 [JNSLP] Surveillance, Vol. 8 No. 3, "10 Standards for Oversight 2107 and Transparency of National Intelligence Services 2108 http://jnslp.com/". 2110 [M3AAWG] "Messaging, Malware, Mobile Anti-Abuse Working Group 2111 (M3AAWG) https://www.maawg.org/". 2113 [Nygren] https://blogs.akamai.com/2017/03/ reaching-toward- 2114 universal-tls-sni.html, "Erik Nygren, personal reference". 2116 [QUIC] https://datatracker.ietf.org/wg/quic/charter/, "QUIC 2117 (quic)". 2119 [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext 2120 Transfer Protocol -- HTTP/1.0", RFC 1945, 2121 DOI 10.17487/RFC1945, May 1996, 2122 . 2124 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 2125 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 2126 . 2128 [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic 2129 Technology and the Internet", BCP 200, RFC 1984, 2130 DOI 10.17487/RFC1984, August 1996, 2131 . 2133 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 2134 RFC 2131, DOI 10.17487/RFC2131, March 1997, 2135 . 2137 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2138 "Definition of the Differentiated Services Field (DS 2139 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2140 DOI 10.17487/RFC2474, December 1998, 2141 . 2143 [RFC2504] Guttman, E., Leong, L., and G. Malkin, "Users' Security 2144 Handbook", FYI 34, RFC 2504, DOI 10.17487/RFC2504, 2145 February 1999, . 2147 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 2148 Translator (NAT) Terminology and Considerations", 2149 RFC 2663, DOI 10.17487/RFC2663, August 1999, 2150 . 2152 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 2153 DOI 10.17487/RFC2775, February 2000, 2154 . 2156 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 2157 DOI 10.17487/RFC2804, May 2000, 2158 . 2160 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2161 Defeating Denial of Service Attacks which employ IP Source 2162 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 2163 May 2000, . 2165 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 2166 Shelby, "Performance Enhancing Proxies Intended to 2167 Mitigate Link-Related Degradations", RFC 3135, 2168 DOI 10.17487/RFC3135, June 2001, 2169 . 2171 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 2172 C., and M. Carney, "Dynamic Host Configuration Protocol 2173 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2174 2003, . 2176 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2177 Jacobson, "RTP: A Transport Protocol for Real-Time 2178 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2179 July 2003, . 2181 [RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of 2182 the Middle and the Future of End-to-End: Reflections on 2183 the Evolution of the Internet Architecture", RFC 3724, 2184 DOI 10.17487/RFC3724, March 2004, 2185 . 2187 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export 2188 Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004, 2189 . 2191 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 2192 "SEcure Neighbor Discovery (SEND)", RFC 3971, 2193 DOI 10.17487/RFC3971, March 2005, 2194 . 2196 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 2197 Translation (NAT) Behavioral Requirements for Unicast 2198 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2199 2007, . 2201 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2202 Address Autoconfiguration", RFC 4862, 2203 DOI 10.17487/RFC4862, September 2007, 2204 . 2206 [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. 2207 Wagner, "Specification of the IP Flow Information Export 2208 (IPFIX) File Format", RFC 5655, DOI 10.17487/RFC5655, 2209 October 2009, . 2211 [RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An 2212 Extensible Format for Email Feedback Reports", RFC 5965, 2213 DOI 10.17487/RFC5965, August 2010, 2214 . 2216 [RFC6108] Chung, C., Kasyanov, A., Livingood, J., Mody, N., and B. 2217 Van Lieu, "Comcast's Web Notification System Design", 2218 RFC 6108, DOI 10.17487/RFC6108, February 2011, 2219 . 2221 [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization 2222 Support", RFC 6235, DOI 10.17487/RFC6235, May 2011, 2223 . 2225 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 2226 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 2227 DOI 10.17487/RFC6269, June 2011, 2228 . 2230 [RFC6430] Li, K. and B. Leiba, "Email Feedback Report Type Value: 2231 not-spam", RFC 6430, DOI 10.17487/RFC6430, November 2011, 2232 . 2234 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 2235 RFC 6455, DOI 10.17487/RFC6455, December 2011, 2236 . 2238 [RFC6590] Falk, J., Ed. and M. Kucherawy, Ed., "Redaction of 2239 Potentially Sensitive Data from Mail Abuse Reports", 2240 RFC 6590, DOI 10.17487/RFC6590, April 2012, 2241 . 2243 [RFC6591] Fontana, H., "Authentication Failure Reporting Using the 2244 Abuse Reporting Format", RFC 6591, DOI 10.17487/RFC6591, 2245 April 2012, . 2247 [RFC6650] Falk, J. and M. Kucherawy, Ed., "Creation and Use of Email 2248 Feedback Reports: An Applicability Statement for the Abuse 2249 Reporting Format (ARF)", RFC 6650, DOI 10.17487/RFC6650, 2250 June 2012, . 2252 [RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail 2253 (DKIM) for Failure Reporting", RFC 6651, 2254 DOI 10.17487/RFC6651, June 2012, 2255 . 2257 [RFC6652] Kitterman, S., "Sender Policy Framework (SPF) 2258 Authentication Failure Reporting Using the Abuse Reporting 2259 Format", RFC 6652, DOI 10.17487/RFC6652, June 2012, 2260 . 2262 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 2263 "Specification of the IP Flow Information Export (IPFIX) 2264 Protocol for the Exchange of Flow Information", STD 77, 2265 RFC 7011, DOI 10.17487/RFC7011, September 2013, 2266 . 2268 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 2269 for IP Flow Information Export (IPFIX)", RFC 7012, 2270 DOI 10.17487/RFC7012, September 2013, 2271 . 2273 [RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, 2274 "Internet Small Computer System Interface (iSCSI) Protocol 2275 (Consolidated)", RFC 7143, DOI 10.17487/RFC7143, April 2276 2014, . 2278 [RFC7146] Black, D. and P. Koning, "Securing Block Storage Protocols 2279 over IP: RFC 3723 Requirements Update for IPsec v3", 2280 RFC 7146, DOI 10.17487/RFC7146, April 2014, 2281 . 2283 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2284 Protocol (HTTP/1.1): Message Syntax and Routing", 2285 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2286 . 2288 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 2289 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 2290 RFC 7234, DOI 10.17487/RFC7234, June 2014, 2291 . 2293 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 2294 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2295 2014, . 2297 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 2298 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 2299 eXtensible Local Area Network (VXLAN): A Framework for 2300 Overlaying Virtualized Layer 2 Networks over Layer 3 2301 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 2302 . 2304 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 2305 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 2306 December 2014, . 2308 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 2309 Known Attacks on Transport Layer Security (TLS) and 2310 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 2311 February 2015, . 2313 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 2314 Message Authentication, Reporting, and Conformance 2315 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 2316 . 2318 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 2319 Service Function Chaining", RFC 7498, 2320 DOI 10.17487/RFC7498, April 2015, 2321 . 2323 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2324 "Recommendations for Secure Use of Transport Layer 2325 Security (TLS) and Datagram Transport Layer Security 2326 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2327 2015, . 2329 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 2330 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 2331 DOI 10.17487/RFC7540, May 2015, 2332 . 2334 [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication 2335 Method in the Internet Key Exchange Protocol Version 2 2336 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, 2337 . 2339 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 2340 Trammell, B., Huitema, C., and D. Borkmann, 2341 "Confidentiality in the Face of Pervasive Surveillance: A 2342 Threat Model and Problem Statement", RFC 7624, 2343 DOI 10.17487/RFC7624, August 2015, 2344 . 2346 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 2347 Chaining (SFC) Architecture", RFC 7665, 2348 DOI 10.17487/RFC7665, October 2015, 2349 . 2351 [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. 2352 Nordmark, "Technical Considerations for Internet Service 2353 Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, 2354 March 2016, . 2356 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 2357 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 2358 May 2016, . 2360 [RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 2361 and M. Stiemerling, Ed., "Real-Time Streaming Protocol 2362 Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 2363 2016, . 2365 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 2366 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 2367 April 2016, . 2369 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 2370 and P. Hoffman, "Specification for DNS over Transport 2371 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2372 2016, . 2374 [RFC8073] Moriarty, K. and M. Ford, "Coordinating Attack Response at 2375 Internet Scale (CARIS) Workshop Report", RFC 8073, 2376 DOI 10.17487/RFC8073, March 2017, 2377 . 2379 [RFC8164] Nottingham, M. and M. Thomson, "Opportunistic Security for 2380 HTTP/2", RFC 8164, DOI 10.17487/RFC8164, May 2017, 2381 . 2383 [RFC8165] Hardie, T., "Design Considerations for Metadata 2384 Insertion", RFC 8165, DOI 10.17487/RFC8165, May 2017, 2385 . 2387 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 2388 Performance and Diagnostic Metrics (PDM) Destination 2389 Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, 2390 . 2392 [RFC8274] Kampanakis, P. and M. Suzuki, "Incident Object Description 2393 Exchange Format Usage Guidance", RFC 8274, 2394 DOI 10.17487/RFC8274, November 2017, 2395 . 2397 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 2398 "Network Service Header (NSH)", RFC 8300, 2399 DOI 10.17487/RFC8300, January 2018, 2400 . 2402 [SACM] https://datatracker.ietf.org/wg/sacm/charter/, "Security 2403 Automation and Continuous Monitoring (sacm) IETF Working 2404 Group". 2406 [Snowden] http://www.jjsylvia.com/bigdatacourse/wp- 2407 content/uploads/2016/04/p14-verble-1.pdf, "The NSA and 2408 Edward Snowden: Surveillance In The 21st Century", 2014. 2410 [TCPcrypt] 2411 https://datatracker.ietf.org/wg/tcpinc/charter/, 2412 "TCPcrypt". 2414 [TLS100Proceedings] 2415 IETF 100, TLS Working Group Session, "Presentation before 2416 the TLS WG at IETF 2417 https://datatracker.ietf.org/meeting/100/materials/ 2418 slides-100-tls-sessa-tls13/", 2017. 2420 [TS3GPP] "3GPP TS 24.301, "Non-Access-Stratum (NAS) protocol for 2421 Evolved Packet System (EPS); Stage 3"", 2017. 2423 [UPCON] 3GPP, "User Plane Congestion Management 2424 http://www.3gpp.org/DynaReport/ 2425 FeatureOrStudyItemFile-570029.htm", 2014. 2427 [UserData] 2428 Network and Distributed Systems Symposium, The Internet 2429 Society, "The Security Impact of HTTPS Interception", 2430 2017. 2432 Authors' Addresses 2434 Kathleen Moriarty (editor) 2435 Dell EMC 2436 176 South St 2437 Hopkinton, MA 2438 USA 2440 Phone: +1 2441 Email: Kathleen.Moriarty@dell.com 2443 Al Morton (editor) 2444 AT&T Labs 2445 200 Laurel Avenue South 2446 Middletown,, NJ 07748 2447 USA 2449 Phone: +1 732 420 1571 2450 Fax: +1 732 368 1192 2451 Email: acmorton@att.com