idnits 2.17.1 draft-mm-wg-effect-encrypt-13.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 771: '... SHOULD be turned off [RFC4787]....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 10, 2017) is 2383 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 1984' is mentioned on line 143, but not defined == Missing Reference: 'RFC 2804' is mentioned on line 143, but not defined == Missing Reference: 'RFC 2775' is mentioned on line 143, but not defined == Missing Reference: 'RFC 3724' is mentioned on line 143, but not defined == Missing Reference: 'RFC 7754' is mentioned on line 143, but not defined == Unused Reference: 'EFF' is defined on line 1861, but no explicit reference was found in the text == Unused Reference: 'RFC2775' is defined on line 1933, but no explicit reference was found in the text == Unused Reference: 'RFC2804' is defined on line 1937, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-tls-sni-encryption-00 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7234 (Obsoleted by RFC 9111) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Moriarty 3 Internet-Draft Dell EMC 4 Intended status: Informational A. Morton 5 Expires: April 13, 2018 AT&T Labs 6 October 10, 2017 8 Effect of Pervasive Encryption on Operators 9 draft-mm-wg-effect-encrypt-13 11 Abstract 13 Pervasive Monitoring (PM) attacks on the privacy of Internet users is 14 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 management practices that may be impacted by the 20 shift to increased use of encryption to help guide protocol 21 development in support of manageable, 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 April 13, 2018. 40 Copyright Notice 42 Copyright (c) 2017 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 2. Network Service Provider Monitoring . . . . . . . . . . . . . 6 60 2.1. Passive Monitoring . . . . . . . . . . . . . . . . . . . 7 61 2.1.1. Traffic Surveys . . . . . . . . . . . . . . . . . . . 7 62 2.1.2. Troubleshooting . . . . . . . . . . . . . . . . . . . 7 63 2.1.3. Traffic Analysis Fingerprinting . . . . . . . . . . . 9 64 2.2. Traffic Optimization and Management . . . . . . . . . . . 10 65 2.2.1. Load Balancers . . . . . . . . . . . . . . . . . . . 10 66 2.2.2. Differential Treatment based on Deep Packet 67 Inspection (DPI) . . . . . . . . . . . . . . . . . . 12 68 2.2.3. Network Congestion Management . . . . . . . . . . . . 13 69 2.2.4. Performance-enhancing Proxies . . . . . . . . . . . . 13 70 2.2.5. Caching and Content Replication Near the Network Edge 13 71 2.2.6. Content Compression . . . . . . . . . . . . . . . . . 14 72 2.3. Network Access and Accounting . . . . . . . . . . . . . . 14 73 2.3.1. Content Filtering . . . . . . . . . . . . . . . . . . 15 74 2.3.2. Network Access and Data Usage . . . . . . . . . . . . 15 75 2.3.3. Application Layer Gateways . . . . . . . . . . . . . 16 76 2.3.4. HTTP Header Insertion . . . . . . . . . . . . . . . . 17 77 3. Encryption in Hosting SP Environments . . . . . . . . . . . . 17 78 3.1. Management Access Security . . . . . . . . . . . . . . . 18 79 3.1.1. Customer Access Monitoring . . . . . . . . . . . . . 19 80 3.1.2. SP Content Monitoring of Applications . . . . . . . . 20 81 3.2. Hosted Applications . . . . . . . . . . . . . . . . . . . 21 82 3.2.1. Monitoring Managed Applications . . . . . . . . . . . 21 83 3.2.2. Mail Service Providers . . . . . . . . . . . . . . . 22 84 3.3. Data Storage . . . . . . . . . . . . . . . . . . . . . . 22 85 3.3.1. Host-level Encryption . . . . . . . . . . . . . . . . 23 86 3.3.2. Disk Encryption, Data at Rest . . . . . . . . . . . . 23 87 3.3.3. Cross Data Center Replication Services . . . . . . . 24 88 4. Encryption for Enterprises . . . . . . . . . . . . . . . . . 24 89 4.1. Monitoring Practices of the Enterprise . . . . . . . . . 25 90 4.1.1. Security Monitoring in the Enterprise . . . . . . . . 25 91 4.1.2. Application Performance Monitoring in the Enterprise 26 92 4.1.3. Enterprise Network Diagnostics and Troubleshooting . 27 93 4.2. Techniques for Monitoring Internet Session Traffic . . . 28 94 5. Security Monitoring for Specific Attack Types . . . . . . . . 30 95 5.1. Mail Abuse and SPAM . . . . . . . . . . . . . . . . . . . 30 96 5.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 31 97 5.3. Phishing . . . . . . . . . . . . . . . . . . . . . . . . 31 98 5.4. Botnets . . . . . . . . . . . . . . . . . . . . . . . . . 32 99 5.5. Malware . . . . . . . . . . . . . . . . . . . . . . . . . 32 100 5.6. Spoofed Source IP Address Protection . . . . . . . . . . 32 101 5.7. Further work . . . . . . . . . . . . . . . . . . . . . . 33 102 6. Application-based Flow Information Visible to a Network . . . 33 103 6.1. IP Flow Information Export . . . . . . . . . . . . . . . 33 104 6.2. TLS Server Name Indication . . . . . . . . . . . . . . . 34 105 6.3. Application Layer Protocol Negotiation (ALPN) . . . . . . 34 106 6.4. Content Length, BitRate and Pacing . . . . . . . . . . . 35 107 7. Impact on Mobility Network Optimizations and New Services . . 35 108 7.1. Effect of Encypted ACKs . . . . . . . . . . . . . . . . . 35 109 7.2. Effect of Encrypted Transport Headers . . . . . . . . . . 36 110 7.3. Effect of Encryption on New or Emerging Services . . . . 36 111 7.4. Effect of Encryption on Mobile Network Evolution . . . . 37 112 8. Response to Increased Encryption and Looking Forward . . . . 38 113 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 114 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 115 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 116 12. Informative References . . . . . . . . . . . . . . . . . . . 39 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 119 1. Introduction 121 In response to pervasive monitoring revelations and the IETF 122 consensus that Pervasive Monitoring is an Attack [RFC7258], efforts 123 are underway to increase encryption of Internet traffic. Pervasive 124 Monitoring (PM) is of serious concern to users, operators, and 125 application providers. RFC7258 discussed the critical need to 126 protect users' privacy when developing IETF specifications and also 127 recognized that making networks unmanageable to mitigate PM is not an 128 acceptable outcome, but rather that an appropriate balance would 129 emerge over time. 131 This document discusses practices currently used by network operators 132 to manage, operate, and secure their networks and how those practices 133 may be impacted by a shift to increased use of encryption. It 134 provides network operators' perspectives about the motivations and 135 objectives of those practices as well as effects anticipated by 136 operators as use of encryption increases. It is a summary of 137 concerns of the operational community as they transition to managing 138 networks with less visibility. The document does not endorse the use 139 of the practices described herein. Nor does it aim to provide a 140 comprehensive treatment of the effects of current practices, some of 141 which have been considered controversial from a technical or business 142 perspective or contradictory to previous IETF statements (e.g., [RFC 143 1958], [RFC 1984], [RFC 2804], [RFC 2775], [RFC 3724], [RFC 7754]). 145 This document aims to help IETF participants understand network 146 operators' perspectives about the impact of pervasive encryption, 147 both opportunistic and strong end-to-end encryption, on operational 148 practices. The goal is to help inform future protocol development to 149 ensure that operational impact is part of the conversation. Ideally, 150 new methods could be developed to accomplish the goals of current 151 practices despite changes in the extent to which cleartext will be 152 available to network operators. Discussion of current practices and 153 the potential future changes is provided as a prerequisite to 154 potential future cross-industry and cross-layer work to support the 155 ongoing evolution towards a functional Internet with pervasive 156 encryption. 158 Traditional network management, planning, security operations, and 159 performance optimization have been developed in an Internet where a 160 large majority of data traffic flows without encryption. While 161 unencrypted traffic has made information that aids operations and 162 troubleshooting at all layers accessible, it has also made pervasive 163 monitoring by unseen parties possible. With broad support and 164 increased awareness of the need to consider privacy in all aspects 165 across the Internet, it is important to catalog existing management, 166 operational, and security practices that have depended upon the 167 availability of cleartext to function. 169 This document includes a sampling of current practices and does not 170 attempt to describe every nuance. Some sections cover technologies 171 used over a broad spectrum of devices and use cases. 173 1.1. Additional Background on Encryption Changes 175 Session encryption helps to prevent both passive and active attacks 176 on transport protocols; more on pervasive monitoring can be found in 177 Confidentiality in the Face of Pervasive Surveillance: A Threat Model 178 and Problem Statement [RFC7624]. The Internet Architecture Board 179 (IAB) released a statement advocating for increased use of encryption 180 in November 2014. Perspectives on encryption paradigms have also 181 shifted. One such shift is documented in "Opportunistic Security" 182 (OS) [RFC7435], which suggests that when use of authenticated 183 encryption is not possible, cleartext sessions should be upgraded to 184 unauthenticated session encryption, rather than no encryption. OS 185 encourages upgrading from cleartext, but cannot require or guarantee 186 such upgrades. Once OS is used, it allows for an evolution to 187 authenticated encryption. These efforts are necessary to improve end 188 user's expectation of privacy, making pervasive monitoring cost 189 prohibitive. With OS in use, active attacks are still possible on 190 unauthenticated sessions. OS has been implemented as NULL 191 Authentication with IPsec [RFC7619] and there are a number of 192 infrastructure use cases such as server to server encryption, where 193 this mode is deployed. IPsec with authentication has many useful 194 applications and usage has increased for infrastructure applications 195 such as for virtual private networks between data centers. 197 Although there is a push for OS, there is also work being done to 198 improve the implementation, development and configuration of TLS and 199 DTLS sessions to prevent active attacks used to monitor or intercept 200 session data. The 202 (UTA) working group has been publishing documentation to improve the 203 security of TLS and DTLS sessions. They have documented the known 204 attack vectors in [RFC7457] and have documented Best Practices for 205 TLS and DTLS in [RFC7525] and have other documents in the queue. 207 In addition to encrypted web site access (HTTP over TLS), there are 208 other well-deployed application level transport encryption efforts 209 such as mail transfer agent (MTA)-to-MTA session encryption transport 210 for email (SMTP over TLS) and gateway-to-gateway for instant 211 messaging (Extensible Messaging and Presence Protocol (XMPP) over 212 TLS). Although this does provide protection from transport layer 213 attacks, the servers could be a point of vulnerability if user-to- 214 user encryption is not provided for these messaging protocols. User- 215 to-user content encryption schemes, such as S/MIME and PGP for email 216 and encryption (e.g. Off-the-Record (OTR)) for XMPP are used by 217 those interested to protect their data as it crosses intermediary 218 servers, preventing the vulnerability described by providing an end- 219 to-end solution. User-to-user schemes are under review and 220 additional options will emerge to ease the configuration 221 requirements, making this type of option more accessible to non- 222 technical users interested in protecting their privacy. 224 Increased use of encryption, either opportunistic or authenticated, 225 at the transport, network or application layer, impacts how networks 226 are operated, managed, and secured. In some cases, new methods to 227 operate, manage, and secure networks will evolve in response. In 228 other cases, currently available capabilities for monitoring or 229 troubleshooting networks could become unavailable. This document 230 lists a collection of functions currently employed by network 231 operators that may be impacted by the shift to increased use of 232 encryption. This draft does not attempt to specify responses or 233 solutions to these impacts, but rather documents the current state. 235 This document refers to several different forms of service providers, 236 distinguished with adjectives. For example, network service 237 providers (or network operators) provide IP-packet transport 238 primarily, though they may bundle other services with packet 239 transport. Alternatively, application service providers primarily 240 offer systems that participate as an end-point in communications with 241 the application user, and hosting service providers lease computing, 242 storage, and communications systems in datacenters. In practice, 243 many companies perform two or more service provider roles, but may be 244 historically associated with one. 246 2. Network Service Provider Monitoring 248 Network Service Providers (SP) for this definition include the 249 backbone Internet Service providers as well as those providing 250 infrastructure at scale for core Internet use (hosted infrastructure 251 and services such as email). 253 Following the Snowden revelations, application service providers 254 responded by encrypting traffic between their data centers (IPsec) to 255 prevent passive monitoring from taking place unbeknownst to them 256 (Yahoo, Google, etc.). Large mail service providers also began to 257 encrypt session transport (TLS) to hosted mail services. This and 258 other increases in the use of encryption had the immediate effect of 259 helping protect the privacy of users' data, but created a problem for 260 some network management functions. They could no longer gain access 261 to some session streams resulting in actions by several to regain 262 their operational practices that previously depended on cleartext 263 data sessions. 265 The EFF reported [EFF2014] several network service providers taking 266 steps to prevent the use of SMTP over TLS by breaking STARTTLS 267 (section 3.2 of [RFC7525]), essentially preventing the negotiation 268 process resulting in fallback to the use of clear text. In other 269 cases, some service providers have relied on middle boxes having 270 access to clear text for the purposes of load balancing, monitoring 271 for attack traffic, meeting regulatory requirements, or for other 272 purposes. These middle box implementations, whether performing 273 functions considered legitimate by the IETF or not, have been 274 impacted by increases in encrypted traffic. Only methods keeping 275 with the goal of balancing network management and PM mitigation in 276 [RFC7258] should be considered in solution work resulting from this 277 document. 279 Network service providers use various techniques to operate, manage, 280 and secure their networks. The following subsections detail the 281 purpose of each technique and which protocol fields are used to 282 accomplish each task. In response to increased encryption of these 283 fields, some network service providers may be tempted to undertake 284 undesirable security practices in order to gain access to the fields 285 in unencrypted data flows. To avoid this situation, ideally new 286 methods could be developed to accomplish the same goals without 287 service providers having the ability to see session data. 289 2.1. Passive Monitoring 291 2.1.1. Traffic Surveys 293 Internet traffic surveys are useful in many pursuits, such as input 294 for CAIDA studies [CAIDA], network planning and optimization. 295 Tracking the trends in Internet traffic growth, from earlier peer-to- 296 peer communication to the extensive adoption of unicast video 297 streaming applications, has relied on a view of traffic composition 298 with a particular level of assumed accuracy, based on access to 299 cleartext by those conducting the surveys. 301 Passive monitoring makes inferences about observed traffic using the 302 maximal information available, and is subject to inaccuracies 303 stemming from incomplete sampling (of packets in a stream) or loss 304 due to monitoring system overload. When encryption conceals more 305 layers in each packet, reliance on pattern inferences and other 306 heuristics grows, and accuracy suffers. For example, the traffic 307 patterns between server and browser are dependent on browser supplier 308 and version, even when the sessions use the same server application 309 (e.g., web e-mail access). It remains to be seen whether more 310 complex inferences can be mastered to produce the same monitoring 311 accuracy. 313 2.1.2. Troubleshooting 315 Network operators use packet captures and protocol-dissecting 316 analyzers when responding to customer problems, to identify the 317 presence of attack traffic, and to identify root causes of the 318 problem such as misconfiguration. The protocol dissection is 319 generally limited to supporting protocols (e.g., DNS, DHCP), network 320 and transport (e.g., IP, TCP), and some higher layer protocols (e.g., 321 RTP, RTCP). 323 Network operators are often the first ones called upon to investigate 324 application problems (e.g., "my HD video is choppy"). When 325 diagnosing a customer problem, the starting point may be a particular 326 application that isn't working. The ability to identify the problem 327 application's traffic is important and deep packet inspection (DPI) 328 is often used for this purpose; IP address filtering is not useful 329 for applications using CDNs or cloud providers. After identifying 330 the traffic, an operator may analyze the traffic characteristics and 331 routing of the traffic. 333 For example, by investigating packet loss (from TCP sequence and 334 acknowledgement numbers), round-trip-time (from TCP timestamp options 335 or application-layer transactions, e.g., DNS or HTTP response time), 336 TCP receive-window size, packet corruption (from checksum 337 verification), inefficient fragmentation, or application-layer 338 problems, the operator can narrow the problem to a portion of the 339 network, server overload, client or server misconfiguration, etc. 340 Network operators may also be able to identify the presence of attack 341 traffic as not conforming to the application the user claims to be 342 using. 344 One way of quickly excluding the network as the bottleneck during 345 troubleshooting is to check whether the speed is limited by the 346 endpoints. For example, the connection speed might instead be 347 limited by suboptimal TCP options, the sender's congestion window, 348 the sender temporarily running out of data to send, the sender 349 waiting for the receiver to send another request, or the receiver 350 closing the receive window. All this information can be derived from 351 the cleartext TCP header. 353 Packet captures and protocol-dissecting analyzers have been important 354 tools. Automated monitoring has also been used to proactively 355 identify poor network conditions, leading to maintenance and network 356 upgrades before user experience declines. For example, findings of 357 loss and jitter in VoIP traffic can be a predictor of future customer 358 dissatisfaction (supported by metadata from RTP/RTCP protocol 359 )[RFC3550], or increases in DNS response time can generally make 360 interactive web browsing appear sluggish. But to detect such 361 problems, the application or service stream must first be 362 distinguished from others. 364 When using increased encryption, operators lose a source of data that 365 may be used to debug user issues. Because of this, application 366 server operators using increased encryption should expect to be 367 called upon more frequently to assist with debugging and 368 troubleshooting, and thus may want to consider what tools can be put 369 in the hands of their clients or network operators. 371 Further, the performance of some services can be more efficiently 372 managed and repaired when information on user transactions is 373 available to the service provider. It may be possible to continue 374 such monitoring activities without clear text access to the 375 application layers of interest, but inaccuracy will increase and 376 efficiency of repair activities will decrease. For example, an 377 application protocol error or failure would be opaque to network 378 troubleshooters when transport encryption is applied, making root 379 cause location more difficult and therefore increasing the time-to- 380 repair. Repair time directly reduces the availability of the 381 service, and most network operators have made availability a key 382 metric in their Service Level Agreements and/or subscription rebates. 383 Also, there may be more cases of user communication failures when the 384 additional encryption processes are introduced (e.g., key management 385 at large scale), leading to more customer service contacts and (at 386 the same time) less information available to network operations 387 repair teams. 389 In mobile networks, knowledge about TCP's stream transfer progress 390 (by observing ACKs, retransmissions, packet drops, and the Sector 391 Utilization Level etc.) is further used to measure the performance of 392 Network Segments (Sector, eNodeB (eNB) etc.). This information is 393 used as Key Performance Indicators (KPIs) and for the estimation of 394 User/Service Key Quality Indicators at network edges for circuit 395 emulation (CEM) as well as input for mitigation methods. If the 396 make-up of active services per user and per sector are not visible to 397 a server that provides Internet Access Point Names (APN), it cannot 398 perform mitigation functions based on network segment view. 400 It is important to note that the push for encryption by application 401 providers has been motivated by the application of the described 402 techniques. Some application providers have noted degraded 403 performance and/or user experience when network-based optimization or 404 enhancement of their traffic has occurred, and such cases may result 405 in additional operator troubleshooting, as well. 407 2.1.3. Traffic Analysis Fingerprinting 409 Fingerprinting is used in traffic analysis and monitoring to identify 410 traffic streams that match certain patterns. This technique is 411 sometimes used with clear text or encrypted sessions. Some 412 Distributed Denial of Service (DDoS) prevention techniques at the 413 network provider level rely on the ability to fingerprint traffic in 414 order to mitigate the effect of this type of attack. Thus, 415 fingerprinting may be an aspect of an attack or part of attack 416 countermeasures. 418 A common, early trigger for DDoS mitigation includes observing 419 uncharacteristic traffic volumes or sources; congestion; or 420 degradation of a given network or service. One approach to mitigate 421 such an attack involves distinguishing attacker traffic from 422 legitimate user traffic. The ability to examine layers and payloads 423 above transport provides a new range of filtering opportunities at 424 each layer in the clear. If fewer layers are in the clear, this 425 means that there are reduced filtering opportunities available to 426 mitigate attacks. However, fingerprinting is still possible. 428 Passive monitoring of network traffic can lead to invasion of privacy 429 by external actors at the endpoints of the monitored traffic. 430 Encryption of traffic end-to-end is one method to obfuscate some of 431 the potentially identifying information. Many DoS mitigation systems 432 perform this manner of passive monitoring. 434 For example, browser fingerprints are comprised of many 435 characteristics, including User Agent, HTTP Accept headers, browser 436 plug-in details, screen size and color details, system fonts and time 437 zone. A monitoring system could easily identify a specific browser, 438 and by correlating other information, identify a specific user. 440 2.2. Traffic Optimization and Management 442 2.2.1. Load Balancers 444 A standalone load balancer is a function one can take off the shelf, 445 place in front of a pool of servers, configure appropriately, and it 446 will balance the traffic load among servers in the pool. This is a 447 typical setup for load balancers. Standalone load balancers rely on 448 the plainly observable information in the packets they are forwarding 449 and rely on industry-accepted standards in interpreting the plainly 450 observable information. Typically, this is a 5-tuple of the 451 connection. This configuration terminates TLS sessions at the load 452 balancer, making it the end point instead of the server. Standalone 453 load balancers are considered middleboxes, but are an integral part 454 of server infrastructure that scales. 456 In contrast, an integrated load balancer is developed to be an 457 integral part of the service provided by the server pool behind that 458 load balancer. These load balancers can communicate state with their 459 pool of servers to better route flows to the appropriate servers. 460 They rely on non-standard system-specific information and operational 461 knowledge shared between the load balancer and its servers. 463 Both standalone and integrated load balancers can be deployed in 464 pools for redundancy and load sharing. For high availability, it is 465 important that when packets belonging to a flow start to arrive at a 466 different load balancer in the load balancer pool, the packets 467 continue to be forwarded to the original server in the server pool. 468 The importance of this requirement increases as the chances of such 469 load balancer change event increases. 471 Mobile operators deploy integrated load balancers to assist with 472 maintaining connection state as devices migrate. With the 473 proliferation of mobile connected devices, there is an acute need for 474 connection-oriented protocols that maintain connections after a 475 network migration by an endpoint. This connection persistence 476 provides an additional challenge for multi-homed anycast-based 477 services typically employed by large content owners and Content 478 Distribution Networks (CDNs). The challenge is that a migration to a 479 different network in the middle of the connection greatly increases 480 the chances of the packets routed to a different anycast point-of- 481 presence (POP) due to the new network's different connectivity and 482 Internet peering arrangements. The load balancer in the new POP, 483 potentially thousands of miles away, will not have information about 484 the new flow and would not be able to route it back to the original 485 POP. 487 To help with the endpoint network migration challenges, anycast 488 service operations are likely to employ integrated load balancers 489 that, in cooperation with their pool servers, are able to ensure that 490 client-to-server packets contain some additional identification in 491 plainly-observable parts of the packets (in addition to the 5-tuple). 492 As noted in Section 2 of [RFC7258], careful consideration in protocol 493 design to mitigate PM is important, while ensuring manageability of 494 the network. 496 Some integrated load balancers have the ability to use additional 497 plainly observable information even for today's protocols that are 498 not network migration tolerant. This additional information allows 499 for improved availability and scaleability of the load balancing 500 operation. For example, BGP reconvergence can cause a flow to switch 501 anycast POPs even without a network change by any endpoint. 502 Additionally, a system that is able to encode the identity of the 503 pool server in plain text information available in each incoming 504 packet is able to provide stateless load balancing. This ability 505 confers great reliability and scaleability advantages even if the 506 flow remains in a single POP, because the load balancing system is 507 not required to keep state of each flow. Even more importantly, 508 there's no requirement to continuously synchronize such state among 509 the pool of load balancers. 511 Current protocols, such as TCP, allow the development of stateless 512 integrated load balancers by availing such load balancers of 513 additional plain text information in client-to-server packets. In 514 case of TCP, such information can be encoded by having server- 515 generated sequence numbers (that are ACK'd by the client), segment 516 values, lengths of the packet sent, etc. 518 Mobile operators apply Self Organizing Networks (3GPP SON) for 519 intelligent workflows such as content-aware MLB (Mobility Load 520 Balancing). Where network load balancers have been configured to 521 route according to application-layer semantics, an encrypted payload 522 is effectively invisible. This has resulted in practices of 523 intercepting TLS in front of load balancers to regain that 524 visibility, but at a cost to security and privacy. 526 In future Network Function Virtualization (NFV) architectures, load 527 balancing functions are likely to be more prevalent (deployed at 528 locations throughout operators' networks), so they would be handling 529 traffic using encrypted tunnels whenever it is present. 531 2.2.2. Differential Treatment based on Deep Packet Inspection (DPI) 533 Data transfer capacity resources in cellular radio networks tend to 534 be more constrained than in fixed networks. This is a result of 535 variance in radio signal strength as a user moves around a cell, the 536 rapid ingress and egress of connections as users hand off between 537 adjacent cells, and temporary congestion at a cell. Mobile networks 538 alleviate this by queuing traffic according to its required bandwidth 539 and acceptable latency: for example, a user is unlikely to notice a 540 20ms delay when receiving a simple Web page or email, or an instant 541 message response, but will very likely notice a re-buffering pause in 542 a video playback or a VoIP call de-jitter buffer. Ideally, the 543 scheduler manages the queue so that each user has an acceptable 544 experience as conditions vary, but inferences of the traffic type 545 have been used to make bearer assignments and set scheduler priority. 547 Deep Packet Inspection (DPI) allows identification of applications 548 based on payload signatures, in contrast to trusting well-known port 549 numbers. Application and transport layer encryption make the traffic 550 type estimation more complex and less accurate, and therefore it may 551 not be effectual to use this information as input for queue 552 management. With the use of WebSockets [RFC6455], for example, many 553 forms of communications (from isochronous/real-time to bulk/elastic 554 file transfer) will take place over HTTP port 80 or port 443, so only 555 the messages and higher-layer data will make application 556 differentiation possible. If the monitoring system sees only "HTTP 557 port 443", it cannot distinguish application streams that would 558 benefit from priority queueing from others that would not. 560 Mobile networks especially rely on content/application based 561 prioritization of Over-the-Top (OTT) services - each application-type 562 or service has different delay/loss/throughput expectations, and each 563 type of stream will be unknown to an edge device if encrypted; this 564 impedes dynamic-QoS adaptation. An alternate way to achieve 565 encrypted application separation is possible when the User Equipment 566 (UE) requests a dedicated bearer for the specific application stream 567 (known by the UE), using a mechanism such as the one described in 568 Section 6.5 of 3GPP TS 24.301 [TS3GPP]. The UE's request includes 569 the Quality Class Indicator (QCI) appropriate for each application, 570 based on their different delay/loss/throughput expectations. 571 However, UE requests for dedicated bearers and QCI may not be 572 supported at the subscriber's service level, or in all mobile 573 networks. 575 These effects and potential alternative solutions have been discussed 576 at the accord BoF [ACCORD] at IETF95. 578 2.2.3. Network Congestion Management 580 For User Plane Congestion Management (3GPP UPCON) - ability to 581 understand content and manage network during congestion. Mitigating 582 techniques such as deferred download, off-peak acceleration, and 583 outbound roamers. 585 2.2.4. Performance-enhancing Proxies 587 Due to the characteristics of the mobile link, performance-enhancing 588 TCP proxies may perform local retransmission at the mobile edge. In 589 TCP, duplicated ACKs are detected and potentially concealed when the 590 proxy retransmits a segment that was lost on the mobile link without 591 involvement of the far end (see section 2.1.1 of [RFC3135] and 592 section 3.5 of [I-D.dolson-plus-middlebox-benefits]). 594 This optimization at network edges measurably improves real-time 595 transmission over long delay Internet paths or networks with large 596 capacity-variation (such as mobile/cellular networks). 598 In general, performance-enhancing proxies have a lower Round-Trip 599 Time (RTT) to the client and therefore determine the responsiveness 600 of flow control. A lower RTT makes the flow control loop more 601 responsive to changing in the mobile network conditions and enables 602 faster adaptation in a delay and capacity varying network due to user 603 mobility. 605 Further, service-provider-operated proxies are used to reduce the 606 control delay between the sender and a receiver on a mobile network 607 where resources are limited. The RTT determines how quickly an 608 user's attempt to cancel a video is recognized and therefore how 609 quickly the traffic is stopped, thus keeping un-wanted video packets 610 from entering the radio scheduler queue. 612 An application-type-aware network edge (middlebox) can further 613 control pacing, limit simultaneous HD videos, or prioritize active 614 videos against new videos, etc. 616 2.2.5. Caching and Content Replication Near the Network Edge 618 The features and efficiency of some Internet services can be 619 augmented through analysis of user flows and the applications they 620 provide. For example, network caching of popular content at a 621 location close to the requesting user can improve delivery efficiency 622 (both in terms of lower request response times and reduced use of 623 International Internet links when content is remotely located), and 624 authorized parties acting on their behalf use DPI in combination with 625 content distribution networks to determine if they can intervene 626 effectively. Web proxies are widely used [WebCache], and caching is 627 supported by the recent update of "Hypertext Transfer Protocol 628 (HTTP/1.1): Caching" in [RFC7234]. Encryption of packet contents at 629 a given protocol layer usually makes DPI processing of that layer and 630 higher layers impossible. That being said, it should be noted that 631 some content providers prevent caching to control content delivery 632 through the use of encrypted end-to-end sessions. CDNs vary in their 633 deployment options of end-to-end encryption. The business risk is a 634 motivation outside of privacy and pervasive monitoring that are 635 driving end-to-end encryption for these content providers. 637 Content replication in caches (for example live video, DRM protected 638 content) is used to most efficiently utilize the available limited 639 bandwidth and thereby maximize the user's Quality of Experience 640 (QoE). Especially in mobile networks, duplicating every stream 641 through the transit network increases backhaul cost for live TV. The 642 Enhanced Multimedia Broadcast/Multicast Services (3GPP eMBMS) - 643 trusted edge proxies facilitate delivering same stream to different 644 users, using either unicast or multicast depending on channel 645 conditions to the user. 647 Alternate approaches such as blind caches [I-D.thomson-http-bc] are 648 being explored to allow caching of encrypted content; however, they 649 still need to intercept the end-to-end transport connection. 651 2.2.6. Content Compression 653 In addition to caching, various applications exist to provide data 654 compression in order to conserve the life of the user's mobile data 655 plan and optimize delivery over the mobile link. The compression 656 proxy access can be built into a specific user level application, 657 such as a browser, or it can be available to all applications using a 658 system level application. The primary method is for the mobile 659 application to connect to a centralized server as a proxy, with the 660 data channel between the client application and the server using 661 compression to minimize bandwidth utilization. The effectiveness of 662 such systems depends on the server having access to unencrypted data 663 flows. 665 2.3. Network Access and Accounting 667 Mobile Networks and many ISPs operate under the regulations of their 668 licensing government authority. These regulations include Lawful 669 Intercept, adherence to Codes of Practice on content filtering, and 670 application of court order filters. Such regulations assume network 671 access to provide content filtering and accounting, as discussed 672 below. 674 2.3.1. Content Filtering 676 There are numerous reasons why service providers might block content: 677 to comply with requests from law enforcement or regulatory 678 authorities, to effectuate parental controls, to enforce content- 679 based billing, or for other reasons, possibly considered 680 inappropriate by some. See RFC7754 [RFC7754] for a survey of 681 Internet filtering techniques and motivations. This section is 682 intended to document a selection of current content blocking 683 practices by operators and the effects of encryption on those 684 practices. Content blocking may also happen at endpoints or at the 685 edge of enterprise networks, but those are not addressed in this 686 section. 688 In a mobile network content filtering usually occurs in the core 689 network. A proxy is installed which analyses the transport metadata 690 of the content users are viewing and either filters content based on 691 a blacklist of sites or based on the user's pre-defined profile (e.g. 692 for age sensitive content). Although filtering can be done by many 693 methods, one commonly used method involves a trigger based on the 694 proxy identifying a DNS lookup of a host name in a URL which appears 695 on a blacklist being used by the operator. The subsequent requests 696 to that domain will be re-routed to a proxy which checks whether the 697 full URL matches a blocked URL on the list, and will return a 404 if 698 a match is found. All other requests should complete. This 699 technique does not work in situations where DNS traffic is encrypted 700 (e.g., by employing [RFC7858] ). 702 Another form of content filtering is called parental control, where 703 some users are deliberately denied access to age-sensitive content as 704 a feature to the service subscriber. Some sites involve a mixture of 705 universal and age-sensitive content and filtering software. In these 706 cases, more granular (application layer) metadata may be used to 707 analyze and block traffic. Methods that accessed cleartext 708 application-layer metadata no longer work when sessions are 709 encrypted. This type of granular filtering could occur at the 710 endpoint. However, the lack of ability to efficiently manage 711 endpoints as a service reduces providers' ability to offer parental 712 control. 714 2.3.2. Network Access and Data Usage 716 Approved access to a network is a prerequisite to requests for 717 Internet traffic. 719 However, there are cases (beyond parental control) when a network 720 service provider currently redirects customer requests for content 721 (affecting content accessibility): 723 1. The network service provider is performing the accounting and 724 billing for the content provider, and the customer has not (yet) 725 purchased the requested content. 727 2. Further content may not be allowed as the customer has reached 728 their usage limit and needs to purchase additional data service, 729 which is the usual billing approach in mobile networks. 731 Currently, some mobile network service providers redirect the 732 customer using HTTP redirect to a page that explains to those 733 customers the reason for the blockage and the steps to proceed. When 734 the HTTP headers and content are encrypted, this prevents mobile 735 carriers from intercepting the traffic and performing an HTTP 736 redirect. As a result, some mobile carriers block customer's 737 encrypted requests, which is a far less optimal customer experience 738 because the blocking reason must be conveyed by some other means. 739 The customer may need to call customer care to find out the reason, 740 both an inconvenience to the customer and additional overhead to the 741 mobile network service provider. 743 Further, when the requested service is about to consume the remainder 744 of the user's plan limits, the transmission could be terminated and 745 advance notifications may be sent to the user by their service 746 provider to warn the user ahead of the exhausted plan. If web 747 content is encrypted, the network provider cannot know the data 748 transfer size at request time. Lacking this visibility of the 749 application type and content size, the network would continue the 750 transmission and stop the transfer when the limit was reached. A 751 partial transfer may not be usable by the client wasting both network 752 and user resources, possibly leading to customer complaints. The 753 content provider does not know user's service plans or current usage, 754 and cannot warn the user of plan exhaustion. 756 In addition, mobile network operator often sell tariffs that allow 757 free-data access to certain sites, known as 'zero rating'. A session 758 to visit such a site incurs no additional cost or data usage to the 759 user. This feature is impacted if encryption hides the details of 760 the content domain from the network. 762 2.3.3. Application Layer Gateways 764 Application Layer Gateways (ALG) assist applications to set 765 connectivity across Network Address Translators (NAT), Firewalls, 766 and/or Load Balancers for specific applications running across mobile 767 networks. Section 2.9 of [RFC2663] describes the role of ALGs and 768 their interaction with NAT and/or application payloads. ALG are 769 deployed with an aim to improve connectivity. However, it is an IETF 770 Best Common Practice recommendation that ALGs for UDP-based protocols 771 SHOULD be turned off [RFC4787]. 773 One example of an ALG in current use is aimed at video applications 774 that use the Real Time Session Protocol (RTSP) [RFC7826] primary 775 stream as a means to identify related Real Time Protocol/Real Time 776 Control Protocol (RTP/RTCP) [RFC3550] flows at set-up. The ALG in 777 this case relies on the 5-tuple flow information derived from RTSP to 778 provision NAT or other middle boxes and provide connectivity. 779 Implementations vary, and two examples follow: 781 1. Parse the content of the RTSP stream and identify the 5-tuple of 782 the supporting streams as they are being negotiated. 784 2. Intercept and modify the 5-tuple information of the supporting 785 media streams as they are being negotiated on the RTSP stream, 786 which is more intrusive to the media streams. 788 When RTSP stream content is encrypted, the 5-tuple information within 789 the payload is not visible to these ALG implementations, and 790 therefore they cannot provision their associated middelboxes with 791 that information. 793 2.3.4. HTTP Header Insertion 795 Some mobile carriers use HTTP header insertion (see section 3.2.1 of 796 [RFC7230]) to provide information about their customers to third 797 parties or to their own internal systems [Enrich]. Third parties use 798 the inserted information for analytics, customization, advertising, 799 to bill the customer, or to selectively allow or block content. HTTP 800 header insertion is also used to pass information internally between 801 a mobile service provider's sub-systems, thus keeping the internal 802 systems loosely coupled. When HTTP connections are encrypted, mobile 803 network service providers cannot insert headers to accomplish the 804 functions above. 806 3. Encryption in Hosting SP Environments 808 Hosted environments have had varied requirements in the past for 809 encryption, with many businesses choosing to use these services 810 primarily for data and applications that are not business or privacy 811 sensitive. A shift prior to the revelations on surveillance/passive 812 monitoring began where businesses were asking for hosted environments 813 to provide higher levels of security so that additional applications 814 and service could be hosted externally. Businesses understanding the 815 threats of monitoring in hosted environments only increased that 816 pressure to provide more secure access and session encryption to 817 protect the management of hosted environments as well as for the data 818 and applications. 820 3.1. Management Access Security 822 Hosted environments may have multiple levels of management access, 823 where some may be strictly for the Hosting SP (infrastructure that 824 may be shared among customers) and some may be accessed by a specific 825 customer for application management. In some cases, there are 826 multiple levels of hosting service providers, further complicating 827 the security of management infrastructure and the associated 828 requirements. 830 Hosting service provider management access is typically segregated 831 from other traffic with a control channel and may or may not be 832 encrypted depending upon the isolation characteristics of the 833 management session. Customer access may be through a dedicated 834 connection, but discussion for that connection method is out-of-scope 835 for this document. 837 Application Service Providers may offer content-level monitoring 838 options to detect intellectual property leakage, or other attacks. 839 In service provider environments where Data Loss Prevention (DLP) has 840 been implemented on the basis of the service provider having 841 cleartext access to session streams, the use of encrypted streams 842 prevents these implementations from conducting content searches for 843 the keywords or phrases configured in the DLP system. DLP is often 844 used to prevent the leakage of Personally Identifiable Information 845 (PII) as well as financial account information, Personal Health 846 Information (PHI), and Payment Card Information (PCI). If session 847 encryption is terminated at a gateway prior to accessing these 848 services, DLP on session data can still be performed. The decision 849 of where to terminate encryption to hosted environments will be a 850 risk decision made between the application service provider and 851 customer organization according to their priorities. DLP can be 852 performed at the server for the hosted application and on an end 853 user's system in an organization as alternate or additional 854 monitoring points of content; however, this is not frequently done in 855 a service provider environment. 857 Application service providers, by their very nature, control the 858 application endpoint. As such, much of the information gleaned from 859 sessions are still available on that endpoint. However, when a gap 860 exists in the application's logging and debugging capabilities, this 861 has led the application service provider to access data-in-transport 862 for monitoring and debugging. 864 Overlay networks (e.g. VXLAN, Geneve, etc.) may be used to indicate 865 desired isolation, but this is not sufficient to prevent deliberate 866 attacks that are aware of the use of the overlay network. It is 867 possible to use an overlay header in combination with IPsec, but this 868 adds the requirement for authentication infrastructure and may reduce 869 packet transfer performance. Additional extension mechanisms to 870 provide integrity and/or privacy protections are being investigated 871 for overlay encapsulations. Section 7 of [RFC7348] describes some of 872 the security issues possible when deploying VXLAN on Layer 2 873 networks. Rogue endpoints can join the multicast groups that carry 874 broadcast traffic, for example. 876 3.1.1. Customer Access Monitoring 878 Hosted applications that allow some level of customer management 879 access may also require monitoring by the hosting service provider. 880 Monitoring could include access control restrictions such as 881 authentication, authorization, and accounting for filtering and 882 firewall rules to ensure they are continuously met. Customer access 883 may occur on multiple levels, including user-level and administrative 884 access. The hosting service provider may need to monitor access 885 either through session monitoring or log evaluation to ensure 886 security service level agreements (SLA) for access management are 887 met. The use of session encryption to access hosted environments 888 limits access restrictions to the metadata described below. 889 Monitoring and filtering may occur at an: 891 2-tuple IP-level with source and destination IP addresses alone, or 893 5-tuple IP and protocol-level with source IP address, destination IP 894 address, protocol number, source port number, and destination port 895 number. 897 Session encryption at the application level, TLS for example, 898 currently allows access to the 5-tuple. IP-level encryption, such as 899 IPsec in tunnel mode prevents access to the original 5-tuple and may 900 limit the ability to restrict traffic via filtering techniques. This 901 shift may not impact all hosting service provider solutions as 902 alternate controls may be used to authenticate sessions or access may 903 require that clients access such services by first connecting to the 904 organization before accessing the hosted application. Shifts in 905 access may be required to maintain equivalent access control 906 management. Logs may also be used for monitoring that access control 907 restrictions are met, but would be limited to the data that could be 908 observed due to encryption at the point of log generation. Log 909 analysis is out of scope for this document. 911 3.1.2. SP Content Monitoring of Applications 913 The following observations apply to any IT organization that is 914 responsible for delivering services, whether to third-parties, for 915 example as a web based service, or to internal customers in an 916 enterprise, e.g. a data processing system that forms a part of the 917 enterprise's business. 919 Organizations responsible for the operation of a data center have 920 many processes which access the contents of IP packets (passive 921 methods of measurement, as defined in [RFC7799]). These processes 922 are typically for service assurance or security purposes as part of 923 their data center operations. 925 Examples include: 927 - Network Performance Monitoring/Application Performance 928 Monitoring 930 - Intrusion defense/prevention systems 932 - Malware detection 934 - Fraud Monitoring 936 - Application DDOS protection 938 - Cyber-attack investigation 940 - Proof of regulatory compliance 942 Many application service providers simply terminate sessions to/from 943 the Internet at the edge of the data center in the form of SSL/TLS 944 offload in the load balancer. Not only does this reduce the load on 945 application servers, it simplifies the processes to enable monitoring 946 of the session content. 948 However, in some situations, encryption deeper in the data center may 949 be necessary to protect personal information or in order to meet 950 industry regulations, e.g. those set out by the Payment Card Industry 951 (PCI). In such situations, various methods have been used to allow 952 service assurance and security processes to access unencrypted data. 953 These include SSL/TLS decryption in dedicated units, which then 954 forward packets to SP-controlled tools, or by real-time or post- 955 capture decryption in the tools themselves. The use of tools that 956 perform SSL/TLS decryption are impacted by the increased use of 957 encryption that prevents interception. 959 Data center operators may also maintain packet recordings in order to 960 be able to investigate attacks, breach of internal processes, etc. 961 In some industries, organizations may be legally required to maintain 962 such information for compliance purposes. Investigations of this 963 nature have used access to the unencrypted contents of the packet. 964 Alternate methods to investigate attacks or breach of process will 965 rely on endpoint information, such as logs. As previously noted, 966 logs often lack complete information, and this is seen as a concern 967 resulting in some relying on session access for additional 968 information. 970 3.2. Hosted Applications 972 Organizations are increasingly using hosted applications rather than 973 in-house solutions that require maintenance of equipment and 974 software. Examples include Enterprise Resource Planning (ERP) 975 solutions, payroll service, time and attendance, travel and expense 976 reporting among others. Organizations may require some level of 977 management access to these hosted applications and will typically 978 require session encryption or a dedicated channel for this activity. 980 In other cases, hosted applications may be fully managed by a hosting 981 service provider with service level agreement expectations for 982 availability and performance as well as for security functions 983 including malware detection. Due to the sensitive nature of these 984 hosted environments, the use of encryption is already prevalent. Any 985 impact may be similar to an enterprise with tools being used inside 986 of the hosted environment to monitor traffic. Additional concerns 987 were not reported in the call for contributions. 989 3.2.1. Monitoring Managed Applications 991 Performance, availability, and other aspects of a SLA are often 992 collected through passive monitoring. For example: 994 o Availability: ability to establish connections with hosts to 995 access applications, and discern the difference between network or 996 host-related causes of unavailability. 998 o Performance: ability to complete transactions within a target 999 response time, and discern the difference between network or host- 1000 related causes of excess response time. 1002 Here, as with all passive monitoring, the accuracy of inferences are 1003 dependent on the cleartext information available, and encryption 1004 would tend to reduce the information and therefore, the accuracy of 1005 each inference. Passive measurement of some metrics will be 1006 impossible with encryption that prevents inferring packet 1007 correspondence across multiple observation points, such as for packet 1008 loss metrics. 1010 Until application logging is sufficient, the ability to make accurate 1011 inferences in an environment with increased encryption will remain a 1012 gap for passive performance monitoring. 1014 3.2.2. Mail Service Providers 1016 Mail (application) service providers vary in what services they 1017 offer. Options may include a fully hosted solution where mail is 1018 stored external to an organization's environment on mail service 1019 provider equipment or the service offering may be limited to monitor 1020 incoming mail to remove SPAM [Section 5.1], malware [Section 5.6], 1021 and phishing attacks [Section 5.3] before mail is directed to the 1022 organization's equipment. In both of these cases, content of the 1023 messages and headers is monitored to detect SPAM, malware, phishing, 1024 and other messages that may be considered an attack. 1026 STARTTLS ought have zero effect on anti-SPAM efforts for SMTP 1027 traffic. Anti-SPAM services could easily be performed on an SMTP 1028 gateway, eliminating the need for TLS decryption services. The 1029 impact to Anti-SPAM service providers should be limited to a change 1030 in tools, where middle boxes were deployed to perform these 1031 functions. 1033 Many efforts are emerging to improve user-to-user encryption, 1034 including promotion of PGP and newer efforts such as Dark Mail 1035 [DarkMail]. Of course, SPAM filtering will not be possible on 1036 encrypted content. 1038 3.3. Data Storage 1040 Numerous service offerings exist that provide hosted storage 1041 solutions. This section describes the various offerings and details 1042 the monitoring for each type of service and how encryption may impact 1043 the operational and security monitoring performed. 1045 Trends in data storage encryption for hosted environments include a 1046 range of options. The following list is intentionally high-level to 1047 describe the types of encryption used in coordination with data 1048 storage that may be hosted remotely, meaning the storage is 1049 physically located in an external data center requiring transport 1050 over the Internet. Options for monitoring will vary with each 1051 encryption approach described below. 1053 3.3.1. Host-level Encryption 1055 For higher security and/or privacy of data and applications, options 1056 that provide end-to-end encryption of the data from the user's 1057 desktop or server to the storage platform may be preferred. With 1058 this description, host level encryption includes any solution that 1059 encrypts data at the object level, not transport level. Encryption 1060 of data may be performed with libraries on the system or at the 1061 application level, which includes file encryption services via a file 1062 manager. Host-level encryption is useful when data storage is 1063 hosted, or scenarios when storage location is determined based on 1064 capacity or based on a set of parameters to automate decisions. This 1065 could mean that large data sets accessed infrequently could be sent 1066 to an off-site storage platform at an external hosting service, data 1067 accessed frequently may be stored locally, or the decision could be 1068 based on the transaction type. Host-level encryption is grouped 1069 separately for the purpose of this document since data may be stored 1070 in multiple locations including off-site remote storage platforms. 1071 If session encryption is used, the protocol is likely to be TLS. 1073 3.3.1.1. Monitoring for Hosted Storage 1075 Monitoring of hosted storage solutions that use host-level (object) 1076 encryption is described in this subsection. Host-level encryption 1077 can be employed for backup services, and occasionally for external 1078 storage services (operated by a third party) when internal storage 1079 limits are exceeded. 1081 Monitoring of data flows to hosted storage solutions is performed for 1082 security and operational purposes. The security monitoring may be to 1083 detect anomalies in the data flows that could include changes to 1084 destination, the amount of data transferred, or alterations in the 1085 size and frequency of flows. Operational considerations include 1086 capacity and availability monitoring. 1088 3.3.2. Disk Encryption, Data at Rest 1090 There are multiple ways to achieve full disk encryption for stored 1091 data. Encryption may be performed on data to be stored while in 1092 transit close to the storage media with solutions like Controller 1093 Based Encryption (CBE) or in the drive system with Self-Encrypting 1094 Drives (SED). Session encryption is typically coupled with 1095 encryption of these data at rest (DAR) solutions to also protect data 1096 in transit. Transport encryption is likely via TLS. 1098 3.3.2.1. Monitoring Session Flows for DAR Solutions 1100 Monitoring for transport of data to storage platforms, where object 1101 level encryption is performed close to or on the storage platform are 1102 similar to those described in the section on Monitoring for Hosted 1103 Storage. The primary difference for these solutions is the possible 1104 exposure of sensitive information, which could include privacy 1105 related data, financial information, or intellectual property if 1106 session encryption via TLS is not deployed. Session encryption is 1107 typically used with these solutions, but that decision would be based 1108 on a risk assessment. There are use cases where DAR or disk-level 1109 encryption is required. Examples include preventing exposure of data 1110 if physical disks are stolen or lost. In the case where TLS is in 1111 use, monitoring and the exposure of data is limited to a 5-tuple. 1113 3.3.3. Cross Data Center Replication Services 1115 Storage services also include data replication which may occur 1116 between data centers and may leverage Internet connections to tunnel 1117 traffic. The traffic may use iSCSI [RFC7143] or FC/IP [RFC7146] 1118 encapsulated in IPsec. Either transport or tunnel mode may be used 1119 for IPsec depending upon the termination points of the IPsec session, 1120 if it is from the storage platform itself or from a gateway device at 1121 the edge of the data center respectively. 1123 3.3.3.1. Monitoring Of IPSec for Data Replication Services 1125 Monitoring for data replication services are described in this 1126 subsection. 1128 Monitoring of data flows between data centers may be performed for 1129 security and operational purposes and would typically concentrate 1130 more on operational aspects since these flows are essentially virtual 1131 private networks (VPN) between data centers. Operational 1132 considerations include capacity and availability monitoring. The 1133 security monitoring may be to detect anomalies in the data flows, 1134 similar to what was described in the "Monitoring for Hosted Storage 1135 Section". If IPsec tunnel mode is in use, monitoring is limited to a 1136 2-tuple, or with transport mode, a 5-tuple. 1138 4. Encryption for Enterprises 1140 Encryption of network traffic within the private enterprise is a 1141 growing trend, particularly in industries with audit and regulatory 1142 requirements. Some enterprise internal networks are almost 1143 completely TLS and/or IPsec encrypted. 1145 For each type of monitoring, different techniques and access to parts 1146 of the data stream are part of current practice. As we transition to 1147 an increased use of encryption, alternate methods of monitoring for 1148 operational purposes may be necessary to reduce the practice of 1149 breaking encryption (other policies may apply in some enterprise 1150 settings). 1152 4.1. Monitoring Practices of the Enterprise 1154 Large corporate enterprises are the owners of the platforms, data, 1155 and network infrastructure that provide critical business services to 1156 their user communities. As such, these enterprises are responsible 1157 for all aspects of the performance, availability, security, and 1158 quality of experience for all user sessions. These responsibilities 1159 break down into three basic areas: 1161 1. Security Monitoring and Control 1163 2. Application Performance Monitoring and Reporting 1165 3. Network Diagnostics and Troubleshooting 1167 In each of the above areas, technical support teams utilize 1168 collection, monitoring, and diagnostic systems. Some organizations 1169 currently use attack methods such as replicated TLS server RSA 1170 private keys to decrypt passively monitored copies of encrypted TLS 1171 packet streams. 1173 For an enterprise to avoid costly application down time and deliver 1174 expected levels of performance, protection, and availability, some 1175 forms of traffic analysis, sometimes including examination of packet 1176 payloads, are currently used. 1178 4.1.1. Security Monitoring in the Enterprise 1180 Enterprise users are subject to the policies of their organization 1181 and the jurisdictions in which the enterprise operates. As such, 1182 proxies may be in use to: 1184 1. intercept outbound session traffic to monitor for intellectual 1185 property leakage (by users or, more likely these days, through 1186 malware and trojans), 1188 2. detect viruses/malware entering the network via email or web 1189 traffic, 1191 3. detect malware/Trojans in action, possibly connecting to remote 1192 hosts, 1194 4. detect attacks (Cross site scripting and other common web related 1195 attacks), 1197 5. track misuse and abuse by employees, 1199 6. restrict the types of protocols permitted to/from the entire 1200 corporate environment, 1202 7. detect and defend against Internet DDoS attacks, including both 1203 volumetric and layer 7 attacks. 1205 A significant portion of malware hides its activity within TLS or 1206 other encrypted protocols. This includes lateral movement, Command 1207 and Control, and Data Exfiltration. Detecting these functions are 1208 important to effective monitoring and mitigation of malicious 1209 traffic, not limited to malware. 1211 Security monitoring in the enterprise may also be performed at the 1212 endpoint with numerous current solutions that mitigate the same 1213 problems as some of the above mentioned solutions. Since the 1214 software agents operate on the device, they are able to monitor 1215 traffic before it is encrypted, monitor for behavior changes, and 1216 lock down devices to use only the expected set of applications. 1217 Session encryption does not affect these solutions. Some might argue 1218 that scaling is an issue in the enterprise, but some large 1219 enterprises have used these tools effectively. 1221 4.1.2. Application Performance Monitoring in the Enterprise 1223 There are two main goals of monitoring: 1225 1. Assess traffic volume on a per-application basis, for billing, 1226 capacity planning, optimization of geographical location for 1227 servers or proxies, and other goals. 1229 2. Assess performance in terms of application response time and user 1230 perceived response time. 1232 Network-based Application Performance Monitoring tracks application 1233 response time by user and by URL, which is the information that the 1234 application owners and the lines of business request. Content 1235 Delivery Networks (CDNs) add complexity in determining the ultimate 1236 endpoint destination. By their very nature, such information is 1237 obscured by CDNs and encrypted protocols -- adding a new challenge 1238 for troubleshooting network and application problems. URL 1239 identification allows the application support team to do granular, 1240 code level troubleshooting at multiple tiers of an application. 1242 New methodologies to monitor user perceived response time and to 1243 separate network from server time are evolving. For example, the 1244 IPv6 Destination Option Header (DOH) implementation of Performance 1245 and Diagnostic Metrics (PDM) will provide this 1246 [I-D.ietf-ippm-6man-pdm-option]. Using PDM with IPSec Encapsulating 1247 Security Payload (ESP) Transport Mode requires placement of the PDM 1248 DOH within the ESP encrypted payload to avoid leaking timing and 1249 sequence number information that could be useful to an attacker. Use 1250 of PDM DOH also may introduce some security weaknesses, including a 1251 timing attack, as described in Section 7 of 1252 [I-D.ietf-ippm-6man-pdm-option]. For these and other reasons, 1253 [I-D.ietf-ippm-6man-pdm-option] requires that the PDM DOH option be 1254 explicitly turned on by administrative action in each host where this 1255 measurement feature will be used. 1257 4.1.3. Enterprise Network Diagnostics and Troubleshooting 1259 One primary key to network troubleshooting is the ability to follow a 1260 transaction through the various tiers of an application in order to 1261 isolate the fault domain. A variety of factors relating to the 1262 structure of the modern data center and multi-tiered application have 1263 made it difficult to follow a transaction in network traces without 1264 the ability to examine some of the packet payload. Alternate 1265 methods, such as log analysis need improvement to fill this gap. 1267 4.1.3.1. Address Sharing (NAT) 1269 Content Delivery Networks (CDNs) and NATs and Network Address and 1270 Port Translators (NAPT) obscure the ultimate endpoint designation 1271 (See [RFC6269] for types of address sharing and a list of issues). 1272 Troubleshooting a problem for a specific end user requires finding 1273 information such as the IP address and other identifying information 1274 so that their problem can be resolved in a timely manner. 1276 NAT is also frequently used by lower layers of the data center 1277 infrastructure. Firewalls, Load Balancers, Web Servers, App Servers, 1278 and Middleware servers all regularly NAT the source IP of packets. 1279 Combine this with the fact that users are often allocated randomly by 1280 load balancers to all these devices, the network troubleshooter is 1281 often left with very few options in today's environment due to poor 1282 logging implementations in applications. As such, network 1283 troubleshooting is used to trace packets at a particular layer, 1284 decrypt them, and look at the payload to find a user session. 1286 This kind of bulk packet capture and bulk decryption is frequently 1287 used when troubleshooting a large and complex application. Endpoints 1288 typically don't have the capacity to handle this level of network 1289 packet capture, so out-of-band networks of robust packet brokers and 1290 network sniffers that use techniques such as copies of TLS RSA 1291 private keys accomplish this task today. 1293 4.1.3.2. TCP Pipelining/Session Multiplexing 1295 TCP Pipelining/Session Multiplexing used mainly by middle boxes today 1296 allow for multiple end user sessions to share the same TCP 1297 connection. Today's network troubleshooter often relies upon session 1298 decryption to tell which packet belongs to which end user, since the 1299 logs are currently inadequate for the analysis performed. 1301 Increased use of HTTP/2 will likely further increase the prevalence 1302 of session multiplexing, both on the Internet and in the private data 1303 center. 1305 4.1.3.3. HTTP Service Calls 1307 When an application server makes an HTTP service call to back end 1308 services on behalf of a user session, it uses a completely different 1309 URL and a completely different TCP connection. Troubleshooting via 1310 network trace involves matching up the user request with the HTTP 1311 service call. Some organizations do this today by decrypting the TLS 1312 packet and inspecting the payload. Logging has not been adequate for 1313 their purposes. 1315 4.1.3.4. Application Layer Data 1317 Many applications use text formats such as XML to transport data or 1318 application level information. When transaction failures occur and 1319 the logs are inadequate to determine the cause, network and 1320 application teams work together, each having a different view of the 1321 transaction failure. Using this troubleshooting method, the network 1322 packet is correlated with the actual problem experienced by an 1323 application to find a root cause. The inability to access the 1324 payload prevents this method of troubleshooting. 1326 4.2. Techniques for Monitoring Internet Session Traffic 1328 Corporate networks commonly monitor outbound session traffic to 1329 detect or prevent attacks as well as to guarantee service level 1330 expectations. In some cases, alternate options are available when 1331 encryption is in use, but techniques like that of data leakage 1332 prevention tools at a proxy would not be possible if encrypted 1333 traffic cannot be intercepted, encouraging alternate options such as 1334 performing these functions at the edge. 1336 Some DLP tools intercept traffic at the Internet gateway or proxy 1337 services with the ability to man-in-the-middle (MiTM) encrypted 1338 session traffic (HTTP/TLS). These tools may use key words important 1339 to the enterprise including business sensitive information such as 1340 trade secrets, financial data, personally identifiable information 1341 (PII), or personal health information (PHI). Various techniques are 1342 used to intercept HTTP/TLS sessions for DLP and other purposes, and 1343 are described in "Summarizing Known Attacks on TLS and DTLS" 1344 [RFC7457]. Note: many corporate policies allow access to personal 1345 financial and other sites for users without interception. Another 1346 option is to terminate a TLS session prior to the point where 1347 monitoring is performed. 1349 Monitoring traffic patterns for anomalous behavior such as increased 1350 flows of traffic that could be bursty at odd times or flows to 1351 unusual destinations (small or large amounts of traffic) is common. 1352 This traffic may or may not be encrypted and various methods of 1353 encryption or just obfuscation may be used. 1355 Restrictions on traffic to approved sites: Web proxies are sometimes 1356 used to filter traffic, allowing only access to well-known sites 1357 found to be legitimate and free of malware on last check by a proxy 1358 service company. This type of restriction is usually not noticeable 1359 in a corporate setting as the typical corporate user does not access 1360 sites that are not well-known to these tools, but may be noticeable 1361 to those in research who are unable to access colleague's individual 1362 sites or new web sites that have not yet been screened. In 1363 situations where new sites are required for access, they can 1364 typically be added after notification by the user or proxy log alerts 1365 and review. Home mail account access may be blocked in corporate 1366 settings to prevent another vector for malware to enter as well as 1367 for intellectual property to leak out of the network. This method 1368 remains functional with increased use of encryption and may be more 1369 effective at preventing malware from entering the network. Web proxy 1370 solutions monitor and potentially restrict access based on the 1371 destination URL or the DNS name. A complete URL may be used in cases 1372 where access restrictions vary for content on a particular site or 1373 for the sites hosted on a particular server. 1375 Desktop DLP tools are used in some corporate environments as well. 1376 Since these tools reside on the desktop, they can intercept traffic 1377 before it is encrypted and may provide a continued method of 1378 monitoring intellectual property leakage from the desktop to the 1379 Internet or attached devices. 1381 DLP tools can also be deployed by Network Service providers, as they 1382 have the vantage point of monitoring all traffic paired with 1383 destinations off the enterprise network. This makes an effective 1384 solution for enterprises that allow "bring-your-own" devices when the 1385 traffic is not encrypted, and for devices outside the desktop 1386 category (such as mobile phones) that are used on corporate networks 1387 nonetheless. 1389 Enterprises may wish to reduce the traffic on their Internet access 1390 facilities by monitoring requests for within-policy content and 1391 caching it. In this case, repeated requests for Internet content 1392 spawned by URLs in e-mail trade newsletters or other sources can be 1393 served within the enterprise network. Gradual deployment of end to 1394 end encryption would tend to reduce the cacheable content over time, 1395 owing to concealment of critical headers and payloads. Many forms of 1396 enterprise performance management may be similarly affected. 1398 5. Security Monitoring for Specific Attack Types 1400 Effective incident response today requires collaboration at Internet 1401 scale. This section will only focus on efforts of collaboration at 1402 Internet scale that are dedicated to specific attack types. They may 1403 require new monitoring and detection techniques in an increasingly 1404 encrypted Internet. As mentioned previously, some service providers 1405 have been interfering with STARTTLS to prevent session encryption to 1406 be able to perform functions they are used to (injecting ads, 1407 monitoring, etc.). By detailing the current monitoring methods used 1408 for attack detection and response, this information can be used to 1409 devise new monitoring methods that will be effective in the changed 1410 Internet via collaboration and innovation. 1412 5.1. Mail Abuse and SPAM 1414 The largest operational effort to prevent mail abuse is through the 1415 Messaging, Malware, Mobile Anti-Abuse Working Group (M3AAWG)[M3AAWG]. 1416 Mail abuse is combatted directly with mail administrators who can 1417 shut down or stop continued mail abuse originating from large scale 1418 providers that participate in using the Abuse Reporting Format (ARF) 1419 agents standardized in the IETF [RFC5965], [RFC6430], [RFC6590], 1420 [RFC6591], [RFC6650], [RFC6651], and [RFC6652]. The ARF agent 1421 directly reports abuse messages to the appropriate service provider 1422 who can take action to stop or mitigate the abuse. Since this 1423 technique uses the actual message, the use of SMTP over TLS between 1424 mail gateways will not affect its usefulness. As mentioned 1425 previously, SMTP over TLS only protects data while in transit and the 1426 messages may be exposed on mail servers or mail gateways if a user- 1427 to-user encryption method is not used. Current user-to-user message 1428 encryption methods on email (S/MIME and PGP) do not encrypt the email 1429 header information used by ARF and the service provider operators in 1430 their abuse mitigation efforts. 1432 5.2. Denial of Service 1434 Response to Denial of Service (DoS) attacks are typically coordinated 1435 by the SP community with a few key vendors who have tools to assist 1436 in the mitigation efforts. Traffic patterns are determined from each 1437 DoS attack to stop or rate limit the traffic flows with patterns 1438 unique to that DoS attack. 1440 Data types used in monitoring traffic for DDoS are described in the 1441 DDoS Open Threat Signaling (DOTS) [DOTS] working group documents in 1442 development. 1444 Data types used in DDoS attacks have been detailed in the IODEF 1445 Guidance draft [I-D.ietf-mile-iodef-guidance], Appendix A.2, with the 1446 help of several members of the service provider community. The 1447 examples provided are intended to help identify the useful data in 1448 detecting and mitigating these attacks independent of the transport 1449 and protocol descriptions in the drafts. 1451 5.3. Phishing 1453 Investigations and response to phishing attacks follow well-known 1454 patterns, requiring access to specific fields in email headers as 1455 well as content from the body of the message. When reporting 1456 phishing attacks, the recipient has access to each field as well as 1457 the body to make content reporting possible, even when end-to-end 1458 encryption is used. The email header information is useful to 1459 identify the mail servers and accounts used to generate or relay the 1460 attack messages in order to take the appropriate actions. The 1461 content of the message often contains an embedded attack that may be 1462 in an infected file or may be a link that results in the download of 1463 malware to the user's system. 1465 Administrators often find it helpful to use header information to 1466 track down similar message in their mail queue or users inboxes to 1467 prevent further infection. Combinations of To:, From:, Subject:, 1468 Received: from header information might be used for this purpose. 1469 Administrators may also search for document attachments of the same 1470 name, size, or containing a file with a matching hash to a known 1471 phishing attack. Administrators might also add URLs contained in 1472 messages to block lists locally or this may also be done by browser 1473 vendors through larger scales efforts like that of the Anti-Phishing 1474 Working Group (APWG). See the Coordinating Attack Response at 1475 Internet Scale (CARIS) workshop Report [RFC8073] for additional 1476 information and pointers to the APWG's efforts on anti- phishing. 1478 A full list of the fields used in phishing attack incident response 1479 can be found in RFC5901. Future plans to increase privacy 1480 protections may limit some of these capabilities if some email header 1481 fields are encrypted, such as To:, From:, and Subject: header fields. 1482 This does not mean that those fields should not be encrypted, only 1483 that we should be aware of how they are currently used. 1485 Some products protect users from phishing by maintaining lists of 1486 known phishing domains (such as misspelled bank names) and blocking 1487 access. This can be done by observing DNS, clear-text HTTP, or SNI 1488 in TLS, in addition to analyzing email. Alternate options to detect 1489 and prevent phishing attacks may be needed. More recent examples of 1490 data exchanged in spear phishing attacks has been detailed in the 1491 IODEF Guidance draft [I-D.ietf-mile-iodef-guidance], Appendix A.3. 1493 5.4. Botnets 1495 Botnet detection and mitigation is complex and may involve hundreds 1496 or thousands of hosts with numerous Command and Control (C&C) 1497 servers. The techniques and data used to monitor and detect each may 1498 vary. Connections to C&C servers are typically encrypted, therefore 1499 a move to an increasingly encrypted Internet may not affect the 1500 detection and sharing methods used. 1502 5.5. Malware 1504 Malware monitoring and detection techniques vary. As mentioned in 1505 the enterprise section, malware monitoring may occur at gateways to 1506 the organization analyzing email and web traffic. These services can 1507 also be provided by service providers, changing the scale and 1508 location of this type of monitoring. Additionally, incident 1509 responders may identify attributes unique to types of malware to help 1510 track down instances by their communication patterns on the Internet 1511 or by alterations to hosts and servers. 1513 Data types used in malware investigations have been summarized in an 1514 example of the IODEF Guidance draft [I-D.ietf-mile-iodef-guidance], 1515 Appendix A.1. 1517 5.6. Spoofed Source IP Address Protection 1519 The IETF has reacted to spoofed source IP address-based attacks, 1520 recommending the use of network ingress filtering [RFC2827] and the 1521 unicast Reverse Path Forwarding (uRPF) mechanism [RFC2504]. But uRPF 1522 suffers from limitations regarding its granularity: a malicious node 1523 can still use a spoofed IP address included inside the prefix 1524 assigned to its link. The Source Address Validation Improvements 1525 (SAVI) mechanisms try to solve this issue. Basically, a SAVI 1526 mechanism is based on the monitoring of a specific address 1527 assignment/management protocol (e.g., SLAAC [RFC4862], SEND 1529 [RFC3971], DHCPv4/v6 [RFC2131][RFC3315]) and, according to this 1530 monitoring, set-up a filtering policy allowing only the IP flows with 1531 a correct source IP address (i.e., any packet with a source IP 1532 address, from a node not owning it, is dropped). The encryption of 1533 parts of the address assignment/management protocols, critical for 1534 SAVI mechanisms, can result in a dysfunction of the SAVI mechanisms. 1536 5.7. Further work 1538 Although incident response work will continue, new methods to prevent 1539 system compromise through security automation and continuous 1540 monitoring [SACM] may provide alternate approaches where system 1541 security is maintained as a preventative measure. 1543 6. Application-based Flow Information Visible to a Network 1545 This section describes specific techniques used in monitoring 1546 applications that may apply to various network types. It also 1547 inlcudes an overview of IPFIX, a flow-based protocol used to export 1548 information about network flows. 1550 6.1. IP Flow Information Export 1552 Many of the accounting, monitoring and measurement tasks described in 1553 this document, especially Section 2.3.2, Section 3.1.1, 1554 Section 4.1.3, Section 4.2, and Section 5.2 use the IPFIX protocol 1555 [RFC7011] for export and storage of the monitored information. IPFIX 1556 evolved from the widely-deployed NetFlow protocol [RFC3954], which 1557 exports information about flows identified by 5-tuple. While NetFlow 1558 was largely concerned with exporting per-flow byte and packet counts 1559 for accounting purposes, IPFIX's extensible information model 1560 [RFC7012] provides a variety of Information Elements (IEs) 1561 [IPFIX-IANA] for representing information above and below the 1562 traditional network layer flow information. Enterprise-specific IEs 1563 allow exporter vendors to define their own non-standard IEs, as well, 1564 and many of these are driven by header and payload inspection at the 1565 metering process. 1567 While the deployment of encryption has no direct effect on the use of 1568 IPFIX, certain defined IEs may become unavailable when the metering 1569 process observing the traffic cannot decrypt formerly cleartext 1570 information For example, HTTPS renders HTTP header analysis 1571 impossible, so IEs derived from the header (e.g. httpContentType, 1572 httpUserAgent) cannot be exported. 1574 The collection of IPFIX data itself, of course, provides a point of 1575 centralization for potentially business- and privacy-critical 1576 information. The IPFIX File Format specification [RFC5655] 1577 recommends encryption for this data at rest, and the IP Flow 1578 Anonymization specification [RFC6235] defines a metadata format for 1579 describing the anonymization functions applied to an IPFIX dataset, 1580 if anonymization is employed for data sharing of IPFIX information 1581 between enterprises or network operators. 1583 6.2. TLS Server Name Indication 1585 When initiating the TLS handshake, the Client may provide an 1586 extension field (server_name) which indicates the server to which it 1587 is attempting a secure connection. TLS SNI was standardized in 2003 1588 to enable servers to present the "correct TLS certificate" to clients 1589 in a deployment of multiple virtual servers hosted by the same server 1590 infrastructure and IP-address. Although this is an optional 1591 extension, it is today supported by all modern browsers, web servers 1592 and developer libraries. Akamai [Nygren] reports that many of their 1593 customer see client TLS SNI usage over 99%. It should be noted that 1594 HTTP/2 introduces the Alt-SVC method for upgrading the connection 1595 from HTTP/1 to either unencrypted or encrypted HTTP/2. If the 1596 initial HTTP/1 request is unencrypted, the destination alternate 1597 service name can be identified before the communication is 1598 potentially upgraded to encrypted HTTP/2 transport. HTTP/2 requires 1599 the TLS implementation to support the Server Name Indication (SNI) 1600 extension (see section 9.2 of [RFC7540]). 1602 This information is only visible if the client is populating the 1603 Server Name Indication extension. This need not be done, but may be 1604 done as per TLS standard and as stated above this has been 1605 implemented by all major browsers. Therefore, even if existing 1606 network filters look out for seeing a Server Name Indication 1607 extension, they may not find one. The SNI Encryption in TLS Through 1608 Tunneling [I-D.ietf-tls-sni-encryption] draft has been adopted by the 1609 TLS working group, which provides soltuions to encrypt SNI. As such, 1610 there will be an option to encrypt SNI in future versions of TLS. 1611 The per-domain nature of SNI may not reveal the specific service or 1612 media type being accessed, especially where the domain is of a 1613 provider offering a range of email, video, Web pages etc. For 1614 example, certain blog or social network feeds may be deemed 'adult 1615 content', but the Server Name Indication will only indicate the 1616 server domain rather than a URL path. 1618 6.3. Application Layer Protocol Negotiation (ALPN) 1620 ALPN is a TLS extension which may be used to indicate the application 1621 protocol within the TLS session. This is likely to be of more value 1622 to the network where it indicates a protocol dedicated to a 1623 particular traffic type (such as video streaming) rather than a 1624 multi-use protocol. ALPN is used as part of HTTP/2 'h2', but will 1625 not indicate the traffic types which may make up streams within an 1626 HTTP/2 multiplex. ALPN will be encrypted in TLS 1.3. 1628 6.4. Content Length, BitRate and Pacing 1630 The content length of encrypted traffic is effectively the same as 1631 the cleartext. Although block ciphers utilise padding, this makes a 1632 negligible difference. Bitrate and pacing are generally application 1633 specific, and do not change much when the content is encrypted. 1634 Multiplexed formats (such as HTTP/2 and QUIC) may however incorporate 1635 several application streams over one connection, which makes the 1636 bitrate/pacing no longer application-specific. 1638 7. Impact on Mobility Network Optimizations and New Services 1640 This section considers the effects of transport level encryption on 1641 existing forms of mobile network optimization techniques, as well as 1642 potential new services. The material in this section assumes 1643 familiarity with mobile network concepts, specifications, and 1644 architectures. Readers who need additional background should start 1645 with the 3GPP's web pages on various topics of interest[Web3GPP], 1646 especially the article on Long Term Evolution (LTE). 3GPP provides a 1647 mapping between their expanding technologies and the different series 1648 of technical specifications [Map3GPP]. 3GPP also has a canonical 1649 specification of their vocabulary, definitions, and acronyms [Vocab], 1650 as does the RFC Editor for abbreviations [RFCEdit]. 1652 7.1. Effect of Encypted ACKs 1654 The stream of TCP ACKs that flow from a receiver of a byte stream 1655 using TCP for reliability, flow-control, and NAT/firewall transversal 1656 is called an ACK stream. The ACKs contain segment numbers that 1657 confirm successful transmission and their RTT, or indicate packet 1658 loss (duplicate ACKs). If this view of progress of stream transfer 1659 is lost, then the mobile network has greatly reduced ability to 1660 monitor transport layer performance. When the ACK stream is 1661 encrypted, it prevents the following mobile network functions from 1662 operating: 1664 a. Measurement of Network Segment (Sector, eNodeB (eNB) etc.) 1665 characterization KPIs (Retransmissions, packet drops, Sector 1666 Utilization Level etc.), estimation of User/Service KQIs at 1667 network edges for circuit emulation (CEM), and mitigation 1668 methods. The active services per user and per sector are not 1669 visible to a server that only services Internet Access Point 1670 Names (APN), and thus could not perform mitigation functions 1671 based on network segment view. 1673 b. Ability to deploy SP-operated proxies that reduce control round- 1674 trip time (RTT) between the TCP transmitter and receiver. The 1675 RTT determines how quickly a user's attempt to cancel a video is 1676 recognized (how quickly the traffic is stopped, thus keeping un- 1677 wanted video packets from entering the radio scheduler queue). 1679 c. Performance-enhancing proxy with low RTT determines the 1680 responsiveness of TCP flow control, and enables faster adaptation 1681 in a delay & capacity varying network due to user mobility. Low 1682 RTT permits use of a smaller send window, which makes the flow 1683 control loop more responsive to changing mobile network 1684 conditions. 1686 7.2. Effect of Encrypted Transport Headers 1688 When the Transport Header is encrypted, it prevents the following 1689 mobile network features from operating: 1691 a. Application-type-aware network edge (middlebox) that could 1692 control pacing, limit simultaneous HD videos, prioritize active 1693 videos against new videos, etc. 1695 b. For Self Organizing Networks (3GPP SON) - intelligent SON 1696 workflows such as content-aware MLB (Mobility Load Balancing) 1698 c. Reduces the benefits IP/DSCP-based transit network delivery 1699 optimizations where a mobile<->transit marking agreement exists; 1700 since multiple applications are multiplexed within the same 1701 5-tuple transport connection, a reasonable assumption is that the 1702 DSCP markings would be withheld from the outer IP header to 1703 further obscure which packets belong to each application flow. 1705 d. Advance notification for dense data usages - If the application 1706 types are visible, transit network element could warn (ahead of 1707 usage) that the requested service consumes user plan limits, and 1708 transmission could be terminated. Without such visibility, the 1709 network might have to continue the operation and stop the 1710 operation at the limit. Partially loaded content wastes 1711 resources and may not be usable by the client, thus increasing 1712 customer complaints. Content publisher will not know user- 1713 service plans, and Network Edge would not know data transfer 1714 lengths before large object is requested. 1716 7.3. Effect of Encryption on New or Emerging Services 1718 This section describes some new/emerging mobile services and how they 1719 might be affected with transport encryption: 1721 1. Content/Application based Prioritization of Over-the-Top (OTT) 1722 services - each application-type or service has different 1723 delay/loss/throughput expectations, and each type of stream will 1724 be unknown to an edge device if encrypted; this impedes dynamic- 1725 QoS adaptation. 1727 2. Rich Communication Services (3GPP-RCS) using different Quality 1728 Class Indicators (QCIs in LTE) - Operators offer different QoS 1729 classes for value-added services. The QCI type is visible in RAN 1730 control plane and invisible in user plane, thus the QCI cannot be 1731 set properly when the application -type is unknown. 1733 3. 1735 7.4. Effect of Encryption on Mobile Network Evolution 1737 The transport header encryption prevents trusted transit proxies. It 1738 may be that the benefits of such proxies could be achieved by end to 1739 end client & server optimizations and distribution using CDNs, plus 1740 the ability to continue connections across different access 1741 technologies (across dynamic user IP addresses). The following 1742 aspects need to be considered in this approach: 1744 1. In a wireless mobile network, the delay and channel capacity per 1745 user and sector varies due to coverage, contention, user 1746 mobility, and scheduling balances fairness, capacity and service 1747 QoE. If most users are at the cell edge, the controller cannot 1748 use more complex QAM, thus reducing total cell capacity; 1749 similarly if a UMTS edge is serving some number of CS-Voice 1750 Calls, the remaining capacity for packet services is reduced. 1752 2. Roamers: Mobile wireless networks service in-bound roamers (Users 1753 of Operator A in a foreign operator Network B) by backhauling 1754 their traffic though Operator B's network to Operator A's Network 1755 and then serving through the P-Gateway (PGW), General GPRS 1756 Support Node (GGSN), Content Distribution Network (CDN) etc., of 1757 Operator A (User's Home Operator). Increasing window sizes to 1758 compensate for the path RTT will have the limitations outlined 1759 earlier for TCP. The outbound roamer scenario has a similar TCP 1760 performance impact. 1762 3. Issues in deploying CDNs in RAN: Decreasing Client-Server control 1763 loop requires deploying CDNs/Cloud functions that terminate 1764 encryption closer to the edge. In Cellular RAN, the user IP 1765 traffic is encapsulated into General Packet Radio Service (GPRS) 1766 Tunneling Protocol-User Plane (GTP-U in UMTS and LTE) tunnels to 1767 handle user mobility; the tunnels terminate in APN/GGSN/PGW that 1768 are in central locations. One user's traffic may flow through 1769 one or more APN's (for example Internet APN, Roaming APN for 1770 Operator X, Video-Service APN, OnDeckAPN etc.). The scope of 1771 operator private IP addresses may be limited to specific APN. 1772 Since CDNs generally operate on user IP flows, deploying them 1773 would require enhancing them with tunnel translation, etc., 1774 tunnel management functions. 1776 4. While CDNs that de-encrypt flows or split-connection proxy 1777 (similar to split-tcp) could be deployed closer to the edges to 1778 reduce control loop RTT, with transport header encryption, such 1779 CDNs perform optimization functions only for partner client 1780 flows; thus content from some Small-Medium Businesses (SMBs) 1781 would not get such CDN benefits. 1783 8. Response to Increased Encryption and Looking Forward 1785 In the best case scenario, engineers and other innovators would work 1786 to solve the problems at hand in new ways rather than prevent the use 1787 of encryption. As stated in [RFC7258], "an appropriate balance 1788 (between network management and PM mitigations) will emerge over time 1789 as real instances of this tension are considered." 1791 There has already been documented cases of service providers 1792 preventing STARTTLS [NoEncrypt] to prevent session encryption 1793 negotiation on some session to inject a super cookie. In order to 1794 effectively deploy encryption and prevent interception, 1795 considerations for protocol design should factor in network 1796 management functions to work toward the balance called out in 1797 RFC7258. 1799 It is well known that national surveillance programs monitor traffic 1800 [JNSLP] as Internet security practitioners monitor for criminal 1801 activities. Governments vary on their balance between monitoring 1802 versus the protection of user privacy, data, and assets. Those that 1803 favor unencrypted access to data ignore the real need to protect 1804 users' identity, financial transactions and intellectual property, 1805 which requires security and encryption to prevent crime. A clear 1806 understanding of technology, encryption, and monitoring goals will 1807 aid in the development of solutions to appropriately balance these 1808 with privacy. As this understanding increases, hopefully the 1809 discussions will improve; this draft is meant to help further the 1810 discussion. 1812 Changes to improve encryption or to deploy OS methods have little 1813 impact on the detection of malicious actors; they already have access 1814 to strong encryption. The current push to increase encryption is 1815 aimed at increasing users' privacy and providing application 1816 integrity. There is already protection in place for purchases, 1817 financial transactions, systems management infrastructure, and 1818 intellectual property although this too can be improved. The 1819 Opportunistic Security (OS) [RFC7435] efforts aim to increase the 1820 costs of monitoring through the use of encryption that can be subject 1821 to active attacks, but make passive monitoring broadly cost 1822 prohibitive. This is meant to restrict monitoring to sessions where 1823 there is reason to have suspicion. 1825 9. Security Considerations 1827 There are no additional security considerations as this is a summary 1828 and does not include a new protocol or functionality. 1830 10. IANA Considerations 1832 This memo makes no requests of IANA. 1834 11. Acknowledgements 1836 Thanks to our reviewers, Natasha Rooney, Kevin Smith, Ashutosh Dutta, 1837 Brandon Williams, Jean-Michel Combes, Nalini Elkins, Paul Barrett, 1838 Badri Subramanyan, Igor Lubashev, Suresh Krishnan, Dave Dolson, 1839 Mohamed Boucadair, Stephen Farrell, Warren Kumari, Alia Atlas, Roman 1840 Danyliw, and Mirja Kuhlewind for their editorial and content 1841 suggestions. Surya K. Kovvali provided material for section 7. 1842 Chris Morrow and Nik Teague provided reviews and updates specific to 1843 the DoS fingerprinting text. Brian Trammell provided the IPFIX text. 1845 12. Informative References 1847 [ACCORD] "Acord BoF IETF95 1848 https://www.ietf.org/proceedings/95/accord.html". 1850 [CAIDA] "CAIDA *Anonymized Internet Traces* 1851 [http://www.caida.org/data/overview/ and 1852 http://www.caida.org/data/passive/ 1853 passive_2016_dataset.xml]". 1855 [DarkMail] 1856 "The Dark Mail Technical Aliance https://darkmail.info/". 1858 [DOTS] https://datatracker.ietf.org/wg/dots/charter/, "DDoS Open 1859 Threat Signaling IETF Working Group". 1861 [EFF] "Electronic Frontier Foundation https://www.eff.org/". 1863 [EFF2014] "EFF Report on STARTTLS Downgrade Attacks 1864 https://www.eff.org/deeplinks/2014/11/ 1865 starttls-downgrade-attacks". 1867 [Enrich] Narseo Vallina-Rodriguez, et al., "Header Enrichment or 1868 ISP Enrichment? Emerging Privacy Threats in Mobile 1869 Networks, Hot Middlebox'15, August 17-21 2015, London, 1870 United Kingdom", 2015. 1872 [I-D.dolson-plus-middlebox-benefits] 1873 Dolson, D., Snellman, J., Boucadair, M., and C. Jacquenet, 1874 "Beneficial Functions of Middleboxes", draft-dolson-plus- 1875 middlebox-benefits-03 (work in progress), March 2017. 1877 [I-D.ietf-ippm-6man-pdm-option] 1878 Elkins, N., Hamilton, R., and m. mackermann@bcbsm.com, 1879 "IPv6 Performance and Diagnostic Metrics (PDM) Destination 1880 Option", draft-ietf-ippm-6man-pdm-option-13 (work in 1881 progress), June 2017. 1883 [I-D.ietf-mile-iodef-guidance] 1884 Kampanakis, P. and M. Suzuki, "Incident Object Description 1885 Exchange Format Usage Guidance", draft-ietf-mile-iodef- 1886 guidance-11 (work in progress), September 2017. 1888 [I-D.ietf-tls-sni-encryption] 1889 Huitema, C. and E. Rescorla, "SNI Encryption in TLS 1890 Through Tunneling", draft-ietf-tls-sni-encryption-00 (work 1891 in progress), August 2017. 1893 [I-D.thomson-http-bc] 1894 Thomson, M., Eriksson, G., and C. Holmberg, "Caching 1895 Secure HTTP Content using Blind Caches", draft-thomson- 1896 http-bc-01 (work in progress), October 2016. 1898 [IPFIX-IANA] 1899 "IP Flow Information Export (IPFIX) Entities 1900 https://www.iana.org/assignments/ipfix/". 1902 [JNSLP] Surveillance, Vol. 8 No. 3, "10 Standards for Oversight 1903 and Transparency of National Intelligence Services 1904 http://jnslp.com/". 1906 [M3AAWG] "Messaging, Malware, Mobile Anti-Abuse Working Group 1907 (M3AAWG) https://www.maawg.org/". 1909 [Map3GPP] http://www.3gpp.org/technologies, "Mapping between 1910 technologies and specifications". 1912 [NoEncrypt] 1913 "ISPs Removing their Customers EMail Encryption 1914 https://www.eff.org/deeplinks/2014/11/ 1915 starttls-downgrade-attacks/". 1917 [Nygren] https://blogs.akamai.com/2017/03/ reaching-toward- 1918 universal-tls-sni.html, "Erik Nygren, personal reference". 1920 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1921 RFC 2131, DOI 10.17487/RFC2131, March 1997, 1922 . 1924 [RFC2504] Guttman, E., Leong, L., and G. Malkin, "Users' Security 1925 Handbook", FYI 34, RFC 2504, DOI 10.17487/RFC2504, 1926 February 1999, . 1928 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1929 Translator (NAT) Terminology and Considerations", 1930 RFC 2663, DOI 10.17487/RFC2663, August 1999, 1931 . 1933 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1934 DOI 10.17487/RFC2775, February 2000, 1935 . 1937 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 1938 DOI 10.17487/RFC2804, May 2000, 1939 . 1941 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1942 Defeating Denial of Service Attacks which employ IP Source 1943 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1944 May 2000, . 1946 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 1947 Shelby, "Performance Enhancing Proxies Intended to 1948 Mitigate Link-Related Degradations", RFC 3135, 1949 DOI 10.17487/RFC3135, June 2001, 1950 . 1952 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1953 C., and M. Carney, "Dynamic Host Configuration Protocol 1954 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1955 2003, . 1957 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1958 Jacobson, "RTP: A Transport Protocol for Real-Time 1959 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1960 July 2003, . 1962 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export 1963 Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004, 1964 . 1966 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 1967 "SEcure Neighbor Discovery (SEND)", RFC 3971, 1968 DOI 10.17487/RFC3971, March 2005, 1969 . 1971 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 1972 Translation (NAT) Behavioral Requirements for Unicast 1973 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 1974 2007, . 1976 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1977 Address Autoconfiguration", RFC 4862, 1978 DOI 10.17487/RFC4862, September 2007, 1979 . 1981 [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. 1982 Wagner, "Specification of the IP Flow Information Export 1983 (IPFIX) File Format", RFC 5655, DOI 10.17487/RFC5655, 1984 October 2009, . 1986 [RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An 1987 Extensible Format for Email Feedback Reports", RFC 5965, 1988 DOI 10.17487/RFC5965, August 2010, 1989 . 1991 [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization 1992 Support", RFC 6235, DOI 10.17487/RFC6235, May 2011, 1993 . 1995 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 1996 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 1997 DOI 10.17487/RFC6269, June 2011, 1998 . 2000 [RFC6430] Li, K. and B. Leiba, "Email Feedback Report Type Value: 2001 not-spam", RFC 6430, DOI 10.17487/RFC6430, November 2011, 2002 . 2004 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 2005 RFC 6455, DOI 10.17487/RFC6455, December 2011, 2006 . 2008 [RFC6590] Falk, J., Ed. and M. Kucherawy, Ed., "Redaction of 2009 Potentially Sensitive Data from Mail Abuse Reports", 2010 RFC 6590, DOI 10.17487/RFC6590, April 2012, 2011 . 2013 [RFC6591] Fontana, H., "Authentication Failure Reporting Using the 2014 Abuse Reporting Format", RFC 6591, DOI 10.17487/RFC6591, 2015 April 2012, . 2017 [RFC6650] Falk, J. and M. Kucherawy, Ed., "Creation and Use of Email 2018 Feedback Reports: An Applicability Statement for the Abuse 2019 Reporting Format (ARF)", RFC 6650, DOI 10.17487/RFC6650, 2020 June 2012, . 2022 [RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail 2023 (DKIM) for Failure Reporting", RFC 6651, 2024 DOI 10.17487/RFC6651, June 2012, 2025 . 2027 [RFC6652] Kitterman, S., "Sender Policy Framework (SPF) 2028 Authentication Failure Reporting Using the Abuse Reporting 2029 Format", RFC 6652, DOI 10.17487/RFC6652, June 2012, 2030 . 2032 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 2033 "Specification of the IP Flow Information Export (IPFIX) 2034 Protocol for the Exchange of Flow Information", STD 77, 2035 RFC 7011, DOI 10.17487/RFC7011, September 2013, 2036 . 2038 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model 2039 for IP Flow Information Export (IPFIX)", RFC 7012, 2040 DOI 10.17487/RFC7012, September 2013, 2041 . 2043 [RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, 2044 "Internet Small Computer System Interface (iSCSI) Protocol 2045 (Consolidated)", RFC 7143, DOI 10.17487/RFC7143, April 2046 2014, . 2048 [RFC7146] Black, D. and P. Koning, "Securing Block Storage Protocols 2049 over IP: RFC 3723 Requirements Update for IPsec v3", 2050 RFC 7146, DOI 10.17487/RFC7146, April 2014, 2051 . 2053 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2054 Protocol (HTTP/1.1): Message Syntax and Routing", 2055 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2056 . 2058 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 2059 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 2060 RFC 7234, DOI 10.17487/RFC7234, June 2014, 2061 . 2063 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 2064 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2065 2014, . 2067 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 2068 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 2069 eXtensible Local Area Network (VXLAN): A Framework for 2070 Overlaying Virtualized Layer 2 Networks over Layer 3 2071 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 2072 . 2074 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 2075 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 2076 December 2014, . 2078 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 2079 Known Attacks on Transport Layer Security (TLS) and 2080 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 2081 February 2015, . 2083 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2084 "Recommendations for Secure Use of Transport Layer 2085 Security (TLS) and Datagram Transport Layer Security 2086 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2087 2015, . 2089 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 2090 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 2091 DOI 10.17487/RFC7540, May 2015, 2092 . 2094 [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication 2095 Method in the Internet Key Exchange Protocol Version 2 2096 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, 2097 . 2099 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 2100 Trammell, B., Huitema, C., and D. Borkmann, 2101 "Confidentiality in the Face of Pervasive Surveillance: A 2102 Threat Model and Problem Statement", RFC 7624, 2103 DOI 10.17487/RFC7624, August 2015, 2104 . 2106 [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. 2107 Nordmark, "Technical Considerations for Internet Service 2108 Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, 2109 March 2016, . 2111 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 2112 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 2113 May 2016, . 2115 [RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., 2116 and M. Stiemerling, Ed., "Real-Time Streaming Protocol 2117 Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 2118 2016, . 2120 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 2121 and P. Hoffman, "Specification for DNS over Transport 2122 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2123 2016, . 2125 [RFC8073] Moriarty, K. and M. Ford, "Coordinating Attack Response at 2126 Internet Scale (CARIS) Workshop Report", RFC 8073, 2127 DOI 10.17487/RFC8073, March 2017, 2128 . 2130 [RFCEdit] https://www.rfc-editor.org/materials/abbrev.expansion.txt, 2131 "RFC Editor Abbreviation List". 2133 [SACM] https://datatracker.ietf.org/wg/sacm/charter/, "Security 2134 Automation and Continuous Monitoring (sacm) IETF Working 2135 Group". 2137 [TS3GPP] "3GPP TS 24.301, "Non-Access-Stratum (NAS) protocol for 2138 Evolved Packet System (EPS); Stage 3"", 2017. 2140 [Vocab] https://portal.3gpp.org/desktopmodules/Specifications/ 2141 SpecificationDetails.aspx?specificationId=558, "3GPP TR 2142 21.905 V13.1.0 (2016-06) Vocabulary for 3GPP 2143 Specifications". 2145 [Web3GPP] http://www.3gpp.org/technologies/95-keywords-acronyms, 2146 "3GPP Web pages on specific topics of interest". 2148 [WebCache] 2149 Xing Xu, et al., "Investigating Transparent Web Proxies in 2150 Cellular Networks, Passive and Active Measurement 2151 Conference (PAM)", 2015. 2153 Authors' Addresses 2155 Kathleen Moriarty 2156 Dell EMC 2157 176 South St 2158 Hopkinton, MA 2159 USA 2161 Phone: +1 2162 Email: Kathleen.Moriarty@dell.com 2164 Al Morton 2165 AT&T Labs 2166 200 Laurel Avenue South 2167 Middletown,, NJ 07748 2168 USA 2170 Phone: +1 732 420 1571 2171 Fax: +1 732 368 1192 2172 Email: acmorton@att.com